Emil, thanks for the reply. Yes, I think you've understood the problem. My 'evidence' is complex enough that the direct, intuitive solution you mention wasn't sitting well with me, basically due to the brittleness you mention. The moment you starting having .1 and .2 added to strings to indicate different instances all sorts of alarm bells go off in my head.
The middle node solution was something I'd thought about but was unsure how it would work in practice, I'll give that route a try now, thanks. As you say, the one thing you end up loosing in the direct relationship between the database graph and the entity relationship graph. thanks, Jonny On Thu, Sep 25, 2008 at 5:47 PM, Emil Eifrem <[EMAIL PROTECTED]> wrote: > On Fri, Sep 26, 2008 at 12:37 AM, Jonny Wray <[EMAIL PROTECTED]> > wrote: > > Hi, > > > > I'm in the process of moving an application over from an RDF based graph > > store to Neo. So far it's being great but I'm currently hitting a > modelling > > question that I'm sure some experience with the technology would help, > and > > so I'm asking the group. > > Hi Jonny, > > I *think* I understand your problem and basically the solution will be > depending on the complexity of the evidence data. If it's fairly > complex, I think injecting a middle node will be the best way. So when > node1 is SIMILAR related (just making this up) to node2, then instead > of the obvious: > > ( node1 ) -- SIMILAR --> ( node2 ) > > you would model it like this: > > ( node1 ) -- SIMILAR --> ( node14 ) -- SIMILAR --> ( node2 ) > > Node 14 in this diagram is the middle node, and you an attach whatever > information you want to it, either in the form of properties or for > example separate evidence nodes that aggregate data for a single piece > of evidence and that attach to node14 through e.g. a > SUPPORTING_EVIDENCE relationship. > > But if your evidence data is simple enough, it may be enough to just > connect the nodes with a relationship and then add the data as > key-encoded properties. For example: > > ( node1 ) -- SIMILAR --> ( node2 ) > > And then on the relationship, you would have properties like: > > evidence1.origin = something > evidence1.weight = 0.8f > evidence2.origin = somethingelse > evidence2.weight = 0.4f > > The advantage with the middle node design is that the node space > layout in a sense is more clean and flexible. But it loses out on > intuition and "white-board friendliness." > > The advantage with the second layout is that it's the intuitive and > obvious way to model this data. It also keeps the number of primitives > down. The disadvantage is that it's brittle to encode information in > the names of the property keys. (How do you delete one piece of > evidence? Gotta loop through all keys and do string matching. Yuk!) > > Which one is the better choice I believe comes down to personal > preference and the specifics of the actual domain. > > Does that make sense or did I misunderstand the use case? > > Cheers, > > -- > Emil Eifrém, CEO [EMAIL PROTECTED] > Neo Technology, www.neotechnology.com > Cell: +46 733 462 271 | US: 206 403 8808 > _______________________________________________ > Neo mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
