Hijack alert (going completely off topic) I noticed the following statement: "all reasoning is best with a linked list data structure." When looking at the underlying store we see that the RelationshipRecord indeed forms two linked lists, one for the incoming side of the relationship and one for the outgoing side of the relationship, yet the API provides more or less the methods of a Set. The insert mechanism for Relationships guarantees that the two linked lists cannot contain duplicates (hence they form a set). The lists are always prepended, with an entry point to the head of the list stored in the NodeRecord. In the past I have (ad nauseum) proposed a partitioning of the Relationship linked lists per Direction per RelationshipType. I am not going to repeat my arguments, they can be found here: http://lists.neo4j.org/pipermail/user/2011-August/011191.html and in other posts to the mailing list around that time. Partitioning the two linked lists per Direction per RelationshipType, I now realize, also makes it possible to treat the two linked lists as implementations of the LinkedList interface in a meaningful way. For many practical purposes an ordering of Relationships makes little sense when the Relationships of a Node are not grouped by some critieria, but once we apply such a grouping, ordering starts to make sense. The simplest example I can think of is a timeline, where all relationships are either appended or prepended to the linked lists (depending on the preferred timeline arrow), so each iteration over the Relationships of a certain node for a given Direction and RelationshipType will be returned in the insert order (or inverse insert order) of the Relationships. Supporting all methods of a linked list would also allow for constructs like createRelationshipTo(node, SOME_REL, 2, 4), where 2 and 4 represent the positions in the linked lists (throwing IndexOutOfBoundsExceptions when appropriate). Since linked list data structures are foundational to the Neo4j engine it would make sense to make these structures more explicit in the API, so application programmers can take advantage of the inherent ordering of the underlying storage. Many applications eventually present information in some default sort order, so it would be nice if it were possible to insert relationships according to some sort criterion. Niels
> From: [email protected] > Date: Fri, 14 Oct 2011 11:28:16 -0600 > To: [email protected] > Subject: Re: [Neo4j] Article: "The Coming SQL Collapse" > > Hi, > > >> This is not conducive to Baysian-based reasoning, evidential reasoning, > >> other forms of logics (classical and non-classical) .... > > > > How would you model those to a suitable domain model? > > Can you give a good example? > > Michael > > Here is an article that argues for support of other data semantics in the Web > of Data (RDF world) beyond description logics. In here, you will find > examples of other forms of reasoning. > > http://arxiv.org/abs/0905.3378 > > Unlike the triple/quad-store world, graph databases provide a very generic > data model with limited constraints on meaning. Unfortunately (in my > opinion), graph databases like OrientDB and DEX employ typing at the graph > database level. Neo4j provides it at the Spring Data Graph level -- a level > above. This is good in that Neo4j is not pushing a world view to low into the > stack. The world of RDF, on the other hand, and its strong bent towards OWL > (description logic) makes it such that the entire technology stack is mixed > up with this logic. And, while this logic is very cool, its not the only way > to do things -- the only way to view the world. > > ---- however, at some point, there is always an assumption, and the > foundational assumption of graph databases is "all reasoning is best with a > linked list data structure." > > See ya, > Marko. > > http://markorodriguez.com > > _______________________________________________ > Neo4j mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
