Fork me on GitHub

When you call asami.core/transact (or asami.core/transact-async) then the argument can be: • a seq of triples to be inserted • a map If it’s a map, then the accepted keys are: • tx-data: a seq of :db/assert and :db/remove statements • tx-triples: like the non-map version, a seq of triples to be inserted • executor: a user supplied executor. Defaults to the Clojure Agent executor • input-limit: limits the maximum number of triples that can be inserted in this transaction (I recommend never using this. It was a UI hack for Cisco) • update-fn: a Graph update function. You want to pass update-fn This is a function that accepts a graph, and returns a graph. The Graph protocol is found in asami.graph/Graph You can do a resolve-triple for something like [the-entity :count ?c] and then: (graph-transact graph [[the-entity :count (inc c)]] [[the-entity :count c]]) So:

(asami.core/transact my-connection
                      (fn [graph]
                        (let [c (ffirst (asami.graph/resolve-triple graph :my-entity :count '?c))]
                          (asami.graph/graph-transact graph [[:my-entity :count (inc c)]] [[:my-entity :count c]])))})


Not pretty, I’m sorry


But possible

Jakub Holý (HolyJak)06:01:56

Thank you! "possible" is great!


When I get to SPARQL, then this is something I’ll have a query language to do for you. I just need more weekends. Well… weekends when the kids don’t need me

👍 4

Hey 🙂 out of interest, have you seen that there's the basics of an "RDF" module in XT which reuses the RDF4J parser and compiles a small subset of SPARQL into XT's public query API? See It's mainly been used for benchmarking with (etc.). Just thought I'd mention it just in case it helps for some inspiration or at least ideas about what not to do with your hypothetical weekends!


Thank you 🙂


As inspiration… sure!

💯 2

Time for a little bit of personal philosophy: There is lots of work out there that I could be leveraging to help build out Asami faster. I really ought to. But I choose not to for a few reasons: • I try to keep the dependencies very minimal. This has proven to be very useful. • Each thing I implement myself is a learning experience. I appreciate this. • Most external systems are not Clojure/ClojureScript compatible. I’m also hoping to incorporate ClojureCLR support soon. It would be even cooler if I can make it work with ClojureDart or (eventually) Jank. I admit that there’s a certain amount of hubris/ego happening here. But it’s my hobby, so I’m allowed do it the way I’d like.

❤️ 6
😎 2

Also, I tend to be a little opinionated. It’s nice to have an environment where I get to express that


That last one is the most flexible though. I will often look back at something I wrote and realize that my position has evolved, and I wouldn’t do it like that anymore 🙂


I am completely on board with all of that! There's real beauty in pure Clojure.


This is why Raphael exists. Otherwise I’d have used riot from Jena


Years ago (like 12), I tried an RDF/XML parser, but the Clojure XML parser didn’t handle namespaces! I did try patching it, but I probably used non-idiomatic Clojure back then, and it was rejected. So I stopped. But it’s since been fixed, so I should try again.


Godspeed 🙂


Honestly, I like TTL a lot more. Now that it’s formally accepted as an RDF format, I feel like I’m justified in sticking to it 🙂

💯 2

There are some government datasets in RDF/XML, so it’s still around


But I’m mostly inspired to consider RDF/XML because my mentor uses it


I author my OWL in TTL. She does it in RDF/XML. And honestly, she’s been working on it longer than I am (she worked on the DAML+OIL committee!)

😎 2