Clojurians Log v2

Going off of what you said, I wrote this lib because I was annoyed that there was literally no viable DSL for SPARQL or RDF queries except for Aristotle, which we previously used but quickly ran into its limitations.

Aha, so you get precisely what I mean. Thanks for making this! How stable would you say it is?

We're currently using Flint on our current projects at our company, so it's definitely stable enough.

Though of course as a new library there will be bugs that'll be uncovered and will need to be ironed out.

So there were a couple of reasons I went with the angle bracket syntax: 1. The thought of using types/protocols simply did not occur to me, as I said in the main thread. 2. I wanted to have a SPARQL-like feel when using Flint, hence variables start with ?, blank nodes start with _, and yes IRIs are surrounded by angle brackets. 3. Related to the above, I thought that the angle bracket syntax was the easiest for a user to grasp, especially if they already had knowledge of SPARQL. 4. Specific to URI but I don't want to be dependent on Java classes like that (not really a problem with custom protocols but then that's another thing for the user to become familiar with).

Firstly, I’m really sorry if I’m coming across as belligerent; I genuinely LOVE everything you’ve done with flint, except this small small detail. Again I’m very grateful for you sharing this! 🙇 > 2. I wanted to have a SPARQL-like feel when using Flint, hence variables start with ?, blank nodes start with _, and yes IRIs are surrounded by angle brackets. Yes, I totally love this. I just feel like the problem is that URI’s are the odd ones out. i.e. all of your other types are proper ones… e.g. you don’t parse strings to check if they’re xsd:dateTime’s, you map the underlying #inst datatype. Years ago in an early version of grafter, I did the same; allowing strings to be treated like URI’s in some contexts, and later regretted it a lot. > 4. Specific to URI but I don’t want to be dependent on Java classes like that (not really a problem with custom protocols but then that’s another thing for the user to become familiar with). Coming at this from a different angle; I think if you’re doing serious RDF work you’ll already be using a robust library for properly handling the datatypes somewhere. In the work I do, we care a lot about the correct unambiguous interpretation of data. A lot of the time query results from one query will be used in a subsequent query; and having to coerce those types is a problem. I think a good division of responsibilities is for flint to provide protocols for that coercion to be delegated to a library like this and call it at the right time (as late as possible). You don’t need to pick a backend or favour any particular one (I’d certainly rather you remained agnostic); however supporting builtin platform provided types and mapping them to xsd/rdf where possible makes sense and needn’t contradict this goal. For example adding support for java.net.URI is unambiguous… and cljc would just use goog.Uri a user could optionally then choose to use a library like: https://github.com/henryw374/uri Similarly another dep can always extend support for rdf4j/jena or rdf.js.

incidentally you can resolve this problem:

(-> {:select *
 :where [[(URI. "") ?p ?o]]}
 :where
 first) ;; => '(URI. "")

{:select *
 :where [[#flint/uri "" ?p ?o]]}

You shouldn’t coin #uri incase clojure does in the future (I’d love it if it did)… but could probably use #f/uri as a namespace 🙂

First of all, don't worry about coming off as belligerent; it's all constructive criticism, so it's all good. The main thing that's holding me back (besides obvious time constraints and such) is that this would be a major change to how Flint queries and updates are written, especially if we break backwards compatibility by getting rid of the <> syntax. (Though I guess it's an argument for "make this change early in the project's life.") I'll have to talk about it with my coworkers who are already using Flint before making such changes.

As a side note, the quoting issue was actually never one of the reasons why I chose the <> syntax. In part because there are worse ways to run into quoting issues, e.g. when you're building Flint queries from the ground up (and in that case I just quote the symbols individually).

whilst you’re here, so to speak… I was wondering if you could elaborate for me what asami/datomic’s approach to the quoting/binding issue with query data is? i.e. you have a query as data like:

'{:select *
  :where [[?s ?p ?o]]}

Well, if the ?s is supposed to be bound to a specific URI, then it would be ideal if the pattern were written that way. e.g. if the uri is . Also, I’m going to pretend that I have a uri reader so I can write it in code as #uri "" Then:

'{:select *
  :where [[#uri "" ?p ?o]]}

'{:select [#uri "" :as ?s ?p ?o]
  :where [[#uri "" ?p ?o]]}

(q '{:find [?s ?p ?o]
     :in $ ?s
     :where [[?s ?p ?o]]}
   the-db #uri "")

(q '{:find [?s ?p ?o]
     :in $ ?s
     :where [[?p* :db/ident ?p] [?s ?p* ?o]]}
   the-db #uri "")

Thanks… I was actually asking a slightly different question… How would you resolve this (deliberate) class of problem; in the asami/datomic world?

(let [s (URI. "<http://s>")]
   '{:select *
     :where [[s ?p ?o]]})
=> {:select * :where [[s ?p ?o]]} ;; <=== not what we want :-)

Sorry, I don’t follow. Are you trying to get the * in the select clause to have 3 bindings (with ?s already set to the required URI)? Also, I’m presuming that you have pseudo-code there, since you didn’t unquote the s in the where clause

the lack of unquote is the deliberate mistake

i.e. a correct way to do it is here: https://clojurians.slack.com/archives/C09GHBXRC/p1645026177945909 I’m really just asking how people tend do this dynamic query generation stuff with asami/datomic… in particular binding replacement… e.g. another way to do it in a more restricted case is in rdf4j you can take a query like:

SELECT * WHERE { ?s ?p ?o }

a small issue with the way I linked is that the use of syntax quote makes the query noisier as you need to use ~' to avoid materialising namespace qualified symbols. I’m personally ok with it; but if you do dislike it you can also avoid it with a thin layer of macros.

I’m still a bit confused as to how the binding with the :in clause doesn’t work?

internally, Asami literally creates a map of {?s (URI. "")} when you do this

ok that bit does answer the question — and is essentially the same approach as in rdf4j etc

Thanks. I was basically asking, because I suspected the :in clause in datomic/asami did this… I was wondering because I thought this sort of thing might be an acceptable solution for flint — treating URI types more rigorously etc… cc @kelvin063

@quoll is there a way in the api to do that kind of substitution on fragments of a query; or must it always be applied at the top?

Come to think of it, it’s not quite a map. Asami results are just seqs of vectors, with metadata for the column names. So:

^{:cols '[?s ?p ?o]}
([s1 p1 o1]
 [s2 p2 o2]
 [s3 p3 o3])

^{:cols '[?s]}
([<>])

👍 makes perfect sense

Not sure what you mean by “fragments of a query”?

You can provide bindings to start with, so it need not be one-column/one-row bindings. You can pre-bind multiple columns and rows, and start the query from that point

say you’re dynamically generating a query; and have a sub function that will ultimately generate a FILTER NOT EXISTS { bgps } block… but some of those bgps contain lexically scoped bindings you want rewritten

Hmmm, that’s interesting. I’ve never thought about prebinding things you want removed.

Yeah; it’s a useful trick

OK… in Asami there is currently no way. It would be easy enough to do (from a query resolution perspective), but I’d need to figure out the API to get the data into the right place

especially if you had, say, 2 or more NOT EXISTS, then how do you get the bindings to the right one? 🙂

lexical scope is one way

e.g.

`{:select * 
 :where [[~(sub-query arg1)]
         [~(sub-query arg2)]]}

then the subqueries internally replace through the discussed mechanism

For this kind of thing, I build the query in code, and not as a series of quote/unquoting operations

(assoc query :where (concat first-part second-part)) kind of thing

yeah at some point of complexity that’s always required; the question is how far can you get without sacrificing too much in the way of intent/expressivity 🙂

I think it needs to be a part of the query grammar