Fork me on GitHub

Hello everyone! Today Pathom Viz 2022.2.15 is out! This release includes: • Resize panels now uses % instead of absolute sizes for a better app resize flow • Render entity data in request history when available ◦ Note for that you need to bump Pathom Viz Connector to version 2022.02.14 • Fix situation where Pathom 3 renders a Trace view with blank data • Save entity data in query history • Support lenient mode setting in query editor • Support include stats setting in query editor • Support report from strict errors in Pathom 3 ◦ Note that the latest Pathom 3 doesn't have the changes yet to work with this, but you can try using the latest SNAPSHOT release of Pathom 3, which is 2022.02.14-alpha-SNAPSHOT. For more info on this check For current users, just relaunch the app to get it automatically updated. Or download it from

🎉 10
pathom 3

Introducing v0.1.0 of Flint, a Clojure(Script) DSL for creating SPARQL query and update strings. Example:

(require '[com.yetanalytics.flint :as flint])

(flint/format-query '{:select [?x] :where [[?x "<>" 100]]})

;; => SELECT ?x WHERE { ?x <> 100 . }

🆒 9
👍 6
🎉 2

Wow this looks great! It’s something I’ve been meaning to write for a long time; bravo!!! I’ve only looked at this for two minutes, and it looks like it works almost exactly how I’d imagine but a few questions: 1. Have you thought about adding a protocol for representing URI literals, and extending it to and perhaps letting users extend it to jena/rdf4j’s URI classes? Having to encode a string as "<>" feels wrong. What if you had an xsd string which was of the form "<[stuff]>" how would that be interpreted? 2. Similarly providing protocols for coercing other literals, e.g. xsd:date vs xsd:dateTime etc. (These protocols would presumably want to also define datatype-uri accessor.) Like 1 this would allow passing datatypes easily between this and an arbitrary RDF backend e.g. jena/rdf4j. 3. In the map bgp/triple syntax can you also write {:dc/publisher ?publisher} or do you always need to wrap a set over it? 4. Have you considered adding a parser that targets SPARQL 1.1. query strings and converts them into this edn query data structure?


This looks very useful. Thanks a lot!


@U06HHF230 1. I actually have not thought about using protocols to represent literals. Extending any such protocol to a particular Java library could be tricky, however, since Flint supports cljs (and doubly so for a particular Jena class, since I want it to remain implementation-agnostic). As of right now, angle brackets = IRIs, so any string surrounded by them is an IRI, and any IRI will have to be surrounded by them. 2. For the above reason (i.e. I haven't thought about using protocols), there isn't support for literals beyond strings, numerics, booleans, and dateTimes. I wasn't sure how I'd actually implement literals beyond that so thanks for the protocols suggestion; I figure that the already-supported literals will cover most peoples' cases, though, so this would not be a huge priority. 3. You always need to wrap an object in a set, as that is how they're written in I understand that this can get annoying, though, so maybe in the future Flint can have syntactic sugar where ?obj becomes #{?obj}. 4. I actually did, but I abandoned that idea early on due to its complexity. A big problem is that there are certain valid SPARQL strings that Flint does not support, e.g., as well as subtle syntax variations.


@U02FU7RMG8M: Thanks for the reply… perhaps we can take this discussion to #rdf?


I was not aware that there was an RDF channel, but sure we can talk more there.


:thumbsup: cool