Skip to content

Ontologies (Advanced)

Jump to bottom Edit New page
Carsten Stocklöw edited this page Apr 21, 2018 · 4 revisions

Table of Contents

Introduction

The universAAL platform enables interoperability in open distributed systems without limiting the scope of the system. This is possible because of shifting all specifics to plug-able units called ontologies. For this reason, a certain level of familiarity with ontologies is required when you start to develop on top of the universAAL platform.

The term Ontology is derived from the Greek words "onta" (of being, existence or reality) and "logos" (science, study, theory). Before the wide-spread usage in computer science, ontology was mostly classified as a philosophical term with its original meaning (the theory of being). In information technology, however, it is used to refer to an explicit specification of a set of concepts and their relationships from a domain in a formal language that is developed with the goal to be shared by humans and machines as a shared understanding of the domain. Some important discussion points that we would like to highlight in conjunction with ontologies, are (you can skip the following enumeration if you are less interested in a general-purpose technology analysis):

  • Being based on a formal language, it must be obvious that by introducing ontologies, computer scientists aimed at enabling computer programs to benefit from ontologies in data and information processing.
  • When writing an application in a domain, a developer creates a model of that domain in his/her mind that will eventually be reflected in his/her program implicitly or explicitly. No matter how explicit or implicit domain models are created, they already reflect the programmer's understanding of the domain. Hence, the programmer is already working with something similar to an ontology; the question, however, is about the explicitness, share-ability, and used formalism.
  • The degree of explicitness of domain models in computer programs depends on different factors, such as the programming language. For example, object-oriented programming (OOP) languages are designed for more explicit capturing of domain models. Using OOP languages, it is possible to specify the entities in the domain and the relationships among them. This is pretty similar to what you can also do with ontologies, namely modeling a domain. But, there are still three important differences:
    1. When it comes to share-ability, computer programs often focus on sharing functionality so that the role of domain models (even if created explicitly) becomes secondary / auxiliary. Instead, interface specifications get into the center of attention. An interface specification consists of a set of operations with certain input and output parameters. The names of the operations are arbitrary strings even if they are usually chosen in a way that humans can guess what the operations are going to do. The same applies to the names of the parameters. The types of the parameters, as a matter of fact, might be selected from among the types of entities explicitly defined in the domain model. That is, interfaces are specified as contracts among developers and are not interpretable by computer programs because parts of the knowledge about the purpose of operations often remain implicit; especially, there is nothing interpretable for computer programs about the effects of operations specified in interface definitions.
    2. In order to enhance the capabilities of computer programs, some of the execution environments provide facilities for querying the type system (Java reflection is an example facility in this regard). However, the knowledge about the underlying domain model in these type systems is limited to the capacities of OOP languages of today. Java reflection, for example, cannot help to find out anything about possible interrelationships between two instance variables because in terms of modeling the properties of instances of a class, the corresponding Java class can just specify them in terms of instance variables along with their types while indirectly providing a hint about their cardinality (no definite specification of cardinality but in case of non-array, the cardinality is at most one, even if it is still not clear if the instance variable is mandatory or optional; similarly, in case of arrays, there is a hint that the number of values might be more than just one but again nothing can be deduced about any upper or lower limit).
    3. Even the explicit part of domain models in computer programs can only (with acceptable amount of effort) be shared among programs that are written in the same programming language and / or run in the same execution environment.
That is, computer programs are so far not suitable for explicit sharing of domain models because (1) some knowledge eventually remains implicit, (2) the formalism of programming language is not powerful enough for this purpose, and (3) share-ability remains confined in the scope of a certain technology.
  • Modern database schemata in database systems come also close to what ontologies are supposed to be; but, even here, the formalism of the underlying data definition languages is not powerful enough and the share-ability remains confined in the scope of a certain technology.
  • The most wide-spread ontological framework with the largest developer base nowadays seems to be what has been specified under the umbrella of the Semantic Web. The Semantic Web builds on top of the following achievements of today's Web:
    • increase share-ability by representing things as simple text that is independent from specific development and runtime environments
    • identify everything by globally unique IDs in terms of URIs / IRIs
    • especially, names represented by URIs / IRIs must be globally unique - a part of which usually "points to" a namespace and the rest of which is a local name within that namespace (cf. XML namespaces)
The universAAL platform is based on the ontological framework of the Semantic Web, especially the following four specifications:
  1. A meta model for data representation called the Resource Description Framework (RDF). RDF provides a standard model for representing data that is independent from the data itself (all sorts of data can be serialized in terms of RDF). The most popular syntaxes for RDF serialization are (1) the original XML syntax, (2) the N3 Notation that was developed by Tim Berners-Lee specifically for the RDF model, and (3) a simplified version of N3 called Turtle that is currently the most wide-spread syntax for RDF. The universAAL platform also uses the Turtle syntax. The RDF model basically says that data can be represented either as a literal or as a resource. Resources can be identified by URIs / IRIs and can be described based on their properties. The types of resources and the names of their properties are also resources, and as such, must be identified by URIs / IRIs. The names of resource types and resource properties follow the rule formulated in the last bullet of the previous enumeration. To describe a resource, statements must be built. A statement comprises a subject (the resource to be described), a predicate (a distinct property of that resource), and an object (the value of that property, which might be a literal or a resource).
  2. A first-level schema definition language for explicit specification of data models called RDF Schema (RDFS). RDFS extends the language constructs so that not only data but also data models can be represented in terms of RDF model. The most important language keywords added by RDFS are: rdfs:Class (the class of all classes), rdfs:Datatype (the type of all datatypes), rdfs:Resource (the root class for all resources), rdfs:Literal (the root datatype), rdfs:domain and rdfs:range that can be used for specifying certain relationships between a property (an instance of rdf:Property) and classes or datatypes, namely the domain and range of properties, rdfs:subClassOf that can be used for specifying hierarchical relationships between classes, and rdfs:subPropertyOf (similarly for specifying hierarchical relationships between properties).
  3. The Web Ontology Language (OWL) which builds on top of RDFS and introduces a set of new language constructs that provide us with the power of Description Logic (DL) for definition of ontologies. OWL divides rdfs:Resource into four disjoint subclasses, namely owl:Class (the class of all abstract classes), owl:Thing (the class of all individuals), owl:ObjectProperty (the class of properties that only accept individuals as value) and owl:DatatypeProperty (the class of properties that only accept literal values). It additionally defines (among others):
    • owl:FunctionalProperty as the class of all properties – no matter if an object property or a datatype property – that are not multi-valued and accept at most one value
    • owl:SymmetricProperty, owl:TransitiveProperty, and owl:InverseFunctionalProperty as subclasses of owl:ObjectProperty and equivalent to their counterparts in the theory of functions / relations in mathematics
    • owl:equivalentProperty and owl:inverseOf for defining further relationships (in addition to rdfs:subPropertyOf) between properties
    • owl:equivalentClass, owl:disjointWith, and owl:complementOf for defining further relationships (in addition to rdfs:subClassOf) between classes
    • owl:intersectionOf and owl:unionOf for constructing classes as intersection or union of other classes
    • owl:oneOf for constructing classes by enumerating all of their instances
    • owl:sameAs and owl:differentFrom for defining relationships between individuals
    • OWL defines another special construct for defining classes that is used in universAAL very intensively, namely owl:Restriction. Each restriction defines the class of all individuals that satisfy a condition on a certain property, e.g., the class of all individuals that are colored green or the class of all individuals that have at most three moons. To define a restriction, we have to specify a certain property as the value of owl:onProperty as well as exactly one of the following language keywords: owl:minCardinality (the minimum number of values), owl:maxCardinality (the maximum number of values – see the above example with "three" moons), owl:cardinality (the exact number of values), owl:hasValue (the exact value – see the above example with "green"), owl:allValuesFrom (exactly one specific type for all acceptable values), and owl:someValuesFrom (the mandatory type for some acceptable values).
  4. The SPARQL Protocol And RDF Query Language (SPARQL) that is a SQL-like query language for querying data represented in terms of RDF. The usage of SPARQL in universAAL is, however, currently very limited but is planned to be used more in future versions. For this reason, we are not providing any example here and invite the reader to refer to its original specification when interested.
Now, it's time to have a look at common topics by example (using the Turtle syntax that is also used in universAAL) so that we get ready for the more practical things in the next chapters. The examples are all from the domain of normal office working places in a simplified form with entities like Employees and Managers.

URIs of class and property names

Obviously, Employee and Manager are names with almost the same abstract meaning for all humans that have some understanding of these English words. When representing them in the virtual realm as reusable concepts, however, we need a unique identifier for them. As stated above, URIs / IRIs are used in the Semantic Web as the unique identifier. A URL dedicated to one distinct thing (and not used for different purposes) is an example of such URIs / IRIs. The most frequently used form for URIs / IRIs of abstract names representing concepts (such as type names and the names of properties) is to reserve a URL to uniquely represent a corresponding namespace and then append the concrete names to the URL of that namespace in order to build a unique identifier for each of those names. As a convention, the URLs of namespaces end with a "#" so that each name appended to it appears as a locally unique fragment, just in accordance with one of the wide-spread conventions in the Web.

Let us reserve the URL http://www.example.org/ontologies/office# to point to our office namespace. The URIs of the above names can then be built by appending them to this URL, which would result in (we have added a third concept, namely Staff as generalization of the other two concepts) 

<http://www.example.org/ontologies/office#Employee>
<http://www.example.org/ontologies/office#Manager>
<http://www.example.org/ontologies/office#Staff>
Let us also assume that employees usually report to managers; "reports to" is defining an asymmetric relationship between employees and managers. As we know from above, one of the functions of properties in the Semantic Web is to represent relationships between resources (see owl:ObjectProperty above). Hence, with http://www.example.org/ontologies/office#reportsTo we can also create an example of the URI of a property in our office namespace. As another example, let us define a datatype property for specifying a staff's name and call it hasName resulting in the URI http://www.example.org/ontologies/office#hasName.

In order to avoid repeating such long URIs each time we want to refer to a name, the Semantic Web standards follow the specification of XML namespaces and often make use of an abbreviated form defined in that specification. The abbreviated form consists of a so-called prefix (a short string ending with a ":" that represents the URI of the namespace) followed by the local names. In the above introductions to RDF, RDFS, and OWL, we have already made use of this form. For example, rdfs:subClassOf is the abbreviated form of http://www.w3.org/2000/01/rdf-schema#subClassOf; that is, the RDFS namespace has the URL http://www.w3.org/2000/01/rdf-schema#, which is normally associated with the prefix "rdfs:". The URL of the RDF namespace is http://www.w3.org/1999/02/22-rdf-syntax-ns# (usually substituted by the prefix "rdf:"). The OWL namespace (http://www.w3.org/2002/07/owl#) is normally abbreviated as "owl:".

Each of the syntaxes used for the serialization of RDF provides means for defining the namespace prefixes. In Turtle, this is done for the above three examples the following way (as you can see in this example, complete URIs are written in Turtle in a pair of <>): 

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
All names that have no prefix belong to a default namespace. In Turtle, names from the default namespace start with a ":" provided that such an empty prefix is previously defined in the corresponding Turtle segment. For example, with the following, we can define our office namespace as the default namespace: 
@prefix : <http://www.example.org/ontologies/office#> .
In some of the examples below, we assume that the above four namespace declarations are proceeding the corresponding Turtle segment as header and might avoid repeating them.

Subtypes of rdfs:Literal

In RDF, you can concretize the type of a literal by specifying a concrete datatype. For the basic datatypes, RDF reuses the primitive datatypes defined by XML Schema. Assuming the following prefix declaration 

@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
some of the imported datatypes can be referred to as xsd:string, xsd:int, xsd:float, xsd:double, xsd:boolean, xsd:dateTime, xsd:duration, and xsd:anyURI.

In Turtle, literal values are represented in quotation marks. If you want to provide a hint about the concrete type, you may optionally add "^^" followed by the URI of the datatype, e.g., "true"^^xsd:boolean or "2011-04-30T21:29:48"^^xsd:dateTime. For some types of literal values, (for example integers, floats, doubles, and booleans), the Turtle parser is expected to recognize the values when they are not in quotation marks; that is, true is equivalent to "true"^^xsd:boolean in Turtle.

Interpreting RDF statements in Turtle

Dependent on the log level you have configured, some RDF graphs may be logged and are available for further analysis and debugging purposes. Thus, this section gives an overview on how to write/interpret RDF statements that are serialized in Turtle format. You certainly remember that statements comprise a subject, a predicate, and an object. Writing a single statement in Turtle is very straightforward; you must only use the syntactical element "." to finish a statement: 

subject predicate object .
There can be two concrete forms of statements: 
resource property resource .
or 
resource property literal .
If you would like to make more than one statement with the same subject, you can leave out the subject in the subsequent statements if you finish the previous statement with a ";" instead of a "." (the word value is used as a placeholder for the object of the statements, whether a resource or a literal): 
resource-1 property-1 value-1 ;
           property-2 value-2 .
The above is equivalent to 
resource-1 property-1 value-1 .
resource-1 property-2 value-2 .
If we want to specify more than one value for the same property, we can use another form of abbreviation. That is, the following 
resource-1 property-1 value-1 ;
           property-1 value-2 .
can be abbreviated as 
resource-1 property-1 value-1 , value-2 .
However, both of the above mean that there might be other values for the same property that we do not know or do not mention in these statements. But, if you really mean that resource-1 has exactly two values for property-1, then you must rewrite it the following way 
resource-1 property-1 ( value-1 value-2 ) .
To state that resource-1 has no values for property-1, the syntax would be 
resource-1 property-1 ( ) .
We will give further hints about the Turtle syntax when the need arises, but would like to still add a hint about the way you can specify the type of a resource in Turtle. To follow the RDF specification, the types of resources must be specified as the value for the standard property rdf:type, for example 
resource-1 rdf:type resource-2 .
In Turtle, you can abbreviate the above statement the following way 
resource-1 a resource-2 .
In the next sections, you will see concrete usage of this notation.

URIs of individuals

As stated above, all resources that are neither classes nor properties are classified as individuals. Individuals might be known or anonymous. Known individuals must be referred to using their URIs / IRIs. These URIs might follow the convention mentioned for names or be formed in other ways, or even use schemes other than "http:" (e.g., "urn:" or "mailto:"). Let's assume that in our example office, all URIs of the staff start with http://www.example.org/staff/ and end with the full name of the concrete staff without spaces, but with a capital letter in the beginning of each word. Then, Alice Muster can be identified by http://www.example.org/staff/AliceMuster and Bob Pattern by http://www.example.org/staff/BobPattern.

The representation of anonymous individuals might differ in different syntaxes. In Turtle, "[]" is used to indicate an anonymous individual. If you know some properties of an anonymous individual, you can directly write the corresponding statements within the brackets (see the example of three anonymous instances of owl:Restriction below). If you need to refer to the same anonymous resource more than just once, then you can associate it with a pseudo-URI from the "namespace" of anonymous resources denoted as "_:" followed by a string that is unique in your Turtle segment, e.g. "_:anon001".

The office ontology

Now, let's formulate all of the implicit assumptions in our example so far as well as statements made in natural language explicitly in a formal way. We trust that you can interpret the following correctly when you compare the statements with what you have read so far. 

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix : <http://www.example.org/ontologies/office#> .
:hasName a owl:DatatypeProperty .
:reportsTo a owl:ObjectProperty .
:Staff a owl:Class ;
       rdfs:subclassOf [ a owl:Restriction ; owl:onProperty :hasName ; owl:cardinality 1 ] ;
       rdfs:subclassOf [ a owl:Restriction ; owl:onProperty :hasName ; owl:allValuesFrom xsd:string ] .
:Manager a owl:Class ;
         rdfs:subClassOf :Staff .
:Employee a owl:Class ;
          rdfs:subClassOf :Staff ;
          owl:disjointWith :Manager ;
          rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :reportsTo ; owl:allValuesFrom :Manager ] .
You might ask why we have avoided the following more exhaustive way of defining our properties: 
:hasName a owl:DatatypeProperty ;
         rdfs:domain :Staff ;
         rdfs:range xsd:string .
:reportsTo a owl:ObjectProperty ;
           rdfs:domain :Employee ;
           rdfs:range :Manager .
It was not because of waiting for the classes :Staff, :Employee, and :Manager to be defined (forward-referencing is allowed anyhow), but the point is that by using the restriction form with owl:allValuesFrom we reach the desired effect while letting it open that the same properties are used in the context of other classes differently.

Exchange of data based on an ontology

Now that we have already defined our ontology, let's write some RDF statements based on this ontology, e.g., that Alice Muster is a manager to whom the employee named Bob Pattern reports: 

@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix : <http://www.example.org/ontologies/office#> .
<http://www.example.org/staff/AliceMuster> a :Manager ;
                                           :hasName "Alice Muster"^^xsd:string .
<http://www.example.org/staff/BobPattern> a :Employee ;
                                          :hasName "Bob Pattern"^^xsd:string ;
                                          :reportsTo <http://www.example.org/staff/AliceMuster> .

For the purposes of this overview, this first impression of RDF and OWL should be enough. More information can be taken from the official primers at the W3C homepage (RDF and OWL).

Found a problem?

  • Report suggestions, missing, outdated or wrong documentation creating an Issue with "documentation" tag

Support:

Found a problem?
  • Report suggestions, missing, outdated or wrong documentation creating an Issue with "documentation" tag

Clone this wiki locally