quadstorejs / quadstore

A LevelDB-backed graph database for JS runtimes (Node.js, Deno, browsers, ...) supporting SPARQL queries and the RDF/JS interface.
https://github.com/quadstorejs/quadstore
MIT License
203 stars 14 forks source link

Support for RDF* #95

Closed jacoscaz closed 3 years ago

jacoscaz commented 4 years ago

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

jacoscaz commented 4 years ago

See work on RDF/JS:

jacoscaz commented 3 years ago

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 commented 2 years ago

@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 (https://github.com/w3c/rdf-star/issues/270)

jacoscaz commented 2 years ago

@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.