W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > February 2011

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

From: Nathan <nathan@webr3.org>
Date: Sun, 06 Feb 2011 18:09:26 +0000
Message-ID: <4D4EE3D6.8080406@webr3.org>
To: Shane McCarron <shane@aptest.com>
CC: RDFa Working Group WG <public-rdfa-wg@w3.org>, Manu Sporny <msporny@digitalbazaar.com>
Shane McCarron wrote:
> I appreciate what you are trying to do here, but I don't then understand 
> what you propose to do with @vocab?  In your original mail about this 
> issue you mentioned:
>> <div vocab="http://xmlns.com/foaf/0.1/" about="#me">
>>     My name is <span property="name">John Doe</span> and ..
>> </div> 
> about would still take the datatype SafeCURIEorCURIEorURI.  I think what 
> you are proposing means that "#me" is not a legal CURIE, so this becomes 
> a relative URI reference to the current base.  Which is of course what 
> was intended in the fragment above.

Yes, by changing CURIE so that the colon is always required, "#me" is no 
longer a valid CURIE and thus must be a relative URI reference relative 
to the base.

@vocab is used to set the base for terms, and @datatype @property @rel 
@rev @typeof all use TERMorCURIEorAbsURIs - so @vocab would continue to 
be used as intended.

> Unfortunately, this change would (I 
> think) destroy the main use case for @vocab - referencing CURIES in all 
> situations without a prefix.

I thought the entire purpose of @vocab was to reference TERMs?

CURIEs without a prefix are massively ambiguous because every "term" and 
every "relative URI" are then valid CURIEs, and thus will be processed 
as such. Which begs the question why have this unexpected / ambiguous 
behaviour when both terms and relative URIs are well defined and used 
often without a problem?

> Now, I agree that there seem to be 
> problems with that use case anyway, but I want us to make this change 
> with our eyes all the way open.  If a CURIE cannot take the form 'curie' 
> any longer, we are making a MAJOR change to the definition of a CURIE.
> I don't think this change is incompatible with the use cases in the Role 
> Attribute specification, but it might be incompatible with other CURIE 
> consumers out there.  And that would be bad.
> Also, I would point out that this is a backward compatibility change.  
> RDFa Syntax 1.0 explicitly permits the use of a CURIE with no prefix and 
> no colon, although the RDFa specification itself does not use this feature.

Hmm, from 5.4.1:
5.4.2. Converting a CURIE to a URI

Since a CURIE is merely a means for abbreviating a URI, its value is a 
URI, rather than the abbreviated form. Obtaining a URI from a CURIE 
involves the following steps:

Split the CURIE at the colon to obtain the prefix and the resource.
Using the prefix and the current in-scope mappings, obtain the URI that 
the prefix maps to.
Concatenate the mapped URI with the resource value, to obtain an 
absolute URI.

I can't see that the processing even accounts for CURIEs with no prefix 
and colon, infact it specifically says to split the CURIE at the colon. 
(implying CURIE must contain colon) ?

5.4.3. General Use of CURIEs in Attributes
However, this mark-up would set a subject, since it is not a CURIE, but 
a valid relative URI:
<div about="Albert_Einstein">

also states that "Albert_Einstein" is /not/ a valid CURIE, so I'd 
suggest that we've already broken BC by saying that it now /is/ a valid 
CURIE in rdfa core.

Thus, one may suggest that doing this would fix the currently broken bc. 
(in addition to making RDFa compatible with other RDF serializations)

Will leave you to think about it for a while, and see if I can come up 
with any other ways around it.



> If there is a way to fix this problem in RDFa without breaking faith 
> with the original CURIE definition, I would prefer that.  We could, for 
> example, continue to say there is no 'no prefix' mapping in RDFa.  
> Actually, I think we can do this and everything will be fine.  We 
> specified the 'no prefix' mapping via @vocab, but there is really no 
> need to do that.  The text in section 7.4.3 clearly describes @vocab as 
> something that effects interpretation of 'TERM's - so it has nothing to 
> do with CURIEs.
> Anyway, that would be my preferred way of dealing with this so we don't 
> have a compatibility problem with anyone who might be counting on RDFa 
> supplying the canonical definition of what a CURIE is.
> On 2/5/2011 6:02 PM, Nathan wrote:
>> RDFa Working Group Issue Tracker wrote:
>>> ISSUE-83 (CURIEs must require colon): CURIEs are dangerous when used 
>>> in combination with @vocab and @about [LC Comment - RDFa Core 1.1]
>>> http://www.w3.org/2010/02/rdfa/track/issues/83
>> Note, this also affects @resource - there's more on the issue here:
>>  http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Feb/0032.html
>> I've went through some different approaches and the one thing that 
>> appears to clear up both this issue, and the others mentioned, is to 
>> change the definition of CURIE so that the ':' is always present.
>> Here's some proposed text for the CURIE syntax section:
>> [[
>> The key component of RDF is the URI, but these are usually long and 
>> unwieldy. RDFa therefore supports a mechanism by which URIs can be 
>> abbreviated, called 'compact URIs' or simply, CURIEs.
>> A CURIE is comprised of two components, a prefix and a reference. The 
>> prefix comprises an optional prefix_name and always ends with a single 
>> colon (:).
>> The general syntax of a CURIE can be summarized as follows:
>>   prefix_name  ::=   NCName
>>   prefix       ::=   [ prefix_name ] ':'
>>   reference    ::=   irelative-ref (as defined in [RFC3987])
>>   curie        ::=   prefix reference
>>   safe_curie   ::=   '[' prefix reference ']'
>> Note: The prefix_name consisting of the single char '_' is reserved 
>> for usage with BlankNodes and has special meaning, implementations 
>> MUST NOT allow this prefix to be associated with a URI.
>> In normal evaluation of CURIEs the following context information would 
>> need to be provided:
>> - a set of mappings from prefixes to URIs;
>> - a mapping to use with the default prefix (for example, :p);
>> - a mapping to use with the '_' prefix, which is used to generate 
>> unique identifiers (for example, _:p).
>> In RDFa these values are defined as follows:
>> - the set of mappings from prefixes to URIs is provided by the current 
>> in-scope prefix declarations of the current element during parsing;
>> the mapping to use with the default prefix is the current default 
>> prefix mapping;
>> - the mapping to use with the '_' prefix, is not explicitly stated, 
>> but since it is used to generate bnodes, its implementation needs to 
>> be compatible with the RDF definition and rules in Referencing Blank 
>> Nodes. A document should not define a mapping for the '_' prefix. A 
>> Conforming RDFa Processor must ignore any definition of a mapping for 
>> the '_' prefix.
>> If there is no in-scope mapping for a prefix, then the value is not a 
>> Note that the resulting URI must be a syntactically valid IRI 
>> [RFC3987]. For a more detailed explanation see CURIE and URI 
>> Processing. Also note that while the lexical space of a CURIE is as 
>> defined in curie above, the value space is the set of IRIs.
>> ]]
>> This ensures all prefixes include the ':', removes the "no prefix" 
>> mapping (which @vocab set), ensures that prefixes are defined in the 
>> same way as the other specs, and also means that CURIEs and Terms are 
>> now unambiguous, such that:
>>   ':' valid CURIE
>>   ':me' valid CURIE
>>   'foaf:me' valid CURIE
>>   'name' valid Term.
>> Note that some other minor text changes may need to be made to the 
>> draft if this were accepted, and that the definition of @prefix would 
>> need to change to:
>>  prefix
>>   a white space separated list of prefix-name URI pairs of the form
>>   prefix ' '+ xs:anyURI
>> Which would also allow people to then do:
>>   prefix=": http://example.org/foo#"
>> (which they can't currently)
>> Best,
>> Nathan
Received on Sunday, 6 February 2011 18:10:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:24 UTC