This sounds very similar to a library I knocked together about 6 months ago:
https://github.com/Swirrl/matcha It's essentially an in memory triple store for Clojure (written as a thin layer of macros over core.logic). Like with your library, Matcha also uses the concept of a triple without being directly tied to RDF types. Essentially any clojure or java value can be used in any ?s ?p or ?o position of a triple. Matcha also has seamless optional support for Grafter (a clojure RDF library) without having any direct dependency on it. It's intended primarily to help working with RDF, and consequently recreates some of SPARQLs semantics. A colleage and I have recently been working to add support for SPARQL OPTIONALs and VALUES bindings, this work is expected to be finished and merged in the next few days. Matcha's approach seems slightly different to yours; in that we aim to hide core.logic, and instead present an interface that is familar to clojure developers who know SPARQL. In particular I believe Matcha programs should always terminate, not allow recursion; and provide ceremony free interop with clojure. We also have some "cute" features, for example Matcha's construct does not construct graphs of triples; but clojure data structures. e.g. a query like this: (def db [[:s1 :rdfs/label "subject"]]) (construct {:s ?s :rdfs/label ?label } [[?s :rdfs/label ?label]] db) constructs the solutions in the shape of the supplied map template e.g. ; => [{:s :s1 :rdfs/label "subject"}] You can do this to arbitrary depth e.g. (construct {:s ?s :nested-map {:label ?label } } [[?s :rdfs/label ?label]] db) ;; => [{:s :s1 :nested-map {:label "subject"}}] We also facilitate grouping of resources with the special keyword :grafter.rdf/uri like so: (def db [[:s1 :rdfs/label "subject"] [:s1 :rdfs/label "another subject"] [:s1 :foo "bar"]]) (construct {:grafter.rdf/uri ?s ?p ?o } [[?s ?p ?o]] db2) ;; => [{:grafter.rdf/uri :s1 :rdfs/label #{"subject" "another subject"} :foo "bar}] This later usage groups solutions into maps by ?s and ?p, lifting multiple values with the same predicate into a set. This resource object form is particularly useful for post processing in clojure. Performance hasn't been investigated deeply; but it's good enough for us right now and we use it for production workloads. It's certainly nowhere near as fast as a proper commercial triple store; but some systems we have may query with modestly complex patterns Matchagraphs with up to perhaps a million edges, and return all solutions within a few seconds. Though I'd say it's much more typical for us to use it on small graphs of dozens to thousands of edges. Anyway I spotted your email and thought I'd share incase you find it relevant or useful. On Tue, 26 Feb 2019 at 17:41, Amirouche Boubekki < [email protected]> wrote: > Hello, > > > Following on my previous work with mini/micro kanren with wiredtiger > storage engine. > > I made a in-memory triple store with minikanren querying. > > The source is attached to this mail. It can also be found at source hut > <https://git.sr.ht/~amz3/azul/tree/master/src/azul/data/base/yiwen.scm>. > There is a few tests in yiwen.test.scm > <https://git.sr.ht/~amz3/azul/tree/master/src/azul/data/base/yiwen.test.scm>. > The full minikanren language is > supported even recursive queries like appendo. There is no tests for that, > tho, because I did not find a good example of recursive queries in triple > store > setting. > > In the code 'azul logic' is minikanren from the reasoned schemer second > edition. > It rely on r7rs scheme mapping module that is actually srfi 146 > <https://git.sr.ht/~amz3/azul/tree/master/src/azul/data/base/yiwen.scm> > which is > (like wiredtiger) an ordered mapping. It is less that 200 sloc. > > This should be easy to port to any scheme that has some kind of ordered > mapping. > The current implementation rely on a red-black tree. > > Also, it is not RDF. It is not datomic either because I does not force to > declare a > schema upfront. Garbage in, garbage out! > > All scheme base data types (string, fixnum, floatnum, array, cons/lists, > symbol) are > supported as subject, predicate and value. They are compared using their > respective > equal predicate and comparator (see SRFI 128 comparators > <https://srfi.schemers.org/srfi-128/>). It seems to work with > records like srfi-9 too. > > I am currently experimenting with that triple store as an application tree > to build an > editor. An editor has more or less deeply nested structures think about > the rendering > tree of horizontal and vertical panes. You might think zippers or cursors. > > The triple store allows to easily represent recursive data structures in a > single flat > namespace by introducing indirection between a key-value pair > (predicate-object) > and its 'subject'. Also, the fact that the triple store is a sort-of > global unique data > structure that stores everything, it makes it easy to debug state. Not > introducing > zipper or cursors is easier to my mind because at the end of the day a > triple store > is a mapping that is ordered. > > -- > You received this message because you are subscribed to the Google Groups > "minikanren" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/minikanren. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "minikanren" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/minikanren. For more options, visit https://groups.google.com/d/optout.
