Fork me on GitHub
#rdf
<
2023-05-28
>
Takis_16:05:56

Is using RDF databases, as real time transactional databases a good idea? I am using Jena TDB2 the last weeks and everything goes well, jena provides query builder, udf functions and accumulators, looks very nice.

Takis_16:05:19

but i don't have experience to know so far i just tranfer queries from a mongodb, not updates yet, from your experience can we use rdf as database or it should be used only for knowledge base and read mostly operations?

simongray07:05:37

I don't see why not. Clojure is 10x slower than Java, yet we are fine building things in Clojure since the ergonomics during dev time make up for the relative drop in runtime speed. Datomic and the other Clojure triplestores are not marketed as read-only, so why should the mature RDF triplestores be? The other part is having confidence in data integrity over time. I am not an expert, but I am guessing that Jena, since it is at version 4.x, is stable enough that this won't be critical. In any case, any critical data should be backed up regularly no matter which guarantees the database has. BTW I wrote a small Clojure wrapper for Apache Jena transactions, if you're interested: https://github.com/kuhumcst/DanNet/blob/master/src/main/dk/cst/dannet/transaction.clj

Takis_11:05:26

yes i think the same that for queries that wouldn't require many joins in relational or document database might be kinda slower, but i think they can be fine, if the database is good, thank you for the jena wrapper i will check it out : )

simongray11:05:40

I use Aristotle as my Jena wrapper, but it doesn't have transactions (or really any kind of support for persisted databases). Furthermore, the Jena Java API itself is a bit of a mess, as you can tell by the completely separate interfaces I've had to wrap to make it work, so this wrapper of Jena transactions was definitely needed. I might contribute it to Aristotle, but lately I've actually been thinking about forking that project since Luke doesn't seem like he has time to maintain it. I made some contributions, but it's a very slow process.

Kelvin11:05:38

@U4P4NREBY That’s fairly similar to a Jena transaction wrapper (+ convenience macros) that I wrote

Kelvin11:05:26

The psp protocol implementations are thin wrappers for the above interop functions

simongray11:05:04

Cool! I think your solution is a bit more low-level than mine, though, right? I don’t actually call the different transaction steps manually anywhere in my code, I just delegate to the default Jena transaction handlers for the different datatypes.

Kelvin11:05:04

Interesting, I wasn’t aware that you could actually do that. Given that one of our implementations is a remote AWS Neptune database (i.e. not a Jena built-in DB), I’m not sure how well that would work.

simongray11:05:12

I was tempted to write a similar solution to yours when I found out that each datatype has a slightly different API for creating a transaction. This works very well for me as I only really use those three objects in my code: graph, model, and dataset.

simongray11:05:07

it’s a testament to how messy the Jena Java API is that each object has a slightly different, yet equivalent interface…

quoll02:06:54

I need to get Asami up-to-speed with RDF/SPARQL, but it actually does have transactions, though I hide them well. Transactions can take a function that accept and return a graph. These are actually managed by starting a transaction, running the operation (in which there will be numerous read and write operations on the graph) and finishing with a commit operation. If an exception is thrown, the transaction is rolled back.