- From: Toby Inkster <tai@g5n.co.uk>
- Date: Mon, 25 Oct 2010 16:45:59 +0100
- Cc: Martin McEvoy <martin@weborganics.co.uk>, public-rdfa-wg@w3.org
On Mon, 25 Oct 2010 13:15:44 +0100 Martin McEvoy <martin@weborganics.co.uk> wrote: > The second vocab attribute "2#" would resolve to > http://example.com/base2#which may be wrong? No, that's not how base works. Check this in a browser: <html> <base href="http://example.com/base"> <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 <http://www.w3.org/1999/xhtml/vocab#next>. 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. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk>
Received on Monday, 25 October 2010 15:46:29 UTC