{{announcement.body}}
{{announcement.title}}

Comparing Grakn to Semantic Web Technologies — Part 3/3

DZone 's Guide to

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.

· AI Zone ·
Free Resource
This is Part 3 of Comparing Semantic Web Technologies to Grakn. In the first two parts, we looked at how RDF, RDFS, and SPARQL compare to Grakn. In this part, we look specifically at OWL and SHACL. You can find Part 1  here  and Part 2  here .

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.

Restrictions

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 hasParent with 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 Animal-parents.

Java
 




xxxxxxxxxx
1
14


 
1
:Person
2
  a owl:Class ;
3
  rdfs:subClassOf
4
    [ a owl:Restriction ;
5
      owl:onProperty :hasParent ;
6
      owl:allValuesFrom :Person
7
   ] .
8
:Animal
9
  a owl:Class ;
10
  rdfs:subClassOf
11
    [ a owl:Restriction ;
12
      owl:onProperty :hasParent ;
13
      owl:allValuesFrom :Animal
14
   ] .



To do this in Grakn, the restriction is represented in the schema definition. person and animal entity types are created and two relations with restrictions: person-parentship and animal-parenthship. The former only relates to person while the latter relates to animal.

Java
 






Transitive Properties

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.

Java
 




xxxxxxxxxx
1


1
:isLocated rdf:type owl:TransitiveProperty.
2
 
           
3
:KingsCross isLocated :London.
4
:London isLocated :UK.
5
:UK isLocated :Europe.


 

In Grakn, a rule would be created to represent the transitivity:

Java
 




xxxxxxxxxx
1


 
1
when {
2
    $r1 (located: $a, locating: $b); 
3
    $r2 (located: $b, locating: $c);    
4
}, then {
5
    (located: $a, locating: $c);
6
};



Once the rule is defined, if this data is loaded:

Java
 




xxxxxxxxxx
1


 
1
insert
2
$a isa city, has name "London"; 
3
$b isa country, has name "Uk"; 
4
$c isa continent, has name "Europe"; 
5
(located: $a, locating: $b); (located: $b, locating: $c); 



If we then query for:

Java
 




xxxxxxxxxx
1


 
1
match
2
$b isa continent, has name "Europe"; 
3
(located: $a, locating: $b); get $a; 



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 continent 'Europe".

Equivalent Properties

OWL also provides a construct to model equivalent properties. This states that two properties have the same property extension. An example:

Java
 




xxxxxxxxxx
1


 
1
:borrows owl:equivalentProperty :checkedOut .



This can be represented with a rule in Grakn, where can infer a new relation checked-out like this:

Java
 




xxxxxxxxxx
1


 
1
when {
2
    (borrower: $x, borrowing: $y) isa borrowing;
3
}, 
4
then {
5
    (checking-out: $x, checked-out: $y) isa checked-out;
6
};



Symmetric Properties

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.

Java
 




xxxxxxxxxx
1


 
1
:hasSibling rdf:type owl:SymmetricProperty .



In Grakn, symmetricity can be modelled by simply repeating roles in one or multiple relations:

Java
 




xxxxxxxxxx
1


 
1
(sibling: $p, sibling: $p2) isa siblingship;



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.

Functional Properties

This is how we can model a few more OWL constructs. The owl:FunctionalProperty is represented like this:

Java
 




xxxxxxxxxx
1


 
1
hasFather rdf:type owl:FunctionalProperty .



In Grakn, a rule can be used:

Java
 




xxxxxxxxxx
1


 
1
when {
2
    (father: $x, child: $ y) isa fatherhood;
3
    (father: $d, child: $ y) isa fatherhood;
4
}, 
5
then {
6
    (father: $x, father: $y) isa same-father;
7
};



IntersectionOf

If we use owl:intersectionOf with this example:

Java
 




xxxxxxxxxx
1


 
1
:Mother rdfs:subClassOf [ owl:interesctionOf ( :Female :Parent ) ]



This assigns the class :Mother if the resource is both :Female and Parent. In Grakn we can choose to use a rule, containing a conjunctive condition to represent this:

Java
 




xxxxxxxxxx
1


 
1
when {
2
    $p isa person, has gender "female"; 
3
    (mother: $p) isa motherhood; 
4
}, 
5
then {
6
    (parent: $p) isa parenthood; 
7
};



UnionOf

If we have this example of owl:unionOf:

Java
 




xxxxxxxxxx
1


 
1
:Person owl:equivalentClass [ owl:unionOf (: Woman :Man ) ]



This assigns the class :Person if the resource is either class :Woman or :Man. In Grakn, if we wanted to achieve the same, one way would be to use a type inheritance:

Java
 




xxxxxxxxxx
1


 
1
person sub entity;
2
man sub person;
3
woman sub person; 



HasValue

The owl:hasValue restriction can state that red wines should have the color "red" as the value of their color property:

Java
 




xxxxxxxxxx
1


 
1
:RedWine
2
  a owl:Class ;
3
  rdfs:subClassOf
4
    [ a owl:Restriction ;
5
      owl:onProperty :color ;
6
      owl:hasValue "red" 
7
    ] .



In Grakn, a rule can be used to represent this:

Java
 




xxxxxxxxxx
1


 
1
when {
2
    $w isa red-wine; 
3
}, 
4
then {
5
    $w has color "red"; 
6
};



hasSelf

The owl:hasSelf restriction can state that someone who is a narcissist loves themselves.

Java
 




xxxxxxxxxx
1


 
1
:Narcissist rdfs:subClassOf
2
    [ owl:hasSelf true ; owl:onProperty :loves ] 



This could be represented in Grakn:

Java
 




xxxxxxxxxx
1


 
1
when {
2
    $n isa narcissist; 
3
}, 
4
then {
5
    (loving: $n) isa loves; 
6
};



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:

Java
 




xxxxxxxxxx
1
10


 
1
:Person a sh:NodeShape, rdfs:Class ;
2
    sh:property [
3
    sh:path schema:worksFor ;
4
    sh:node :Company ;
5
] .
6
:Company a sh:Shape ;
7
    sh:property [
8
    sh:path     schema:name ;
9
    sh:datatype xsd:string;
10
] .



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

Java
 




xxxxxxxxxx
1
10


 
1
define
2
person sub entity, 
3
    plays employee; 
4
company sub entity, 
5
    has name,
6
    plays employer; 
7
employment sub relation, 
8
    relates employer,
9
    relates employee;
10
name sub attribute, value string; 



To learn more, make sure to attend our upcoming webinars via  .

In conclusion, we've see how:

  1. 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.
  2. 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.
  3. 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.

Topics:
artificial intelligence, grakn, owl, semantic web, tutorial

Published at DZone with permission of Tomas Sabat , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}