Data Model

Foreign Keys[03]

AllegroGraph does not allow for user-defined consistency rules (like, say, foreign key constraints in a relational database)

Isolation Levels[03]

Every transaction sees a snapshot of the persistent database state as of the time when the transaction is started. During the transaction, it can change the persistent state without affecting the snapshot of others. When finishes, any updates made by concurrent transactions are visible.

Logging[04]

When the commit operation of AllegroGraph returns, the database server will have written the updates made by the transaction to the transaction log and waited for the log I/O operation to finish. Transaction log files record all committed database changes (triple additions and deletions), along with some other information.

Query Compilation

Query Interface[05]

SPARQL, RDFS++ Reasoning, Prolog. SPARQL is the query language of choice for modern triple stores. AllegroGraph's RDFS++ reasoning supports all the RDFS predicates and some of OWL's. Prolog is an alternative query mechanism for AllegroGraph. With Prolog, you can specify queries declaratively.

Storage Architecture[06]

Storage Model

Graph / RDF

Stored Procedures[07]

Users can use Lisp or JavaScript to define stored procedures.

System Architecture[06]

Partition with Federation. AllegroGraph's federation mechanism and flexible triple store architecture combine to make it easy to connect multiple stores together and treat them as one. When a user creates an AllegroGraph federated repository, a virtual index of the constituent stores is created and maintained in the client session to facilitate intelligent query processing and maximum performance.

Views[08][09]

A logic view is offered by Prolog. Query can support match graph ( contains multiple triples), join, filter, order, etc.