n-quads & Turtle Levels

On Mon, 2012-05-28 at 14:01 +0100, Andy Seaborne wrote:
> 
> On 28/05/12 13:11, Ivan Herman wrote:
> >> I don't see why. The only spec that has any reason to mention quads
> >> is N-Quads. (Well, JSON-LD may too but it uses a definition that's
> >> different from Sandro's.) Other uses of quads are implementation
> >> strategies and those don't belong into the specs.
> > Correct. My question was whether this WG would define NQuads as well
> > or not. If we do define NQuads (and I do not believe this has been
> > decided pro or con) then we have to properly define Quads and that in
> > relations to any formalism we have on named graphs. If we decide that
> > NQuads are not to be formally defined by this WG, then indeed this
> > section may become unnecessary.
> >
> > Ivan
> >
> 
> Firstly, I think we really ought to define N-Quads; it's in use and 
> extending the N-Triples work to N-Quads is valuable.

I thought so too -- which is why I wrote it up for the rdf-spaces
document, but the discussion with Manu in the last telecon gave me
second thoughts.  

He was arguing how bad it was to be proliferating syntaxes.  I'm very
sensitive to his criticism: in the OWL WG, having OWL 2 QL, EL, and RL,
with the Direct and RDF-Based Semantics, ... it all made so much sense
and seemed so necessary.  Outside the OWL WG?  Not so much.)

So I was thinking we might frame it as:

Turtle Level 0 --- canonical n-triples
Turtle Level 1 --- what we're now calling Turtle
Turtle Level 2 --- something like Trig that's a superset of Turtle

I'm not sure N-Triples as currently defined even needs a name in the new
regime; it could be Level 0.1 I guess.

So, the problem with N-Quads is that it doesn't fit into this scheme.
It's an extension to a subset, forking the neat sequence.  I dunno; just
a thought.   There's a lot to be said for having some trivial quad
syntax.

Another thought about canonical syntaxes: let's specify a single TAB
between terms.  And we'll require any tabs inside strings be escaped in
this canonical form.  That way a TSV parser will correctly put the terms
into the right columns, even for N-Quads, where the graph name goes
after the literal.   (I think I'd put a tab before the trailing dot, so
the last field doesn't end up in the last column's data.)  I believe
this gets us past grep(1) all the way to join(1) and friends (sort, cut,
uniq, ...).   Not that I've used join(1) in the past 20 years....

(FWIW I'm not adamant about quads being in the spec; I think they make
it easier to read and talk about and think about.)

     -- Sandro

> Secondly, it does not mean we have to give quads as first class items in 
> the extended data model.
> 
> N-Quads-the-format can be defined by:
> 
> <s> <p> <o> <g> .
> 
> is just a way of saying triple <s> <p> <o> in space <g>.  That fits 
> nicely into the way Turtle use state variables to explain parsing.
> 
> We do not strictly need to define a quad and then define how it is 
> associated with a graph pair - just do it in one step.
> 
> It's a matter of simplicity - if quads are defined as a first class 
> concept, we have to keep the dataset-based part of the specs in step 
> with the quads-based parts (e.g. the empty graph case) .  c.f. MT and 
> the rules.
> 
> SPARQL Query does not mention quads.
> 
> SPARQL syntax does for update (it's a rule name in the grammar)
> 
> SPARQL Update uses this as explanation for templates in the form
> { ... GRAPH .... } and constructs a dataset out of them.
> 
> The definition of Graph Store doesn't mention quads.
> 
>  Andy
> 
>

Received on Tuesday, 29 May 2012 23:52:15 UTC