
Fig 01 - An Entity-Event Knowledge Graph in Franz AllegroGraph
The basic idea behind AllegroGraph is that, it will a) transform your existing enterprise data into triples, which can then be thought of as either entities or events; and b) store it all inside, effectively, one enormous network comprised of all of your entities, events and sub-events, possibly including entire taxonomies. In other words, a graph. This method of storage makes it much easier and simpler to write complex queries. For example, picking out a single user or other entity and obtaining a comprehensive, 360º view of their relationships is almost trivial, requiring only a single line of SPARQL. Moreover, as of version 7.0 of AllegroGraph, you have the ability to create “Entity-Event Knowledge Graphs”, or EEKGs. This novel approach allows you to capture your core entities as well as related events and relevant knowledge bases within a hierarchical tree structure (see Figure 1). Notably, EEKGs can be built incrementally, starting with a simple model and extending as needed without altering what has come before. They also store provenance information and data lineage.
Franz offers multiple methods for deploying AllegroGraph across the enterprise, including federated, distributed and hybrid deployment models. The last of these uses a sharding approach, via the company’s patented FedShard technology, which works by storing replicas of your unshardable data (datasets that must be stored as a single piece) on each of your machines, then federating that data with the repositories located on that machine. This means that you only need to load in your unshardable data once for each machine during any given query.

Fig 02 - Sending a notification using AI in AllegroGraph
AllegroGraph utilises “multimode” artificial intelligence, consisting of both machine learning and a CEP (Complex Event Processing) system developed in Prolog. The idea is to use multiple kinds of AI to estimate the likelihood of future events occurring based on currently observed events stored in a graph. For example, if you are a police force, you might want to monitor the outgoing and incoming calls used by a criminal cell, estimate the probability they are about to meet face to face, and send a notification when that probability rises above a certain threshold. You could accomplish this with the rule displayed in Figure 2.
Although the structure of this rule is set in stone, the parameters (highlighted in yellow) are equipped with confidence intervals, which are calculated based on past observations and events. Moreover, instead of sending a notification, you can create a ‘possible event’ in your graph. This is an event equipped with a probability that represents the likelihood of it occurring or of having occurred.
Finally, AllegroGraph also features native, near real-time multi-master replication and management; multi-modal input from RDF, CSV, JSON, JSON Lines and JSON-LD files; built-in document storage (comparable to MongoDB) with support for graph algorithms and semantics; natural language processing (NLP), speech recognition, and textual analysis, including entity extraction; and extensive support for a variety of data science tools.