Align on convention for quoted triples.

[jeswr]

Currently there is no convention on how to handle the graph term in quoted triples when implementing the RDF-star CG spec.

In my view there are 3 ways options of how to go about this without introducing any new terms:

1. Make the graph term optional in RDFJS quads, and do not include it in quoted triples (this would be breaking) or allow the graph term to be set to null (also breaking).
2. Agree that all quoted triples should be represented as RDFJS quads with the DefaultGraph set for the graph term
3. Agree that all quoted triples should be represented as RDFJS quads with the graph term the same as that of the top level quad.

To give a concrete example then if we have the following nquads statement

<<:a :b :c>> :p :o :g

it would, in RDFJS, become

under option 1

quad(
   quad(
      namedNode('http://example.org/a'),
      namedNode('http://example.org/b'),
      namedNode('http://example.org/c'),
      null,
   ),
  namedNode('http://example.org/p'),
  namedNode('http://example.org/o'),
  namedNode('http://example.org/g'),
)

under option 2 (and as is currently implemented in this PR)

quad(
   quad(
      namedNode('http://example.org/a'),
      namedNode('http://example.org/b'),
      namedNode('http://example.org/c'),
      DEFAULT_GRAPH,
   ),
  namedNode('http://example.org/p'),
  namedNode('http://example.org/o'),
  namedNode('http://example.org/g'),
)

under option 3

quad(
   quad(
      namedNode('http://example.org/a'),
      namedNode('http://example.org/b'),
      namedNode('http://example.org/c'),
      namedNode('http://example.org/g'),
   ),
  namedNode('http://example.org/p'),
  namedNode('http://example.org/o'),
  namedNode('http://example.org/g'),
)

---

Currently I have a PR open to support the current RDF-star specification in N3.js where I have gone with option 2 (see rdfjs/N3.js#311).

[rubensworks]

I think option 2 is the only correct one, since RDF-star only defines nested triples (= quads in the default graph), but doesn't define triples in named graphs.

Make the graph term optional in RDFJS quads, and do not include it in quoted triples (this would be breaking) or allow the graph term to be set to null (also breaking).

Note that the graph term is already option in the data factory, as it defaults to the default graph.

[tpluscode]

I would totally expect that quoted triples are in the same graph as the quad they are part of. Consider same quad in Trig*

GRAPH :g {
  <<:a :b :c>> :p :o
}

I would be very surprised if :a :b :c was in the default graph and not g

[tpluscode]

Looking at the spec now, I'm confused even more. Trig-star section says

RDF-star describes quoted triples, which are not necessarily present in any named graph, or within the default graph.

I find this sentence grammatically unclear. On the other hand, paragraph 2.1 states:

In RDF 1.1, an asserted triple is an element of the set of triples that make up an RDF graph. RDF-star does not change this except that an RDF-star triple can contain quoted triples. A triple can be used as an asserted triple, a quoted triple, or both, in a given graph.

This seems to corroborate my gut feeling that a quoted triple belongs to the same graph as the quoting triple. null could make sense but it is null so great by its nature

---

Bottom line, it is most certainly not DEFAULT_GRAPH IMO

[rubensworks]

GRAPH :g {
  <<:a :b :c>> :p :o
}

Note that the above does not mean that the triple :a :b :c exists (in :g or somewhere else). It means that the triple :a :b :c is the subject of a quad with predicate :p, object :o, and graph :g. But that triple does not necessarily have to be present in the dataset.

In order to indicate that a triple exists, it must be added to the dataset explicitly, without being quoted (or as well as being quoted). In that case, this triple could be added to a default graph or named graph. This could be done by repeating that triple, or by using the compact annotation syntax of Turtle-star and TriG-star.

---

AFAICS, the RDF-star spec does not say anything about quoting triples coupled with a named graph. Since we define triples as quads in the default graph, it makes most sense to me to use the default graph as a convention for quoted triples (which would require no breaking changes to the spec).

[tpluscode]

Note that the above does not mean that the triple :a :b :c exists

I would not like to make this thread philosophical, but clearly, that triple does exist, doesn't it? :)

Please look at the paragraph 2.1 quoted above. Now, with my emphasis

[...], an asserted triple is an element of the set of triples that make up an RDF graph. [...] A triple can be used as an asserted triple, a quoted triple, or both, in a given graph.

Quoted triples do not just float around like some phantoms. They are part of the very graph where they are quoted. I'd find any other way strange

[rubensworks]

I would not like to make this thread philosophical, but clearly, that triple does exist, doesn't it? :)

No, not at all, that's the whole point of quoted triples in RDF-star :-)
The statement Ruben says "elephants are yellow" does not imply that elephants are yellow.

[...], an asserted triple is an element of the set of triples that make up an RDF graph. [...] A triple can be used as an asserted triple, a quoted triple, or both, in a given graph.
Quoted triples do not just float around like some phantoms. They are part of the very graph where they are quoted. I'd find any other way strange

That part of the spec is referring to asserted triples, which are not the same as quoted triples.

Asserted triples are indeed part of the graph they are mentioned in, but quoted triples are not.

See https://w3c.github.io/rdf-star/cg-spec/editors_draft.html#quoted-triples

[tpluscode]

Fair enough on the philosophical part. That said, I did not mean to say that a quoted triple represents an assertion (truth). By itself it does exist, as in it has been stated...

For the second, let's look one more time:

A triple can be used as an asserted triple, a quoted triple, or both, in a given graph.

"Quoted triple"
"in a given graph"

I can't see how this can be misunderstood ;)

[woutermont]

A triple can be used as an asserted triple, a quoted triple, or both, in a given graph.

To me, this means that a triple can occur in two places within a graph: either directly (as an asserted triple), or indirectly (as a quoted triple nested in another triple). It does not answer the question of which graph a quoted triple belongs to.

That question is i.m.o. trivial: a quoted triple belongs to the graph the triple belongs to; whether it is quoted or not does not matter. Thus the quad :a :b :c :x is a triple belonging to :x, and :a :b :c is a triple belonging to the default graph.

Whether we assert or quote those triples changes nothing about these facts. So << :a :b :c >> :p :o :g is a triple in :g about a triple in the default graph, just as << :a :b :c :x >> :p :o :g is a triple in :g about a triple in :x (written in a logical extension of RDF-Star).

So I would agree with @rubensworks that this is the only correct way to go about handling quoted triples as quads.

[tpluscode]

Cannot agree with this logic.  It is quoted triple, not quad. The form `<< s p o g >>` does not exist.  If we want to agree that a quoted triple does not belong to any graph, ever, then IMO `null` is the only option which ensures that one will be able to distinguish asserted triples from quoted triples 

[jeswr]

I agree with Ruben that (2) is the only semantically correct** and non-breaking solution. It is why I chose to implement it that way in N3.js

So << :a :b :c >> :p :o :g is a triple in :g about a triple in the default graph

I disagree - here << :a :b :c >> is just a term that is part of a triple. In the same way that :a is not a term in the default graph or in :g, if :a :p :o :g is a triple in :g.

Or to go back to Rubens example Ruben says "elephants are yellow". I am not saying that "elephants are yellow" is part of :g or the default graph. I am simply saying making the overall statement Ruben says "elephants are yellow" in :g and the terms within that statement cannot be placed into any graph.

Just as << :a :b :c :x >> :p :o :g is a triple in :g about a triple in :x

I also disagree on this point - RDF-star explicitly disallows quoted quad statements (hence why I am opening this discussion of what we should always do with the graph term). This statement simply does not make sense in the context of the current RDF-star spec and cannot be expressed in any of the syntaxes defined by the spec.

** Note that semantically I think it would be better to set the graph term to null, but for the sake of not breaking the current RDF/JS interface I think the value of the graph term should be set to DEFAULT_GRAPH with the understanding that we ignore the graph term in quoted triples as the quoted triple does not actually belong to a graph in its own right

[woutermont]

@jeswr

So << :a :b :c >> :p :o :g is a triple in :g about a triple in the default graph

I disagree - here << :a :b :c >> is just a term that is part of a triple. In the same way that :a is not a term in the default graph or in :g, if :a :p :o :g is a triple in :g.

That is not what I meant, but you are entirely correct in the obvious way of interpreting the sentence. 🤦‍♂️ What I meant was that it is a triple about some other triple 'as if' the latter were asserted in the default graph. This to accentuate the contrast with a triple about a triple that could be asserted in some other (named) graph.

Just as << :a :b :c :x >> :p :o :g is a triple in :g about a triple in :x

RDF-star explicitly disallows quoted quad statements (hence why I am opening this discussion of what we should always do with the graph term). This statement simply does not make sense in the context of the current RDF-star spec and cannot be expressed in any of the syntaxes defined by the spec.

(also @tpluscode:) That is precisely why I added that that syntax should be interpreted as a logical extension of RDF-Star. 🙃 The reason I introduced this 'non-sensical' notation, is as an intuition-pump: it shows how one could think about the graph term of a quoted triple, in a way that is consistent with both the way we handled (asserted) triple -> quad conversions in the past, and the way we will likely handle (quoted) triple -> quad conversions in the future. That way, according to me, is to interpret all triples (quads without graph), as quads with the default graph.

On a less technical analogue:

• "Elephants are yellow," is a statement without context, which we therefore interpret in the default context (to conclude that the speaker may have drunk too much).
• "Elephants are yellow in my favorite childhood book," is a statement with a named context, which we can therefore interpret and evaluate in that named context (to conclude that the speaker had a pretty normal childhood book).
• "Ruben says 'Elephants are yellow'," is a statement (without context) about a statement without context, which we therefore interpret in the default context for both the asserted and the quoted part (to conclude that Ruben may have drunk too much).
• "Ruben says 'Elephants are yellow in my favorite childhood book'," is a statement (without context) about a statement with a named context, which we therefore interpret and evaluate in the default context for the asserted part and in the named context for the quoted part (to conclude that Ruben had a pretty normal childhood book).

From this we can conclude that interpretation of statements/triples works very intuitively when we use the default context /graph if a named context/graph is lacking, both in cases where the statement is asserted and in cases where it is quoted.

To repeat: in none of the above do I claim that quoted triples have to be triples currently asserted in the default graph! I simply indicate that, given that they are quoted (and thereby already not necessarily asserted), these triples can be seen as having the default graph, since that would be where they are evaluated.

[rubensworks]

I agree with all of the above @jeswr and @woutermont!

[tpluscode]

I agree that null would be somewhat a breaking change. Not only to n3 but the spec in general. I think that maybe this is an unanticipated consequence of RDF-*?

At least with null, however, it is clear that a quoted triple is different from asserted triple. Otherwise, I fear that it will be easy to make that mistake somewhere in code that a quoted triple "escapes" its usage and becomes asserted. But in which graph?

import { Quad, Quad_Graph, DatasetCore } from '@rdfjs/types'

let graph: Quad_Graph
let quotedQuad: Quad = // "elephants are yellow"
let assertedQuad: Quad = $rdf.quad(ex.ruben, ex.says, quotedQuad, graph)

let dataset: DatasetCore

// this is business as usual, as described by paragraph 2.1
dataset.add(assertedQuad)

// this should be illegal
dataset.add(assertedQuad.object)

Do you see the problem? The current spec does not prevent the quoted quad from becoming asserted? Either solution other that graph: null is wrong an may lead to subtle errors, where it becomes asserted in graph graph (option 2) or DEFAULT_GRAPH (option 3).

I conclude that I was initially wrong about choosing option 3 and more leaning towards option 1

I said above that the change is only "somewhat breaking". I'd argue that if current types and implementation do not follow the spec in that regard than a seemingly breaking change qualifies as necessary bug fix and are thus excusable :)

Having looked a little into the current types, I think a mistake to make Quad a Term. Maybe instead we should have brought back Triple? That would properly reflect the RDF0Star spec which as "quoted triples" and not "quoted quads"

diff --git a/node_modules/@rdfjs/types/data-model.d.ts b/node_modules/@rdfjs/types/data-model.d.ts
index 6fff406..5559fe0 100644
--- a/node_modules/@rdfjs/types/data-model.d.ts
+++ b/node_modules/@rdfjs/types/data-model.d.ts
@@ -10,7 +10,7 @@
  * @see DefaultGraph
  * @see BaseQuad
  */
-export type Term = NamedNode | BlankNode | Literal | Variable | DefaultGraph | BaseQuad;
+export type Term = NamedNode | BlankNode | Literal | Variable | DefaultGraph | BaseQuad | Triple;
 
 /**
  * Contains an IRI.
@@ -133,7 +133,7 @@ export interface DefaultGraph {
  * @see BlankNode
  * @see Variable
  */
-export type Quad_Subject = NamedNode | BlankNode | Quad | Variable;
+export type Quad_Subject = NamedNode | BlankNode | Triple | Variable;
 
 /**
  * The predicate, which is a NamedNode or Variable.
@@ -149,7 +149,7 @@ export type Quad_Predicate = NamedNode | Variable;
  * @see BlankNode
  * @see Variable
  */
-export type Quad_Object = NamedNode | Literal | BlankNode | Quad | Variable;
+export type Quad_Object = NamedNode | Literal | BlankNode | Triple | Variable;
 
 /**
  * The named graph, which is a DefaultGraph, NamedNode, BlankNode or Variable.
@@ -233,6 +233,8 @@ export interface Quad extends BaseQuad {
     equals(other: Term | null | undefined): boolean;
 }
 
+export type Triple = Omit<BaseQuad, 'graph'>
+
 /**
  * A factory for instantiating RDF terms and quads.
  */

Option 4: A quoted triple does not have graph at all.

[woutermont]

At least with null, however, it is clear that a quoted triple is different from asserted triple. Otherwise, I fear that it will be easy to make that mistake somewhere in code that a quoted triple "escapes" its usage and becomes asserted.

I get the feeling that you have a fundamentally different view on what a triple is then I do. Semantically, at least, it is impossible to "escape usage": if a triple :a :b :c is quoted then it is a quoted triple, and if it is asserted then it is an asserted triple; if it is both quoted and asserted, it is both a quoted and asserted triple.

Naming variables quotedQuad: Quad or assertedQuad: Quad is misguided, since they are not yet in use. The former one only becomes quoted when used in the quad(ex.s, ex.o, quotedQuad, ex.g) constructor, and the latter one only becomes asserted when added to a dataset with dataset.add(assertedQuad). It should be perfectly possible to first create a triple, and only later decide to use it in one, both, or no way. Using the wrong variable in the wrong place is simply bad programming. Otherwise, we could take it to the extreme with the following, and introduce new types for every variable to prevent it being used elsewhere.

let base: int = 0
let toAdd: int = 3
let toSubstract: int = 2

// this should be illegal
let result: int = base + toSubstract - toAdd

The fact that "quoted quads" are not yet specified does not preclude it from being a valuable addition to this discussion. To the contrary, choosing to treat nested triples just like regular quads (instead of trying to make it behave like some totally different ephemeral object) keeps open the brigh future where we can say stuff like "Ruben says elephants are gray, but Ruben also says elephants are yellow ... in his favorite childhood book." Moreover, we could take all the things that Ruben says, and create a dataset from that, with possibly multiple graphs and a default graph.

[tpluscode]

Yes, thank you for complaining about variable naming and ignoring the merit.

Here's a revised snippet to remove the distraction:

import { Quad, Quad_Graph, DatasetCore } from '@rdfjs/types'

// Ruben says "elephants are Yellow"
let quad: Quad = $rdf.quad(
  ex.ruben, 
  ex.says, 
  $rdf.quad(ex.elephant, ex.color, "Yellow", ex.GraphB) 
  ex.GraphA
)

let dataset: DatasetCore

dataset.add(quad)
dataset.add(quad.object)

To rephrase: the last line is problematic because we don't know what graph the assertedQuad.object should belong.

The winning proposal is DEFAULT_GRAPH. But wait, the quad was created with GraphB as last argument. Finally, the quad is asserted in GraphA (this would be Option 3).

Which one is it then? This will inevitably lead to hard to find errors. My proposed change in types is to force the caller to explicitly assert in the graph they need:

let quad
let { subject, predicate, object } = quad.object

// to assert in GraphC
dataset.add($rdf.quad(subject, predicate, object, ex.GraphC))