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

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.

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

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

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

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

> - (Editorial) For the sake of completeness, I think section 6.4.4 should also list @vocab and @profile as accepting only URI-s
>   

Done.
> Ivan
>
>
>
> On Apr 8, 2010, at 19:41 , Shane McCarron wrote:
>
>   
>> As per my action items today, I have updated the RDFa Core spec and pushed a new Editor's Draft.  This is available via our drafts page at http://www.w3.org/2010/02/rdfa/drafts
>>
>> I have also done some work on our publishing toolchain, so we are getting diff marks, postscript, and PDF versions of specs automatically now.
>>
>> Please take a close look at this document, as I expect it is in the nearly final form for FPWD.
>>
>> -- 
>> Shane P. McCarron                          Phone: +1 763 786-8160 x120
>> Managing Director                            Fax: +1 763 786-8180
>> ApTest Minnesota                            Inet: shane@aptest.com
>>
>>
>>
>>     
>
>
> ----
> 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
>
>
>
>
>
>   

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

Received on Saturday, 10 April 2010 19:25:26 UTC