Choosing a (graph) database #5
Description
From #3.
Finally, the databases: as a general thing, I would like to keep this reasonably simple to deploy on a reasonably-sized machine. Titan hits me very badly on this front.
I've worked with Virtuoso in the past, and sworn myself that I will never again touch it with a stick. It's a mad piece of software; needs to die. Not a rational argument here, so much as an irrational fear :)
That leaves Orient and Cayley: Cayley is really awesome from what I've seen, including native quad support. But it's just very, very new and it looks like some fairly basic bits are missing (e.g. I think it may only do bulk import at launch at this time?). Orient looks really cool, going to explore that more today. Haven't seen any mentions of quads yet, though.
From @ahdinosaur
i'm working on something similar to uf6 (open-app, openappjs), and for the data subsystem i was thinking of building on top of leveldb and levelgraph, as the level and levelgraph ecosystems allow you to "build your own database" using modules.
a) you can add additional properties to triples like so. they can be accessed during query filters, but the additional properties are not by default indexed like the triples are. there's also an issue up about proper named graphs: levelgraph/levelgraph#43.
b) it's built in JS and either leveldb on the server or IndexedDB in the browser. i don't know of any REST APIs for it, but it wouldn't be hard to do.in general, the "build your own database" approach has less "batteries included", so it's really dependent on what you want, just figured i might as well share.