A Triple which is not a Quad

[awwright]

It came to my attention in #124 that we don't really have a way of talking about triples without implying that they're part of a graph. Since #124 is about a slightly different issue (if triple should be aliased to quad), I'd like to separately raise adding a Triple interface.

I think it's important to have separate Triple and Quad instances, because they're not the same thing. A Triple is an axiomatic statement; a Quad additionally signifies a Triple exists in a single graph. But sometimes I want to be able to talk about an RDF statement without implying membership in a graph.

So far we've supposed the DefaultGraph should be sufficient if graph membership is unimportant—just treat it as extraneous information. Perhaps we add the requirement that RDF sources add configuration options on how to generate graph names. But this is a workaround; it adds additional complexity to many components of an ecosystem that could be dispensed with entirely.

For example, suppose I parse two Turtle documents and want to test if they're isomorphic. What does this mean if I'm returned a Dataset, without any interface-level guarantee all the triples will be in a single graph? Confusing Quad for Triple muddies the semantics of RDF, which does not define interpretations/entailment over anything other than a single graph. RDF uniquely identifies statements by (subject,predicate,object), and this triple is the same triple even if present in multiple graphs. But the current implementation considers them to be different quads; so there is no way to test for triple-equality.

Adding a graph property immediately doubles the memory requirements to have a fully indexed RDF store. For applications that don't need a graph property—such as testing isomorphism or entailment—this can be quite significant.

URIs/IRIs are supposed to be universal, and so this adds a requirement that each component agree on how to name graphs & treat graph names. While this shouldn't be a foreign concept to RDF developers, a fourth dimension of IRI to maintain is not insignificant, and in my experience working with RDF, not typically necessary; as a result, we now have to decide how to configure a parser that should be zero-configuration.

Sometimes I want to be able to hold multiple graphs in memory without naming them. What are the semantics of having two Quad stores with different information for the same graphs? It's probably possible to figure out, but it's not immediately apparent to me.

It appears to me that Quad stores and named graphs were invented for applications that can't store graphs without names; for example SPARQL, where the graph name is an alternative to a file on the filesystem. But we don't have this limitation in ECMAScript, and I don't think we should limit the data interface to things describable over SPARQL.

---

For some perspective: Presently I'm working on an application that uses and produces RDFa data. (In the future, it'll do the same with JSON-LD and JSON Hyper-schema.) It uses datasets and quads to identify which RDFa document makes which statements. This is done with a library I've maintained, itself derived from webr3's work.

First, I want the application to manage the namespace for the graphs, as opposed to libraries I call out to. I've tried managing the data a few different ways, and I've simply found it's simpler if I work with Triples when I'm dealing with graphs, and Quads in a single case where I'm aggregating all the information together or querying it.

Second, several of the document operations demands use for Triple, because I have a Graph implementation that provides useful methods that only make sense defined over graphs, things like unions, merges, equality/isomorphism testing, and so on. We're defining an OO interface, and so I would like to define methods that are defined over a graph and not an entire dataset.

Additionally I've been considering adding these methods to Triple, because Triples can be considered a singleton Graph; but a Triple is not a Quad: Since Quad implies two pieces of axiomatic information (both a statement, and its membership to a single graph), and sometimes these methods are only defined over one or the other, not both.

---

I hope this makes a convincing point; I'm happy to answer any questions or consider any feedback. Thanks!

[awwright]

Issues in brief:

1. I should be able to compare two triples for equality regardless of which graphs they're a member of, if any;

2. I should be able to define methods that only make sense over Graphs and Triples (itself either as a triple or as a singleton graph)

[elf-pavlik]

I should be able to compare two triples for equality regardless of which graphs they're a member of, if any

If you have 'triple in some graph', I think you already have a quad there. Any application can implement functions to compare equality only based on s, p, o and to ignore the graph component.
I don't understand how do you imagine to have

two triples for equality regardless of which graphs they're a member of

once again, quad means a triple in a graph (named or default)

RDF uniquely identifies statements by (subject,predicate,object), and this triple is the same triple even if present in multiple graphs.

I understand that sometimes you see need to only consider the s, p, o part of the quad. If I understand you correctly, you would like to have an interface that only represents s, p, o (aka Triple), does it mean that instance of Triple would never equal an instance of Quad even if it has graph set to an instance of DefaultGraph?

In practice, that seems to mean that Turtle parser would emit instances of Triple, while Trig parser would emit instances of Quad, some of them with graph set to an instance of DefaultGraph. If we get them as representation returned from deferencing the same IRI, I find it not aligning very well with https://www.w3.org/TR/rdf11-concepts/#section-dataset-conneg

Sometimes I want to be able to hold multiple graphs in memory without naming them. What are the semantics of having two Quad stores with different information for the same graphs? It's probably possible to figure out, but it's not immediately apparent to me.

You can do it by having two different datasets, each having its distinct default graph. Since blank node labels stay scoped to dataset, one has to stay careful when merging data from two different datasets. If you have two distinct graphs from the same dataset, at least one of them needs to be named graph.

Adding a graph property immediately doubles the memory requirements to have a fully indexed RDF store.

@jacoscaz could you please comment on that based on your experience with node-quadstore

[awwright]

If you have 'triple in some graph', I think you already have a quad there.

A Quad specifically means a Triple is a member of a named graph (potentially including a single default graph with no URI). I scarcely use named graphs.

Imagine I parse two identical Turtle files with a single triple, and a TriG file representing this:

a.ttl

<http://example.com/thing> a <http://example.com/Thing> .

b.ttl

<http://example.com/thing> a <http://example.com/Thing> .

dataset.trig

GRAPH <http://example.org/a.ttl> {
   <http://example.com/thing> a <http://example.com/Thing> .
}
GRAPH <http://example.org/b.ttl> {
   <http://example.com/thing> a <http://example.com/Thing> .
}

In the Turtle case, Quad#equals returns true. In the TriG case, Quad#equals returns false. Why define an equals function at all, if it isn't going to follow RDF semantics for strict identity of statements?

Since there's no concept of a Triple, our current Quad#equals is useless for comparing statements in multiple Datasets (or even between different graphs). The only place I use Quad#equals is in my Dataset implementation, inside individual instances.

---

If we get them as representation returned from deferencing the same IRI, I find it not aligning very well with https://www.w3.org/TR/rdf11-concepts/#section-dataset-conneg

Why should parsers for different media types emit the same thing? Nobody ever complained that JSON parsers can't return a DOM because HTML does.

The paragraph you reference specifically suggests how to convert the two data models between one another for compatibility, an admission they're not the same thing:

If an RDF dataset is returned and the consumer is expecting an RDF graph, the consumer is expected to use the RDF dataset's default graph.

---

You can do it by having two different datasets, each having its distinct default graph.

This is not intuitive. The point of having a Dataset is to manage multiple graphs; if you add "... unless you need multiple unnamed graphs, then use multiple Datasets" now I have to decide what to do in the case two datasets have conflicting information about the same named graph.

[bergos]

@awwright This spec is not about covering everything for every library which does RDF, it's about a common set of interfaces most of us can agree on. That requires to make it open enough for custom features which are still spec compliant and allow custom features without (big) performance drawbacks.

I think what you want to do is possible in a spec compliant way. Maybe it must be implemented in a not so nice way, but it's possible. e.g. you can make a tripleEquals(a, b) function to compare only the SPO part of a quad. Also the spec doesn't forbid to implement a Graph with indexes only for SPO. If you also add graph = new DefaultGraph() to the prototype of Quad, it requires close to zero additional memory.

It looks like there is a consensus that triple will be removed (#124). If there is any chance to convince people of your point, I think code examples would be the best option with a comparison of doing it the spec way vs. your way.

[awwright]

@bergos That's a fair point, but then the question becomes why Quad? I see evidence that Triple is somewhat simpler, more intuitive, has more uses, and so is more likely to see adoption.

Up until this one, every RDF library has exposed Triples, and now that we've had some implementation experience, what evidence do we have so far that Quads produces a more successful API?

And consider Quad#equals, which has little need for standardization (I can't use it to compare the atoms of the statement, it's not necessary for interoperability, the few libraries that need can just implement their own, yes?)

But that's assuming it's a one-or-the-other proposition. We can have both; it's the natural progression of standards to expand in scope as different implementations realize they're implementing the same features.

[bergos]

Parsers for JSON-LD, TriG or N-Quads require having a Quad. I don't know how an option/compromise for Triples handling Quads could look like without being a Quad. The other way round by using DefaultGraph for the graph looks much less than a compromise. Also @timbl said there is always a 4th property for a statement (graph or why in rdflib.js).

[elf-pavlik]

I think handling clearly #117 would get affected by having another option of undefined graph. In practice one would have to use either triples or quads and never mix them to avoid unpredictable behavior.

And consider Quad#equals, which has little need for standardization (I can't use it to compare the atoms of the statement, it's not necessary for interoperability, the few libraries that need can just implement their own, yes?)

I consider to proposing not to include Quad#equals or Term#equals in the spec.

[elf-pavlik]

In #153 we have removed Triple alias and DataFactory.triple() method, at the same time recommending to represent a triple as quad set to an instance of DefaultGraph.

#154 show further motivation for it, Source#match() will query the 'union' (all graphs) with null or undefined passed as graph argument. To query just the 'default graph' one can pass an instance of DefaultGraph as graph argument. Allowing undefined graph on Quad or having Triple which would have graph: undefined wouldn't work well with Source#match since one couldn't query just for those.

[blake-regalia]

@awwright Quad is the more generic class of Triple. I think it would be easy to support your idea of Triple via subclassing Quad in some impl, but getting something like this into the spec is likely much harder. However, I do think it would be less cumbersome to propose (yet another) term type, e.g., 'NoGraph' (kinda like how we currently use 'DefaultGraph'), as opposed to introducing a new class Triple. This would ostensibly allow all the features you describe without any special handling in existing implementations, while also allowing for certain optimizations depending on the method/use-case. I'm sure people here will have qualms with the idea of proposing a new term type but if supporting Triples the way you describe them is a priority this might be the more compatible approach.

[awwright]

@blake-regalia What's the behavior for equals then? Two triples are the same Triple regardless of which graphs they're found in. Do we change the behavior of equals to match this?

What about implementations that rely on using equals to sort and do strict equality of the graph property? Does the function become non-commutative?

[elf-pavlik]

Two triples are the same Triple regardless of which graphs they're found in. Do we change the behavior of equals to match this?

If you 'find it in a graph' then you have a Quad. As I understand @blake-regalia a Triple would have always graph set to suggested NoGraph, as soon as we have graph set to NamedNode or DefaultGraph (or BlankNode in generalized RDF) we have a Quad.

BTW personally I don't see need for suggested Triple and NoGraph and think we might just struggle with a different way of looking at the same thing.

[awwright]

If you 'find it in a graph' then you have a Quad.

A Quad is an assertion that a given Triple exists in a given Graph. It makes sense to talk about two Quads I find and ask if they're the same Triple!

[elf-pavlik]

function equalTriples(some, other) {
  return some.subject.equals(other.subject) &&
         some.predicate.equals(other.predicate) &&
         some.object.equals(other.object)
}