Stardog

Figure 1 – Stardog functional architecture

The functional architecture of Stardog is illustrated in Figure 1, though the underlying architecture is not represented here. This is significant because, in the recently released version 6.0 alpha, the storage layer has been re-written to run on RocksDB and deployment is now based on containers and Kubernetes. RocksDB is a persistent key-value store written in C++. The significance of this is that, compared to say Hadoop, RocksDB is much faster, and has a much smaller footprint.

The company has also introduced Stardog Studio, which it describes as a Knowledge Graph IDE. Currently, the product is replacing a pre-existing web console, but it includes contextually aware auto-completion and hints for editing graph queries, with that support being extended to mappings, rules, and graph data models in upcoming releases.

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).

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 the source environments. With 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).

For unstructured data, Stardog uses BITES. This is an extensible, but optional, document storage system which provides configurable storage and processing for unifying unstructured data (including images, voice and so forth) with Stardog graphs. Note that by “unstructured” here we exclude semi-structured data contained in, for example, either XML or JSON documents, both of which can be handled via virtual graphs. Sources are processed to extract structured data from the unstructured base artefact so that relevant details can be stored as graph data within the database. BITES allows users to extract text from the source document and then use Stardog’s full-text search capabilities over the contents of both the extracted document data and the explicit graph data.

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, and the fact that it supports Gremlin as well as SPARQL. We should also mention Stardog’s support for reusable data models that support scalability for enterprise use cases.

And finally we are also pleased that Stardog’s storage engine has been moved to RocksDB as this will significantly improve performance.

The Bottom Line

Stardog is suitable for, and targeted at, environments requiring queries across large, heterogeneous datasets. That said, it’s principle claim to fame is on supporting the creation and leverage of enterprise knowledge graphs. If this is an issue for you, you should give Stardog serious consideration.

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.