Hi David, On Wed, Jul 28, 2010 at 5:36 PM, David Montag <david.mon...@neotechnology.com> wrote: > From your description it sounds like the factors that influence the metric > don't change, so a single calculation per pair is enough. In this case, you > could just determine the pairs in some way and then do the computation, > storing the relationship in Neo4j. You can do it all in one go, nothing > fancy. You would of course have to compute the metric to N peers for each > new user. > > In other scenarios, the factors that influence the metric might change over > time, e.g. a user's city or favorite movie. Then you actually need to keep > recomputing the metric between existing users, and yes, then you probably > want some scheme to make sure that you don't starve some users. You might > for example want to prioritize the most active users first. Again, I don't > know if this applies to your case though.
The preferences of a user can change so recalculating the scores is something I'll probably have to deal with at some point. > As for the indexing, I'm not sure how you would use it here. Like, what kind > of querying were you picturing? Querying for non-related nodes? Like get 10 nodes with attributes blabla that are not related to node_id X. If I understood correctly this type of query is not possible in Neo but it might be possible using indexing? >> > Depending on your scenario, if your users know each other, it might be >> > interesting to start computing in a foaf style order (breadth first). >> > Remember, the power is in the relationships. Isolated nodes are not >> > interesting. >> >> You mean I look first for possible pairs with users that are friends >> of friends instead of randomly? We are also interesting in storing >> friendship relationship so that sounds interesting. >> That would be a different type of query: Traverse the graph from node >> A to nodes which are friends of friends of A and have no match >> relationship with A. I guess that is not difficult to implement using >> Neo4j? >> > > Exactly, so you might want to start with the most relevant other people, > i.e. people you can realistically meet IRL via friends. Don't know if that's > relevant to your application though. > > Neo4j would be a perfect fit for storing friendship relationships between > users. It opens up all kinds of interesting data mining possibilities. > > The FOAF query would be easy to write using the Neo4j APIs, or some other > tool such as Gremlin on top of Neo4j. > > So you could combine the friendship relationships with your processing step > and prioritize active users, and start by checking people close to them in > their social network. Again, if it's relevant. And, as Mattias suggested, if > you can leverage friendship relationships between users, you might be able > to calculate your metric on the fly, given that you limit the search to the > user's extended social network. Of course, if you go deep enough, you might > reach all users this way too. In this app we will compute a lot of scores between users so the relationships of a user will continue growing, specially if he's an active user, and this presents some doubts to me about the way I can find new nodes to calculate the score with... If we manage to map the whole calculation process to Neo4j and do it on the fly I guess we will have more chances and ways to query the graph. For the moment, we don't have relationships like friends. We have favorites which is similar but not bidirectional and there is definitely some potential in that (like: users that have favorited this have also favorited that...) but the score between users still bugs me... _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
