Fork me on GitHub
Al Baker01:04:37

interesting -- have you taken a look at clj-sparql ? 🙂

Al Baker01:04:34

could probably use Flint and clj-sparql together... I think I had some examples of the various sparql builder/DSLs that folks have built

Al Baker01:04:42

it's just wrapper around ARQ


I have! (Though the fact that it hasn't been updated since 2015, with outstanding TODOs, ultimately dissuaded me from using it.)


What I had not looked at was, which seems to be a SPARQL DSL created long before Flint!


(Though again it hasn't been actively maintained since 2014.)


An incomplete list of difference between Matsu and Flint that I noticed: • Matsu uses an expression-based syntax (e.g. (query (select ...) (where ...))) while Flint uses a map-based syntax at the top level. • Matsu uses tuples for prefixed IRIs (e.g. [:foaf :mbox]) whereas Flint uses qualified keywords (e.g. :foaf/mbox). • In Matsu, one can register global prefixes, whereas in Flint you cannot. Flint's approach is more functional, but I can see how Matsu's approach can be more convenient. • In Matsu, IRIs are encoded as URI instances, while in Flint they're regular strings wrapped with angle brackets. The former was the approach @rickmoynihan suggested for Flint. • Matsu is missing support for some SPARQL features, such as subqueries, graph management updates (eg CREATE and DROP), and certain expressions. Not an intentional omission since they're all listed in TODOs, but the fact that they're not present would've made Matsu problematic for the applications I've been working on.


On the global prefixes, personally, I really like them, despite SPARQL (and TTL, etc) not having them. I mean, does anyone ever really want to redefine xsd: rdf: rdfs: owl: or skos:?


Since I'm here, I might as well comment on some of the other points: • The expression-based syntax looks a lot like the internal structure that Jena uses, but I think that the map works better in Clojure. Order doesn't actually matter, but there should never be more than 8 keys (I think?) so I think you'll get an array map, which will preserve the ordering (useful for printing). • I like using keywords for QNames. Theoretically, I think there are some QNames that may not be valid keyword literals? But a) I can't think of any, and b) you can always construct illegal keywords with the keyword function, since it just saves a pair of strings. 🙂 • I commented on liking global prefixes. • I agree with @rickmoynihan on using URIs. Similarly to keywords, does not do any checking or translating, which means that they can handle IRIs just fine:

=> (.getPath ( ""))
• Nice that you've done all of the SPARQL operations :thumbsup:

👍 1

BTW, I take it back about the keywords. It looks like I can type any QName character at a repl and it can make a keyword. .e.g :a.b.c/x%0a˿


Oh, no... the PN_LOCAL_ESC sequences won't work 🙂


(Those would make for hairy QNames, and are definitely not CURIs)


• Flint actually re-orders top-level maps, so you could intentionally misorder your clauses ( and it will still be formatted in the right order. • (Not much to say about qkws.) • Honestly I could see future Flint having a prefix registry similar to Matsu, which (like in Matsu) can be augmented with additional prefixes directly in the :prefixes map. But to maintain the functional spirit it would be totally optional. • Seems like people really like that URI feature. My main issue is that point is that Flint would need to keep the <> system for IRIs for backwards compatibility - not that such things are new of course. • Indeed, and with expressions in particular this is where I'd say Flint is superior to Matsu's approach (where the latter has to define separate functions for each SPARQL expr).

👍 1
Eric Scott16:04:17

This probably qualifies as a shameless plug, but one of IGraph's sister projects is , which uses clojure namespace metadata to hold mappings to rdf equivalents, and has support for translating between URIs, clojure keywords, and qnames.


> Seems like people really like that URI feature. My main issue is that point is that Flint would need to keep the <> system for IRIs for backwards compatibility - not that such things are new of course. @U02FU7RMG8M: My fear with that is that type correctness still suffers. i.e. strings can be misinterpreted as URIs. Would it not be possible to define set a flag which disables the parsing of strings into URI’s? > Flint’s approach is more functional, but I can see how Matsu’s approach can be more convenient. I’m a strong supporter of what you’ve done here. Passing the prefixes in at the top each time is much better than having a global registry, or storing stuff on namespaces/vars. If someone wants a global registry/singleton, let them define it. Having such things can cause problems for folk because you’re complecting namespace loading with side effects. Doing those things is fine of course, but it’s an application concern to do it, not a library concern. e.g. integrant systems want to componentise by moving the require tree into a DAG expressed in edn configuration.