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

Re: Some comments re: the current Turtle working draft

From: Gavin Carothers <gavin@topquadrant.com>
Date: Fri, 8 Jul 2011 13:02:29 -0700
Message-ID: <CAPqY83zEM+K7JgAYv0e-nVdqaPG73skg_205oZmF6=7k5qBHng@mail.gmail.com>
To: Mischa Tuffield <mischa.tuffield@garlik.com>
Cc: RDF WG <public-rdf-wg@w3.org>
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
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.

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

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


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

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

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.

Received on Friday, 8 July 2011 20:03:14 UTC

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