Received: by 10.204.143.143 with SMTP id v15mr1456179bku.8.1335561750944; Fri, 27 Apr 2012 14:22:30 -0700 (PDT) X-BeenThere: neo4j@googlegroups.com Received: by 10.204.5.133 with SMTP id 5ls881701bkv.0.gmail; Fri, 27 Apr 2012 14:22:28 -0700 (PDT) Received: by 10.204.143.143 with SMTP id v15mr1456175bku.8.1335561748701; Fri, 27 Apr 2012 14:22:28 -0700 (PDT) Received: by 10.204.143.143 with SMTP id v15mr1456174bku.8.1335561748658; Fri, 27 Apr 2012 14:22:28 -0700 (PDT) Return-Path: Received: from mail-bk0-f48.google.com (mail-bk0-f48.google.com [209.85.214.48]) by gmr-mx.google.com with ESMTPS id k15si8861190bks.0.2012.04.27.14.22.28 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Apr 2012 14:22:28 -0700 (PDT) Received-SPF: pass (google.com: domain of michael.hun...@neopersistence.com designates 209.85.214.48 as permitted sender) client-ip=209.85.214.48; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of michael.hun...@neopersistence.com designates 209.85.214.48 as permitted sender) smtp.mail=michael.hun...@neopersistence.com Received: by mail-bk0-f48.google.com with SMTP id jf20so903583bkc.7 for ; Fri, 27 Apr 2012 14:22:28 -0700 (PDT) d=google.com; s=20120113; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer:x-gm-message-state; bh=zx7vdLQ3q85TdddWA+VcqaDYW1Fy5HCfnFmp9OrZIGo=; b=YRVgpPFoNS+0lQA2kT2ZS4h3kHZeCp/KnIs0kA2zp7ApQhrGlYeOmAxYYhvnLMwESG OemVf3doMh75MCc5tcd6ZyzH3zj5CMPFQJd0cxBX6y/+vNzF5603IKOk9wfTc5NdGGck QTfemaWhXMhdHUGG/JdGuNailWIt5ESGlJDMFGC1XDipjCHRoCVoszmS7J9kZH0+iH76 UfdemQ5FUdAbeQNonQOv+BzuOA66a6Hgq4mhGQXsykUhxnDLNoLDnNxyuApW2+oi74YT FQJHXzp2F3gClLAGulNaA4uan5csvU3/EX66+TcWwEYmqq0lGVn1VtMty8RBvmRljR8I iy5A== Received: by 10.204.152.132 with SMTP id g4mr2211475bkw.88.1335561748308; Fri, 27 Apr 2012 14:22:28 -0700 (PDT) Return-Path: Received: from [192.168.111.125] (146-52-56-51-dynip.superkabel.de. [146.52.56.51]) by mx.google.com with ESMTPS id z14sm13623976bky.15.2012.04.27.14.22.25 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Apr 2012 14:22:26 -0700 (PDT) From: Michael Hunger Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-3-772259290 Subject: Re: [Neo4j] News feed and relationships (Cypher) Date: Fri, 27 Apr 2012 23:22:24 +0200 In-Reply-To: <33329714.115.1335560583779.JavaMail.geo-discussion-forums@ynfo5> To: neo4j@googlegroups.com References: <3019445.682.1335539918338.JavaMail.geo-discussion-forums@ynbv35> <24853E90-85D5-4F96-A258-13833DB48...@neotechnology.com> <26463669.2821.1335558671681.JavaMail.geo-discussion-forums@vbxz8> <33329714.115.1335560583779.JavaMail.geo-discussion-forums@ynfo5> Message-Id: <686D057B-D5F8-4261-96E6-001A956EB...@neotechnology.com> X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQl5V8Qg3B1ehzfUuZLhWXqUu8uQdrW0UEYdZShP/zMQATevsqRm+yMkSzje1sI3/0knQneB --Apple-Mail-3-772259290 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Ok, if you don't know the relationship direction then it gets trickier, we should add functions for determining the direction, start- and = end-node to cypher anyway. What you can do is to have two blocked properties which contain just the = ID of the node that is blocked. so you can compare=20 (r.block1 =3D ID(a) || r.block2=3D ID(a) -> a is blocked (r.block1 =3D ID(b) || r.block2=3D ID(b) -> b is blocked Michael Am 27.04.2012 um 23:03 schrieb Fabio Tarantino: > Hi Micheal, > could you explain me how to convert the blocked-rel to a property on = the knows relationship, please? > Note that i can't query a-[:KNOWS]->b but a-[:KNOWS]-b (i.e. without = direction) >=20 > thanks again, > Fabio >=20 >=20 >=20 >=20 > On Friday, April 27, 2012 10:40:01 PM UTC+2, Michael Hunger wrote: > fabio i meant numeric values of 0,1,2,3 for the blocked property >=20 > A second blocked relationship might be possible, depends on how many % = of your users block things. >=20 > You can give the blocked-rel a try, if it doesn't work out it is = pretty simple to convert it back to a property on the knows = relationship. > It is faster to just check the relationship-type. >=20 > start .... > match a-[:KNOWS]->b > where not(a-[:BLOCKS]->b) >=20 > Michael >=20 > Cheers >=20 > Michael >=20 >=20 > Am 27.04.2012 um 22:31 schrieb Fabio Tarantino: >=20 >> Hi Michael, >> thank you for your quick response! >> Though that solution seems don't work for me... How could i = distinguish who blocks who, using properties in a simple way (i.e. with = a generic cypher query)? >>=20 >> Suppose r is the relationship between A and B, and r.block is the = property. >> Look at these two queries: >> 1) match A-[r:knows]-B where r.block =3D ??=20 >> 2) match B-[r:knows]-A where r.block =3D ?? >> the r.block property has obviously the same value, but in the first = query i only know the ID of A and B is unknown, viceversa for the second = query. >> How i could express a semantic value in the correct order? >>=20 >> What do you think about using another relationship? for example: >> match A-[r:knows]-B, A-[!:blocks]->B where ... >> is it faster than evaluating on properties? >>=20 >>=20 >> thanks, >> Fabio >>=20 >> =20 >>=20 >> On Friday, April 27, 2012 5:53:54 PM UTC+2, Michael Hunger wrote: >> Fabio, >>=20 >> you could have 2 properties (or one with a 3 state value 0 no block, = 1 A blocks B, 2 B blocks A, 3 both block each other) that indicate = direction of the block (or contain also semantic values about _what_ is = blocked) >>=20 >> for your news-streams please look at the work around graphity by Ren=E9= Pickardt >>=20 >> see: http://www.youtube.com/watch?v=3D_e62dBot-LY >> and: = http://www.rene-pickhardt.de/graphity-an-efficient-graph-model-for-retriev= ing-the-top-k-news-feeds-for-users-in-social-networks/ >>=20 >> Cheers >>=20 >> Michael >>=20 >> Am 27.04.2012 um 17:18 schrieb Fabio Tarantino: >>=20 >>> Hi, >>> i have a simple question on how to model a typical newsfeed for a = social network... >>>=20 >>> My model consists of users and posts as nodes. Users are linked to = other users with the "KNOWS" relationship. Users are linked to posts = with the "WRITES" relationship. >>> I know that i can traverse relationships in a bidirectional way, so = i could query all post nodes of a friend B of user A. >>> START n=3Dnode(A) MATCH n-[r:KNOWS]-B-[t:WRITES]->post RETURN B,post >>>=20 >>> Now i would introduce a blocking feature to not show posts of = blocked friends. To do so i added a "block" property on the "KNOWS" = relationship: >>> START n=3Dnode(A) MATCH n-[r:KNOWS]-B-[t:WRITES]->post WHERE = t.block=3D0 RETURN B,post >>>=20 >>> That query works but it's not correct because if A-KNOWS-B then A = could block B but not viceversa.=20 >>> So i need two KNOWS relationship between A and B ? Or there is a = more efficient method? >>>=20 >>> thanks, >>> Fabio >>=20 >=20 --Apple-Mail-3-772259290 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Ok, = if you don't know the relationship direction then it gets = trickier,

we should add functions for determining the = direction, start- and end-node to cypher = anyway.

What you can do is to have two blocked = properties which contain just the ID of the node that is = blocked.

so you can = compare 
(r.block1 =3D ID(a) || r.block2=3D ID(a) -> a = is blocked
(r.block1 =3D ID(b) || r.block2=3D ID(b) -> b is = blocked

Michael

Am = 27.04.2012 um 23:03 schrieb Fabio Tarantino:

Hi = Micheal,
could you explain me how to convert the blocked-rel to = a property on the knows relationship, please?
Note that i can't query = a-[:KNOWS]->b but a-[:KNOWS]-b (i.e. without = direction)

thanks = again,
Fabio




On Friday, April 27, 2012 = 10:40:01 PM UTC+2, Michael Hunger wrote:
fabio i = meant numeric values of 0,1,2,3 for the blocked = property

A second blocked relationship might be = possible, depends on how many % of your users block = things.

You can give the blocked-rel a try, if = it doesn't work out it is pretty simple to convert it back to a property = on the knows relationship.
It is faster to just check the = relationship-type.

start ....
match = a-[:KNOWS]->b
where = not(a-[:BLOCKS]->b)

Michael

Cheers

Michael

Am 27.04.2012 um 22:31 schrieb Fabio = Tarantino:

Hi Michael,
thank you = for your quick response!
Though that solution seems don't work for = me... How could i distinguish who blocks who, using properties in a = simple way (i.e. with a generic cypher query)?

Suppose r is the = relationship between A and B, and r.block is the property.
Look at = these two queries:
1) match A-[r:knows]-B where r.block =3D ??
2) = match B-[r:knows]-A where r.block =3D ??
the r.block property has = obviously the same value, but in the first query i only know the ID of A = and B is unknown, viceversa for the second query.
How i could express = a semantic value in the correct order?

What do you think about = using another relationship? for example:
match  A-[r:knows]-B, = A-[!:blocks]->B where ...
is it faster than evaluating on = properties?


thanks,
Fabio

 

On Friday, = April 27, 2012 5:53:54 PM UTC+2, Michael Hunger wrote:
Fabio,

you could have = 2 properties (or one with a 3 state value 0 no block, 1 A blocks B, 2 B = blocks A, 3 both block each other) that indicate direction of the block = (or contain also semantic values about _what_ is = blocked)

for your news-streams please look at = the work around graphity by Ren=E9 = Pickardt

see: http://www.youtube.com/watch?v=3D_e62dBot-LY

Cheers

=
Michael

Am 27.04.2012 um 17:18 = schrieb Fabio Tarantino:

Hi,
i = have a simple question on how to model a typical newsfeed for a social = network...

My model consists of users and posts as nodes. Users = are linked to other users with the "KNOWS" relationship. Users are = linked to posts with the "WRITES" relationship.
I know that i can = traverse relationships in a bidirectional way, so i could query all post = nodes of a friend B of user A.
START n=3Dnode(A) MATCH = n-[r:KNOWS]-B-[t:WRITES]->post RETURN B,post

Now i would = introduce a blocking feature to not show posts of blocked friends. To do = so i added a "block" property on the "KNOWS" relationship:
START = n=3Dnode(A) MATCH n-[r:KNOWS]-B-[t:WRITES]->post WHERE t.block=3D0 = RETURN B,post

That query works but it's not correct because = if  A-KNOWS-B then A could block B but not viceversa.
So i need = two KNOWS relationship between A and B ? Or there is a more efficient = method?

thanks,
Fabio



= --Apple-Mail-3-772259290--