3. DL Semantics - quoll/DLe GitHub Wiki
The following provides the formal set-based semantics of the Description Logic table:
| Name | Syntax | Semantics |
|---|---|---|
| Top | β€ | π«β |
| Bottom | β₯ | β |
| Conjunction | C β D | Cβ β Dβ |
| Disjunction | C β D | Cβ β Dβ |
| Negation | Β¬C | π«β \ Cβ |
| Existential restriction | βr.C | {d β π«β | βe β π«β.(d,e) β rβ β e β Cβ} |
| Value restriction | βr.C | {d β π«β | βe β π«β.(d,e) β rβ β e β Cβ} |
| Self restriction | βr.Self | {d β π«β | (d,d) β rβ} |
| Unqualified number restriction | (β€n r) (β₯n r) (=n r) |
{d β π«β | #{e | (d,e) β rβ} β€ n} {d β π«β | #{e | (d,e) β rβ} β₯ n} {d β π«β | #{e | (d,e) β rβ} = n} |
| Qualified number restriction | (β€n r.C) (β₯n r.C) (=n r.C) |
{d β π«β | #{e | (d,e) β rβ β e β Cβ} β€ n} {d β π«β | #{e | (d,e) β rβ β e β Cβ} β₯ n} {d β π«β | #{e | (d,e) β rβ β e β Cβ} = n} |
| Nominal | {a} | {aβ} |
| Role value map | (r β s) | {d β π«β | {e | (d,e) β rβ} = {e' | (d,e') β sβ}} |
| Predicate restriction | βc1,β¦,ck.P | {d β π«β | (c1β(d),β¦,ckβ(d)) β Pπ»} |
| Role composition | r β s | {(d,f) β π«β Γ π«β | βe β π«β.(d,e) β rβ β (e,f) β sβ} |
| Inverse role | rβ» | {(e,d) β π«β Γ π«β | (d,e) β rβ} |
| Feature chain | g1β―gnh | (g1β―gnh)β(d) = hβ(gnβ(β―(giβ(d))β―)) |
| General Concept Inclusion | C β D | Cβ β Dβ |
| Concept Definition | A β‘ C | Aβ = Cβ |
| Role inclusion | r β s | rβ β sβ |
| Role disjointness | Disj(r,s) | rβ β sβ = β |
| Role transitivity | Trans(r) | (d,e) β rβ β (e,f) β rβ β (d,f) β rβ) |
| Role functionality | Func(r) | (d,e) β rβ β (d,f) β rβ β e = f |
| Role reflexivity | Ref(r) | d β π«β β (d,d) β rβ |
| Role irreflexivity | Irref(r) | d β π«β β (d,d) β rβ |
| Role symmetry | Sym(r) | (d,e) β rβ β (e,d) β rβ |
| Role antisymmetry | Asym(r) | (d,e) β rβ β (e,d) β rβ |
| Concept assertion | a:C | aβ β Cβ |
| Role assertion | (a,b):r | (aβ,bβ) β rβ |
Description Logic (DL) is used to "describe" concepts and roles (or classes, and relationships/properties). However, these descriptions are an abstract concept over data, rather than specifying particular data.
On the other hand, Sets describe a specific group of instances that are members of the set. This is a concrete representation of the data.
When a Concept (from DL) is applied to a particular context, then a set can be derived. For instance, when the concept "Employee" is considered in the context of a particular company, then the resulting set will contain all of the employees of that company. But when the concept is applied in the context of a different company, then this will result in a completely different set of employees. This is clearer when we combine expressions. For instance, we may want to consider nurses who are employees, and so we create the conjunction of Nurse β Employee. In the concept of a legal firm, the set of people who are described by this concept is likely to be an empty set, but in a healthcare company the set might be the majority of the workforce. Similarly, when roles are applied in a particular context, this creates a set of specific relationships in that context.
When Concepts and Roles are defined together in relation to one another, they form a Model. When a Model is applied within a context to create sets, this is referred to as Interpreting the model in that context. For our Employees, we may have a role for "reportsTo" which connects most employees to their manager, and when we interpret this in the context of a specific company, we can get a set of everyone who works there, and the reporting structure of that company's Org Chart.
Because the Concepts and Roles in a model can be used to define sets in a particular context, but are not themselves sets, they are not manipulated or combined using the syntax of set operations. Instead, we have similar, related operators, that are specific to Description Logic. This is why DL has β when set theory uses β, β when sets use β,and β when sets use β. These operators are distinct from the set operators, but are visually similar.
An Interpretation β=(π«β,β β) is defined as a set of a instances π«β, along with an operator β β that maps concepts to a subset of π«β, and maps roles to a subset of binary relations defined by π«β Γ π«β. For instance, in the context of a particular company, π«β could contain all the employees, contractors, business units, assets, and contracts. The β β mapping then maps this complete set of elements to the appropriate concepts, while also mapping relationships between elements to appropriate roles.
So in a hypothetical company "Peter", "Mary", and "Accounting" may appear within π«β. This company, that may both be part of the "Employee" class, with ("Mary","Accounting") and ("Peter","Accounting") being part of the "worksIn" role, and ("Peter","Mary") being an element of the "reportsTo" role.
Some roles may also connect entities to elements of a concrete domain π», where π» contains values such as strings and numbers. These sorts of roles are often referred to as attributes.
In the above table we can see "Feature chain" defining a composition of roles to a specific attribute. "Abstract features" describe roles that connect one entity in π«β to another, such as gβ:π«ββπ«β while "concrete features" describe roles that connect entities to concrete values, as in hβ:π«ββπ«π».
In the "Predicate restriction" entry of the table, a set of attributes (which may be abstract roles referencing elements of π«β, but will typically be values in π«π») on an entity is referenced, where some predicate Pπ» can be applied to these values to determine a true/false value.
For example, consider the attributes startDate and endDate. The predicate greaterThan can be defined as a binary predicate that returns true when the first argument is larger than the second, and false otherwise. Consequently, the expression βstartDate,endDate.greaterThan references a class of all elements which have startDate and endDate values where the startDate comes after the endDate (we probably want to report all instances of this class as erroneous).
Note that predicates Pπ» are not defined by DL, and are expected to be defined elsewhere.
Syntactically, Role Value Maps look like Role Inclusion, just with parentheses added. This is unfortunate, as the semantics are vastly different.
Role Inclusion means that for a given pair of roles r β s then every relationship of r between two entities implies the relationship s between those entities. Consider a concrete example of hasMother β hasParent (We will use the "default" namespace of ":", so all individuals and properties that appear as IRIs will be prefixed with :).
So if Mary is Peter's mother then this would be expressed in various syntaxes as:
-
(peter, mary):hasMotherβ DL role assertion syntax -
:peter :hasMother :maryβ RDF triple -
ObjectPropertyAssertion( :hasMother :peter :mary )β OWL Functional Notation -
hasMother(peter, mary)β Datalog syntax
The hasMother β hasParent statement says that for every hasMother relationship, there is a hasParent relationship:
(peter, mary):hasParent:peter :hasParent :maryObjectPropertyAssertion( :hasParent :peter :mary )hasParent(peter, mary)
Role value maps are used to describe concept classes where a role connecting the class instance to a value is equal to another role connecting the same instance to the same value.
For instance, say we define a Course as being a thing that is held-at an instance of University. We also define a Lecturer as one who teaches a Course and is employed-by a University. We can use a role value map to indicate that if the lecturer teaches a course held at a university, then they are employed-by that university. This is done by using a role value map between the composed property of teaches β held-at and employed-by:
( teaches β held-at β employed-by )
Note that this defines a class: in this case, it provides a stricter definition for the Lecturer class. It does this by defining the composed combination of teaches/held-at to lead to the same instance of University that the employed-by property references.
Because both sides of the role value map operator must lead to the same value, the order of the operators does not matter. So the above statement is equivalent to:
( employed-by β teaches β held-at )