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:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Ravi Shankar Sent: Tuesday, May 29, 2012 12:12 AM To: CODE4LIB@LISTSERV.ND.EDU 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
