Map available SPARQL packages and their requirements

[alexhebing]

In particular, keep track of which database requirements they have.

[jgonggrijp]

@alexhebing You may want to read this. It discusses the core principles behind linked data. I'm still reading up myself.

Probably the nicest triple serialization format will be JSON-LD.

JavaScript implementation: jsonld.js. Python implementation: PyLD (same author as jsonld; no restrictions on database implementation, but you have to manage the schema by yourself) Converting between RDF and JSON-LD in Python: RDFLib-jsonld

[jgonggrijp]

This is an excellent resource. Saved to surfdrive.

This pointed me to rdflib, which we should probably use if we are going to offer SPARQL. "Getting started" documentation is here. Documentation on how to attach your own store is here and here and probably also in other places.

There is rdflib-django, which we might be able to use, but which is unmaintained since 2012. There is a fork by devkral which appears to be more useful. If we go with this, we have less freedom to decide on our own models; most information that we store will be in triples that are completely managed by rdflib-django3.

There appear to be no existing integrations between rdflib and Django REST framework, but we might not need those.

@alexhebing At this point, I think we have two main options:

1. Stick to what we already know as much as we can. Implement the model from #6 as a regular Django database and initially expose it through DRF with regular serializers and viewsets. Operate Backbone at the frontend in the regular way. Tack on JSON-LD later if we need to. Cry if we end up needing to implement SPARQL, because then we have to write custom glue code between our own data model and rdflib.
2. Bite the bullet and use rdflib + rdflib-django3 + rdflib-jsonld from the start. In this case there will be many things to figure out initially:
   • Where is the border between the triple store managed by rdflib-django3 and our own customized data model.
   • How are we going to manage who can use which category (#6), if we are going to manage that.
   • What is the most elegant way to combine Backbone's Model with jsonld.js.

I'm leaning towards option 2, because it has the following strong advantages over option 1:

• We build experience with linked data right from the start, which is highly valuable for future projects.
• Our technical solutions will also be reusable for future projects, since RDF is completely general.
• If we need to implement SPARQL later, we will get it almost for free.

What do you think?

[BeritJanssen]

I agree with Julian's choice for option 2. Option 1 may be faster progress initially, but may be dearly paid for later on.

Seeing as projects in the past (EDPOP) have already requested linked data compatibility and this request is likely to come around again (if there is new budget for EDPOP, or in any other project as linked data is everywhere right now), I think the time invested in investigating option 2 is well invested.