Re: Some comments re: the current Turtle working draft

Hi Gavin, 

Thanks for going through my comments, and making the appropriate changes. 

<snip/>

On 8 Jul 2011, at 21:02, Gavin Carothers wrote:

> On Fri, Jul 8, 2011 at 9:29 AM, Mischa Tuffield
> <mischa.tuffield@garlik.com> wrote:
>> Hi All,
>> I am not sure whether or not this is the right way to go about this, so
>> apologies if I am not doing the right thing™.
>> Firstly some high-level notes on the document :
>> 1. I think we should ditch the URIRef term all together, and we should be
>> consistent with the newer SPARQL specs and we should just use the term IRI.
>> I feel that the term IRI should be defined in Section 2 instead of RDF URI
>> References, and IRI should be used throughout the document. It should be
>> noted that IRIs, IRI Refs, URI, and URI Refs are all used in the current
>> working draft.
> 
> Agreed. Also updated to point at
> http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html#dfn-iri
> the Editors Draft of RDF Concepts.
> 
>> 2. I am not sure whether or not we should expand all acronyms used in the
>> document before using them, an example would be the use of "LALR" or "EBNF",
>> again, this is but a suggestion. I am sure most people implementing parsers
>> will know what it stands for, but for completeness sakes would be nice for
>> it to be expanded upon before use.
> 
> Mmm, I don't think LALR expends nicely. "Look-Ahead LR parser", that's
> not going to help anyone who didn't already know what a LALR was. EBNF
> should be expanded the first time it's mentioned, especially since
> it's W3C EBNF not "normal" EBNF. Extended Backus–Naur Form added as
> title for acronym.
> 
> 
>> 3. In Section 3, I think there should be an "issue" flagged regarding the
>> use of the term "RDF Graph" as this terminology has yet to finalised by the
>> working group as a whole. Whatever terminology decided upon by the Graph's
>> Task Force, which will hopefully be a part of the RDF Concepts document
>> should be mirrored here. I would like to see an issue raised here in section
>> 3.1 of the Turtle Document stating that we are still waiting for
>> clarification to what exact terminology should be used when referring to the
>> ambiguous term that is "RDF Graph".
> 
> How about just linking to the current RDF Concepts ED? Don't really
> want to spew the graph issue all over everything as we're just using
> it by reference and not saying anything new about it.

Agreed, I was just flagging instances of the term "graph". 

> 
> 
>> 
>> And now some more low-level comments :
>> 1. Section 2.1 s/namesand/names and/
> Fixed.
>> 2. Section 2.3 s/xsd:decimal. in/xsd:decimal in/
> Fixed.
>> 3. Section 2.5 : In the first example there are &lt; and &gt; these should
>> probably not be escaped and should be rendered as < and > .
> Fixed, needed to be UNescaped.
>> 4. In Section 4.4 - Grammar: the "BooleanLiteral" is presented to be either
>> "true" or "false" but in the Section C -Changes (Informative): it states
>> that the BooleanLiteral should be implemented to be "case-insensitive", what
>> is correct, does SPARQL go with case insensitive or otherwise ?
> 
> Ah, yes, some language around case sensitivity is needed. @PREFIX for
> example as well?

I guess this is a question for the WG at large. As far as I am aware SPARQL is case insensitive.
> 
>> 5. In Section 4.4 - Grammar: there is a distinct lack of whitespacing here,
>> I am guessing this is based the current grammar is but a first pass. There
>> is an email thread I started on this list which includes feedback from a
>> Stefano D'Angelo (parser implementer), I think we should make sure we
>> address the issues brought forward there [1].
> 
> The EBNF itslef talks slightly about whitespace, see
> http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/turtle.bnf
> however the presentation of the grammar into HTML tables sucks still.
> There may still be whitespace issues in general.
> 
>> 6. Section 5.3 Triple Constructors: This section needs reworking regarding
>> punctuation.
> 
> Ah, yes. TODO.
> 
>> 7. Section 10.2 s/diffrences/differences/
> Yep, still can't spell. Fixed.
>> 8. Section 10.2 I wonder if there should be mention of "subjects as
>> literals" which are allowed in n3 but not in turtle.
> 
> Added.
> 
>> 9. Section 10.3 I can't recall if we were going to make RDF/XML speak IRI
>> instead of URI Refs, but iirc the plan was to not change RDF/XML in that
>> vain, if so it should be noted that there will be some incompatibility
>> issues re: IRIs and URI Refs in the different serialisations.
> 
> Not touching with 10-foot insulated poll.

Sure, but this is something which I feel the WG should address. If RDF/XML is to stay as is wrt to URIRefs, it should be flagged that there will be compatibility issues. 


> 
>> 10. Section 10.4 s/langage/language/
> 
> Fixed.
> 
>> 11. And finally, perhaps there should be some mention of the resolution re:
>> puny-codes and how IRIs should be treated as it, and that the
>> parser/serialiser shouldn't perform any mangling of the IRIs, I guess this
>> could go into the "security considerations" section at the end of the
>> document (but I could be wrong).
> 
> Will think more/harder here. Might be worth mentioning yes.
> 
>> Anyways, I hope this helps, and great work Gavin and Eric in getting this
>> draft together.
> 
> Okay, these changes are on the tip/default branch in hg, have not
> updated the FPWD tagged version. Not really sure on the process here.
> Don't want to change the document too much out from under people
> reviewing it now.

Great stuff, and a big thanks to both you and Eric for getting this up and in the state which it is. 

Happy weekend all, 

Mischa

> 
> --Gavin

___________________________________
Mischa Tuffield PhD
Email: mischa.tuffield@garlik.com
Homepage - http://mmt.me.uk/
+44(0)208 439 8200  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD