W3C home > Mailing lists > Public > public-rdf-wg@w3.org > May 2012

GRAPH keyword in Turtle, PREFIX vs @prefix (was Re: Deprecate most "native" RDF serializations)

From: Sandro Hawke <sandro@w3.org>
Date: Sun, 06 May 2012 09:01:39 -0400
To: Gavin Carothers <gavin@carothers.name>
Cc: Manu Sporny <msporny@digitalbazaar.com>, public-rdf-wg@w3.org
Message-ID: <1336309299.27977.377.camel@waldron>
On Sat, 2012-05-05 at 21:08 -0700, Gavin Carothers wrote:
> On Sat, May 5, 2012 at 8:11 PM, Sandro Hawke <sandro@w3.org> wrote:
> > On Sat, 2012-05-05 at 19:50 -0700, Gavin Carothers wrote:
> >> On Sat, May 5, 2012 at 5:54 PM, Sandro Hawke <sandro@w3.org> wrote:
> >> > On Fri, 2012-05-04 at 11:22 -0400, Manu Sporny wrote:
> >> >>
> >> >> """
> >> >> TURTLE Lite would effectively be a subset of TURTLE - N-Quads, or
> >> >> something that would be N-Quads-like (allowing for either "s p o" or
> >> >> "s
> >> >> p o c" statements).
> >> >> """
> >> >>
> >> >> Gavin has asserted that TURTLE already supports N-Triples... now all
> >> >> we
> >> >> need to do is to make N-Quads a subset of TURTLE and we're good for
> >> >> TURTLE Lite.
> >> >
> >> > Since a subset can't include things not in its superset, I guess you're
> >> > saying that Turtle should include the dataset/quad stuff?  Do you have a
> >> > proposed syntax for that?   I don't think adding the label after the
> >> > triple, as in N-Quads, works well in Turtle...
> >> >
> >> >  s p o1 g, o2 g; p2 o3 g.
> >> >
> >> > Nah.   Maybe just like trig, where you have a triple you could have
> >> > label + { graph }.   Or maybe a GRAPH keyword like in SPARQL.  I kind of
> >> > like that.
> >>
> >> Yes, had proposed adding @graph to Turtle. There wasn't support for
> >> doing so. Too much of a change to the language.
> >
> > It might be more accurate to say there was more opposition than support
> > at the time.   There was some support.   Manu might be offering more --
> > and, more to the point, he's making a new argument that might
> > potentially be supported by data.   (He's arguing for simplicity to
> > appeal to potential adopters.  RDF experts are in some cases the worst
> > people to assess that kind of argument.)
> 
> See http://www.w3.org/2011/rdf-wg/wiki/Graphs-In-Turtle
> Email thread http://lists.w3.org/Archives/Public/public-rdf-wg/2011Sep/0170.html
> Minutes http://www.w3.org/2011/rdf-wg/meeting/2011-09-28

Thanks for digging this up.   It's funny how these things come around
again, barely remembered.

One thing I don't see in the @graph discussion is the idea of more
strongly aligning with TURTLE, using the exact SPARQL syntax

   triples
   GRAPH id { triples }
   GRAPH id { triples }

which is appealing to me, especially given Manu pointing out the emperor
has way too many syntaxes.   As a newcomer working with Turtle and
SPARQL, moving between @prefix and PREFIX, and maybe @graph and
GRAPH, ...?    Well, I might be a judgmental newcomer, but I'd probably
look around for some rotten to vegetables to throw at those W3C folks.

> This was close to my initial argument as well 7 months ago. Publishing
> Turtle as a preferred way to publish RDF at the same as publishing a
> new recommendation about named graphs and not being able to use named
> graphs in Turtle seems poor. Also existing implementations today
> already use special comments in Turtle documents to support something
> very like named graphs. 8 months ago figured I'd wait to worry about
> this more till we settled on named graph support in the next 3 months
> ... yeah ... 

Yeah.   :-(   :-(       The pace of progress is here is depressing.

> The nearness of a Turtle LC and the ongoing
> confusion/conversation/whatever on named graphs is reducing my own
> support for trying to support "named graphs" in Turtle.

I understand.    

I wonder if there's any way to thread this needle -- not holding back
Turtle, but not closing the door to this thing that I suspect is going
to seem like a no-brainer, looking back in a couple of years.

Procedurally, we could put it in as At Risk, asking for community
feedback.   This would require some spec changes, talking about
generating quads instead of triples.   I'd be willing to help with that.

>  This likely
> means that if whatever we come up with for named graphs sees wide
> adoption more people will move towards TriG (or whatever Turtle like
> multi graph format) as the default format rather than
> Turtle/N-Triples. Lee Feigenbaum already comments to that effect in
> the thread. If your using multi graphs today, you can't really use
> Turtle.
> 
> >
> > Other than backward compatibility -- which we're breaking on other
> > places already, can you think of any reason we're using @prefix instead
> > of SPARQL's PREFIX?
> 
> At this time we have non compliant PARSERS. All existing Turtle
> documents should still be valid Turtle documents (with possible very
> odd edge cases), if this is not the case then I would consider it a
> bug in the new specification. Saying that old parsers are not
> compliant is very different than saying that old documents are not
> Turtle any more.

Thanks for clarifying that.    So my proposal here is that the turtle
language be defined with both "@prefix" and "prefix", with a note that
"@prefix" is included for backward compatibility and should not be used
in "new" documents.  (I put "new" in quotes, because there will be some
transition period, as people wait for the old turtle parsers to be
replaced.)

    -- Sandro

> >
> >  -- Sandro
> >
> >> >
> >> > Steve has argued very strongly, and Andy just mentioned again, that
> >> > people want to know from the mime type whether they'll be getting
> >> > triples or quads.   Steve sees it as a big security issue -- you don't
> >> > want to load quads in from the Web and have them over-write your
> >> > crawler's internal state metadata or data that was supposedly fetched
> >> > from other address. I'm not convinced, myself, not at all, because I
> >> > think one needs to have an "untrusted" mode of loading quads that
> >> > renames all the graphs.
> >> >
> >> >    -- Sandro
> >> >
> >> >
> >>
> >
> >
> 
Received on Sunday, 6 May 2012 13:01:51 GMT

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