Introducing Linked Data Fragments

[langsamu]

Summary

This change resolves #200 and introduces a Triple Pattern Fragments (TPF) client to dotNetRDF.

The client is an implementation of the IGraph interface which dispatches graph operations to a TPF endpoint.

Value

The advantage of this approach is that developers can interact with Linked Data Fragments in the exact same manner as they do with any other graph (constructed programmatically or loaded from disk or network).

A corollary is the ability to run SPARQL queries against a TPF endpoint. This is a feature that other LDF clients (like Comunica) achieve by mapping the SPARQL algebra to LDF operations. In our case this is achieved by the Leviathan query engine that maps the same to methods exposed by IGraph, which the implementation introduced here translates to TPF network calls.

Limitations

I've chosen to implement TPF as opposed to Quad Pattern Fragments (QPF) because the chosen implementation approach is not viable for QPF in dotNetRDF as we don't really have quads. Of course QPF could be implemented in DNR in multiple ways, but I think there is still value in exploring this implementation paradigm.

This is a naive implementation. There are no robustness/resilience measures like the capability to rety and back off. It is very likely that production usage will suffer from network outage and throttling. For now, mitigating these scenarios is left to applications hosting this client.
This is an intentional choice: I'd rather start with a naive solution and allow usage patterns to drive further development. Better than me trying to introduce plumbing here based on assumption only.

The client introduced here is also naive in its lack of support for caching. Again, this is by design.

Mitigation

Same applies to the current lack of support for authentication, which is likely to be required in all but the most simple use-cases.

There is a limited extensibility mechanism introduced here that might help aleviate some of the above shortcomings: The client accepts an optional Loader. Callers could implement resilience, caching or authentication here.

Architecture

This feature focuses on the consumption of TPF, so it is under a Client namespace.
Future work could implement server features.

• VDS.RDF.LDF.Client.TpfLiveGraph is the single public API of this client.
  It's an IGraph whose triples are a TpfTripleCollection. This is its major contribution.
  In addition it overrides several methods to advertise lack of support for mutation, blank nodes and RDF*.

• VDS.RDF.LDF.Client.TpfTripleCollection is the main mapping between our graph operations and LDF.
  It's a BaseTripleCollectionimplemented by linking WithXXX and other methods to our TpfEnumerable.

• VDS.RDF.LDF.Client.TpfEnumerator (and TpfEnumerable) is the workhorse of the library.
  It is responsible for returning triples from the TPF endpoint to our client.
  It is the implementation of LDF paging.

• VDS.RDF.LDF.Client.TpfLoader is our representation of the TPF response.

• VDS.RDF.LDF.Client.TpfMetadataGraph is our representation of the TPF response metadata.

• VDS.RDF.LDF.Client.TpfParameters is our representation of a TPF request.

[kal]

Hi @langsamu. As the PR is still in draft I thought I would just leave these comments for you. I'm happy to take on any/all of the suggested changes myself, but I don't want to step on your toes if there is still some further work you want to do on the PR before submitting it as ready for review.

[langsamu]

Thanks for the initial review @kal.

This is far from done.
I was working on mock responses when I noticed your comment.
I'll definitely tackle naming and assertions as well.

[langsamu]

@kal I think this is ready for an interim review.

[kal]

This is great, thanks @langsamu ! I've taken a read through the code and don't have any comments to add beyond the few things that you have already got noted in TODOs. FWIW I think that the use of SPARQL rather than SHACL is fine internally. Being able to configure the parser used would be good, but I don't feel that its absolutely critical to getting the feature merged (though if its not done then worth creating an issue as a reminder to get it done later).

The only missing element for me now is documentation of public classes and methods and ideally also some overview documentation somewhere in the Users' Guide.

[langsamu]

This is great, thanks @langsamu ! I've taken a read through the code and don't have any comments to add beyond the few things that you have already got noted in TODOs. FWIW I think that the use of SPARQL rather than SHACL is fine internally. Being able to configure the parser used would be good, but I don't feel that its absolutely critical to getting the feature merged (though if its not done then worth creating an issue as a reminder to get it done later).

The only missing element for me now is documentation of public classes and methods and ideally also some overview documentation somewhere in the Users' Guide.

• f7104d9
• dde5584
• 293f510
• 9a1d15a
• 12adb18

[langsamu]

All yours @kal.

[kal]

Thanks for all of this work @langsamu! This is a really useful addition to the library and I'm really happy to approve! 🎉