Comparing Grakn to Semantic Web Technologies — Part 3/3
Comparing Grakn to Semantic Web Technologies — Part 3/3
This is part three of Comparing Semantic Web Technologies to Grakn. In this part, we look specifically at OWL and SHACL.
Join the DZone community and get the full member experience.Join For Free
OWL and Grakn
OWL is a family of Descriptive Logic (DL) based ontology language which adds ontological constructs on top of RDFS to express conditions and derive new facts. To make meaningful use of these, OWL provides different flavours: OWL QL, OWL RL, OWL DL, with the user needing to decide which fits their use case best.
Grakn, on the other hand, comes with its own built-in native inference capabilities. This is an important distinction, because OWL assumes a good understanding of the field of logic by the user, while using Grakn doesn't require the user to have studied this field extensively.
The result is that OWL struggles to maintain a satisfactory balance between expressiveness and complexity. Just to reason over two simple constraints: Every parent has a child and Every child is a person requires the use a fully-fledged OWL DL reasoner. Furthermore, OWL is not suited to reasoning with complex relations. Its formal foundations, based on a tree-model property, make it a better fit for tree-shaped data, but scale poorly with more complex data.
OWL adopts open world assumptions, instead of Grakn's closed world assumptions. This means that in an example where OWL has the constraint: Every parent must have at least one child, if we have a person with no children, this is still consistent with the constraint, as we may not yet know about John's children. However, with Grakn's closed world assumption, if there are no actual mentions of John's children, this means he really doesn't have any children and isn't a parent.
Open world assumptions lend themselves well for the open-ended web, which includes incomplete information from multiple sources, which is why OWL provides many concepts to manage and deal with this incompleteness. However, because of this open world assumption, OWL makes it hard to validate consistency of data. That's why relational databases maintain schema constraints to guarantee the quality of data. Grakn combines both styles of reasoning: ontological style open world inference, and schema like closed world constraint checking.
Everything put together, OWL has a very high entry threshold for non-logicians. As it's based on description logic, developers avoid using OWL as it's non-trivial to understand the language and its intended behaviour. Because of this, Grakn's knowledge representation formalisms remain lightweight, providing semantic capabilities to a much larger audience than that of OWL. In other words, Grakn is simpler to use than OWL.
Here we look at some common axioms in OWL and comapre them to Grakn. This is not an exhaustive list, and is provided to help the user understand how to think of migrating to Grakn.
A key functionality of OWL is to define restriction classes (
owl:Restriction). These unnamed classes are defined based on restrictions of the values for certain properties of the class. OWL allows to model situations where certain members of a class need to have certain properties. Restrictions allow to differentiate between something that applies to all members of a class. A restriction is defined by giving a description that limits the kinds of things that can be said about a member of that class.
One example is the restriction
AllValuesFrom, which states that in the context of a specific class, the range of a property should always be a specific class. For instance, if
AllValuesFrom has been applied for Class
Person, and this is applied to the range of
Person, then they can only have
Person-parents, while an
Animal cannot have a
Person-parent. The example below also shows that only
Animals can have
To do this in Grakn, the restriction is represented in the schema definition.
animal entity types are created and two relations with restrictions:
animal-parenthship. The former only relates to
person while the latter relates to
A common inference in OWL is transitivity. This states that relation R is said to be transitive, if A is connected to B with R(a,b), and B is connected to C with R(b, c), this implies that A is connected to C with R(a, c). The construct
owl:TransitiveProperty is used for this. The example below allows the inference that Kings Cross is located in Europe.
In Grakn, a rule would be created to represent the transitivity:
Once the rule is defined, if this data is loaded:
If we then query for:
Not only would this yield the
country "UK", which has a direct relation with the
continent "Europe", but also the
city "London", as this would be inferred as having a transitive relation with the
OWL also provides a construct to model equivalent properties. This states that two properties have the same property extension. An example:
This can be represented with a rule in Grakn, where can infer a new relation
checked-out like this:
A symmetric relation represents a relation that has its own inverse property. For example, if Susan is related to Bob via a
hasSibling property, then the inference that Bob is also related to Susan through a
hasSibling property can be made.
In Grakn, symmetricity can be modelled by simply repeating roles in one or multiple relations:
In other words, something that needs an explicit construct in OWL is native to the Grakn model, i.e., the symmetricity rule doesn't require to be made explicit. However, this is where comparing OWL to Grakn becomes difficult, as both serve different use cases. In particular, given Grakn's closed world assumptions, many of the problems in OWL simply don't exist.
This is how we can model a few more OWL constructs. The
owl:FunctionalProperty is represented like this:
In Grakn, a rule can be used:
If we use
owl:intersectionOf with this example:
This assigns the class
:Mother if the resource is both
Parent. In Grakn we can choose to use a rule, containing a conjunctive condition to represent this:
If we have this example of
This assigns the class
:Person if the resource is either class
:Man. In Grakn, if we wanted to achieve the same, one way would be to use a type inheritance:
owl:hasValue restriction can state that red wines should have the color "red" as the value of their
In Grakn, a rule can be used to represent this:
owl:hasSelf restriction can state that someone who is a narcissist loves themselves.
This could be represented in Grakn:
As mentioned, Grakn is not built for the same uses cases that OWL was built for. As such, a one-to-one direct mapping cannot be made. When working with multiple classes, for example, modelling decisions need to be taken into consideration: which become entities and which roles, in Grakn.
Traditionally, RDF doesn't ensure that the data being ingested adheres to a set of conditions - i.e. a schema. This is what the SHACL standard is for, which checks if the RDF is logically consistent with a schema before it can be committed. There are also other ways of checking for logical verification with slightly different implementations.
Like SHACL, Grakn also checks for validation and highlights issues with regards to the quality of the data. But while SHACL is just a validation schema, Grakn implements a semantic schema.
Using a validation schema, if the data source being ingested contains schema violations, the transaction will fail. We would then look at the source, curate it, and ingest again. With a semantic schema, we would load data, validate it, and mark it for violations. Then we can deal with them online as they are being loaded in.
In this sense, a semantic schema gives you an extra guarantee that all the ingested data will conform to your schema. This means that all the data in your database is consistent with respect to the schema that has been defined.
This code snippet in SHACL shows how the data needs to adhere to certain restrictions:
In Grakn, this validation takes place in Graql's schema language. A
Person entity is defined as only playing the role
employee in an
employment relation, which is related to a
company entity through the role of
employer, and includes an attribute of type
name and value
In conclusion, we've see how:
- Compared to the Semantic Web, Grakn reduces the complexity while maintaining a high degree of expressivity. With Grakn, we avoid having to learn different Semantic Web Standards, each with high levels of complexity. This reduces the barrier to entry.
- Grakn provides a higher-level abstraction for working with complex data than Semantic Web Standards. With RDF we model the world in triples, which is a lower level data model than Grakn's entity-relation concept level schema. Modelling and querying for higher order relationships and complex data is native in Grakn.
- Semantic Web Standards are built for the Web, Grakn works for closed world systems. The former was designed to work for linked data on an open web with incomplete data, while Grakn works like a traditional database management system in a closed world environment.
Grakn provides us with one language that gives us a concept-level model, a type system, a query language, a reasoning engine, and schema verification. To do the same with Semantic Web Standards requires multiple Standards and their respective implementations, each with their own inherent complexities. In particular, OWL is extremely feature-rich, which has resulted in a high degree of complexity making it unsuitable for most software applications. Instead, Grakn provides a suitable balance between complexity and expressivity when it comes to working with knowledge representation and automated reasoning.
This comparison has aimed to provide high-level similarities and differences between both technologies, but, of course, there is more to Grakn and The Semantic Web than what we've tried to show here.
Published at DZone with permission of Tomas Sabat , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.