Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion smells like sql spirit

Received: by 10.50.170.72 with SMTP id ak8mr5960887igc.0.1349701497625;
        Mon, 08 Oct 2012 06:04:57 -0700 (PDT)
X-BeenThere: neo4j@googlegroups.com
Received: by 10.42.249.136 with SMTP id mk8ls12823784icb.9.gmail; Mon, 08 Oct
 2012 06:04:55 -0700 (PDT)
Received: by 10.42.57.79 with SMTP id c15mr9765451ich.33.1349701495736;
        Mon, 08 Oct 2012 06:04:55 -0700 (PDT)
Received: by 10.42.57.79 with SMTP id c15mr9765450ich.33.1349701495726;
        Mon, 08 Oct 2012 06:04:55 -0700 (PDT)
Return-Path: <rot...@manta.com>
Received: from cmhvm005.ecnext03.local (mail.manta.com. [207.86.232.21])
        by gmr-mx.google.com with ESMTPS id dx8si1170544igc.1.2012.10.08.06.04.55
        (version=TLSv1/SSLv3 cipher=OTHER);
        Mon, 08 Oct 2012 06:04:55 -0700 (PDT)
Received-SPF: pass (google.com: domain of rot...@manta.com designates 207.86.232.21 as permitted sender) client-ip=207.86.232.21;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of rot...@manta.com designates 207.86.232.21 as permitted sender) smtp.mail=rot...@manta.com
Received: from CMHVM005.ecnext03.local ([192.168.240.27]) by cmhvm005
 ([192.168.240.27]) with mapi id 14.01.0355.002; Mon, 8 Oct 2012 09:04:54
 -0400
From: Rick Otten <rot...@manta.com>
To: "neo4j@googlegroups.com" <neo4j@googlegroups.com>
Subject: RE: [Neo4j] smells like sql spirit
Thread-Topic: [Neo4j] smells like sql spirit
Thread-Index: AQHNpIZdqI3TdbjcG0+twZ3VZEGGe5evYK4A
Date: Mon, 8 Oct 2012 13:04:53 +0000
Message-ID: <362605510214004CB3313A03D3D697DE75146081@cmhvm005>
References: <507173E6.1090107@gmail.com>
In-Reply-To: <507173E6.1090107@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.240.63]
x-tm-as-product-ver: SMEX-10.1.0.1137-7.000.1014-19252.004
x-tm-as-result: No--27.808900-5.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Don't fans watch matches rather than teams?
   fan1-[:has_seen]->m1  ?

It sounds like you want to apply a 'weight' (rating) of some sort to the te=
am nodes so that you can predict future matches, or at least advertise "the=
 fans' choice" for the better team in the match.=20

Perhaps -- fan1-[:rate]->team1   (if fan1 has seen a match where team1 play=
ed)

Team1's total and aggregate rating is collected from the inbound [:rate] re=
lationships.

-----Original Message-----
From: neo4j@googlegroups.com [mailto:neo4j@googlegroups.com] On Behalf Of g=
mail
Sent: Sunday, October 07, 2012 8:22 AM
To: neo4j@googlegroups.com
Subject: [Neo4j] smells like sql spirit

hi,

i have a modelling problem, that reminds me of fk-tables in RDBMS. i think =
i might be missing something obvious.


my model looks like:

team1-[:IS_PARTICIPATING_IN]->m1<-[:IS_PARTICIPATING_IN]-team2
team1-[:IS_PARTICIPATING_IN]->m2<-[:IS_PARTICIPATING_IN]-team3
team1-[:IS_PARTICIPATING_IN]->m3<-[:IS_PARTICIPATING_IN]-team4


(m1, m2, m3 are sports matches)


i want to introduce user rating, so that a number of users can rate a=20
given team participating in a given match.

so my first thought was to introduce a User node and a HAS_SEEN=20
relationship:

approach A
----------
# first sports match (User 1)
user1-[:HAS_SEEN]->team1
HAS_SEEN relationship properties could be {stars: 5, sportsmatch:1}

user1-[:HAS_SEEN]->team1
HAS_SEEN relationship properties could be {stars: 6, sportsmatch:1}


# second sports match (User 1)
user1-[:HAS_SEEN]->team1
HAS_SEEN relationship properties could be {stars: 7, sportsmatch:2}
user1-[:HAS_SEEN]->team3
HAS_SEEN relationship properties could be {stars: 8, sportsmatch:2}


# first sports match (User 2)
user2-[:HAS_SEEN]->team1
HAS_SEEN relationship properties could be {stars: 9, sportsmatch:1}
user2-[:HAS_SEEN]->team2
HAS_SEEN relationship properties could be {stars: 10, sportsmatch:1}


in the above model the relation between user rating and=20
team-participating is leveraged at the HAS_SEEN property level. ugly.



approach B
----------
i have also played with the introduction of an additional "Rating" node:

user1-[:HAS_CREATED_RATING]->rating->[:RATING_OF_TEAM_IN_A_MATCH],
rating->[:IS_A_RATING_OF_TEAM]-team1,
rating->[:IS_A_RATING_OF_MATCH]-m1,

RATING_OF_TEAM_IN_A_MATCH relationship properties could be {stars:5}




it feels like what i really want is to connect a user rating directly to=20
en existing relationship (eg. the IS_PARTICIPATING_IN relationship in=20
team1-[:IS_PARTICIPATING_IN]->m1 ) since the user is not really rating a=20
team or a match but a team participating in a match.


any pointers to better approaches would be much appreciated

thanks
./allan

--=20