W3C home > Mailing lists > Public > public-rdf-wg@w3.org > July 2011

Some comments re: the current Turtle working draft

From: Mischa Tuffield <mischa.tuffield@garlik.com>
Date: Fri, 8 Jul 2011 17:29:07 +0100
Message-Id: <31BE1DBC-6331-4F6E-BA2D-251819573938@garlik.com>
To: RDF WG <public-rdf-wg@w3.org>
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. 

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. 

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

And now some more low-level comments : 

1. Section 2.1 s/namesand/names and/

2. Section 2.3 s/xsd:decimal. in/xsd:decimal in/

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

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 ?

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

6. Section 5.3 Triple Constructors: This section needs reworking regarding punctuation. 

7. Section 10.2 s/diffrences/differences/

8. Section 10.2 I wonder if there should be mention of "subjects as literals" which are allowed in n3 but not in turtle. 

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. 

10. Section 10.4 s/langage/language/ 

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

Anyways, I hope this helps, and great work Gavin and Eric in getting this draft together.

Regards and happy weekend to all! 


[1] http://www.w3.org/mid/CDD6F29B-BC0E-4AE7-B994-8017FC38440C@garlik.com 

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

Received on Friday, 8 July 2011 16:29:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:07 UTC