Patrick has blogged rather extensively[1] on Neo4j[2] but I'm
wondering if anyone has already started work on a Neo4j-based
Topic Map engine, or a backend for an existing Topic Map engine.
I realise I might make some people squirm if I suggested I was
considering implementing a backend for TM4j (given its status).
A more favourable idea might be implementing a backend for Ontopia
or writing a new engine on top of Neo4j directly. The latter could
be a lot more work and would fail to take advantage of all of
Ontopia's other infrastructure but could also be more suitable if
one only had a requirement for providing an engine, or if one were
interested in implementing the TMRM instead of the TMDM.
Anyone already started on something like this in open source, or
planned open source? I hate to reinvent any wheels.
Murray
[1] http://tm.durusau.net/?cat=155
[2] http://neo4j.org/
...........................................................................
Murray Altheim <murray10 at altheim dot com> = = ===
http://www.altheim.com/murray/ === ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = ===
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
_______________________________________________
topicmapmail mailing list
topicm...@infoloom.com
http://www.infoloom.com/mailman/listinfo/topicmapmail
It's not Neo4j but we have built a native NoSQL Semantic store for the
.NET platform. On top of this are three levels of api. A complete
Entity Framework Model (strongly typed with LINQ support), a generic
proxy API (very much like TMRM) and a low level SPARQL API.
While this is a quad store the idea is that the different layers on
top allow people to build different kinds of (meta) model systems. So
TMRM could be done in terms of the generic proxy API for example, and
TMDM *could* be done in terms of the Entity Framework, or you could
build the bits of TMDM you like/ need in RDF and use SPARQL.
We are currently in a developer preview phase so if anyone wants to
have a play with a Native NoSQL Semantic store on .NET then please
take a look at http://www.brightstardb.com.
Cheers,
Graham
--
Graham Moore, Director, Networked Planet Limited
Editor XTM 1.0, ISO13250 (TopicMaps) -2,-3, TMCL
e: graham...@networkedplanet.com
w: www.networkedplanet.com
t: +44 1865 811131
m: +47 90056479 (Norway)
Networked Planet Limited is registered in England and Wales, no. 5273377
I haven't looked at Graham and Kal's BrightstarDB, mostly because I
would have to have a MS Server setup (as I understand it) and that I
don't have. And probably not going to invest in the hardware/software to
create such a platform.
If you have or can obtain access to such a platform, I would love to
hear about BrightstarDB.
On Neo4j, I am curious what you think is required to write a "..new
engine on top of Neo4j directly"?
Being mindful that I don't think of "merging" as re-writing anything but
presenting results to a user as though rewriting had occurred.
That is one of the weaknesses of my diagram of a topic map tool chain. I
under specified what would/could be done by a topic map engine.
BTW, using Neoj would not be implementing the TMRM. That could be, not
necessarily would be, implementing a different data model with different
rules, from the TMDM. Hopefully disclosed so that the results could be
merged with the results of using other legends.
Hope you are having a great week!
Patrick
--
Patrick Durusau
pat...@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
OASIS Technical Advisory Board (TAB) - member
Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau
Hi Patrick,
Yes, I appreciate that Graham and others are doing that work but that's
the same problem I'd have, as I'm on Linux, using Java.
> On Neo4j, I am curious what you think is required to write a "..new
> engine on top of Neo4j directly"?
>
> Being mindful that I don't think of "merging" as re-writing anything
> but presenting results to a user as though rewriting had occurred.
I've been looking at a couple of different approaches.
One is using a separate document store (perhaps off the shelf) and
mapping the documents and links using Neo4j as an explicit "Dynamic
Link Manager" or DLM (ala Arbortext); another is building the document
store into Neo4J and from that having an implicit DLM. The idea of a
"new" Topic Map engine would be to build it implicitly into Neo4j,
using the graph structure literally as the Topics and Associations
of a Topic Map. The Topic Map engine would *be* the DLM, and vice
versa. If there's any innovation in my idea it's having the document
store itself be an expression of a Topic Map. The one question that
arises is how to keep the classification system/ontology separate
from the documents, though in the TM model they'd just be Occurrences.
I wish I had 10 million dollars and a year -- I'd build the thing. But
I know a lot of people on this list who are in a similar situation...
My last project took me about eight years and I finally ran out of
steam. Not sure I'd want to repeat that. This time I'd want a team.
> That is one of the weaknesses of my diagram of a topic map tool
> chain. I under specified what would/could be done by a topic map
> engine.
That doesn't sound like you.
> BTW, using Neoj would not be implementing the TMRM. That could be,
> not necessarily would be, implementing a different data model with
> different rules, from the TMDM. Hopefully disclosed so that the
> results could be merged with the results of using other legends.
Yes, I realise I misspoke. What I meant was the idea of that implicit
graph structure within the Neo4j graph database exposing an effective
Topic Map, and whatever changes might be necessary to be able to
consider it an expression of the TMRM, without consideration of an
explicit data model. If a data model were in order the TMDM would of
course make the most sense.
That is, unless I stick with TM4j...
[shrieking in background heard]
Murray