Re: ISSUE-83 (CURIEs must require colon): CURIEs are dangerous when used in combination with @vocab and @about [LC Comment - RDFa Core 1.1]

On 2/9/2011 8:23 AM, Nathan wrote:
> Okay, we need to note that it's the 'no prefix' mapping, not the 
> 'default prefix' (:) in the below.

Arrgh.  Yes, the 'no prefix' mapping.

>
> 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).

Because the CURIE definition is for use beyond RDFa.  If we did not have 
a 'term' datatype, this sort of mapping would make sense.  I don't know 
if it is used in the wild today, but we can't break people's ability to 
use it.  It was in our last rec, so it needs to be in this one.    As to 
why we don't include the colon...  I actually cannot imagine why the 
other parts of the stack do.  But regardless, I feel like that is an 
implementation issue not a spec issue.  A serialization is surely 
allowed to choose how it stores the components of an abbreviated URI?

>
> 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).

If by 'implementers' in this case you mean RDFa Host Language 
designers...  I suppose we could.  Assuming you agree that those same 
designers are free to specify a default value for @vocab?  Or embed such 
a default into their host language default profile?  (I know we are 
having a separate debate on the wisdom of those - bear with me).  We 
have constituents who have a requirement that they be able to expose 
simple term mappings to their users (rel='something') and have it work.  
Right now you can achieve that with a default profile that contains term 
mappings, with a default profile that defines a default value for 
@vocab, or by fiat - simply declaring that there are terms available for 
that host language.  This may be too many options, but as we contemplate 
simplifying or restricting these options we should remember that we did 
have this basic requirement.


>
> 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.
>>>
>>
>

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

Received on Wednesday, 9 February 2011 14:42:51 UTC