We evaluated Jena (we actually prototyped the first system in Jena) and RDF4j. At the time we didn't look into Blazegraph. In beginning the project we began to develop hypotheses of the kinds of features we would need. Namely the ability to check the instance data against a very complex and evolving schema. The need to do schema and instance updates in a single transaction. The need to recieve a program interpretable "witness of failure" (a refutation proof) so that automatic strategies could be undertaken to correct failures in certain cases.

As we went forward we also acquired the collaboration and time-travel requirements to facilitate large team data curation - which aren't present in these offerings.

As for SPARQL, it's essentialy a messy and truncated datalog. It just seemed a bit silly not to use an actual datalog! Then as I've said elsewhere, we needed to be able to do fast time-window queries which CLP(fd) is excellent at and which SPARQL doesn't support.

JSON-LD is most definitely not human friendly, and turtle is certainly better. In our interface you can manipulate the schema in turtle as it's far clearer.

The advantage of JSON-LD is as an interchange format. With turtle you are pasting together strings. With JSON-LD libraries for querying the database are just functions which build JSON-LD. It also simplifies parsing on the opposite end.

But in addition JSON-LD + strong schema give you a way to treat segments of the graph as documents! We can use our get_document word and you'll get back the JSON-LD fragment of the graph associated with an ID. JSON-LD was carefully designed so that this bidirectional interpretation is possible.