Re: [Neo] XPath in REST API
XPath is probably not expressive enough for all use cases, but it's a nice
way to express things for the cases where it does work.
As we said, this was only one suggestion for how to do traversals in the
REST framework, our main suggestion was sent out a few minutes ago:
http://lists.neo4j.org/pipermail/user/2010-March/003224.html , the XPath
implementation was meant to complement this main traversal framework.
Since it's two different implementations it's nice to keep the discussions
in separate threads though.
Cheers,
Tobias
On Tue, Mar 30, 2010 at 3:09 PM, Rick Bullotta
rick.bullo...@burningskysoftware.com wrote:
That seems OK. Will xpath give you the expressiveness you need, though?
-Original Message-
From: Mattias Persson matt...@neotechnology.com
Date: Tue, 30 Mar 2010 15:02:19
To: Neo4j user discussionsuser@lists.neo4j.org
Subject: [Neo] XPath in REST API
We're discussing how to expose traversers in the REST API. One of the ideas
that was brought up (more emails with the rest of the ideas are coming) was
to use xpath directly in the URIs. A doubt we're having about that is that
it might not be perfectly RESTful, although USEful.
We'd like to get input from you guys (looking slightly more at you dr. Jim
Webber).
We'd imaginge it would look something like this:
o From the node representation (/node/5) you discover a URI template:
/node/5/xpath/{xpath}
o You insert your xpath query into it and GET, the resulting nodes will be
returned.
Example: GET /node/5/xpath/parent/mother
would return the grand mothers of this node.
A cool feature that this would also enable is that we could expose URI
templates for doing the same kind of xpath traversals from the result set
of
an index lookup by exposing a URI template like this one:
/index/node/{key}/{value}/xpath/{xpath}
Example: GET /index/node/name/Mattias/xpath/child
would return the children of all nodes with 'name' = 'Mattias'
So, what do you guys think?
--
Mattias Persson, [matt...@neotechnology.com]
Neo Technology, www.neotechnology.com
___
Neo mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user
___
Neo mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user
--
Tobias Ivarsson tobias.ivars...@neotechnology.com
Hacker, Neo Technology
www.neotechnology.com
Cellphone: +46 706 534857
___
Neo mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] XPath in REST API
Mattias Persson schrieb am 30.03.2010 um 15:02:19 (+0200): We're discussing how to expose traversers in the REST API. One of the ideas that was brought up (more emails with the rest of the ideas are coming) was to use xpath directly in the URIs. I have some experience working with XSLT and XPath, and I'm probably missing the context here, so I'm wondering: You're probably just considering using some subset of XPath? Like self, child and attribute axes? Because even 1.0 gives you considerable power in navigating trees [1], not to mention 2.0, which has conditional branching, loops and lots more. Also, XPath being for trees, do you constrain the graph to tree form? [1] http://www.xmlplease.com/axis -- Michael Ludwig ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] XPath in REST API
Hi Marko, Marko Rodriguez schrieb am 30.03.2010 um 12:50:21 (-0600): Also, XPath being for trees, do you constrain the graph to tree form? XPath easily generalizes to work for graphs. See http://gremlin.tinkerpop.com and more specifically, http://wiki.github.com/tinkerpop/gremlin/basic-graph-traversals ... However, the // recursion operator can get out of control. That's very interesting! What about cycles? A --knows-- B --knows-- C --knows-- A# or A --knows-- B --knows-- C --knows-- B Will the traverser follow these? Or does it maintain a map of seen edges and/or vertices so it will avoid cycles? 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)? -- Michael Ludwig ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] XPath in REST API
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
Re: [Neo] XPath in REST API
Hi Marko, Marko Rodriguez schrieb am 30.03.2010 um 16:01:42 (-0600): Ha. There is a Gremlin mailing list if you are **super** interested :). http://groups.google.com/group/gremlin-users ... However, don't even try and join unless you are SUPER interested. :P Thanks - too late, I already joined :-) Will be lurking, for the moment. I hope not to annoy people too much by continuing what has started here. Exactly. People tend to forget this point---thats why I stress it. Vertices are adjacent to edges and edges are adjacent to vertices. HyperGraphDB [ http://www.kobrix.com/hgdb.jsp ] throws that distinction out of the water and says all there is are 'atoms' and 'atoms' can be adjacent to each other. By making a distinction between edges and vertices, you are saying that an edge is a binary relationship between two vertices---this makes it a regular graph as opposed to a hypergraph. Neo4j/Gremlin/RDF/and_lots_others are regular graphs. Thanks for explaining. I wasn't aware of hypergraphs. Sounds pretty experimental. I understand outE, inE and bothE. Edges may have a direction (or two, or none - depending on the point of view), so in/out/both looks like the logical thing to do. But what about outV and inV? Vertices aren't directional, are they? Yea---outV means the outgoing vertex from the edge (the tail of the edge). inV means the incoming vertex of the edge (the head of the edge). In Neo4j speak, its startNode and endNode, respectively. Excuse my insolence, but couldn't you simplify by letting the user say: outE/V# bound to be an inV inE/V # bound to be an outV outE/outV # confusing way of saying (in XPath) self::node() inE/inV # ditto Best, -- Michael Ludwig ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] XPath in REST API
Hey, outE/outV # confusing way of saying (in XPath) self::node() inE/inV # ditto .I supposebut once you get to an edge, you need to specify where you want to go next (the tail or the head of the edge).. ? The outE/V convention would mean you have to know that you did outE the prior step to infer you mean the head of the edge at the next step... no? If you really care, you can define a path: path forward ./outE/inV end path backward ./inE/outV end Then you can do: ./forward/forward/forward :). See ya, Marko. ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
