#triplestore

While answering a comment on my latest post about some SW tools I'm - almost daily - using, I saw that a new release of AllegroGraph has just been set.

Actually, I tried it last week while looking for triple stores that support the following requirements:

Named graphs / Context

SPARQL support (w/NG)

Basic inference overs RDFS entailement rules (mainly subClassOf / subProperty)

Even if it was relatively fast, I had to remove it from my shortlist as the needed inference capabilities were supported only with its own query language.

But ... according to its changelog regarding this new release:

Get-triples and SPARQL now both work with AllegroGraph's RDFS++ reasoner

Using Redis as a triple store back-end requires an interesting combination of data types, operations, and multi-commands:

Combination of SUNIONSTORE, SINTERSTORE, SDIFFSTORE, SORT and similar commands allows for interesting use case. Sufficiently complex query can be expressed as dataflow between inputs, intermediate results stored as temporary keys and output result returning optionally sorted and paged values. Ability to store intermediate result in temporary key is essential for performance — it allows to avoid roundtripping of intermediate results between Redis database and application server. In addition Redis enables pipelined execution where multiple commands are sent without waiting for replies. This creates condition for “stored procedure”-like execution with single roundtrip to database. Experimentally Redis supports embedded Lua scripting where instead of pipelining multiple do-and-store commands it is possible to submit single EVAL command with equivalent Lua script.

The post exemplifies a query dataflow: