Real database (ACID with transactions). A semantic Web alternative to SQL databases and Prolog systems.
read more in Features
Compliant (w3c test cases) with Turtle and RDF/XML, SPARQL and SPARQL/Update.
read more in Compliance
Easy to use. Powered by Lua scripting facilities.
read more in Getting Started
Smart use of SPARQL for dynamic Web page with the Lua dynamic HTML page generation.
read more in Documentation
High performance. Extremely fast insertion. Low System resources use.
read more in Performances
Reasoning and inference capabilities. Smart Integration of Rules to SPARQL. Adapted to real RDF database use (frequent graph updates incompatible with inference materialization).
read more in Datalog Extension
Recursive DATALOG rules. Uses negation at Failure. Recursive rules with Negation.
read more in Datalog Extension
Inside StrixStore
StrixStore use a native persistence engine. This engine is transactional (one writer-multiple reader). Concurrent access are possible for threads within the StrixStore process (process owned by the Lua program loading StrixStore.dll or owned by the Web server loading StrixStore.dll as ISAPI module).
The native persistence engine is based on the kernel of Gigabase. Transaction commit protocol is based on shadow pages algorithm, performing atomic update of database. Update transactions start at graph creation or update. If an error occurs, the engine make a rollback.
To get RDF graphs from Internet Network (LOAD command of SPARQL/Update), StrixStore uses webGet.dll (current Windows implementation based on the WinInet API).
StrixStore is developed in C++ for performances and personal convenience.
The included Datalog inference engine is called from SPARQL if the query contains WITH RULES. The resolution algorithm is a modified version of SLG adapted to RDF triples.
Triples indexation is made with 3 B-trees. A Subject-Predicate-Object (SPO) B-tree, a Predicate-Object-Subject (POS) B-tree and finally a Object-Subject-Predicate (OSP) B-tree. With these 3 indexes, all type of SPARQL graph pattern could use an indexed access. For example {X ?p Y}, a pattern with subject and object fixed will use a B-tree walk on OSP index starting from key YX.
SPARQL queries (and SPARQL/Update command using graph patterns) are compiled in a specific byte code to be executed on a virtual machine. The compilation has a cost but has 2 advantages: ability to understand/debug the SPARQL engine and performance if big RDF datasets are exploited. For the moment, the compiled byte code is not optimized: SPARQL queries must be written with precautions.