Re: Comments on RDF Spaces document

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.

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 Monday, 28 May 2012 13:01:55 UTC