Implement RDF*

[rubensworks]

Issue type:

• ➕ Feature request

---

Description:

We should provide an (experimental) implementation of Olaf's RDF*: http://blog.liu.se/olafhartig/2019/01/10/position-statement-rdf-star-and-sparql-star/

[rubensworks]

Some implementation inspiration:

• http://graphdb.ontotext.com/documentation//9.2/free/devhub/rdf-sparql-star.html
• https://rdf4j.org/documentation/programming/rdfstar/

[rubensworks]

Some requirements before we can get started:

• RDF/JS data model: RDF* support rdfjs/data-model-spec#162
• RDF/JS typings: https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/rdf-js https://github.com/rdfjs/types
• SPARQL parser: https://github.com/RubenVerborgh/SPARQL.js/
• N3.js (at least the Turtle parser and serializer): https://github.com/rdfjs/N3.js

Only then can we properly add the final parts into Comunica.

[ragnorc]

Seems like RDF* is now supported in N3.js and Sparql.js.
What would be left to do to get this supported in Comunica? Happy to help!

[jeswr]

RDF* is now supported in N3.js

For parsing yes - for the store itself there is still an open issue around this rdfjs/N3.js#256. In particular, for performance I would suggest that

1. The match method be extended to handle reified data
2. The indexing method for reified quads be re-thought

---

That said - I believe that there should be a way to get around this in Comunica in the meantime; especially since the above suggestions for the match method in N3.js would also need to become part of the RDFJS spec before all RDFJS interfaces can be expected to have that kind of support.

IMO The first thing that needs to be done on the communica end is adding support for reified triples in the resolve-quad-pattern actors.

My suggestion for implementing this in the case of RDFJS sources (which can probably be extended to the other sources as well) is to treat reified triples containing variables, as a special case. The best way to explain how to handle this special case is by example: if you had <<?s a Person>> ex:annotation ex:value, you would first call match(null, ex:annotation, ex:value) on the store (that is, match against any subject), and then filter the resulting stream to limit the results to those such that the subject is a quad matching the pattern ?s a Person.

In addition to this there will need to be new query-operation actors for anything new/modified algebra operations in sparqlalgebrajs. @joachimvh probably has the best insight on this.

[rubensworks]

To add upon what @jeswr has said above, there's also the issue of implementing supporting the evaluation of SPARQL* queries, since there are some specific new features in SPARQL* that did not exist before in SPARQL. (it's been too long ago since I looked into it, so I'm not sure anymore what exactly would be needed)

@ragnorc if you want to take up (part of) this effort, any help is definitely very welcome. Also happy to have a call to discuss what needs to be done.

[joachimvh]

In addition to this there will need to be new query-operation actors for anything new/modified algebra operations in sparqlalgebrajs. @joachimvh probably has the best insight on this.

It could be that sparqlalgebrajs already works out of the box with this, since it copies the Term and Quad objects directly from the sparqljs output. That is for the BGP parts of a query though, I'm not really following RDF*/SPARQL* so not sure if other features are needed.

[ragnorc]

Thank you @jeswr and @joachimvh for your input.
@rubensworks Happy to jump on a call to discuss this!

[rubensworks]

@ragnorc Could you mail me some suggestions for meeting slots (next week or later)?

[rubensworks]

Done in #1222.