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

Re: Turtle comments

From: Gavin Carothers <gavin@topquadrant.com>
Date: Thu, 14 Jul 2011 22:05:14 -0700
Message-ID: <CAPqY83xjDcwaFBFgV-3_9N-HR_OGJqY7gfVs-cxc5oFyDbSa8g@mail.gmail.com>
To: Dean Allemang <dallemang@topquadrant.com>
Cc: RDF-WG WG <public-rdf-wg@w3.org>
Thanks Dean for the review! Comments inline.

On Thu, Jul 14, 2011 at 6:39 PM, Dean Allemang
<dallemang@topquadrant.com> wrote:
> 1) "Comments may be given after a #  and continue to the end of the line."

Yes, possible fix:

Comments may be given after a # that is not part of another term and
continue to the end of the line.

> I guess this is true, but not every # introduces a comment.   An example
> follows on the same page:
> Comments may be given after a #  and continue to the end of the line.
> # this is not a complete turtle document
> <http://example.org/path/>
> <http://example.org/path/#fragment>
> </path>
> <#fragment>
> <>
> The first # marks a comment, the other two are parts of URIs.

Perfectly normal to a RDFista, rather odd if your just reading the spec agreed.
> I see that in section 4.2 this is specified fully; perhaps no reason to deal
> with it here.

Seems worth a word or two.

> 2) You can't copy-and-paste the examples.

Huh, that's bad. Browser version? No issues in FF or Chrome here on Linux.

> Is it legal to define a prefix twice?  What does it mean if you do?
> @prefix foo: <http://foo.com/ns#>
> @prefix foo: <http://bar.com/ns#>
> What does foo:bar mean?

Ah, yes. MMm... turtle does handle it but it's very much an anti
pattern. Worth mentioning as an anti pattern that doesn't break
parsing? Is mentioned in section 3 "Subsequent @prefix may re-map the
same local name." ... it doesn't remap the local part does it? It
remaps the prefix.
> 3)  The prefix example is weird.  Shouldn't it be with a # or / at the end?
> @prefix foo: <http://foo.com/ns#>
> When I send what you've got here to the Turtle parser in TBC, I get
> @prefix foo: <http://foo.com/ns>
> foo:bar refers to <http://foo.com/nsbar>
> I think this is correct, but quite weird.  An example ending in # or / would
> be better.

Prefix example is very odd and disagrees with the code mentioned in
the preceding paragraph. Good catch.

> 4) Pursuant to our lunchtime discussion - you should include examples of
> blank nodes that begin with non-alpha
> _:1234

There is one in a note, and it applies not just to blank nodes but any
prefixed name. Perhaps some examples using that new feature.

> Also, if any special characters are allowed in blank node names, include
> examples of those.

It seems likely that some higher unicode characters should be used in
some examples to show that it's easy and possible.

> 5) Example in section 2.5;  don't you mean ( :a :b :c )   (I see spaces
> after the colons)

Yep, typo. (Really should PARSE all the complete turtle document
examples again, I thought I had)

> 6) Why isn't the reference to RFC3986 section 5.5.1 a link?

5.1.1 ... Yeah, that needs to be.

> 7) Give an example of a unicode escape;  you use the notation U+000A in the
> table, but I think \u000A is how it would appear in the escape.

The table if 4.3 is showing escape to code points. I think your referring to:
'\n' 	U+000A

Where '\n' is the escape, and U+000A is the code point.

> 8) Section 5, opening paragraph - there is a typo somewhere where.
> "to a set of triples by mapping this strings matching productions and
> lexical tokens to these RDF terms or their components "
>                                            ^
> Perhaps you mean string's  ?

Yes. That sentence needs help.

> 9) The productions for STRING_LITERAL1 and STRING_LITERAL2 are very
> difficult to read, because of the font.  I see from copy/paste that the
> first one says "'", and the second says '"'.  This is really hard to see in
> the font of this document.  I have adjusted the font of this comment to make
> this clear; in thunderbird's default font, it is almost as bad as in the
> draft.

Other then including a better monospace CSS font not sure of what we
can do here. Can we include an OFL licensed font for monospaced here
if helps?

> 10) Comparing Turtle to N3 is unnecessary, and could cause confusion ("Hey!
> I want that!")  Strike section 10.2.

I do think that there may be too much being said about N3 in the
current Turtle document. I think we need more consensus on that from
the WG. Will have something more concrete in another email.

> Comparisons to SPARQL and RDF/XML are good - these things are  (parts of)
> recommendations.
> A bit more about RDF/XML seems in order - to read this, you would get the
> impression that they are kind of alike (so few differences!) .

Ah, yeah never expanded the RDF/XML section after moving it from the
introduction. How much do we want to say about RDF/XML in an
introduction to Turtle? I admit my personal reaction "Run away run
away before it eats your brain!" is not perhaps the most politic.

>  RDF/XML is an alternative serialization for RDF, but uses a completely
> different grammar from Turtle.  Nevertheless, RDF/XML shares with Turtle an
> capability to refer to resource IRIs.

Ah, and right there we are already in trouble. <pedantic>RDF/XML does
NOT in fact deal with IRIs only URIs </pedantic>, and I think the
current consensus in the WG is to let sleeping XML lie.

Thanks again for the feedback!

Received on Friday, 15 July 2011 05:05:47 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:44 GMT