I would recommend rather than focusing on native support, focus on which database has the best SPARQL implementation.

While I have dealt with projects using MySQL database I am currently implementing a project in Neo 4j due to the complex interrelationship of semantic concepts that I want to model. But my preference depends on the specific dataset I have to deal with

I have used both Jena TDB and AllegroGraph (http://franz.com/agraph/allegrograph/). The former is free open source, while the latter is commercial (with a limited free edition). Jena TDB has the advantage of being straightforward: no setup required, and easy to use, which is great for quick prototyping. Like AllegroGraph, it is transactional and provides ACID transactions. AllgroGraph however is a more like a complete "solution" that offers way more advanced features, such as support for large ontologies, security, federation, dynamic entailments, geospatial indexing, etc. Inferencing in Jena is materialised, which means that you have to pre-compute inferences in advance before using them (you can store those for future quick access if that suits you). This is fine if your ontologies are rather "static" or "small". But it has limitations with large or frequently updated ontologies.

Another well known triple store and API is RDF4J (formerly known as Sesame). It provides a REST interface. I have never used this one though...

Here is a list of available subject-predicate-object (not only RDF) databases.

From my experience, Virtuoso is often used in academic projects, but it is not the best in terms of specification compatibility and deployment. Lately, we used Stardog quite often which is easy to use. There is also a free community edition available.

The question is: What should the triple store be used for? Without accurate information, it is difficult to make a recommendation.

https://en.wikipedia.org/wiki/List_of_subject-predicate-object_databases

thanks Marvin,

we need a triple store database to store Social Network connections betwees users. So basically we need it as a basis for SNA algorithms. So, the subject-predicate-objet model should fit 100%.

Carlo, I would also consider graph databases such as Titan or Neo4J. Briefly speaking, triple stores are suitable for reasoning, graph databases are suitable for graph operations and queries (find shortest path, etc.)...

It really depends on what you need. I have very good experience with GraphDB and Parliament. GraphDB is quick and reliable, but requires a license. Depending on the size of your dataset (if we're talking about less than a billion triples), I would opt for Parliament. It's a free and open source triple store. It's very robust and supports GeoSPARQL Queries, in case you have to deal with geometries.

Cheers!

we can also uses the LOD cloud fro RDF data-set where the dataset is published through a SPARQL endpoint.

@JimJones do you have any experience in securing Parliament? e.g. for DELETE, UPDATE, INSERT?

@Pasquale Di Donato: no, not really, but a colleague once solved this issue by isolating the parliament server from the network and enabling access to it only via an apache server, protected with proper credentials. It was a workaround to protect an existing instance running with jetty.

@Pasquale Di Donato:

Do you need protection to the store generally or more fain-grained, e.g. on a graph-based level?

Would say the store generally. I'm evaluating if I can use it on 'prod', then access for external users should be readonly.

I agree with Jasper. Ontotext has improved a lot the performance and usability of GraphDB. GraphDB 8 offers an amazing user experience! The GeoSPARQL implementation, although still in its early stages, works pretty good. Its configuration is also very easy.

Hi all,

I've experimented some of them. I had problems with Virtuoso. Did you also? Eventually I have adopted Neo4J.

adding to the above answers:

I work in benchmarking a wide variety of rdf stores and graph stores.. The word "best" depends on your use case to be honest. If you consider linear queries triples stores such as openlink virtuoso are high optimised. If you wish to compare stores on their scalability (lets say query federation) rdf stores are the way to go. If you are comparing the performance for complex aggregation based queries then graph stores, such as neo4j , sparksee are highly optimised (also note that they benefit a lot from graph locality, which is not in the case of rdf stores). You may find the findings in Conference Paper Trying Not to Die Benchmarking – Orchestrating RDF and Graph...

In general openlink virtuoso, mark logic rdf stores are all promising. For graph based tasks and complex, navigation-based queries graph stores are the way to go. However, migration from RDF to property graph data model is not trivial.

Cheers!

Hi Jasper,

Thanks for your interest!

Since this was a pilot study focused towards demonstrating the relative ease of benchmarking diverse RDF and Graph stores, we did not cover the spectrum of DMSs.

However, we are currently extending support for various RDF and Graph DMSs such as MarkLogic, Stardog, Giraph, DSE graph, etc in LITMUS. Once accomplished, we plan to conduct another round of benchmarking and publish the results.

However, we can only consider the graph DMSs which are TinkerPop-enabled, since the choice of language is Gremlin.

LITMUS v.0.2 is scheduled for release in Dec 2017.

Hope this helps!

AllegroGraph 7.0.1

Jena Fuseki works well too.