Bertrand
I've been doing a lot of Ontology (OWL) with directed graphs (with cycles)
and DAGS. One application we went with the nested map structure however now
that I've been working on a normalized BPMN/XPDL utility
( https://github.com/FrankC01/tributary ) I'm becoming enamored with the in
XML format produced by xml-parse and then zipping it up. Coupled with
clojures 'functional' nature, zippers become your friend really quickly and
provide a most generic way of dealing with any graph with any number of
layers.
The next step will be a normalized DSL on top of the zippers and using
things like hickory-parse/data.zip selector concepts.
For the Ontology work we use datomic as the persist mechanism.
On Thursday, July 10, 2014 4:26:33 AM UTC-4, Bertrand Dechoux wrote:
>
> Hi,
>
> I have various general questions about how one can perform simple and
> flexible graph query/update.
>
> If we start by a structure being nested maps then I know about
> get-in/update-in/assoc-in. The common point about these functions is that
> they all take a path to where the data is in the superstructure and that
> this path is only a sequence of keys, which may or not be symbols.
>
> 1) What happens when one layer of this superstructure is not a map but a
> sequence? For the sake of the argument, we can keep the discussion simple
> by only arguing about the vector case.
>
> Typically instead of
> { :key1 { :key2 val }}
>
> we now have
> { :key1 [{ :key2 val }]}
>
> Of course, one can perform get/update/assoc using map/reduce. However, it
> means that the code using this superstructure is taking a hit on
> complexity/maintenance each time a non-map layer must be crossed. Of
> course, the simplicity/beauty of the current implementation is that a path
> can point to at most one target substructure/value. Is there a way to do
> something similar with a more general definition of a path? One would
> assume that it is something that might be handled by xml/html modification
> libraries (think xpath or css selector) but this problem is more general
> and not domain specific. Is there a clean library that handle that case
> without being tied to html/xml?
>
> 2) How to deal with more general superstructure like a graph?
>
> One could build an immutable graph but I don't believe it is something
> that can be done by nesting immutable maps and vectors. One solution to
> deal with 'entity'--'entity' relationships is for one of the member to own
> only an identifier to get the other member from another reference structure.
>
> (from the basic OM tutorial:)
>
> {:people
> [{:type :student :first "Ben" :last "Bitdiddle"}
> {:type :professor :first "Gerald" :last "Sussman" :classes [:6001
> :6946]}]
> :classes
> {:6001 "The Structure and Interpretation of Computer Programs"
> :6946 "The Structure and Interpretation of Classical Mechanics"
> :1806 "Linear Algebra"}}
>
>
> It is, of course, again, manually possible to get/update/assoc using
> map/reduce. But then, again, this is the same problematic as with the
> first question : each time a relation needs to be crossed, the code using
> this superstructure is taking a hit on complexity/maintenance. How do you
> usually deal with this problematic?
>
> For both question 1) and 2), a more appropriate data structure might be
> the answer like a graph/semantic-like store (Datomic or something else).
> The questions are about intermediary solutions which would be less heavier.
>
> 3) How does Demeter lives with graph traversal?
>
> This law is often heard in the OOP world but it is a bit more general than
> that. When a long path on a superstructure is specified then if one
> intermediary layer is introduced later, all hardcoded paths will be broken
> ie in multiple locations in the code base. One would like to store local
> structure knowledge in a single place. How do you usually deal with this
> problematic?
>
> I have yet to take a serious look at lenses and their composition, they
> are probably an element of answer, but they are more often seen in more
> statically typed langage.
>
> Thanks for any feedback.
>
> Bertrand
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
