Stardog

Fig 01 - Stardog functional architecture

The functional architecture of Stardog is illustrated in Figure 1. The storage layer is founded on RocksDB (a key-value store written in C++) and deployment is based on containers and Kubernetes.

As far as Figure 1 is concerned, we have already mentioned the support for SPARQL and Gremlin while the support for the GraphQL API is also noteworthy. However, the most important elements to explain are the virtual graph and natural language processing pipelines (BITES) capabilities, along with support for declarative models (which require no coding) that enable the creation of your knowledge graph(s). As far as BITES is concerned this is an extensible document storage system which provides configurable storage and processing for unifying unstructured data with Stardog graphs.

As far as virtual graphs are concerned, Stardog believes (and we agree) that support for data virtualisation is fundamental to supporting knowledge graphs. In this context it is important to appreciate that graphs can be used to represent any sort of data and not just business data. Within the context of federating data to create a suitable knowledge graph, this means a graph that represents metadata about source environments. With structured and semi-structured data sources, you create a graph that represents all the data sources you can address, while any particular query is defined by the sub-graph that defines the nodes (data sources) that you access. As for the details of each source that you might want to access, these are defined in what Stardog calls virtual graphs. To create these virtual graphs, you declaratively (no code) map tabular data into the graph model used by a Stardog database, typically using R2RML (relational to RDF modelling language). At run-time, Stardog makes use of caching to optimise federated query performance.

Fig 02 - Stardog supporting data virtualisation

In this context, Stardog provides out-of-the-box virtual connectors for more than 30 popular sources, some of which are illustrated in Figure 2. Examples of other supported sources include Google BigQuery, ElasticSearch and Exasol. An SDK is available for users to develop their own connectors.

There are some other notable features of Stardog that are worth mentioning, including extended SQL support so that you can use tools such as PowerBI and Tableau to query data, support for Active Directory, and built-in machine learning capabilities with support provided for supervised classification, supervised linear regression and unsupervised similarity detection.

There is not only lots (and growing amounts) of enterprise data, that data is spread across all sorts of data sources, both structured and unstructured. To make full use of all this data you need to know where it is, what is there and how the different datasets relate to one another. Only once this data landscape is fully understood can you fully exploit it for analysis purposes. What an enterprise knowledge graph does, is to provide a comprehensive map of your ecosystem, for precisely this purpose.

Stardog is not the only vendor targeting knowledge graphs, but it does have significant advantages, particularly in its declarative approach, its support for unstructured data, the extensive reasoning and inferencing that it provides, and its support for multiple inferencing schemas. In addition, the fact that it supports Gremlin as well as SPARQL is important because while information architects tend to like RDF graphs, developers often prefer property graphs, and supporting both these approaches gives you the best of both worlds.

The Bottom Line

Stardog is suitable for, and targeted at, environments requiring queries across large, heterogeneous datasets through support for virtual graphs. Further, these support the creation of enterprise knowledge graphs for which there is growing demand. As a supplier that has focused on this area for some time, Stardog is well-positioned to capitalise on this trend.