- From: Nathan <nathan@webr3.org>
- Date: Wed, 09 Feb 2011 14:23:52 +0000
- To: Shane McCarron <shane@aptest.com>
- CC: Toby Inkster <tai@g5n.co.uk>, RDFa Working Group WG <public-rdfa-wg@w3.org>, sysbot+tracker@w3.org
Okay, we need to note that it's the 'no prefix' mapping, not the 'default prefix' (:) in the below. I'm still unsure just why we'd have a whole set of CURIEs that can't be used, and that when used break RDFa, would be good to know why (likewise why we don't include the colon in a prefix when the rest of the semweb stack does). Should we also have a note in there to say that implementers MUST NOT assign a 'no prefix' mapping (otherwise this "bug" just comes back for them). Best, Nathan Shane McCarron wrote: > +1. This is EXACTLY what I meant. It was an (editorial) error to have > @vocab set the default prefix. I put that text in while we were > experimenting with this feature and it somehow stayed there. > > On 2/9/2011 6:05 AM, Toby Inkster wrote: >> On Sat, 05 Feb 2011 23:27:42 +0000 >> RDFa Working Group Issue Tracker<sysbot+tracker@w3.org> wrote: >> >>> The solution to this problem must not create backward >>> incompatibilities and must allow the usage of @vocab. >> Proposed solution - which is probably the same as what Shane >> suggested... >> >> 1. @vocab no longer sets the default prefix mapping. >> >> 2. @vocab sets some other concept called something like the "wildcard >> profile". >> >> 3. The wildcard profile URI is used as a prefix for any terms which are >> discovered but have not been defined by any of the active profiles. >> >> Imagine the CURIE/Term mapping for about="#me" now: >> >> - it does not match the Term production, so we don't check to >> see if "#me" is a term in any of the defined profiles. >> Further, it is not subject to the wildcard profile. >> >> - it *does* match the CURIE production, however, only with the >> default prefix. The default prefix is undefined by default, >> and people can no longer use @vocab to define it (because >> that's not what @vocab does any more!) >> >> - so it falls back to a relative URI reference. >> >> That should mean that Nathan's example gets parsed correctly. >> >
Received on Wednesday, 9 February 2011 14:25:51 UTC