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