Re: A rose by any other name is just as thorny...

On Mar 29, 2010, at 16:07 , Shane McCarron wrote:

> 
> 
> Ivan Herman wrote:
>>>  
>>> 
>>> Maybe this was said already - I don't remember.  Can't we just say that references to the XHTML vocabulary are mapped to lower case and any other vocabularies are not?  I know it is sort of a hack, but it would mean that we don't need to to any remote retrieval to know if the vocab is case insensitive or not.
>>>     
>>> 
>> 
>> It is a hack. It is even an ugly hack:-) But if the case insensitiveness of the XHTML case is the _only_ reason why we would use a default @profile for (X)HTML, we could do something like that. (We still have the issue of junk triples, though...)
>> 
>> But what this should say is that 'if the @vocab value is '....xhtml', then keywords are case insensitive for @rel/@rev. ie, we would not still not list the keywords in the document, the hack would be @vocab value based, so to say, right? 
>>   
>> 
> Yes, I think so.  Well... it is http://www.w3.org/1999/xhtml/vocab# to be precise.  We just declare that this is the CURIE 'no prefix mapping' at the start of processing, and that any time terms are referenced in this vocabulary with no prefix and no colon they are mapped to lowercase.  

Just to make it sure: this and only this vocabulary, right? The lowercase mapping does not apply to any other vocabularies if used as a default prefix (and the reason for this slight inconsistency with the rest is due to legacy).

Ivan

> And I don't think I care very much whether this is pretty or not.  We have a legacy environment we need to support.  Note that I am NOT proposing that they be mapped to lowercase if they are referenced with a prefix and a colon (e.g., xv:someTermWithCamelCase).  There are mixed case terms in that document now, and I imagine there will be more in the future (from aria).
> 
> In a more recent email Mark points out that we hard-coded the 'reserved words' specifically so that we could avoid this whole problem in RDFa 1.0.  And I think that was a reasonable solution at the time.  But in the brave new world that allows the use of RDFa in HTML5 we need a way to ensure that processors adapt as the collection of terms expands.  Hard-coding these is not a long term solution.  I said above we need to support the legacy environment, and I meant it.  But we need to do that in a way consistent with our forward, dynamic path for 'terms'.
> 
> P.S.  Note my use of the word 'term'.  I am purposely introducing this concept every time I write now.  Mostly because it is a word we have not used before and I am trying to avoid overloading my position with concepts from other positions.  Vocabularies have terms.  In RDFa a 'term' from the 'default vocabulary' is a CURIE with no prefix and no colon - in other words, a CURIE that uses 'no prefix mapping'.  This is expressly permitted by the CURIE definition, although in RDFa 1.0 we specifically said that the 'no prefix mapping' was undefined.  This left the door open to provide for such a mapping in other uses of CURIEs, and also in subsequent versions of RDFa.  And here we are, needing such a concept.  Nice work, Mark!  In my opinion, as long as the definition of what happens in RDFa 1.1 with CURIES that use no prefix mapping is consistent with RDFa 1.0's use of 'reserved words', we are laughing.
> 
> -- 
> Shane P. McCarron                          Phone: +1 763 786-8160 x120
> Managing Director                            Fax: +1 763 786-8180
> ApTest Minnesota                            Inet: 
> shane@aptest.com
> 
> 
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf