Re: [Turtle] starting with http://www.w3.org/2010/01/Turtle/

From: Eric Prud'hommeaux <eric@w3.org>
Subject: Re: [Turtle] starting with http://www.w3.org/2010/01/Turtle/
Date: Thu, 17 Mar 2011 11:45:08 -0500

> * Peter Frederick Patel-Schneider <pfps@research.bell-labs.com> [2011-03-17 11:06-0400]
>> From: Eric Prud'hommeaux <eric@w3.org>
>> Subject: Re: [Turtle] starting with http://www.w3.org/2010/01/Turtle/
>> Date: Thu, 17 Mar 2011 09:43:03 -0500
>> 
>> [...]
>> 
>> >> I'm afraid that this cleanup doesn't address a fundamental problem in
>> >> the document: Section 4.7 says "each GraphNode [...] in the document
>> >> produces an RDF triple" but "GraphNode" does not appear elsewhere in
>> >> the document, and following the link here leads to the SPARQL
>> >> document.
>> 
>> > Indeed, was meant to be "object". I claim to again, but with more
>> > confidence, to have cleaned up.
>> 
>> However the statement
>> 	Each object N in the document produces an RDF triple: curSubject
>> 	curPredicate N . 
>> is not true, as objects can occur in collections.
> 
> ooo, unfortunate.
> 
> Also, 'cause i was reluctant to talk about productions "returning"
> something, the specialized rule [[ If the blankNodePropertyList is
> matching a subject, that subject will be the blank node B. ]] doesn't
> address "( [] )" or "( ( ) )".
> 
> Actually the treatment of blankNodePropertyList and collection can be
> viewed as similar, where beginning the collection production sets a
> new curSubject and curPredicate to B and rdf:first respectively.  I
> re-defined collection in terms of manipulating curSubject and
> curPredicate.
>   http://www.w3.org/2010/01/Turtle/#sec-parsing-triples
> 
> I think this addresses this bug; do you?

Maybe, I would have to go through the entire parsing setup again to make
sure.  See below for further discussion.

>> >> As well, there are no rules for generating blank nodes, except that
>> >> in two places there is the mention of "novel blank node".  Even so,
>> >> novelty of generated blank nodes is inadequate for parsing Turtle.
>> 
>> > I added Map[string -> blank node] bnodeLabels to the state, and this
>> > to the Term Constructors:
>> > [[
>> > BLANK_NODE_LABEL | blank node | The string matching the second
>> > argument, PN_LOCAL, is a key in bnodeLabels. If there is no
>> > corresponding blank node in the map, one is allocated.
>> > ]]
>> > 
>> > Perhaps you have a proposed wording which better captures either the
>> > notion of every BLANK_NODE_LABEL maps to some blank node, or the more
>> > procedural view of allocationg a blank node every time a novel
>> > BLANK_NODE_LABEL is parsed.
>> 
>> I still think that the processing of blank nodes needs to be specified
>> much more fully.  I think that the wording in my initial proposal
>> (http://lists.w3.org/Archives/Public/semantic-web/2008Jan/0128) is
>> adequate.
> 
> Hmm, I had intended the recipe for turtle2rdf inform implementers of
> linear parsers and show that Turtle could be concatonated after every
> '.' (hence the reluctance to rely on recursive definitions). 

I think that this desire hits the crux of both the specific problems
with the document and my unease with its general setup.  

You are providing a recipe for parsing instead of a definition of that
RDF graph corresponds to a particular Turtle document.  Because you want
to use this parsing method you have a much more complex, fragile, and
bug-prone specification.  I think that it would be much better to just
define the relationship straight out.  If you then want to show that you
can parse Turtle documents using a simple parser, that then can be done
in a informative appendix. 

The text
> [[
> 3.1/ For each name used in a nodeID in the document select a fresh blank
>      node and replace any occurence of nodeID of the form _:name with
>      that blank node.  This processes each of the occurences.
> ]]
> denotes an operation over the complete set of BLANK_NODE_LABELs.
> Perhaps this text doesn't definition will map intuitively to the
> get-or-create model of the bnodeLabels map.
> 
> Any others out there have opinions?

My approach is very different from yours, so there is no reason to
expect that it would be useful with use it with a bnode map.

>> >> The organization of 4.5 through 4.8 is unsettled, e.g., there is an
>> >> example in the middle of parsing rules.  peter
>> > 
>> > Re-worked to gather all of the parsing rules, and to place the parsing
>> > example in a separate informative section at the end.
>> >   http://www.w3.org/2010/01/Turtle/was
>> > has the old structure, in case folks want to argue that it's better.
>> 
>> I still think that the organization in Sections 5.1 to 5.4 should be
>> much better.
>> 
>> Another problem that remains is that the productions for anonymous blank
>> nodes are not really short forms or syntactic sugar, as they generate
>> blank nodes that cannot be referenced elsewhere.
> 
> I persume you speak here of section 6, or at least, not section 5. Is
> that so?

Well, wherever the document talks about short forms or syntactic sugar,
which I believe is mostly Section 6 (although one instance of this used
to be right in the middle of the parsing section).

> -ericP

peter

Received on Thursday, 17 March 2011 16:59:52 UTC