This document is also available in non-normative PDF version.
Copyright © 2004 DERI®, All Rights
Reserved. DERI liability, trademark,
document use, and software licensing rules apply.
Ontologies are the key to link consensual real world semantics intended by humans with computers. They conceptualize a certain domain and add formal semantics to its definition. Defining an Ontology language or an API for Ontology interchange can be viewed as an ontological problem, too. The domain is here the proper modeling primitives for describing ontologies and the Ontology that consists of these modeling primitives is a Meta-Ontology, that defines how to define Ontologies. An API can be language neutral or language dependent. The latter assume one language that is used on a world-wide scale to define Ontologies. However, this is a very strong assumption and we will have to see whether this ideal state can be achieved after the days of Babel. With XML(S), RDF(S), and OWL we already have three W3C recommendations in this area and further may follow around the standardization of rule languages for the web. Notice, that OWL alone comprises three different languages and similar may happen for the rule language (and quadratic for the combination of rules and OWL). A language-neutral API introduces weaker assumptions. It fixes a meta model (i.e., it standardizes at the epistemological level and not at the logical level underneath [Brachman, 1983]). This deliverable defines this language-neutral meta model for defining Ontologies. The actual language for defining the semantics of the elementary slots of this model are kept open.
Ontologies define a consensual terminology by providing concepts and relationships among the set of concepts. In order to capture semantic properties of relations and concepts, an Ontology generally also provides a set of axioms, which means expressions in some logical framework, for instance First-Order Logic. Each element that belongs to the established terminology, i.e. concepts and relations, can be further constrained semantically by means of a logical constraint that expresses some sort of real-world semantics related to this element. In principle, an Ontology constitutes of four main building blocks: concepts, relations, instances and axioms. In addition, we need non-functional description of Ontologies and mediators to enable distributed Ontology specification. An Ontology is defined as follows [1]:
Listing 1. Ontology definition |
| ontology[ nonFunctionalProperties => nonFunctionalProperties usedMediators =>> mediatorDefinition concepts =>> conceptDefinition relations =>> relationDefinition instances =>> instanceDefinition axioms =>> axiomDefinition ] |
non functional properties of an Ontology consist of
the properties described in Section 2.1.Non functional properties are defined as a set of tuples, where each tuple
consists of a property and its value constraint. They consist of the Dublin Core Metadata
ElementSet [Weibel et al.] plus the
version element:
Listing 2. Non functional properties definition |
| nonFunctionalProperties[ title => title creator => creator subject => subject description => description publisher => publisher contributor => contributor date => date type => type format => format identifier => identifier source => source language => language relation => relation coverage => coverage rights => rights version => version ] |
title will be a
name by which the element is formally known.creator include a person, an
organization, or a service. Typically, the name of a
creator should be used to indicate the entity.subject will be expressed as keywords, key phrases or
classification codes that describe a topic of the element. Recommended
best practice is to select a value from a controlled vocabulary or
formal classification scheme.description include, but are not limited to: an abstract,
table of contents, reference to a graphical representation of content
or a free-text account of the content.publisher include a person, an organization, or a service.
Typically, the name of a publisher should be used to
indicate the entity.contributor include a person, an
organization, or a service. Typically, the name of a
contributor should be used to indicate the entity.date will be associated with the creation or availability
of the element.Type includes terms describing general categories,
functions, genres, or aggregation levels for content.format may include the media-type or dimensions of the
element. Format may be used to identify the software, hardware, or
other equipment needed to display or operate the element. Examples of
dimensions include size and duration.source element
in whole or in part. Recommended best practice is to identify the
referenced element by means of a string or number conforming to a
formal identification system.coverage will include spatial location (a place name or
geographic coordinates), temporal period (a period label, date, or date
range) or jurisdiction (such as a named administrative entity).rights will contain a rights management statement for the
element, or reference a service providing such information. Rights
information often encompasses Intellectual Property Rights (IPR),
Copyright, and various Property Rights. If the Rights element is
absent, no assumptions may be made about any rights held in or over the
element.In this section, we introduce the notion of mediators and
define the elements that are used in the description of a mediator. Mediators
import ontologies and resolve possible representation mismatches between
ontologies. The mediator is defined as follows:
Listing 3. Mediator definition |
| mediatorDefinition[ nonFunctionalProperties => nonFunctionalProperties sourceComponent =>> ontology mediationService => implementation ] |
mediation service points to a declarative
description of the way in which ontolgies are imported and the way in
which possible representation mismatches between ontologies involved in
the mediator are resolved and/or a web service that actually implements
the way in which ontolgies are imported and the way in which possible
representation mismatches are resolved.Concepts constitute the basic elements of the consensual terminology for some problem domain. They provide an abstract view on real-existing and artificial artifacts within the addressed domain of discourse.
From a high-level perspective, a concept – described by a concept
definition – provides attributes with names and types. It has a name, can be
textually described in natural language and might change over time and thus
has a version (they are part of the non functional properties of the
concept).
Furthermore, a concept can have several (possibly none) direct superconcepts as specified by the so-called "is_a"-relation.
When describing the semantics of concepts within some Ontology, we favor a uniform and rather general approach: we consider the semantics to be captured by means of a logical expression.
For instance, this allows us to state that some concept represents the union or intersection of two or more other concepts. Consider an Ontology on social structures within a human society, and then we can define concepts like “Human-being” or “Female” and accurately describe the semantics of the concept “Granny” as precisely the intersection of the concepts “Human-being”, “Female” and “Parent of some parent”.
Such modeling styles are commonly used in many Description Logics [Baader et al., 2003] and can be found in widely-used Ontology languages like OWL [Dean et al., 2004] as well.
Hence, we extract the following abstract description for concepts:
Listing 4. Concept definition |
| conceptDefinition :: axiomDefinition conceptDefinition[ superConcepts =>> conceptDefinition attributes =>> attributeDefintion methods =>> methodDefintion ] |
superconcepts for some concept. attributes that represent named slots for data values and
instances that have to be filled at the instance level. An attribute
specifies a slot of a concept by fixing the name of the slot as well as
a logical constraint on the possible values filling that slot. Hence,
this logical expression can be interpreted as a typing constraint.
Listing 5. Attribute definition |
| attributeDefintion :: axiomDefinition attributeDefintion[ range => axiomDefinition ] |
methods that can be invoked on each instance of a concept
and in response return some result value.
A method specifies a function that can be invoked on a specific instance of a concept. When invoking the function, one has to specify the values of the parameters, for which the function has to be computed. The specific instance, for which the method is invoked, can be seen as an implicit input parameter of the function, which is not explicitly contained in the set of input parameters. The computed value will then be returned to the invoker.
Listing 6. Method definition |
| methodDefintion :: axiomDefinition methodDefintion[ range => axiomDefinition parameters => LIST(parameterDefinition) ] |
parameter is a named placeholder for some value.
This concept is used in the definition of methods as well as in
the definition of n-ary relations.
Listing 7. Parameter definition |
| parameterDefinition ::
axiomDefinition parameterDefinition[ domain => axiomDefinition ] |
Relations are used in order to model interdependencies
between several concepts (respectively instances of these concepts) with
respect to the problem domain.
Relations between concepts are more general than simple
attributes or properties as for instance in OWL. Mathematically,
relationships are simply sets of n-tuples, over the domain of instances of
concepts. In popular and commonly used system modeling languages like UML [Fowler, 2003] such concrete tuples are often called
links. The underlying semantics of cardinalities in the case of n-ary
relations follows the definition in the UML framework [Rumbaugh et al., 1998].
Relations can be very specific in nature and only applicable
in the context of a particular problem domain, but there are also relations
that occur frequently when modeling ontologies for different application
areas. There are several common properties that modeled relations can
provide, e.g. symmetry, transitivity, and reflexivity. Again, for the sake of
simplicity we decide not to represent these common properties of
relationships currently within the Meta-Ontology explicitly but implicitly by
means of axioms.
Other dependencies between relationships (for instance subset, intersection, union, difference, and inverse relationship between two or more relations) will be dealt with in the same way.
Listing 8. Relation definition |
| relationDefinition :: axiomDefinition relationDefinition[ parameters => LIST(parameterDefinition) ] |
parameter descriptions specifying each of the
concepts that are interrelated.
Eventually, within an Ontology there might be instances
defined for some concept. Therefore we have to reflect the
“instance_of”-relation that can be given within an Ontology
specification.
Listing 9. Instance definition |
| instanceDefinition :: axiomDefinition instanceDefinition[ instanceOf =>> conceptDefinition attributeValues =>> attributeValueDefinition ] |
Listing 10. Attribute value definition |
| attributeValueDefinition ::
axiomDefinition attributeValueDefinition[ value => axiomDefinition ] |
An axiomDefinition is considered to be a logical expression
enriched by some extra-logical information.
Listing 11. Axiom definition |
| axiomDefinition[ nonFunctionalProperties => nonFunctionalProperties defined_by => logicalExpression ] |
non functional properties of an axiom consist of the
properties described in Section 2.1.This document presents a language-neutral API for Ontology interchange that is conform to WSMO [Roman et al., 2004] which developed by the SDK project cluster.
[Baader et al., 2003] F. Baader, D. Calvanese, and D. McGuinness: The Description Logic Handbook, Cambridge University Press, 2003.
[Brachman, 1983] R. J. Brachman: What IS-A Is and Isn't: An Analysis of Taxonomic Links in Semantic Networks. IEEE Computer 16(10): 30-36 (1983).
[Dean et al., 2004] M. Dean, G. Schreiber, S. Bechhofer, F. van Harmelen, J. Hendler, I. Horrocks, D. L. McGuinness, P. F. Patel-Schneider, and L. A. Stein: OWL Web Ontology Language Reference, W3C Recommendation, 10 February 2004. Available at http://www.w3.org/TR/2004/REC-owl-ref-20040210/.
[Fowler, 2003] M. Fowler: UML Distilled: A Brief Guide to the Standard Object Modeling Language, Addison-Wesley, 3rd edition, 2003.
[Roman et al., 2004] D. Roman, U. Keller, H. Lausen (eds.): Web Service Modeling Ontology - Standard (WSMO - Standard), version 0.2 available at http://www.wsmo.org/2004/d2/v02/.
[Rumbaugh et al., 1998] J. Rumbaugh, I. Jacobson, and G. Booch: The Unified Modeling Language Reference Manual, Object Technology Series, Addison-Wesley, 1998.
[Weibel et al. 1998] S. Weibel, J. Kunze, C. Lagoze, and M. Wolf: RFC 2413 - Dublin Core Metadata for Resource Discovery, September 1998.
The work is funded by the European Commission under the projects DIP, Knowledge Web, Ontoweb, SEKT, SWWS, Esperonto, and h-TechSight; by Science Foundation Ireland under the DERI-Lion project; and by the Vienna city government under the CoOperate program.
The editors would like to thank to all the members of the WSML working group for their advice and input into this document.
[1] The notation used for defining different concepts in this deliverable is based on F-Logic syntax.