Re: Term case-sensitivity


I think you are right, and the consequence of that decision is indeed that the terms 'agent' and 'Agent' would map to the same values.

To be honest, we never found a really satisfiable solution. The only approach that was around is that the term mapping itself (ie, in the RDF notation, the 

[ rdfa:term "Agent" ; rdfa:onUri "blabla" ]

would get an extra flag (or type) setting the mapping to be case sensitive or not. Even in the current notation this is an extra complication that was not hitherto deemed to be worth the while; let alone the fact that some commenters request a change of the mapping to become something like

<blabla> rdfa:term "Agent" .

which would make this even more complicated, and others oppose the usage of an RDF encoding altogether...

There is also another technical issue that can mud the waters. Imagine a

   <div profile="myprofile">
      <div rel="NEXT" resource="asfasdfa"/>

and, say, myprofile defines a term for 'next' with

   a rdfa:CaseSensitiveMapping ;
   rdfa:term "next" ; 
   rdfa:onUri "blabla" 

It is not absolutely clear in my mind what would be the property generated for @rel. If there was no profile, NEXT==next, it is the relevant XHTML URI for 'next'. But the profile gives another meaning to 'next' but makes it in a case sensitive way. Would NEXT be mapped against the XHTML URI? Probably yes, but I think it is a bit disturbing for users if these things are messed up, don't you think?

Maybe others will remember of other reasons.

So the question is: is that situation really such a show stopper? I am not convinced...



On Oct 8, 2010, at 21:38 , Gregg Kellogg wrote:

> I asked this question back in May [1], but never received an answer. It seems that it has been resolved in [2], but I'm wondering if this is really the intention of the WG. This is currently defined as follows:
> [[
> When an RDFa attribute permits the use of a term, and the value being evaluated matches the production for term above, it is transformed to a URI using the following logic:
> 	 If the term matches an item in the local term mappings list when compared case-insensitively, use the associated URI.
> ]]
> The question regards case-insentive matching of terms to local term mappings. I understand that this is necessary for XHTML Vocabulary items, so that rel="next" is the same as rel ="NEXT", but this also has the consequence of not allowing the creation of terms from other vocabularies, where case sensitivity is essential. For example, I might want to create the following terms:
> [ rdfa:term "agent"; rdfa:uri "" ] .
> [ rdfa:term "Agent"; rdfa:uri "" ] .
> As case-sensitivity of URIs, at least, is important in RDF, you could consider that case-sensitifity of terms would also be important, to allow use cases such as I just described. Certainly, I could get around this by changing the term name, but it makes it easy for someone to accidentally include two different terms that differ only in their case.
> If the intention is to simply allow for case-insesitive compatibility with XHTML Vocabulary terms, then it might be better to place special rules in XHTML+RDFa to treat these specific terms case-insensitiveliy, but have other terms be case-sensitive.
> For the record, I find RDFa vocabularies an important addition to RDFa 1.1, as they make the markup much easier to specify and reduce error. By publishing a single vocabulary document, I can provide documentation to authors of acceptable terms across multiple namespaces, and can stay away from the trend towards re-defining core concepts in a single vocabulary as, for example, Media Annotations has done with ma:title, effectively duplicating dc:title.
> RDFa is the natural language for representing vocabularies, as it allows me to combine the documentation with the specification.
> I would also prefer to use the following to express these terms:
> <> rdfa:term "agent .
> <> rdfa:term "Agent" .
> Gregg
> [1]
> [2]

Ivan Herman, W3C Semantic Web Activity Lead
mobile: +31-641044153
PGP Key:

Received on Saturday, 9 October 2010 08:13:24 UTC