Some parts of the Ontiki
architecture are pretty clear,
but other parts are still rather murky:
- Ontiki will use a web-based client / server architecture and a graph database.
- For security, all incoming requests will be handled by the server, Ontiki_S.
The client will be a browser-resident single-page application.
It will handle presentation and user interaction,
using assorted nifty libraries, eg:
- 2D data visualization (D3, ...)
At least initially, the server will use a Ruby-based Web Framework
, Ruby on Rails
This can be reimplemented in another language later, if need be.
The main data store will use Neo4j
(a graph database).
Here's a high-level look at Ontiki's components, including dependencies
(e.g., applications, frameworks, libraries, servers):
Client / Server Division
The diagrams below show Ontiki's client and server app suites,
separated by a dashed, horizontal line.
This emphasizes the fact that all incoming requests are handled
The right-hand diagram adds a Gremlin (i.e., TinkerPop3
for graph manipulation (and possibly for some kinds of Neo4j access):
Ontiki_S may also talk to ancillary servers (e.g., Cache, Logs).
To keep the diagram clean, let's just show these as independent "listeners":
Cache, Logs, etc.
Ontiki_S will be sending and receiving lots of messages (e.g., to other servers).
Caching might be a win for external servers;
logging would aid debugging and analysis in all cases.
So, why not cache the external traffic and log the rest?
(Disk is free, after all. :-)
may play useful roles here,
but I'm not clear about the details yet...
Gremlin (i.e., TinkerPop3) integrates a wide range of graph manipulation tools
into a single, vendor-independent suite.
Also, its property graph model looks a lot like Neo4j's.
Unfortunately (from my perspective):
- It's sending executable code to a Server (yeeps!).
So, I plan to keep an eye on it, but approach it very
- Get the Neo4j-based setup working.
- Set up an instance of TinkerPop3.
- Compare query results, timing, etc.
It isn't necessary to run Ontiki_S on the site's main machine.
will pass requests to other (local) machines:
These apps have to do with data importing, graph analysis,
and other tasks that help to support Ontiki.
It would be interesting (and potentially very useful) to run background apps
that attempt to discover relationships and patterns in the database.
A lot of interesting content (e.g., YAGO
is distributed as RDF triples
typically encoded as Turtle
So, we need a convenient and flexible way to map this onto Neo4j.
The current import suite, built from a combination of Ruby
and the Unix system sort
utility, has some annoying issues:
- It embodies YAGO's conventions, schema, etc.
- The Ruby code is slow and single-threaded.
As I bring in other data sets, I will generalize the suite.
I may also translate the Ruby scripts into a language
that performs better and handles concurrency well.
See YAGO - Installation
and YAGO - Importing
This wiki page is maintained by Rich Morin
an independent consultant specializing in software design, development, and documentation.
Please feel free to email
comments, inquiries, suggestions, etc!