Hey Ravi,

I actually learned about TinkerPop from a posting on this list from
Brian Tingle and I started playing with it and eventually started
working with it for the digital repository we're building. I actually
began with the Sail extension, but scaled back to non-RDF model on
that after realizing it wasn't really a requirement that our users
were asking for...simply using it as a graph db makes things go a lot
quicker. Of course, we're planning on revisiting implementing the
RDF-based model in "the future".

In TinkerPop/Neo4j, there's ACID transaction support and there a bulk
loading utility.  However, there is not transaction support in the
bulk loader...also, I think Sail has kinda different/weird transaction
support, but I think you can override that in Tinkerpop somehow...


On Wed, May 30, 2012 at 2:29 AM, Simon Spero <[log in to unmask]> wrote:
> The latest version of Jena TDB adds atomic transactions (version 0.9.0+)
> See for
> documentation:
> The following limitations are listed:
>   - Bulk loads: the TDB bulk loader is not transactional
>   - Nested transactions are not supported.
>   - Some active transaction state is held exclusively in-memory, limiting
>   scalability.
>   - Long-running transactions. Read-transactions cause a build-up of
>   pending changes;
>   - If a single read transaction runs for a long time when there are many
>   updates, the system will consume a lot of temporary resources.
> On Tue, May 29, 2012 at 7:00 PM, Fleming, Declan <[log in to unmask]> wrote:
>> Hi Ravi - I'll let some of my more technical folks chime in, but we do a
>> bunch with RDF and have found every triplestore we've tried very limited in
>> handling transactions.  Reading and writing at the same time causes a
>> deadlock that's a mess to keep clean.  So, we went back where we started
>> and created a triplestore using SQL with big tables of triples.  We cheat a
>> little bit with a fourth column for ID and a fifth that helps speed up
>> blank node searching.  This has helped us avoid these transactional
>> problems we were having, and the performance is quite good for ingest.
>> Most of our searching is done by stuffing the triples into solr in a JSON
>> format, so we don't rely on the backend data store for that much.  We also
>> sync the SQL triples to Allegrograph in case we need deeper SPARQL things,
>> but we're thinking of shedding this from our architecture.
>> Declan
>> -----Original Message-----
>> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of
>> Ravi Shankar
>> Sent: Tuesday, May 29, 2012 12:12 AM
>> To: [log in to unmask]
>> Subject: [CODE4LIB] triple stores ???
>> We (DLSS at Stanford Libraries) are planning to use a triple store for
>> storing and retrieving annotations (in RDF) on digital objects. We are
>> currently looking at open-source triple stores such as 4store, Virtuoso,
>> Jena SDB and Mulgara. Are you currently using a triple store or
>> contemplating on using one? How would you evaluate 'your' triple store
>> along the lines of 1) ease of setup, 2) scalability, 3) query performance,
>> 3) bulk load performance, 4) access api, 5) documentation and 6) community
>> support?
>> Highly appreciate your thoughts, ideas and suggestions.
>> Thanks,
>> Ravi Shankar