Clojurians Log v2

Everything worked fine! I guess my problem is indeed with the set-semantics of this RDF-like graph world. I find that it is just not enough to model the relationships I have in mind. Or it makes them in my eye more complicated than ideal. Asami does indeed support some of this, but I find the second query rather complects the declarative and imperative worlds, the nice declarative parts are reduced and the intent behind the code becomes less clear. As for domains, for example, it is difficult to model Clojure source code into a graph because in source code order is significant and the default. Arrays would need a counterpart in the graph model for the graph model queries and API to support it well. I was investigating this to see if I could create a proof-of-concept "Emacs-paredit-elisp" but structured graph editing and Clojure. ORDER BY is perhaps not the solution, at least if it does not have a shorcut for the original array order that it would use internally. I would assume that if one queries a relationship where the value is an array, that one gets the relations in the order of the array that I specified, and not some other order. I'm not sure if my thoughts make any sense. Part of why I ask is because I know you have much more experience with working with these models and perhaps have intuitive solutions for these in an RDF-like world, might know which kind of graph model would support these if RDF isn't enough if it exists, or can perhaps just say that it has not been a problem in practice.

There are a couple of things to respond to here. I looked at modeling Clojure into a graph back in 2015. At that point I didn't have Asami, so I used Datomic. Also, SCI didn't exist, so I hacked the Clojure lisp reader. https://github.com/quoll/cast

I know that Ray McDermott wanted to build an emacs-like editor to do this kind of structural editing, using a graph as the data model.

He had collected a few people to help him work on it. I don't know how far they've gotten though

As for ordering in the RDF world, there were traditionally 2 mechanisms: Containers and Collections.

https://www.w3.org/TR/rdf-schema/#ch_container is the superclass of rdf:Bag, rdf:Seq, and rdf:Alt. In this case, you're looking for rdf:Seq. Containers have generally been eschewed from early days, and I don't see them often, but they're still around. There's not a lot to prevent them from being malformed, and the OWA makes them harder to reason around. But as a data structure they're fine… so long as you keep them well-formed. The :a/contains property in Asami is specifically copying the concept of rdfs:ContainerMembershipProperty into the linked lists paradigm, since having a single step to get the entire collection can be very useful.

However, the OWL people can't reason about them, which only discouraged people from using them. But for data structures, why not?

So you can query for all the members of your rdf:Seq, and the properties all provide the offsets.

Otherwise, you have the linked lists of RDF (copied by Asami), but they only come back in order due to serendipity. It would be nice if they could be accompanied by an index, a lá map-indexed.

Ideally, I should introduce a query construct that allows a variable to be bound to a list, that is filled with the full list from a particular node. SPARQL desperately needs this feature, as it would allow for certain OWL queries to be executed in polynomial, rather than exponential time

Feel free to make query syntax suggestions for Asami here 🙂

Thank you for the answer!. I just discovered Ray's work today and started listening to a podcast episode. Maybe there is something in common indeed. I don't have any suggestions yet, I am still researching. There must be a graph formalism where order is in the model itself 🤷 . Maybe the truth is still out there.

I spent the day looking at pyramid, which has another set of included and missing features. Next I will likely look at some document DBs and Neo4j to understand what they offer instead.