Ask a question?
  • Contact Us
  • Support Case System
  • Support Forum

RDF Triple Store

Many relational databases have been used for storing RDF triples and graphs. Also dedicated non-relational approaches, such as using bitmap indices as primary storage medium for triples have been implemented.

At present, there is no industry consensus on what constitutes the optimum storage format and set of indices. The answers to these questions will probably remain workload dependent, so that RDF stores have to leave these choices to application developers.

Virtuoso offers the IRI as a built-in data type, distinct from any other data. This plus the use of Virtuoso's ANY type allows for a single-column representation of a triple's object. The graph, subject and predicate are always IRI's, so they can be declared as such. Since an ANY value is a valid key part with a well-defined collation order between non-comparable data types, indices can be built using the object of a triple.

In selected cases, text indexing may be desired for objects of some triples. This is not directly supported in SPARQL but is a foreseeable need. Virtuoso's existing support of text indexing makes this a simple extension.

Type cast rules of SPARQL and SQL differ. Where SQL expects to signal an error, SPARQL expects a silent failure. Virtuoso deals with this by offering a special SQL compiler directive. With these features in place, SPARQL can be efficiently translated into SQL without introducing needless extra type tests or other clutter.

Many graphs can either be stored in a single table or graph specific tables may be used. This depends on the expected number and size of graphs. In some cases, the graph component will not have to be written in the table at all, saving time and space if dealing with very large single graphs. Virtuoso can provide for a mix of all these storage options.

Work on a system for declaring storage formats per graph is ongoing. For now, Virtuoso puts triples in a single table with the graph IRI as a key part. Future extensions will involve mapping existing relational tables into RDF on the fly, allowing efficient SPARQL access of legacy data and more


Related Links