[Neo] More first (and a little more) impressions

Jonny Wray jwray.develop at gmail.com
Wed Dec 3 05:41:17 CET 2008


Hi,
Following on from a couple of recent posts and points that were raised I
thought I'd outline some of my impressions of using Neo over the last 2-3
months and hopefully it'll be useful to some and/or start some discussion.

i) Indexing and querying. One of my use cases needed the ability to query
node properties using complex queries - basically exactly the thing Lucene
provides. Now, having used the Compass project very successfully in another
project I looked there as a potential solution over and above the provided
Lucene indexer. It was pretty easy to get integrated via their resource
concept and it provides i) transactions ii) configuration via and
integration with Spring (eg @Transactioned) iii) ability to define
searchable resources, type mappings and various other Lucene properties in
configurations files. Could be a potential starting point of better
integrated indexer that has been mentioned a few times? The project also has
event based integration with various ORM technologies so it's not too much
of a stretch to think that it could be extended to provide event based index
updating in Neo.

ii) Remote access. This was an initial worry about the applicability of Neo
to my project. My clients are Swing based and so distributed and need to
talk to a server to get their data. The solution I'm currently using, which
is working well, is a service using Neo as an underlying data store that
sends either GraphML or TreeML documents back to my swing clients, depending
on the use case. This initially required a little rework of the solution I
was migrating from (an RDF store accessed remotely) but I actually think
it's improved the architecture of the solution. The GraphML and TreeML
representations are being used since the display technology I'm using,
prefuse, has the capability of reading that format and I went with that for
ease of prototype development. So far it's working well and I have no plans
of moving to another data transfer format.

iii) Data entry. My project is aimed at integrating data from multiple
different sources and so one of the very nice features of the Sesame RDF
store I was previously using was the ability to import datasources from
common file formats. Neo has no such capability and it is missed, although
it also wasn't too hard to invent my own and write the parsers for it.

iv) Data updated. Another requirement of my project is the ability to update
data in the graph as new versions become available. Since I'm taking data
from multiple different sources these updates don't happen concurrently, but
they do occur as a batch release requiring a deletion of the old data
followed by an insert of the new. The sesame store had a nice solution to
this exact problem (which was driven by real life experience) in that data
could be tagged with a specific context and data in a specific context could
be deleted, and re-uploaded, independently from the rest of the graph. I'm
still thinking about ways to achieve something similar with Neo.

v) Graph data format. The reason I am using Neo and was previously using RDF
is that the data I'm working with is naturally a graph, and so they make
sense. What I ended up disliking about RDF is that everything is treated as
a graph node and relationships, and so the semantic graph of entity
relationships gets confused with the syntatic graph of representing entity
properties. This led to some very nasty code to tease these apart. Neo gets
over this by providing node (and edge) properties that allow entity (and
relationship) properties to be represented naturally resulting in a clean
graph of entity relationships.

vi) The other major advantage Neo has over RDF is traversal. I have use
cases that need it and it was my feeble attempts to implement this over an
RDF store that was the final straw that made me move to Neo. I'm still
learning to appreciate the power of traversals and this, at least for me,
was the major conceptual hurdle in using Neo.

thanks,
Jonny


More information about the User mailing list