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

Hey Shane,


On Apr 10, 2010, at 21:24 , Shane McCarron wrote:

> 
> 
> Ivan Herman wrote:
>> Shane,
>> 
>> I have been playing with the implementation on the week end, and I spotted some other issues or questions. Sorry if I missed something again...
>> 
>> - (Probably editorial) Appendix A still includes the datatypes URIorSafeCURIE and URIorSafeCURIEs, though this is not used in the main text any more...
>>  
> 
> Yes.  Actually I ended up restructuring that last night when I introduced a new TERMorURIorCURIE datatype.  The thing just didn't hang together without a datatype.  You can see the work in progress at http://www.w3.org/2010/02/rdfa/sources/rdfa-core/Overview-src.html  I will push a 'real' updated Editor's Draft soon.  In the interim, if you want to try something somewhat cool while viewing the work in progress, press Alt-Ctrl-Shift-S.  This will popup a dialog.  Press diffmark and you can see a snapshot diffmarked from the previous published draft.  The diff marking is a little confused around examples, and I don't know why yet.  It's on my list.
> 

This is cool:-)

B.t.w., I fully understand your issue for TERMorURIorCURIE; I ended up having something similar for the implementation...


>> - That being said, the notion of safe CURIE is specified in section 8, but it is not really said what safe curie means in terms of processing. Isn't it correct that the last bullet item in this section ('Finally, if there is no in-scope mapping for prefix, the original value is used as the URI.') is valid _except_ if the CURIE was a safe CURIE?
>>  
> 
> Well - yes.  But only because I forgot to fix the production for curie.  That production should be
> 
> '[' [ [ prefix ] : ] reference ']' | [ [ prefix ] : ] reference - in other words, the production for curie should incorporate SafeCURIE and CURIE.  We can do this because in our new way of looking at things, ALL curies are safe.
> 
> I have made this change in the work-in-progress version cited above.
> 
> With this change, I believe Section 8 describes how all types of CURIEs are processed.  In this spec, a curie in square brackets is just a special case of CURIE.  So foo:bar matches the production for a CURIE, as does [foo:bar].  In both cases, we end up with a prefix and a reference, and then process according to CURIE rules.

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

> 
>> - Where do we define what the value of @attribute="" is? 
>> For attributes like @about, where the datatype is URIorCURIE, it is fairly o.k., because the evaluation flows through CURIE processing, gets to the last bullet item in section 8, the normal URI processing kicks in, and this leads to base. 
>> For an attribute like @rel, processing starts by term processing and, if that is unsuccessful, flows into URIorCURIE. First of all, 6.4.3 does not say explicitly what happens is term is empty but the logical conclusion is that, unless there is no local default vocabulary, the term is ignored. Ignored means to move on to URIorCURIE which will lead to... base.
>> 
>> But that is in contradiction with, eg, our agreement that @typeof="" produces a simple BNode. Instead, it will produce a bnode whose type is the base URI... The value of @datatype="" will also be different than in RDFa1.0
>> 
>> I am not sure what the most elegant way of solving that is. I think it should be said explicitly that if an attribute can accept a term and a URIorCURIE, then an empty attribute value does not produce any URI at all.
>>  
> 
> I agree with you that we should explicitly indicate that, with the exception of @about, any or our attributes with 

@about or @resource. Put it another way, if an attribute's datatype is only URIorCURIE.

> an empty value MUST NOT be resolved relative to the current base.  I think this is already covered in that we require a URIorCURIE and a TERMorURIorCURIE are evaluated for a CURIE before they are evaluated for a URI.  Remember that reference is an irelative-ref from the IRI spec.  irelative-ref is permitted to be empty.  This means the string '' (and '[]' actually) matches the production for curie, so it will be evaluated according to the rules specified in Section 8.  In other words, an empty attribute value IS a CURIE.  So, what we need to do is in the section on CURIE and URI Processing make it clear that if a value is empty then it is a CURIE, and in RDFa an empty CURIE is ignored except in the case of @about.  I will ensure this is covered.

O.k. 

I think my problem (and maybe that is true for the previous section, too) comes from the fact that the processing of URIorCURIE and processing of CURIE is sort of merged in section 6 with that last bullet item. Operationally, I believe what happens is that if there is no in-scope mapping for a CURIE then there is nothing; so the evaluation of the URIorCURIE datatype means (1) first try to use that as a CURIE (2) if that is unsuccessful, then comes the URI bit. Ie, maybe that bullet item should not be in section 6, and in section 7.4 (using your new numbering) there should be a somewhat more formal step description that makes things clear. I must say that the fact that this section is a mix of examples and of processing step specification makes it a bit difficult read for my mind:-(


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

> 
>> - (Editorial) I would really like to rearrange the text so that section 6.4.3 is closer to section 8. These two sections form some sort of a unit insofar as how attribute values are mapped on URI-s. As an implementer I had to scroll up and down the text to find these two, which is a bit disagreeable...
>>  
> 
> I appreciate that...  One option is to just move section 8 to a (new) section 6, sliding everything else down.  That would flow better and would still keep the CURIE spec as an independent section.  Keeping it independent is very important for our use of CURIEs in other places.  I hade done this in the work-in-progress version.  Let me know if you think it helps.  (Note that this will mess up diff marking I imagine).

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

Cheers

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