Syntax Turtle used for graphs

Can we change the title to not imply that graph identification is part 
of Turtle?  Why not a separate langauge using the same langauge?  A 
document of a graph can be read to get a stream of triples; a compound 
document can't be.

Style wise - there is packing a collection of graphs together (@graph 
emphasises this), writing/reading named grapg data (TriG emphasises 
this) and dump (N-Quads emphasises this).

I hope we have N-quads as standalone spec c.f. Turtle and N-triples.



[[
Assumptions:

Alignment with SPARQL is more important then alignment with N3.

The community does not have a lot of investment in TriG syntax.

The community has some investment in N-Quads.
]]

While the community may not have a *lot* of investment in TriG syntax it 
is out there and used.  I haven't seen or heard any serious faults with 
the general design (yes - there are specific issues).

To switch to another format needs a positive reason to switch even if 
the barrier is quite low.

Considerations:

Should "format X", a syntax based on Turtle used for graphs,

1/ Have Turtle as a subset?
    i.e. is a valid Turtle document a valid format X?

2/ Have N-Quads as a subset?

I used to think (1) was important but I'm not so convinced any more.  A 
document of triples isn't a document about several sets of triples.

Possibilities for TriG-ish:

A/ TriG as is.

B/ TriG as is, but drop the uniqueness of the default graph and naming 
of graphs (does any system actually impose these conditions? why?).

C/ TriG+NQuads
    Allow N-Quads outside {}

D/ TriG+Turtle
   Allow un-enclosed Turtle for the default graph
   (as well as or instead of {})

Note that C also means N-triples because N-triples is a subset of N-Quads.

These are only general directions - whatever we do there are techncial 
issues like treatment of trailing DOTs.


 Andy

Received on Thursday, 29 September 2011 12:26:00 UTC