Re: Some RDFa 1.1 Core edge cases that we need to clarify

Yeah.... that's just ugly.  I think we should say the terms are put in 
the list in the order they are declared, and that it is the FIRST 
case-insensitive match that counts.

On 10/25/2010 10:45 AM, Toby Inkster wrote:
> On Mon, 25 Oct 2010 13:15:44 +0100
> Martin McEvoy<>  wrote:
>> The second vocab attribute "2#" would resolve to
>> may be wrong?
> No, that's not how base works. Check this in a browser:
> <html>
>   <base href="">
>   <a href="2#">hover over this link, look at status bar</a>
> </html>
>> I think @vocab should always be an absolute URI (easier to parse an
>> less complicated)
> We already need to support relative links in @about, @resource, @src
> and @href, so supporting relative URIs in @vocab is not too much to ask
> from a parser.
> Actually, re-reading the RDFa Core 1.1 spec, it seems we already allow
> @vocab to be relative (or at least we don't seem to forbid it
> anywhere). If so, then it seems my concerns are unwarranted, and
> vocab="2#" is well-defined.
>> I would Imagine that your second example would be dropped from the
>> graph because RDFa is case sensitive and you haven't included the
>> uppercase values in the profile, AGENT, agent and Agent are not the
>> same in the RDF world.
> Not so: profile terms are checked case-sensitively, falling back to a
> case-insensitive check. The URIs they expand to are of course
> case-sensitive. The case was similar under RDFa 1.0 too: rel="next",
> rel="NEXT" and rel="nExT" each were expanded to the case-sensitive URI
> <>.
> The problem here is that "AGENT" doesn't match either "Agent" or "agent"
> case-sensitively, and when the fallback match is attempted, it matches
> both equally.

Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet:

Received on Monday, 25 October 2010 15:50:45 UTC