Re: CURIE Processing (Re 2: Updated RDFa Core Editor's Draft available)

On Apr 12, 2010, at 03:49 , Shane McCarron wrote:

> Some responses inline
> 
> Ivan Herman wrote:
>> 
>> 
>> So what is the value of @about="[abc:def]" if there is no prefix definition for 'abc'? I believe our intention was to say that the value is empty, ie, no URI at all. (Maybe I am wrong.) However, my reading of the current text in section 6 is still that this will be interpreted as a URI with value abc:def. Indeed, the whole of section 6 reads like being valid for all curies, regardless whether they are safe or not, and the processing will get to the 'Finally, if there is no in-scope mapping' bullet item, which says that the original value is used as a URI. I see that you have a sentence right after the grammar rules on safe curie-s but, I believe, this is a bit confusing...
>>   
>> 
> 
> 
> Well...  in section 7.4.2 right at the top, we say "If the value is surrounded by square brackets, then the content within the brackets is always evaluated according to the rules in CURIE Syntax Definition - and if that content is not a CURIE, then the content must be ignored."  I agree that this gets inconsistent with section 6 because I was trying to be too clever.  I am pushing this into the section on CURIE processing to see if it hangs together better there.
> 
> Section 6 really shouldn't talk about what an unmapped CURIE prefix means.  

I think that is indeed the main issue. If that moves elsewhere, things fit...

> That's outside of the scope of a CURIE.  My mistake.  I have updated the so that it talks about the syntax with and without a bracket and what that means.  I am still trying to decide if it hangs together.
> 
>> 
>> 
>> @about or @resource. Put it another way, if an attribute's datatype is only URIorCURIE.
>>   
>> 
> 
> 
> Okay - so you would like resource="" to mean the current document?  I don't mind.  I don't think it is specified in version 1.0.

In RDFa 1.0 @about and @resource had the same datatype (URIEorSafeCURIE) so I would expect they had the same behaviour. The same for RDFa 1.1...

[snip]
> 
> 
>> 
>>   
>> 
>>>> - I saw in 6.4.3. that the notion of safe terms was also introduced. I am not sure what that means and why it is useful; terms are used with attributes like @rel and @rev, where we did not have any notion of safe curie before, why having these safe terms now? It is certainly not defined anywhere what it means...
>>>>  
>>>>       
>>>> 
>>> It is only introduced for consistency.  'next' is a TERM, and historically we permitted 'next' and '[next]'.  Since a TERM is just a special form of CURIE, and since we permit CURIEs in brackets, we need to permit TERMs in brackets too.  I don't think they should really be used or anything, but if we did not permit them then it would be inconsistent and a parser might have to do funny things to evaluate a CURIE.
>>>     
>>> 
>> 
>> Hm. Is it correct that in your new formulation 'TERM is just a special form of CURIE'? Term processing is not covered by section 6 (nor should it be), and the fact that we have now TERMorURIorCURIE makes it very separate. Ie, I just do not see any role of the '[term]' syntax whatsoever; can't we simply get rid of it?
>>   
>> 
> 
> Maybe.  I feel like if we are permitting [foo:bar] we should also permit [bar] in the default vocabulary.  If we don't, then people who *want* to use the smart curie syntax to be absolutely unambiguous about their intent will only be able to use it sometimes.

But what does it mean? Safe CURIE-s were used in the old time for, eg, @about. But, as far as I can see, @about="[next]" is still an ignored URI because the CURIE processing does not talk about things that are reference only. Ie, the '[]' syntax does not bring anything whatsoever for @about; it is even misleading because people might expect that this would indeed be used as a term and it is not the case.

On the other hand for @rel/@rev/etc the effect of '[]' is simply nil. @rel='[term'] and @rel='term' behaves exactly the same way, doesn't it?

[snip]

>> Yes, I think it is better but I wonder whether we can go one step further. Section 6 is still both a syntax definition _and_ a set of processing steps to define a mapping from CURIE-s to URIs. I do not have a problem with that, but I may prefer a structure which says:
>> 
>> section 6: mapping URIs
>> section 6.1 CURIE Syntax Definition and processing (current section 6)
>> section 6.2 Processing steps for the URIorCURIE datatype
>> section 6.3 Term syntax and processing steps for the TERMorURIorCURIE
>> 
>> thereby getting these three in one bundle to cover what is logically our ways of creating URIs in RDFa...
>>   
>> 
> 
> I will see if there is something I can do that still addresses the requirement of having a stand alone section that can be used by other specifications (like the Role Attribute).
> 

With all due respect: do we have this requirement? It is certainly not in our charter;-). If other recommendations want to use CURIE-s they can use the specification in RDFa 1.0...

I guess what I want to say is: if the price for this extra requirement is to confuse the readers of the RDFa 1.1 Core spec, then I am not sure we should go along with that.

Ivan

----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf