Fork me on GitHub

I saw terminusdb a short while back; but I didn’t quite understand exactly what their model is. I also found their feature comparison matrix a bit disingenuous… For example to claim that SQL or SPARQL aren’t “Rich advanced query languages” is a cop out. In what way is datomic/terminusdb’s query language richer and more advanced than those?! Likewise stardog absolutely has ACID transactions: Similarly you might say “like git for data” can also be claimed for stardog too: (though it’s stretching it a bit as the model doesn’t really include proper branching/merging) but it does definitely do MVVC: I mean sure there are potentially caveats to each of these. Also don’t mean to criticise terminus, I know almost nothing about it - and am genuinely curious what the differences are, I just found their feature comparison matrix was too flawed to be useful. Is it actually RDF, or just RDF-like?!


Looks like it’s not RDF, and strong schema upfront gives it very different properties


Oh ok but that’s implemented as URIs with xsd’s just with OWL with closed world semantics


@rickmoynihan So it is then RDF then?


Sort of. I think it’s more accurate to say it supports a subset of RDF graphs. i.e. I don’t think you could take any arbitrary RDF from the wild and load it. I think to load data from the wild you’d need to load the ontologies describing all the terms in the data you’re loading first, and they would need to meet the constraints of the ontology under closed world OWL semantics.

👍 3

I think it’s true to say that any terminus db is valid RDF


only read their whitepaper though, not sure what the docs say


Also they say: > The names for nodes and labels are drawn from a set of IRIs … we have chosen the XSD datatypes as our universe of concrete values. Which seems to leave out blank nodes… so sounds like RDF without blank nodes; which is a good thing to remove.


Excuse my ignorance, but why is that a good thing to remove?


Well whether it’s good or not depends on your perspective. If you need perfect RDF interoperability it’s probably not a good thing to remove. However blank nodes are essentially just a small developer convenience that adds a boat load of complexity to RDF processing. The big problem is bnode identity; each time you load a bnode it generates a different identifier for it (usually scoped to the document it was loaded with). Hence bnodes destroy the ability to easily tell if two graphs are identical etc… in practice they can also cause problems with data loading, as you can easily get duplicated statements if you load the same file twice (and it contains bnodes) etc… so you lose idempotency and probably other set-theoretic properties too. It’s one of the few things that I think RDF would have been better without. It’s hard to see how you can do proper graph branching and merging etc if you allow them… at least without resorting to extra bodges or rules around handling them.

👍 3

I see. Thank you for explaining.


I suspect that’s because blank nodes will mess up their “git like semantics”.


though not seen anything that says that explicitly