Hi Marko, Marko Rodriguez schrieb am 30.03.2010 um 14:42:44 (-0600): > When doing //, it remembers previously seen elements and then halts > that particular path when that element has been seen again. However, > there are many many many paths in any complex enough graph (so usually > this is just a memory and time explosion). Thus, // is usually avoided > --- instead a while/foreach/repeat loop is usually opted for.
Understandably so! Do you lend meaning to the other axes defined in XPath? For example parents, ancestors, following and preceding siblings? I'm struggling to see how all that would map from a tree to a general graph. > > Also, this raises the question of traversal order: Let's assume that > > A --knows--> B, C and D. Is there an order specified for going along > > the edges, such as *document order* in XSLT? Or are edges specified > > to be unordered, such as attributes in XDM (XPath Data Model)? > > The traversal order is determined by how the underlying graph database > serves up its results. So its different for different graph databases > having the same graph data. So it's implementation-defined, which is random from the POV of a specification. And I can't see how edge order could be specified. For me, a graph newbie, there does not seem to be anything inherent in a graph that suggests an order of edges. That's problematic in that it will lead to non-deterministic behaviour: Traversal halting points (and hence the list of edges and vertices being traversed) are up to the implementation, so you cannot use this to declaratively express a result to compute. Well, you can, but what you'll see won't be what you'll get - you'll be at the mercy of the implementation du jour. Of course, you could still make it mandatory for the user to declare (and the implementation to define and adhere to!) an algorithm to unambiguously determine traversal order without relying on nitty-gritty implementation details (such as object id). I just cannot see what would be natural to a graph. I think it would have to be something on the data layer, or a meta attribute, so that you get sortable edges. XSLT and XQuery are built on the XDM (XPath Data Model), which is an abstraction of an XML document. In fact, it's an ordered tree. Is there something like that for graphs that you could (or do) base your graph query language on? Thanks! -- Michael Ludwig _______________________________________________ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
