multiple relationship types match with variable length

82 views
Skip to first unread message

Trey Sandworm

unread,
Jul 2, 2012, 10:33:40 AM7/2/12
to ne...@googlegroups.com
nodes: user, group, interest
relationships:
user -> group = membership
user -> interest = interestedin
group -> interest = interestedin

Users are members of groups. Also, users have interests and groups have interests.

I want to recommend groups to a given user using membership and interests criteria.

Part 1: membership criteria only. Give me all co-members of my groups, and return all of their groups that I am not a member of

START n=node(127370)
MATCH n-[:membership]-(c)-[:membership]-x-[r2:membership]-(y)
WHERE y.category = 'group' AND y.is_sub=0 AND (NOT (n-[:membership]-y))
RETURN y.name, r2.weight ORDER BY r2.weight DESC LIMIT 30;

Part 2: interests criteria only. Give me all groups (that I am not a member of) that have same interests as me

START n=node(127370)
MATCH n-[:interestedin]-(d)-[r2:interestedin]-(y)
WHERE y.category = 'group' AND y.is_sub=0 AND (NOT (n-[:membership]-y))
RETURN y.name, r2.weight ORDER BY r2.weight DESC LIMIT 30;


Is there any way currently to merge these 2 into 1 query?

Florent Empis

unread,
Jul 2, 2012, 10:51:41 AM7/2/12
to ne...@googlegroups.com
You could probably group them with a "or" and some coalescing.
May I just question the idea that these queries have to be merged?

Recommending groups based on your co-membership is one thing, recommending things based on interests might be a different one.

I don't know your real use case but say that you're looking at data similar to meetup.com: physical meetups of people sharing a common interest.
Recommending groups to be part of based on co-membership will return groups that may be of interest to me and (and that's the important part) are geographically close to me.
Recommending groups solely based on interests will return groups that discuss my interests (say, graph theory and java). But returning groups located half-way around the world from me is probably not a realistic option.

My two cents reading your queries is that you should recommend on co-membership and then (with neo4j or not), reorder/boost these groups basing your ordering on common interest.
(but I may be completely off... :-) )

BR,

Florent

2012/7/2 Trey Sandworm <timbr...@gmail.com>

Peter Neubauer

unread,
Jul 2, 2012, 11:08:11 AM7/2/12
to ne...@googlegroups.com
Trey,
you could possibly look at

http://docs.neo4j.org/chunked/snapshot/cypher-cookbook-boostingrecommendations.html

and the other sections of
http://docs.neo4j.org/chunked/snapshot/cypher-cookbook.html for
inspiration on different approaches to recommendations?

Cheers,

/peter neubauer

G: neubauer.peter
S: peter.neubauer
P: +46 704 106975
L: http://www.linkedin.com/in/neubauer
T: @peterneubauer

If you can write, you can code - @coderdojomalmo
If you can sketch, you can use a graph database - @neo4j

Trey Sandworm

unread,
Jul 2, 2012, 1:14:01 PM7/2/12
to ne...@googlegroups.com
Thanks for the responses guys.

Florent, 
while I agree that in some scenarios those 2 recommendations can be seperated, you can also see that 
sometimes you simple want to recommend groups to join based on X different criterias (relationships), 
whatever those may be.
All my relationships have a weight property that I use for boosting. 
And that's what I use when I recommend based on few relationships, I simply SUM the weights and order by it DESC.

If a group is recommended to you based on membership and then based on interes too, it would rank higher (membership.weight + interedin.weight).
See example:

The problem here is I guess that 1 relationship results set is 3 hops away, and the other one 2 hops away.

Ideally I need a MATCH like this

[r2:membership*3|interestedin]-(y)

Daniel Corbett

unread,
Jul 3, 2012, 11:01:50 AM7/3/12
to ne...@googlegroups.com
I have a similar problem, but in a different domain space.   The ability to provide an "OR" in a query for the combination of "MATCH" and "WHERE" clauses would be a big benefit to what we are trying to do.

In our case, two separate queries of course CAN be done, but there's absolutely no advantage to them...  and there's a definite performance hit as well, especially with the cost of going through the REST interface.

Thanks,

    - Daniel

Peter Neubauer

unread,
Jul 9, 2012, 9:15:04 AM7/9/12
to ne...@googlegroups.com
Guys,
if you could construct a sample dataset etc, would it make sense to
add this to the existing feature request on UNION at
https://github.com/neo4j/community/issues/505 ?

Cheers,

/peter neubauer

G: neubauer.peter
S: peter.neubauer
P: +46 704 106975
L: http://www.linkedin.com/in/neubauer
T: @peterneubauer

If you can write, you can code - @coderdojomalmo
If you can sketch, you can use a graph database - @neo4j


Reply all
Reply to author
Forward
0 new messages