RDFa in XHTML Task Force

 

<scribe> ACTION: Ben to author wiki page with charter template for RDFa IG. Manu to provide support where needed. [recorded in http://www.w3.org/2009/05/28-rdfa-minutes.html#action10] [CONTINUES]

<scribe> ACTION: Ben to prepare "how to write RDFa" screencast with fragment parser [recorded in http://www.w3.org/2009/06/11-rdfa-minutes.html#action05] [CONTINUES]

<scribe> ACTION: Mark create base wizard suitable for cloning [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action12] [CONTINUES]

<scribe> ACTION: Mark to send Ben ubiquity related wizard stuff [recorded in http://www.w3.org/2008/11/20-rdfa-minutes.html#action11] [CONTINUES]

<scribe> ACTION: Mark write foaf examples for wiki [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action13] [CONTINUES]

<scribe> ACTION: Ralph find the statement on test suite copyright [recorded in http://www.w3.org/2009/06/04-rdfa-minutes.html#action13] [DONE]

<scribe> ACTION: Ralph make a request for an RDFa issue tracker instance [recorded in http://www.w3.org/2009/05/28-rdfa-minutes.html#action11] [CONTINUES]

<scribe> ACTION: Ralph or Steven fix the .htaccess for the XHTML namespace [recorded in http://www.w3.org/2009/01/08-rdfa-minutes.html#action01].org/2009/01/08-rdfa-minutes.html#action01] [CONTINUES]

<scribe> ACTION: Ralph think about RSS+RDFa [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action15]008/09/11-rdfa-minutes.html#action15] [CONTINUES]

Manu: Any changes to agenda?

<Steven> Agenda: http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Jul/0032

markbirbeck: I'm concerned about safe CURIEs in @rel
... Could we move #4 up to the first item?
... It might help to address major objections - it's been hanging on for some time.
... Simple solution is to do safe CURIEs in @rel.

Manu: Moving agenda item 4 up to 1

Use of regular CURIEs in @rel

ShaneM: I don't think we can do safe CURIEs in @rel

markbirbeck: I think this is a broader problem
... I think the whole issue is @rel="URL" is happening in Atom and other standards.
... We should recognize that this is a broader thing that people take issue with.
... We should come up with a major clarification, or we should try to come up with a solution.
... Just trying to set the context for this discussion.

ShaneM: I agree that that is the context.
... I think it's good that people are using 'relations' with URIs.
... I don't think that Atom has anything to do with HTML.
... different protocol, different markup language.
... If we were to change the syntax of @rel now, it would break every page that is using RDFa already.
... It is an incompatible, dramatic, drastic change.

Steven: I think you're right - it was a decision we made long ago.
... I don't think it's a good idea.

markbirbeck: The argument when we made the decision was what happens when we use legacy values.
... It didn't occur to us at the time that it didn't preclude using safe CURIEs.

markbirbeck: So we could've done it, but we didn't do it. It's a shame, really.
... There is another use case - the only way to get a URL into @rel is to use a CURIE.
... It's the xmlns:http hack...
... It's a bit of a pain for some scenarios.
... I can see why people don't like it - it requires prefix mappings to be there.

Steven: Since you have URLs in some places and CURIEs in some places
... A typical syntax for that is to use <> when you use a URI.
... This wouldn't work now, ofcourse.

markbirbeck: The ideal scenario would be that every attribute could carry a CURIE, URI or token.
... The use of XML namespaces in RDF makes the assumption that you have this concept of a prefix... it's baggage.

<Steven> well, it would be difficult in XML/HTML, since < and > have special meaning

<Steven> {http://www.w3.org}

markbirbeck: Maybe we should explore Shane's point about it breaking something.

ShaneM: Look at Google's implementation = v:foo

<Steven> �http://www.w3.org�

markbirbeck: One way to do it would be to signal a switch - to specify which version of RDFa you are using.

<Steven> |http://www.w3.org|

ShaneM: We didn't require any sort of announcement mechanism.
... @profile and @version come to mind.

markbirbeck: There is nothing to stop defining RDFa in X as different in RDFa in Y.

Steven: It would be nice if we had a unified syntax.
... Can't we find a good way of marking a URI when a CURIE is expected?

Ralph: If there are reasons for RDFa to be different because of host language matters, that's one thing.
... I don't have to want to know that there are different versions of RDFa.

markbirbeck: The google example will have a defined namespace.
... That namespace will be defined.

Steven: Every CURIE or token begins with a letter.
... We just have to choose a non-letter.

ShaneM: I disagree.
... It's as simple as saying that if a namespace is not defined, then it is a URI.

markbirbeck: Yes.
... We probably discussed this ages ago - but not that it is so pressing, we should revisit this.
... Do we get any false positives?
... Do you falsely get a URL when somebody forgot to add the namespace? Yes... but tough.
... We should also allow square brackets.

ShaneM: What happens when somebody re-defines "urn:"?

Manu: Tough - they made a concious decision to do so.

markbirbeck: I agree.
... @rel="URL" is a handy thing.
... It addresses the cut/paste problem.
... If you're generating a snippet, you might as well just use URLs.
... I think what happened with square brackets was that we did rel="[next]" and people didn't like that.
... We never went down the road of only use rel="[prefix:suffix]"
... "if the prefix is undefined, it's a URI" would work everywhere.

ShaneM: The TAG has made it very clear that the issue with CURIEs is that they look like URIs.
... Now we're going down a road that may upset the TAG - all of a sudden it's difficult to differentiate between CURIEs and URIs.

Steven: We had no choice - we didn't invent this.
... we extended an existing notation.
... It looks just like QNames.

ShaneM: The TAG has a dislike for QNames in attributes.

Ralph: That's correct, that practice was not encouraged in attribute _values_.

markbirbeck: The presence of a namespace prefix mapping makes it clear what you mean.
... You can diferentiate them when the statement is in context.

Manu: Do we want to pass this approach by the list?

ShaneM: It doesn't even change the RDFa in XHTML spec.

markbirbeck: It's backwards compatible.

ShaneM: The RDFa in XHTML spec would have to change a bit.

markbirbeck: We may want to write an RDFa in HTML spec, that states this new rule.

Manu: Mark, can you write a proposal and send it to the RDFa mailing list?

Processing of xmlns:* in non-XML languages

Manu: Mark can you start by talking about the @token proposal?

markbirbeck: Yes - the @token is about bridging to the simplicity of Microformats.
... We may want to also help people create tokens on the fly to represent full URIs in a Microformats-style way.
... This @token spec would allow authors to define tokens, regardless of the host language.
... Instead of doing @prefix - you'd use @token.
... You could use 'dc' on it's own, without having to use a reference or suffix.
... The criticism is "How do you follow your nose?"
... Do you really need to make a request to find out what the tokens are? Via @profile?
... One answer is that for many of the standard use cases, you wouldn't have to go off to make the retrieval.
... Ben's criticism wonders whether the mapping should be done at another level.
... He's not here to make that case, so we may not be able to get much further on this.

Manu: Shane, elaborate on criticism of @token proposal.

ShaneM: Not concerned about multiple requests.
... We make MANY connections when loading a web page
... We also cache stuff - so it's not an issue... it's how it should work.
... Manu and I put together a proposal that is similar to this called RDFa Profiles.
... We started this discussion thinkinking that it is just a mental model - now we know that it's not.
... The problem we're trying to solve is to see if there is a way for authors to extend the list of reserved words.
... The proposal that Manu and I had was that the proposal needed an external document.
... The external document was turned for RDF automatically.
... My criticism of the @token proposal is that it's not clear how we get from embedded declaration to the RDF declaration. How do you follow your nose with @token?
... I think that's Ben's concern as well.

markbirbeck: Just to understand... do you mean "What would the external document look like?"
... Or how to you get from @token to RDF?
... All I'm proposing is a small change to the CURIE spec.

ShaneM: Yes, I get that.

markbirbeck: So the minor change is that we can expand prefixes for CURIEs and stop there.
... The external document should itself be HTML+RDFa... as long as it maps to a set of triples.
... Somehow we get a list of mappings from that external document.
... The first approach is we just have @token and that's how the mapping is created.
... Not saying anything about the syntax in the @token attribute.
... Just saying that if one of the prefixes match in a CURIE via a @token, it should be used.

ShaneM: If what we're talking about is having dynamically extensible reserved words... we should divorce the conversation from new attributes.
... If that is a fine thing to do, then so be it.
... We should make sure that the endpoint should be HTML+RDFa.
... The thing that is referenced should be an HTML+RDFa document.

Ralph: The whole semantic web stack should be dereference-able in some RDF form.

ShaneM: In the case of Microformats, we talked about how to extend the XMDP format that they use with RDFa to give something that looks almost exactly like Microformats.

<markbirbeck> We already support this:

<markbirbeck> @xmlns:author="http://example.org/author"

<markbirbeck> @rel="author:"

markbirbeck: I think we should move away from using prefix:suffix to something that could expand without the colon.
... so why not this: xmlns:author="http://example.org/author" and then rel="author"
... It makes it very easy to do cut/paste snippets.
... This is the "let's make it easier" approach.
... So, how do we define these things?
... We all agree that we need to create @prefix, so why not @token.
... If we are going to add a new attribute, why not add this feature as well?

ShaneM: This is a fine approach.
... Ben's position is to say that xmlns: works, so we don't need to change anything.

Ralph: There will be a discussion on distributed extensibility in HTML and that will probably include a discussion on xmlns:*

<markbirbeck> "RDFa means extensibility (which is why some people will never support it)": http://webbackplane.com/mark-birbeck/blog/2009/01/rdfa-means-extensibility

Ralph: xmlns:* isn't necessarily dead, but I'm ok with referring to it by a different name to aid the discussion.

ShaneM: So, we could write a new CURIE spec since there isn't a current CURIE spec.
... if we change anything like this, we're going to have to rev the spec.
... If we are going to rev the spec, it would be a good change.

markbirbeck: If we add @prefix, why not call it @token - that's where I was coming from.

<ShaneM> there should be incremental improvement of RDFa by updating the spec.

markbirbeck: People still have to decide whether to use RDFa or Microformats.
... We should consider that (making RDFa easier to use) when revving the spec.

Case sensitivity in xmlns:

<ShaneM> errata is here http://www.w3.org/MarkUp/2008/REC-rdfa-syntax-20081014-errata/

Manu: Document authors should use lower-case xmlns:prefix-names to be compatible across all processors.
Ralph:+1
Steven: +1

markbirbeck: Is it not possible to rev the spec and include HTML?

ShaneM: No, absolutely not.
... not chartered to do so.

Ralph: That is correct.

<markbirbeck> http://www.semanticuniverse.com/premium/audio/semtech-2009-audio-semantics-google-rfda-microformats-and-more.html

<markbirbeck> That's the SemTech talk from Google, for those who couldn't be there.