Quads in dotNetRDF

[langsamu]

We don't really have quads in dotNetRDF. I think it's worth discussing whether we should introduce them.

Of course we do support several quad serialization formats as well as SPARQL and JSON-LD.
But the way we do it is basically a Triple + an IRI node (for the g element of the quad).

I.e. there is no VDS.RDF.Quad in dotNetRDF.Core

This became apparent to me while working on #608. I would have rather introduced support for Quad Pattern Fragments, but there was no mechanism that lent itself to a simple, initial implementation like the one I'd chosen there for triples.

#615 is also relevant. Of course canonicalization could be implemented (I think) without a native quad interface, but that issue also points to a concept widely used by the community that is missing from dotNetRDF.

Personally, I prefer to rely on 'plain' statements for modelling. I think quads are 'cheating'. But who cares?
Look at RDF/JS, look at Commons RDF, look at Jena, look at RDF4J.

I don't have suggestions at the moment for how we should do this.

[kal]

I think adding a Quad type to the core library would make sense. I would imagine that we would add:

• a Quads property of type IEnumerable to IGraph and ITripleStore (and possibly deprecate the Triples propery on ITripleStore)
• Assert and Retract methods on ITripleStore that take either a Quad or an IEnumerable<Quad> argument to add/remove quads
• a HandleQuad overload on IRdfHandler that receives a Quad (and possibly deprecate the existing HandleQuad overload that has Triple and IRefNode as its arguments)
• A variety of quad retrieval methods on ITripleStore that are equivalent to the indexed triple lookup methods on IGraph e.g. GetQuadBySubject, GetQuadByPredicate etc. Though I actually would suggest instead making a single GetQuads method that takes a 4 nullable INode instances as the interface instead so you could write code like: GetQuads(null, pred, null, graph) rather than adding however many distinct GetByxxx merthods it would need to be to support all possible combinations (12?)

What I would suggest is that (for now at least) we don't really do anything in terms of changing the underlying implementations. Quad could be a simple wrapper around a tuple of (Triple, IRefNode) in most places. We might later want a ITripleStore implementation that has a single IndexedQuadCollection as its storage but that could be done later if there are compelling performance reasons.

[kal]

@langsamu - does that seem like a reasonable (initial) feature set from your point of view? Anything missing that would be useful in an initial release with a Quad type?

[langsamu]

Sounds reasonable: We don't touch the internals but modify the public API of some fundamental constructs to support quads (as my colleague @hellikopter put it).

Rephrasing yours slightly:

• IEnumerable<Quad> Quads on IGraph, each with Quad.Graph equal to this.Name.
• Same on ITripleStore but Quad.Graph equals each graph name.
• Assert and Retract on both graphs and triplestores, no?.
• HandleQuad sounds good. Deprecation also.
• Single graph pattern query method on both graph and triplestore, no?
  Single method sounds good, very similar to other libraries.

A different approach:
Maybe we don't want to touch IGraph at all, since 'graphs' never have quads, only 'datasets' (our ITripleStore).

[kal]

Thanks @langsamu. Maybe as you suggest it would make sense to start with an approach that only modifies ITripleStore. This would make it quicker to implement and as you suggest easier to grok. I do have a suspicion that we will find users wanting to move between Triples and Quads, but lets cross that bridge when we come to it and have some concrete use-cases. So the revised proposal would be (building on your list):

• IEnumerable<Quad> Quads on ITripleStore with Quad.Graph equal to graph name
• Assert and Retract on ITripleStore
• HandleQuad(Quad) on IRdfHandler and deprecate the existing HandleQuad(Triple, IRefNode)
• GetQuads query method on ITripleStore with 4 nullable arguments that specify values to filter on.

I am also thinking that Quad should be independent of Triple and not extend it. This is partially because the notion of identity is different but mainly because it would complicate existing APIs like IGraph.Assert which would then have to handle the fact that the Triple it is handed is actually a Quad.