Re: Turtle comments

* Gavin Carothers <gavin@topquadrant.com> [2011-07-14 22:05-0700]
> 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.

s/term/lexical token/

+1

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

This is a question I hoped to get the WG to answer.
http://dvcs.w3.org/hg/rdf/raw-file/01b18ef38e10/rdf-turtle/index.html#namespaces
takes a conservative stance and says
  [[
  assign a namespace name (IRI_REF) for the prefix (PNAME_NS)
  ]]
which I take to not prohibit overriding or duplicating prefix declarations.

We'd have a simpler language to grok but slightly less flexible if we
prohibited multiple bases and overriding prefixes. By om mission, the
current semantics allow e.g.
  [[
  @base <foo/>
  @base <bar/>
  ]]

to arrive at a Base IRI of <application base/>foo/bar. Note that
http://dvcs.w3.org/hg/rdf/raw-file/01b18ef38e10/rdf-turtle/index.html#handle-IRI_REF
says that "Relative IRI resolution is performed" regardless of whether
the IRI_REF was encountered in a base directive, prefix directive or
RDF term declaration.

I think this is a good model.

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

There are examples we could cop from the SPARQL spec:
  [[
  @prefix dc:       <http://purl.org/dc/elements/1.1/> .
  
  _:a  dc:title         "That Seventies Show"@en .
  _:a  dc:title         "Cette Série des Années Soixante-dix"@fr .
  _:a  dc:title         "Cette Série des Années Septante"@fr-BE .
  _:b  dc:title         "Il Buono, il Bruto, il Cattivo" .
  ]] — http://www.w3.org/TR/rdf-sparql-query/#func-langMatches
and test suite
  [[
  @prefix foaf: <http://xmlns.com/foaf/0.1/> .
  @prefix 食: <http://www.w3.org/2001/sw/DataAccess/tests/data/i18n/kanji.ttl#> .
  _:alice foaf:name "Alice" ;
          食:食べる   食:納豆 .
  _:bob   foaf:name "Bob" ;
          食:食べる   食:海老 .
  ]] — http://www.w3.org/2001/sw/DataAccess/tests/data-r2/i18n/kanji.ttl

Egad, there's an encoding prob in the DAWG test suite at
  http://www.w3.org/2001/sw/DataAccess/tests/r2#kanji-1
!

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

now [[
This section maps a string conforming to the grammar in section 4.4 to
a set of triples by mapping strings matching productions and lexical
tokens to RDF terms or their components (e.g. language tags, lexical
forms of literals).
]]

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

Maybe it's better to e.g. s/"'"/#0027 ?

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

I like it when language specs reveal the discriminators for selecting
or not selecting that language. I feel it saves folks time and confusion.

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

I think RDF/XML deals with URI *references*, which are slightly larger
than IRIs (they allow spaces). (I guess
  <Foo rdf:about="http://a.example/ab cd"/>
is valid RDF/XML syntax for an invalid RDF triple.)

> Thanks again for the feedback!

ditto

> Cheers,
> Gavin
> 

-- 
-ericP

Received on Friday, 15 July 2011 15:58:05 UTC