Feature: Query Support

[jeswr]

Libraries such as LDO and LDflex enable the objects they expose to interact with remote datasets. It would be useful to have the same capability to interact with remote datasets in this library.

[jeswr]

If this were to be implemented, it should be done by wrapping an interface such as https://github.com/rdfjs/query-spec/blob/master/queryable-spec.ts, in a similar manner to how the current Dataset interface is being wrapped - not by importing a query engine.

[langsamu]

If this were to be implemented, it should be done by wrapping an interface such as https://github.com/rdfjs/query-spec/blob/master/queryable-spec.ts, in a similar manner to how the current Dataset interface is being wrapped - not by importing a query engine.

This is interesting. I'm not sure how I could 'wrap' a Stream though. Of course it's trivial to project a Bindings or a Quad through one layer / through one hop of mapping (e.g. a literal to a string), but I don't yet see how we could maintain the recursive aspect of mapping in a streaming context.

One of the central tenets of this (wrapping) approach to mapping is that result terms (e.g. objects of triples with given subject and predicate) can be looked up and traversed further. This would not be done over a stream (other than by opening another stream).

Same applies to Streams of Quads in the case of CONSTRUCT queries.

[langsamu]

Libraries such as LDO and LDflex enable the objects they expose to interact with remote datasets. It would be useful to have the same capability to interact with remote datasets in this library.

I would argue that interaction with remote datasets is not a concern of this library.
Instead it is an orthogonal concern that should not be solved by it (not hidered by it, of course).

The idea here is that we're mapping on a very low level: The RDF/JS DatasetCore interface.
We have no dependency on memory, network, storage, performance, triplestore, LDP, Solid or anything really.
Anything that can act as a dataset is fine for the purpose of this library.

I would argue that interaction with remote datasets is much better handled on the level of various DatasetCore implementations. There is nothing typing us to in-memory datasets (thought that is likely to be a very common pattern).
One could trivially implement a dataset whose add, match, remove etc. operations dispatch to a

• SPARQL endpoint, a
• QPF endpoint or a
• Solid container
  under the hood.

Interaction with remote data is not trivial. Especially if mutable. I would try to keep as many things as possible out of this library: Authentication, network resilience, actual implementation of the DatasetCore interface and so on.

We should focus, in my opinion, on one thing only: JS/TS idiomatic representation of RDF.

[jeswr]

I largely agree - with a key caveat.

You will never be able to execute a network request within a synchronous operation -- which all the methods on DatasetCore are -- fetch will always return a promise.

The gap here is largely the RDF/JS ecosystem itself, i.e. a lack of an AsyncDatasetCore.