Hi,
> Now that looks interesting! But why limit it to a pipe and not merge
> it with the Graph Matching component, so we can find non-linear
> subgraphs with the same API? Or did I misunderstand the concept?
Graph matching can be seen as a subset of graph traversal. Meaning,
any graph matc
On Tue, Mar 15, 2011 at 9:11 AM, Mattias Persson
wrote:
> I'm positive that some nice API will enter the kernel at some point, f.ex.
> I'm experimenting with an API like this:
>
> for(Node node :
> PipeBuilder.fromNode(startNode).into(otherNode(A)).into(otherNode(B)).nodes())
> {
> // node
2011/3/15 Craig Taverner
> >
> > > One question before I dive into this... Do the Traversal framework
> > > involve performance improvements over the core API as shown in your
> > > example?
> >
> > It doesn't currently, since it's using the core API. But I think the goal
> > is
> > to have it "d
2011/3/15 Craig Taverner
> Fantastic. Very nice.
>
> I guess this was also inspired by Marco's Gremlin and pipes?
>
> (so the use case is now well understood?)
>
Absolutely, haven't looked at Marcos pipes code though... be conceptually
it's right up that ally.
>
> On Tue, Mar 15, 2011 at 11:33
>
> > One question before I dive into this... Do the Traversal framework
> > involve performance improvements over the core API as shown in your
> > example?
>
> It doesn't currently, since it's using the core API. But I think the goal
> is
> to have it "drop down" one level in order to gain perfor
Fantastic. Very nice.
I guess this was also inspired by Marco's Gremlin and pipes?
(so the use case is now well understood?)
On Tue, Mar 15, 2011 at 11:33 AM, Mattias Persson wrote:
> Already though of that :) behold:
>
> PipeBuilder.fromNode(startNode).into(otherNode(A))
> .into(traver
2011/3/15 Massimo Lusetti
> On Tue, Mar 15, 2011 at 9:11 AM, Mattias Persson
> wrote:
>
> > more advanced. If you would like to force the traversal down a very
> defined
> > path then go with the core API, like:
> >
> > for(Relationship relA : startNode.getRelationships(A)) {
> > Node node
Already though of that :) behold:
PipeBuilder.fromNode(startNode).into(otherNode(A))
.into(traverse(myTraversalDescription))
.into(traverse(myOtherTraversalDescription))
.into(otherNode(B));
Or whatever. You can even use other "from", f.ex: fromNode, fromNodes,
fromPath, fromP
On Tue, Mar 15, 2011 at 9:11 AM, Mattias Persson
wrote:
> more advanced. If you would like to force the traversal down a very defined
> path then go with the core API, like:
>
> for(Relationship relA : startNode.getRelationships(A)) {
> Node nodeA = relA.getOtherNode(startNode);
> for(
I like the pipes idea. What I would like to see is nested traversers. The
pipe example below seems to imply single hops at each step, but it would be
nicer to allow each step to traverse until it reached a certain criteria, at
which point a different traversal would take over.
In the old and curre
On Tue, Mar 15, 2011 at 9:11 AM, Mattias Persson
wrote:
> I'm positive that some nice API will enter the kernel at some point, f.ex.
> I'm experimenting with an API like this:
>
> for(Node node :
> PipeBuilder.fromNode(startNode).into(otherNode(A)).into(otherNode(B)).nodes())
> {
> // node w
> Cool didn't thought about that... And the order of relationships() is
> the order I want different Relationship should be traversed right?
>
>
A traverser will try to go to all of these relationships on each node it
gets to and order isn't guaranteed. However you can control that order so
that fo
On Mon, Mar 14, 2011 at 3:17 PM, Mattias Persson
wrote:
> Could you describe a bit what kind of traversal you're doing?
I got nodes that describe a base of our organization, each nodes has
relationships with nodes that describe the network used in the base,
each network nodes has relationships w
On Mon, Mar 14, 2011 at 3:13 PM, Mattias Persson
wrote:
> Would you like to do a traversal where relationships of different types can
> be traversed? That can/should be done with one traversal, one
> TraversalDescription:
>
> Traversal.description()
> .relationships(KNOWS, Direction.OUTGOIN
Could you describe a bit what kind of traversal you're doing?
2011/3/14 Mattias Persson
> Would you like to do a traversal where relationships of different types can
> be traversed? That can/should be done with one traversal, one
> TraversalDescription:
>
> Traversal.description()
> .rel
Would you like to do a traversal where relationships of different types can
be traversed? That can/should be done with one traversal, one
TraversalDescription:
Traversal.description()
.relationships(KNOWS, Direction.OUTGOING)
.relationships(LOVES)
.relationships(SOMETHING, Dire
I'm using the Traversal framework
(http://wiki.neo4j.org/content/Traversal_Framework) and I would like
to know if I'm using it the way it has thought to be.
I need to deeply traverse the graph going down through different
RelationshipTypes so I do a first TraversalDescription and while
iterating t
Hi there,
I think something like returning all but the start node would do the
trick in this special, see
http://api.neo4j.org/1.2/org/neo4j/graphdb/ReturnableEvaluator.html#ALL_BUT_START_NODE
or similar.
More generally, if you want to see the history of things, you can
examine the provided PATH
Marko, I don't understand what you are trying to say.
Is the question about finding, given a person node, the co-creators for that
person on any project? Or is it about reasoning in the abstract co-creator
graph. I was under the impression that finding co-creators was the only
thing we were intere
Hi,
Just to be picky:
>> The easiest way to do that in this case is by adding:
>> .uniqueness(Uniqueness.NODE_PATH)
A co-creator's co-creator can be you. Thus, marko's co-creator's co-creator is
marko (amongst other people). In this case, unique on a path would not fail,
no? Can you do somethi
On Sun, Feb 20, 2011 at 7:04 PM, Marko Rodriguez wrote:
> Hi,
>
> > Traversal.description()
> > .depthFirst()
> > .relationships(RelationshipTypes.CREATED, Direction.BOTH)
> > .traverse(developer).nodes()
>
> To be clear, a co-creator is someone is who has created the same things as
> you and who
Hi,
> Traversal.description()
> .depthFirst()
> .relationships(RelationshipTypes.CREATED, Direction.BOTH)
> .traverse(developer).nodes()
To be clear, a co-creator is someone is who has created the same things as you
and who is not you. Thus, you need to go outgoing CREATED, then incoming
CREATE
Thanks.
On Sun, Feb 20, 2011 at 2:24 PM, Tobias Ivarsson
wrote:
> On Sun, Feb 20, 2011 at 10:48 AM, Alfredas Chmieliauskas <
> al.fre...@gmail.com> wrote:
>
>> Dear all,
>>
>> could somebody point me to more documentation on the new traversal
>> framework (besides http://wiki.neo4j.org/content/Tr
On Sun, Feb 20, 2011 at 10:48 AM, Alfredas Chmieliauskas <
al.fre...@gmail.com> wrote:
> Dear all,
>
> could somebody point me to more documentation on the new traversal
> framework (besides http://wiki.neo4j.org/content/Traversal_Framework)?
> Also the new Evaluator and how to use it?
>
That pag
Dear all,
could somebody point me to more documentation on the new traversal
framework (besides http://wiki.neo4j.org/content/Traversal_Framework)?
Also the new Evaluator and how to use it?
If we have a graph described in the pipes Co-Developers example
(https://github.com/tinkerpop/pipes/wiki/Us
Hi Joshi,
the problem may be that your traversal description will traverse from
actor to director (in both directions) and also from director to
actors (also in both directions).
Your "manual" traverser traverses actors to directors in both
directions and then only incoming relationships from dir
I have graph of 2 types of nodes : actors and directors. The graph is
constructed such that an actor may have worked with multiple directors
and the director may have worked with different actors. The objective is
to find the list of actors (sorted by frequency) who have shared the
most number of d
Committed now, feedback is very welcome!
2010/11/19 David Montag
> Then I prefer the first set, doesn't hurt to be explicit. Simply reads
> better with less thinking imo.
>
> David
>
> On Thu, Nov 18, 2010 at 10:41 PM, Mattias Persson <
> matt...@neotechnology.com
> > wrote:
>
> > Maybe instead:
Then I prefer the first set, doesn't hurt to be explicit. Simply reads
better with less thinking imo.
David
On Thu, Nov 18, 2010 at 10:41 PM, Mattias Persson wrote:
> Maybe instead:
>
> INCLUDE_AND_CONTINUE,
> INCLUDE_AND_PRUNE,
> EXCLUDE_AND_CONTINUE,
> EXCLUDE_AND_PRUNE,
>
> because "stop" so
Maybe instead:
INCLUDE_AND_CONTINUE,
INCLUDE_AND_PRUNE,
EXCLUDE_AND_CONTINUE,
EXCLUDE_AND_PRUNE,
because "stop" sounds that the traverser is stopping, where it's really just
stopping that particular branch, i.e. prunes that branch. Or maybe even:
INCLUDE,
INCLUDE_AND_PRUNE,
EXCLUDE,
EXCLUDE_AND_
Fantastic! I have yet to try the implementation out, but I'm positive that
it's an improvement. The only comment I have right now is the use of the
word "SKIP". IMO it is ambiguous with respect to stopping vs excluding. I
prefer EXCLUDE. Will try it out soon. Thanks Mattias!
David
On Thu, Nov 18,
2010/11/18 Mattias Persson
> I just spent less than two hours making this change locally and everything
> works and it generally feels great. Now that I've tried it out myself, this
> way of controlling pruning/filtering feels more awesome. I'll post some
> examples soon so that you can feedback
I just spent less than two hours making this change locally and everything
works and it generally feels great. Now that I've tried it out myself, this
way of controlling pruning/filtering feels more awesome. I'll post some
examples soon so that you can feedback :)
2010/11/10 Mattias Persson
> I'
I've also thought about it, because if you think about it... pruning is just
really there for performance issues and it may be possible to combine
filtering/pruning somehow, yes.
2010/11/7 Yaniv Ben Yosef
> It's a personal taste, but I'm not sure I like all those permutations in
> combined value
It's a personal taste, but I'm not sure I like all those permutations in
combined values.
Perhaps you'll consider that the evaluator would return an object with two
enums:
1. STOP / CONTINUE
2. INCLUDE / EXCLUDE
This will also make it easier to extend the evaluator, so if additional
state is need
David,
I have been noticing the same and came to a similar conclusion. Pruning and
filtering are often used with the same logic. Maybe we could introduce a
combined interface and see if that works better?
/peter - From my cellphone, please excuse typos and brevity...
On Nov 5, 2010 7:56 PM, "David
Hi all,
Hopefully most of you are familiar with the traversal framework that was
introduced in 1.1. It's powerful and provides for reusable traversal
descriptions. It has some flaws though, and I would like to discuss one of
them here.
The traversal framework has this concept of pruning, which ba
37 matches
Mail list logo
