2. DL and OWL

OWL

The Web Ontology Language (OWL - the reason for the unexpected acronym is described here) implements a portion of Description Logic (DL) in a machine-readable way. Rather than having a single syntax, OWL describes a data model, which can be represented in various formats.

OWL is built on a set of design principles that makes it compatible with the Resource Description Framework (RDF): a graph-based representation of data that is constructed around Internationalized Resource Identifiers (IRI)^*. However, the Description Logic basis of OWL is general, making it applicable to other data structures, including non-RDF graphs or Relational Database Management Systems (RDBMS). OWL includes the ability to annotate each of its structural elements, and these annotations can provide metadata for explain any mapping choices to a non-RDF system.

^*IRIs are a more generalized form of Uniform Resource Identifiers (URI), which also allow non-ASCII characters. URIs and URLs are restricted to only using letters and numbers, plus a small set of ASCII characters (-._~:/?#[]@!$&'()*+,;=). Anything else has to be "percent-encoded". In contrast, IRIs can use the entire Unicode set.

OWL Syntax

OWL is defined using the OWL Functional-Style Syntax, which is the syntax used for formally specifying OWL and its data model. This syntax was not designed for machine interaction, though it is often implemented to make it easier for humans to read and write OWL. The recognized syntaxes for writing OWL are:

RDF/XML: A graph representation of the ontology, in RDF/XML format. This is the original format for OWL documents, and the only one that OWL-compliant systems are required to support.
OWL/XML: A direct XML representation of the ontology.
Functional Syntax: The specification language.
Manchester Syntax: A format designed specifically for human readability. Some unusual constructs cannot be expressed in Manchester syntax, but this is where properties and classes are used in multiple ways, such as overloading properties between object/data/annotation properties, or between Classes and Datatypes.
Turtle: A direct graph representation using the Turtle format. Turtle maps the triples of a graph directly to syntax, using a compact representation. As the formal mapping of OWL to RDF is specified in triples, this is an easier format to connect to that standard.

Non-DL Elements of OWL

OWL provides representations for almost all the elements of DL, with a number of pragmatic extensions:

Annotations: each element of a model can be annotated, including annotations themselves. Annotations include both the property (for instance, "label", "comment", "version") and the value (usually text).
Distinction between Object Properties and Data Properties: while the semantics of DL discuss "abstract features" and "concrete features", the syntax of DL does not distinguish between the two. OWL maintains a strict separation between entities in the object domain and values in the data domain. An "abstract feature" in DL is referred to as an ObjectProperty in OWL (a reference to another entity), and a "concrete feature" becomes a DataProperty (an RDF literal value, such as a string, date, or number).
Datatypes: DL has little to say about "concrete" values, mostly treating them as a data domain like other categories. OWL has a list of recognized datatypes borrowed from the XML Schema Definition Language (XSD), along with a couple of extensions: rationals, reals, rdfs:Literal, rdf:PlainLiteral, and rdf:XMLLiteral. OWL also has a "Facets" facility for constraining datatypes by value.
Keys: OWL provides the HasKey mechanism for specifying a collection of object and data properties, which, taken together, can uniquely identify an entity. This is similar to an Inverse Functional property (a single property that can uniquely identify an entity), but can require multiple properties to specify the individual entity. Also, Inverse Functional properties are defined in terms of an inverse property, which is only applicable to object properties, while HasKey can specify data properties that uniquely identify entities.

OWL ↔︎ DL

The following table shows the translation of DL to OWL:

OWL	DL
`owl:Thing`	⊤
`owl:Nothing`	⊥
`owl:topObjectProperty`	U
`owl:bottomObjectProperty`	B
`ObjectIntersectionOf(`C₁ … C_n`)`	C₁ ⊓ … ⊓ C_n
`ObjectUnionOf(`C₁ … C_n`)`	C₁ ⊔ … ⊔ C_n
`ObjectComplementOf(`C`)`	¬C
`ObjectOneOf(`x₁ … x_n`)`	{x₁} ⊔ … ⊔ {x_n}
`ObjectSomeValuesFrom(`r C`)`	∃r.C
`DataSomeValuesFrom(`d C`)`	∃d.C
`ObjectAllValuesFrom(`r C`)`	∀r.C
`DataAllValuesFrom(`d C`)`	∀d.C
`ObjectHasValue(`r x`)`	∃r.{x}
`DataHasValue(`d v`)`	∃d.{x}
`ObjectHasSelf(`r`)`	∃r.Self
`ObjectMinCardinality(`n r`)`	(≥n r)
`ObjectMaxCardinality(`n r`)`	(≤n r)
`ObjectExactCardinality(`n r`)`	(=n r)
`DataMinCardinality(`n d`)`	(≥n d)
`DataMaxCardinality(`n d`)`	(≤n d)
`DataExactCardinality(`n d`)`	(=n d)
`ObjectMinCardinality(`n r C`)`	(≥n r.C)
`ObjectMaxCardinality(`n r C`)`	(≤n r.C)
`ObjectExactCardinality(`n r C`)`	(=n r.C)
`DataMinCardinality(`n d D`)`	(≥n d.D)
`DataMaxCardinality(`n d D`)`	(≤n d.D)
`DataExactCardinality(`n d D`)`	(=n d.D)
`SubObjectPropertyOf(`r s`)`	r ⊑ s
`SubDataPropertyOf(`d e`)`	d ⊑ e
`ObjectPropertyChain(`p₁ … p_n`)`	p₁ ∘ … ∘ p_n
`ObjectInverseOf(`r`)`	r⁻
`SubClassOf(`C D`)`	C ⊑ D
`EquivalentClasses(`A C`)`	A ≡ C
`EquivalentClasses(`C₁ … C_n`)`	⋃_i≠j{C_i ⊑ C_j}
`DisjointClasses(`A C`)`	A ⊑ ¬C
`DisjointClasses(`C₁ … C_n`)`	⋃_i≠j{C_i ⊑ ¬C_j}
`DisjointUnion(`A C`)`	A ≡ ¬C
`DisjointUnion(`C₁ … C_n`)`	⋃_i≠j{C_i ⊑ ¬C_j} ⋃ {C₁ ⊔ … ⊔ C_n}
`SubObjectPropertyOf(`r s`)`	r ⊑ s
`SubDataPropertyOf(`d e`)`	d ⊑ e
`EquivalentObjectProperties(`p₁ … p_n`)`	⋃_i≠j{p_i ⊑ p_j}
`EquivalentDataProperties(`d₁ … d_n`)`	⋃_i≠j{d_i ⊑ d_j}
`DisjointObjectProperties(`r s`)`	Disj(r,s)
`DisjointObjectProperties(`r₁ … r_n`)`	⋃_i≠j{r_i ⊑ ¬r_j}
`DisjointDataProperties(`d₁ … d_n`)`	⋃_i≠j{d_i ⊑ ¬d_j}
`InverseObjectProperties(`r s`)`	r ≡ s⁻
`ObjectPropertyDomain(`r C`)`	∃r.⊤ ⊑ C
`DataPropertyDomain(`d D`)`	(≥1 d) ⊑ D
`ObjectPropertyRange(`r C`)`	⊤ ⊑ ∀r.C
`DataPropertyRange(`d D`)`	⊤ ⊑ ∀d.D
`TransitiveObjectProperty(`r`)`	Trans(r)
`FunctionalObjectProperty(`r`)`	Func(r) or ⊤ ⊑ (≤1 r)
`FunctionalDataProperty(`d`)`	Func(d) or ⊤ ⊑ (≤1 d)
`ReflexiveObjectProperty(`r`)`	Ref(r)
`IrreflexiveObjectProperty(`r`)`	Irref(r)
`SymmetricObjectProperty(`r`)	Sym(r)
`AsymmetricObjectProperty(`r`)`	Asym(r)
`SameIndividual(`a₁ … a_n`)`	⋃_i≠j{a_i = ¬a_j}
`DifferentIndividuals(`a₁ … a_n`)`	⋃_i≠j{a_i ≠ ¬a_j}
`ClassAssertion(`C a`)`	a:C
`ObjectPropertyAssertion(`r a b`)`	(a,b):r
`NegativeObjectPropertyAssertion(`r a b`)`	¬(a,b):r
`DataPropertyAssertion(`d a v`)`	(a,v):d
`NegativeDataPropertyAssertion(`d a v`)`	¬(a,v):d

The so-called DL expressions that use ⋃ are using an informal meta-syntax saying that all of the constraints described in the braces hold.

Annotations

Each of the DLe annotations are mapped to an OWL representation.

DLe	OWL
`@label IRI "text"`	`AnnotationAssertion(rdfs:label :IRI "text")`
`@db IRI "name"`	`AnnotationAssertion(rdfs:isDefinedBy :IRI "name")`
`@doc IRI "text"`	`AnnotationAssertion(rdfs:comment :IRI "text")`
`@storage IRI "text"`	`AnnotationAssertion(rdfs:seeAlso :IRI "text")`
`@ann IRI aProp "text"`	`AnnotationAssertion(:aProp :IRI "text")`
`@prefix pre: <namespace>`	`Prefix(pre:=<namespace>)`
`@import <iri>`	`Import(<iri>)`
`@ontology <iri>`	`Ontology(<iri>` …rest of document…`)`
`# Comment text`	`AnnotationAssertion(dle:comment nextResourceIRI "Comment text")`

The nextResourceIRI refers to the next resource defined in the DLe document. Comments get attached as a special predicate annotation to this entity.

Using these annotations allows DLe to be converted to other OWL formats without loss of information.

Navigation Menu

2. DL and OWL

OWL

OWL Syntax

Non-DL Elements of OWL

OWL ↔︎ DL

Annotations

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Clone this wiki locally