i want to introduce user rating, so that a number of users can rate a given team participating in a given match.
so my first thought was to introduce a User node and a HAS_SEEN 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 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:
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 en existing relationship (eg. the IS_PARTICIPATING_IN relationship in team1-[:IS_PARTICIPATING_IN]->m1 ) since the user is not really rating a team or a match but a team participating in a match.
any pointers to better approaches would be much appreciated
> i want to introduce user rating, so that a number of users can rate a given
> team participating in a given match.
> so my first thought was to introduce a User node and a HAS_SEEN
> 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 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:
> 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 en
> existing relationship (eg. the IS_PARTICIPATING_IN relationship in
> team1-[:IS_PARTICIPATING_IN]->m1 ) since the user is not really rating a
> team or a match but a team participating in a match.
> any pointers to better approaches would be much appreciated
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 team nodes so that you can predict future matches, or at least advertise "the fans' choice" for the better team in the match.
Perhaps -- fan1-[:rate]->team1 (if fan1 has seen a match where team1 played)
Team1's total and aggregate rating is collected from the inbound [:rate] relationships.
-----Original Message-----
From: neo4j@googlegroups.com [mailto:neo4j@googlegroups.com] On Behalf Of gmail
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.
i want to introduce user rating, so that a number of users can rate a given team participating in a given match.
so my first thought was to introduce a User node and a HAS_SEEN 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 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:
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 en existing relationship (eg. the IS_PARTICIPATING_IN relationship in team1-[:IS_PARTICIPATING_IN]->m1 ) since the user is not really rating a team or a match but a team participating in a match.
any pointers to better approaches would be much appreciated
Instead of saying:
" Team1's total and aggregate rating is collected from the inbound [:rate] relationships."
I meant to say:
"Team1's total and average ratings could be collected from a weight/(star number) property on the inbound [:rate] relationships.
I also meant to note that fan's could 'follow' teams, which would enable an application to do things such as alert them to upcoming matches, report on rankings and scores and match history, and that sort of thing.
So a given fan might have two relationships to a team - "[rate:]" and "[follows:]" and another relationship to matches "[watched:]".
I meant to say all this, but got interrupted in the midst of my last sentence and hit 'send' instead of finishing my thoughts. Thanks for letting me finish.
-----Original Message-----
From: neo4j@googlegroups.com [mailto:neo4j@googlegroups.com] On Behalf Of Rick Otten
Sent: Monday, October 08, 2012 9:05 AM
To: neo4j@googlegroups.com
Subject: RE: [Neo4j] smells like sql spirit
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 team nodes so that you can predict future matches, or at least advertise "the fans' choice" for the better team in the match.
Perhaps -- fan1-[:rate]->team1 (if fan1 has seen a match where team1 played)
Team1's total and aggregate rating is collected from the inbound [:rate] relationships.
-----Original Message-----
From: neo4j@googlegroups.com [mailto:neo4j@googlegroups.com] On Behalf Of gmail
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.
i want to introduce user rating, so that a number of users can rate a given team participating in a given match.
so my first thought was to introduce a User node and a HAS_SEEN
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 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:
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 en existing relationship (eg. the IS_PARTICIPATING_IN relationship in team1-[:IS_PARTICIPATING_IN]->m1 ) since the user is not really rating a team or a match but a team participating in a match.
any pointers to better approaches would be much appreciated
On Mon, Oct 8, 2012 at 5:59 PM, Rick Otten <rot...@manta.com> wrote:
> Instead of saying:
> " Team1's total and aggregate rating is collected from the inbound [:rate] relationships."
> I meant to say:
> "Team1's total and average ratings could be collected from a weight/(star number) property on the inbound [:rate] relationships.
> I also meant to note that fan's could 'follow' teams, which would enable an application to do things such as alert them to upcoming matches, report on rankings and scores and match history, and that sort of thing.
> So a given fan might have two relationships to a team - "[rate:]" and "[follows:]" and another relationship to matches "[watched:]".
> I meant to say all this, but got interrupted in the midst of my last sentence and hit 'send' instead of finishing my thoughts. Thanks for letting me finish.
> -----Original Message-----
> From: neo4j@googlegroups.com [mailto:neo4j@googlegroups.com] On Behalf Of Rick Otten
> Sent: Monday, October 08, 2012 9:05 AM
> To: neo4j@googlegroups.com
> Subject: RE: [Neo4j] smells like sql spirit
> 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 team nodes so that you can predict future matches, or at least advertise "the fans' choice" for the better team in the match.
> Perhaps -- fan1-[:rate]->team1 (if fan1 has seen a match where team1 played)
> Team1's total and aggregate rating is collected from the inbound [:rate] relationships.
> -----Original Message-----
> From: neo4j@googlegroups.com [mailto:neo4j@googlegroups.com] On Behalf Of gmail
> 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.
> i want to introduce user rating, so that a number of users can rate a given team participating in a given match.
> so my first thought was to introduce a User node and a HAS_SEEN
> 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 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:
> 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
> en existing relationship (eg. the IS_PARTICIPATING_IN relationship in
> team1-[:IS_PARTICIPATING_IN]->m1 ) since the user is not really rating a
> team or a match but a team participating in a match.
> any pointers to better approaches would be much appreciated
i think i will start off something along your suggestion peter, with a participation_team node concept. only i think i will name it slightly different:
> On Mon, Oct 8, 2012 at 5:59 PM, Rick Otten <rot...@manta.com> wrote:
>> Instead of saying:
>> " Team1's total and aggregate rating is collected from the inbound [:rate] relationships."
>> I meant to say:
>> "Team1's total and average ratings could be collected from a weight/(star number) property on the inbound [:rate] relationships.
>> I also meant to note that fan's could 'follow' teams, which would enable an application to do things such as alert them to upcoming matches, report on rankings and scores and match history, and that sort of thing.
>> So a given fan might have two relationships to a team - "[rate:]" and "[follows:]" and another relationship to matches "[watched:]".
>> I meant to say all this, but got interrupted in the midst of my last sentence and hit 'send' instead of finishing my thoughts. Thanks for letting me finish.
>> -----Original Message-----
>> From: neo4j@googlegroups.com [mailto:neo4j@googlegroups.com] On Behalf Of Rick Otten
>> Sent: Monday, October 08, 2012 9:05 AM
>> To: neo4j@googlegroups.com
>> Subject: RE: [Neo4j] smells like sql spirit
>> 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 team nodes so that you can predict future matches, or at least advertise "the fans' choice" for the better team in the match.
>> Perhaps -- fan1-[:rate]->team1 (if fan1 has seen a match where team1 played)
>> Team1's total and aggregate rating is collected from the inbound [:rate] relationships.