- From: Toby A Inkster <tai@g5n.co.uk>
- Date: Wed, 3 Sep 2008 09:52:11 +0100
- To: public-rdf-in-xhtml-tf@w3.org
Manu Sporny wrote: > Collisions between multiple vocabularies that express reserved > words is > easy to deal with - the last reserved word expressed, wins. That's the opposite way round from XMDP. But anyway, say I use: <body prefix="http://microformats.org/vocab# http://vocabs-r-us.org/vocab#"> <div typeof="vcard">...</div> </body> This works fine for a week, maybe a month, and then vocabs-r-us.org updates their vocabulary adding a few new terms which conflict with microformats.org terms; vocabs-r-us.org terms are last, so win; and my hCards stop working. OK, that's unlikely with a fairly unique term like "vcard", but Microformats do make use of some less unique terms like "role", "description", "summary", "title", "class", "category", "contact", "label", "key", "item", "note", "type", "value" and "version". The only way to avoid unintentional collisions when vocabs are updated is to have a sort of "central clearing house" system so that microformats.org, and vocabs-r-us.org, and vocabs4u.net or whatever all co-ordinate their efforts to avoid collisions. But that's precisely the sort of centralised un-web-like system that RDFa (and RDF in general) was designed to avoid. If you only allow a single vocab to be the "anointed one" (i.e. to be unprefixed), without depending on the vocab documents themselves for anything, this makes it very clear to the author which vocab he's using when he uses an unprefixed term; and he can be confident that any changes that are made to the vocabs (which are probably out of his control) will not change the meaning of his page. This idea will also be familiar to people who have used XML namespaces or RDF/XML, where for any given node, there can be at most one namespace which is usable without prefixes. We wouldn't be inventing anything new: just applying an old idea — that of the default namespace — to RDF. > What about when the author wants one set of reserved words to shadow > another set of reserved words? For example, "I want to use Dublin > Core's > 'title', not Microformat's 'title'". They'd just assign a non-blank prefix to Dublin Core, and use that. A similar question could be applied to your proposal - what happens if I want to use Dublin Core's "title", but hAudio's "contributor". What prefix attribute should I use? <body prefix="http://microformats.org/vocab# http://purl.org/dc/terms/"> <!-- This won't work as Dublin Core contributor wins over hAudio --> <body prefix="http://purl.org/dc/terms/ http://microformats.org/vocab#"> <!-- This won't work as Microformats title wins over Dublin Core --> The solution is to only allow one vocab to be used for unprefixed terms: <body prefix="http://microformats.org/vocab# dc=http://purl.org/dc/ terms/"> > Not true, you could create your own vocabulary document [to define > unprefixed terms for Dublin Core] But if I do that, then I'm using: <body prefix="http://example.com/my-own-document.html"> And the prefix attribute no longer reflects the actual CURIE prefix that I intend to use (i.e. http://purl.org/dc/terms/) In my proposal, the author can just write: <div prefix="http://purl.org/dc/terms/"> And then all unprefixed CURIEs within that <div> will be from Dublin Core. Not only is this easier than having to create my own DC-to- CURIE mapping document, it is also easier for other authors who come across my page later — they can easily spot the well known and popular Dublin Core URI in the code, and don't need to follow their nose (though of course, they can) to find out what metadata vocab I'm using. > This is not a safe assumption to make because it automatically voids > all of the XHTML reserved words. This is still an open question with my proposal, but not a show stopper. The question is, if an author has defined a default CURIE prefix, and uses rel="license" or another RDFa reserved word, which "wins": the author-defined default prefix, or xhv? Just how "special" is xhv? I don't have any strong feelings either way. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk>
Received on Wednesday, 3 September 2008 08:53:26 UTC