Why GRAKN.AI instead of OWL?

Grakn is built on top of Apache TinkerPop, which is an open-source interface offering uniform access to data stored in any TinkerPop-enabled database. There are two immediate advantages to this architecture:

Grakn remains largely storage-agnostic, and can work on top of such graph databases and triple stores as Titan, OrientDB, Blazegraph, StarDog, and others that implement the TinkerPop interface;

The underlying data structure of Grakn is that of a labelled hypergraph. This, in turn, is further mapped to a labelled, directed graph — a model exposed by TinkerPop regardless of the actual data storage involved.

Labelled, directed multigraphs also happen to be the structures underpinning the RDF data model, so it is relatively straightforward to devise a mapping between RDF and hypergraphs. However, the real difference appears at the ontology layer, where Grakn exposes a higher level knowledge model, allowing developers to represent their application domain in terms of entities, resources, relations and roles, as opposed to OWL’s individuals, literals, properties and classes.

Here are the four main reasons why we believe Grakn ontologies are a better fit than OWL for modelling knowledge graphs in the context of stand-alone applications:

1) Grakn combines the Open and Closed World Assumption

By adopting the OWA, OWL makes it very hard to help validate consistency of data and ensure its proper structure. And that is what knowledge graph applications typically require, in a similar sense as relational databases require strict schemas to guarantee the quality of their data.

In Grakn, we carefully combine both styles of reasoning, taking the best of two worlds: ontological-style open-world inference, and schema-like closed-world constraint checking. The long-standing antagonism between the open-world “ontological” and closed-world “schema” modelling stems, in our view, not principally from the formal incompatibility between the two approaches. Rather, it is rooted in the extreme philosophical views on the prototypical application scenarios they are ideally suited for: the open-ended, heterogeneous web of data vs. closed, curated, single-viewed data stores. Because we focus on large, domain-specific knowledge graphs, we find both ends of this spectrum too limiting and see a natural need for endorsing a mixed, yet still balanced solution.

2) OWL profiles have an unsatisfactory balance of expressiveness vs complexity

None of the standardised OWL profiles directly match the typical schema/ontology requirements for knowledge graph applications. In most cases, knowledge graphs require rich constraint patterns to be expressed over the relationships (edges) in the graph, which are only available to some extent in OWL DL, i.e., the most complex of the decidable OWL profiles. At the same time there is little demand for very elaborate class descriptions involving logical operators, broadly supported by that profile, with the expressiveness of the lightweight OWL QL, OWL RL, or even RDFS being sufficient in this respect.

In theory, OWL architecture invites the use of arbitrary fragments (as needed on per use-case basis). However, in practice, “cherry picking” is impeded by the nature of the available reasoning tools, which must anyway involve expensive computational techniques to account for the entire, respective OWL profiles. Just to reason with the two simple constraints “Every parent has a child” and “Every child is a person”, one must involve a full-fledged OWL DL reasoner — a tool that, on average, will scale poorly with large data. This commonly pushes Semantic Web practitioners into a sole use of RDF(S), which on its own is too simplistic as an ontology/schema language.

3) GRAKN.AI is dedicated to graph data

Even in its full expressiveness, OWL is not ideally suited for reasoning with complex graph structures. Its formal foundations (logics with the so-called tree-model property), determined largely by computational limitations (predominantly decidability), make it, in fact, a much more natural language for managing tree-shaped data. Consequently, the entire complexity/expressiveness overhead one must accept to work with OWL to start with does not return the value in the context of knowledge graphs.

4) OWL has a high entry threshold for non-logicians

As the design of OWL has been driven primarily by research on description logics, the entry threshold for non-logicians (in the sense of being able to comprehend the language and achieve the intended behaviour of the OWL-backed systems) is significant. This is another reason why many developers chose to stick to RDF(S).

By ensuring that Grakn’s knowledge representation formalism remains lightweight and is built bottom-up, following the experiences and needs of developers, we hope to enable more semantic capabilities to a much larger audience than that of OWL.

By committing to a novel ontology formalism from that underpinning the Semantic Web, Grakn had to be consequently equipped with a new, dedicated query language, Graql, which is intended to offer the optimal access to information represented in Grakn knowledge graphs. We will discuss the formal properties of Graql in more detail in future posts.