W3C home > Mailing lists > Public > public-rdf-comments@w3.org > May 2013

Re: TriG being disjoint from Turtle

From: Eric Prud'hommeaux <eric@w3.org>
Date: Fri, 17 May 2013 07:50:47 -0400
To: Sandro Hawke <sandro@w3.org>
Cc: Jan Wielemaker <J.Wielemaker@vu.nl>, Andy Seaborne <andy.seaborne@epimorphics.com>, public-rdf-comments@w3.org
Message-ID: <20130517115046.GE13487@w3.org>
* Sandro Hawke <sandro@w3.org> [2013-05-17 07:38-0400]
> On 05/17/2013 06:00 AM, Jan Wielemaker wrote:
> >On 05/17/2013 11:49 AM, Andy Seaborne wrote:
> >
> >[this fragment is from Charles Greer, not answered by Andy]
> >
> >>1.  Could the spec be modified to allow TriG to be a superset of
> >>turtle?  Specifically, could the production rules be modified to allow
> >>a set of triples outside of any '{'  '}' to be the same as triples in a
> >>default anonymous graph?  It seems that even now, the rules allow
> >>multiple anonymous graph productions, whose union would be the unnamed
> >>graph.  It would be convenient if we could dispense with these anonymous
> >>curly braces altogether if possible.
> >
> >Having implemented TriG yesterday on top of the Turtle parser, I
> >must say that I was happily surprised that TriG does not allow for
> >triples
> >outside {}.  This means you can detect whether a document is a Turtle
> >or TriG document at the first triple.
> Why do you want to do that?      I'm imagining a world where people
> load data by URL, not necessarily knowing if it's going to have
> named graphs in it.
> I'd think in a load_graph operation, you'd accept TriG as well,
> using the default graph as the output graph.   Maybe have a flag
> about whether to ignore or raise on error if there are some named
> graphs as well.
> And in a load_dataset operations, I'd think you'd accept Turtle as
> well, and just not get any named graphs out of it.

a hearty +1

There is trig out there, so there's a cost to changing it, but that's
a small cost compared to the missed opportunity have having compatible
Received on Friday, 17 May 2013 11:51:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:59:33 UTC