Support for RDF*

[jacoscaz]

How should we index quads within quads? This is a hard one!

[jacoscaz]

See work on RDF/JS:

• Added RDF* support by extending Quad from Term rdfjs/data-model-spec#165
• https://blog.liu.se/olafhartig/2019/01/10/position-statement-rdf-star-and-sparql-star/

[jacoscaz]

I will close this for now as we do not need this internally and there seem to be very little interest (if any at all). Will reopen should someone ask for it.

[jeswr]

@jacoscaz - just wondering if you ever put more thought into the indexing strategy as I'm currently looking into RDF-star indexing for N3.js (w3c/rdf-star#270)

[jacoscaz]

@jeswr we don't really need RDF-star internally so I haven't given this much thought over the last few months. Last I looked at this, however, I struggled with how to make quads-as-terms easily queryable. The only way I've come up with so far is to convert RDF-star triples into named graphs:

:man :hasSpouse :woman .
<<:man :hasSpouse :woman>> :startDate "2020-02-11"^^xsd:date .

would become

:man :hasSpouse :woman <someprefix_9999>.
<someprefix_9999> :startDate "2020-02-11"^^xsd:date .

However, doing this would likely present a challenge when in the presence of multiple identical quad-subjects:

<<:man :hasSpouse :woman>> :startDate "2020-02-11"^^xsd:date .
<<:man :hasSpouse :woman>> :provenance <some_origin> .

In a naive implementation, this would lead to two different but equivalent named graphs that would need to be reconciled into a single one.

Another potential way to index RDF-star triples might be to have a separate set of indexed for quad-subjects that somehow refer to triples in the standard indexes, but that also leads to a kind of "foreign key" that basically becomes equivalent to a named graph IMHO.