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

Eric, Peter,

Would it be possible to summarize the outcome of this discussion through raising 
issues? We can discuss this at the telecon.

Guus

From: Eric Prud'hommeaux <eric@w3.org>
Date: Thu, 17 Mar 2011 12:45:08 -0400
To: Peter Frederick Patel-Schneider <pfps@research.bell-labs.com>
Cc: sandro@w3.org, public-rdf-wg@w3.org
Message-ID: <20110317164136.GA12732@w3.org>

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


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


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




-- 
Prof. Guus Schreiber
Web & Media, Computer Science
VU University Amsterdam
http://www.cs.vu.nl/~guus

Received on Wednesday, 30 March 2011 15:00:51 UTC