W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > October 2010

Re: HTML5 Polyglot spec and RDFa

From: Nathan <nathan@webr3.org>
Date: Sat, 09 Oct 2010 17:12:15 +0100
Message-ID: <4CB0945F.8040407@webr3.org>
To: Shane McCarron <shane@aptest.com>
CC: Ivan Herman <ivan@w3.org>, Manu Sporny <msporny@digitalbazaar.com>, RDFa WG <public-rdfa-wg@w3.org>
Shane McCarron wrote:
>  Yes - this was part of the rationale for requiring that 'terms' always 
> be processed in a case insensitive manner.  I appreciate the use case 
> where there might be a hybrid vocabulary defined that brought in terms 
> that differ only in case.  I propose that we include in the RDFa Core 
> spec (in the section on RDFa Profiles) a note that when defining such a 
> profile, the author should either forgo one of the terms OR, more 
> interestingly, change one of the terms so that there is no collision.  
> For example, stealing from Gregg's example the other day:
>> [ rdfa:term "agent"; rdfa:uri 
>> "http://purl.org/NET/c4dm/event.owl#agent" ] .
>> [ rdfa:term "Agent"; rdfa:uri "http://xmlns.com/foaf/0.1/Agent" ] .
> Basically, don't do that.  Instead, do:
> [ rdfa:term "owlAgent"; rdfa:uri 
> "http://purl.org/NET/c4dm/event.owl#agent" ] .
> [ rdfa:term "foafAgent"; rdfa:uri "http://xmlns.com/foaf/0.1/Agent" ] .
> No conflict - viola!

sorry, but immediately this screams of no-benefit to me, that's just a 
non-problematic-CURIE with the colon removed - and that we'd be better 
just to stick to


and viola no conflict at all and issue resolved.

In many ways rdfa:term is only really useful if it's a functionality 
match for microformats and link-relations, case insensitive.

ps: fwiw I can't think of an example where we'd have a class like 
foaf:Agent in the property position of a triple, but this still affects 
things like :holdsAccount :replyTo etc - but again when would an 
ontology ever have `:replyTo` and `:replyto` in it? So maybe this is a 
use case we never really hit with any ambiguity..


Received on Saturday, 9 October 2010 16:13:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:21 UTC