AllegroGraph is a database and application framework for building Semantic Web applications. It can store data and meta-data as triples, query these triples through various query APIs like SPARQL and Prolog, and apply RDFS++ reasoning with its built-in reasoner. It's a high performance, persistent RDF store to support Social Network Analysis, Geospatial capabilities, Temporal reasoning, etc.
The first version of AllegroGraph was made available at the end of 2004 by Franz Inc.. It is an ongoing project with the latest stable release 6.3.0 in October 24, 2017. The idea behind developing AllegroGraph as a graph database was to store your relationships as RDF triples, a standard format for Linked Data.
Users can query AllegroGraph with SPARQL, RDFS++ Reasoning or 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.
Current graph databases such as Neo4J, AllegroGraph, and InfiniteGraph do not provide a concept for view definition and maintenance.
No triple locking is performed by AllegroGraph. It uses snapshot isolation and it is possible that a triple that is being read in a transaction could be deleted in a concurrent transaction. It cannot guarantee write concurrency
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.
It shores data as the Resource Description Framework (RDF), which breaks knowledge into assertions of subject predicate object (e.g. Andy Type Human ). These assertions are called triples. AllegroGraph doesn't restrict the contents of its triples to pure RDF. In fact, we can represent any graph data-structure by treating its nodes as subjects and objects, its edges as predicates and creating a triple for every edge.
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.
The purpose of a checkpoint is to provide a known good starting point for restart recovery. When a checkpoint occurs, the system updates and cleans up repository information so that the respository is in a known state. When recovering from server terminations, the system starts at the most recent complete checkpoint and works through to the current (uncheckpointed) state. We do not give the exact list of things done during a checkpoint because these may change from release to release, but it includes things like writing internal database information (e.g., triple count, generation number, the list of indices, duplicate suppression mode, configuration, sequences, text index state, etc) to the transaction log, writing the string table state to the transaction log, flushing non-transient files to stable storage, releasing space occupied by inactive objects, and updating the checkpoint indicator file (a file indicating the position of the checkpoint records in the transaction log stream).
AllegroGraph is a closed source triplestore which is designed to store RDF triples, a standard format for Linked Data.
AllegroGraph follows shared-nothing model, adopts 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.
C#, Clojure, Java, Lisp, Perl, Python, Ruby, Scala