[whatwg] RDFa Features

[Julian Reschke]

Henri Sivonen wrote:
> On Aug 27, 2008, at 16:33, Smylers wrote:
> 
>> So that is one disadvantage of URIs: they are long.  In fact they are so
>> long that people have gone to the bother of inventing additional syntax
>> to avoid having to write them out.
> 
> Moreover, having to look up the URIs is a major pain when writing 
> software that processes namespaced XML. I can remember "xhtml", "xlink" 
> or "svg", but I can't remember the namespace URIs. What random year do 
> they contain? Is there a slash in the end?

I always use copy & paste. So I really don't care a lot.

> The RDF community has minted a lot of namespace URIs over the past 10 
> years. In addition to minting URIs, they have minted canonical prefixes 
> for each one. It would be interesting to analyze how often those 
> canonical prefixes actually collide and how often the local property is 
> within the namespace also collide when the prefix collides.

Make sure that when you do that analysis, you don't forget to check for 
prefixes of less-popular vocabularies, or prefixes used behind closed 
doors (intranets).

> HTML5 isn't really giving language users the choice. It gives the choice 
> to designers of language extensions.
> 
> It seems to me that if the RDF community isn't going to stop using URIs 
> when they mint new property vocabularies, the only way to get a 
> bidirectional generic registryless open-ended mapping between syntax 
> going into text/html resources and RDF easy using URIs for identifying 
> properties.

Yes.

> So the cost of using URIs should be weighed against the benefit of 
> having such a generic bidirectional mapping that is open-ended in the 
> sense that the mapping algorithm doesn't need new out-of-band input from 
> a registry (other than the URI scheme and domain name registries 
> apparently...) when someone mints a new vocabulary.
> 
> . . .
> 
> If we didn't want the mapping to be bidirectional and only wanted it to 
> be unidirectional from HTML identifiers onto URIs, we could specify that 
> you can make a URI from any identifier you find in HTML by concatenating 
> it to a common URI prefix. It doesn't really matter much if we call the 
> prefix http://www.w3.org/1999/xhtml/vocab#, 
> http://n.whatwg.org/rdf-compat# or something else. (To avoid collisions 
> between e.g. rel and class, you could put the attribute name in the URI: 
> http://n.whatwg.org/rdf-compat/rel#keyword http://n.whatwg.org/rdf-compat/class#class-name.) 

That's a possibility, and furthermore exactly the way the Atom link 
relations registry works.

> . . .
> 
> But with a scheme that maps HTML syntax to *some* URIs, can the Power of 
> RDF solve the rest? After all, the Power of RDF already assumes that 
> clients have hard-coded knowledge of URI schemes (at least http) and can 
> consult DNS dynamically. Moreover, the Power of RDF already assumes a 
> dynamically consulted mapping registry (like 
> http://creativecommons.org/ns#) per each vocabulary. We could just say 
> that HTML5 is one big vocabulary, so it can have one mapping registry.

I'm not so sure that what you call "the Power of RDF" actually 
*requires* namespace names to be resolvable.

> The HTML5 draft already specifies a registry for rel values:
> http://wiki.whatwg.org/wiki/RelExtensions

Which seems to be defunct, none of the entries has the state "accepted". 
   I'm also very skeptic about

'For the "Status" section to be changed to "Accepted", the proposed 
keyword must either have been through the Microformats process, and been 
approved by the Microformats community; or must be defined by a W3C 
specification in the Candidate Recommendation or Recommendation state.'

because that requires to either go through the W3C process or the MF 
community. I still believe that a simple IANA registry will work better.

> ...

BR, Julian