Holger Lausen
Dumitru Roman
Uwe Keller
Dieter Fensel
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 case assumes 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, based on the ontology meta model presented in [Roman et al., 2004, chapter 4]. The actual language for defining the semantics of the elementary slots of this model are kept open.
In order to define WSMO, which is meant to be a meta-model for semantic web services, we make use of Meta Object Facility (MOF) [OMG, 2004], a specification that defines an abstract language and a framework for specifying, constructing, and managing technology neutral metamodels. The meaning of the metamodeling constructs, marked as bold in the listings throughout this document, is given by the MOF specification ([OMG, 2004]). We make the following assumptions:
This document is organized as follows: Chapter 2 presents the meta model for ontologies to be used for a language-neutral ontology API; Chapter 3 defines the non functional properties and Chapter 4 the use of mediators. Chapter 5 clarifies the use of the presented meta model in the development of applications, which use ontologies. Finally, we present conclusions and future directions in Chapter 6.
In WSMO Ontologies are the key to link conceptual real world semantics defined and agreed upon by communities of users. An ontology is a formal explicit specification of a shared conceptualization [Gruber, 1993]. From this rather conceptual definition we want to extract the essential components which define an ontology. Ontologies define a common agreed upon 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. An ontology is defined as follows:
Class ontology
hasNonFunctionalProperty type nonFunctionalProperty
hasImportedOntology type ontology
hasUsedMediator type ooMediator
hasConcept type concept
hasRelation type relation
hasFunction type function
hasInstance type instance
hasAxiom type axiom
|
The following non functional properties are available for characterizing ontologies: Contributor, Coverage, Creator, Date, Description, Format, Identifier, Language, Owner, Publisher, Relation, Rights, Source, Subject, Title, Type, Version.
Building an ontology for some particular problem domain can be a rather
cumbersome and complex task. One standard way to deal with the complexity is
modularization. importedOntologies allow a modular approach for
ontology design; this simplified statement can be used as long as no
conflicts need to be resolved, otherwise an ooMediator needs to
be used.
When importing ontologies, most likely some steps for aligning, merging
and transforming imported ontologies have to be performed. For this reason
and in line with the basic design principles underlying the WSMF, ontology
mediators (ooMediator) are used when an alignment of the
imported ontology is necessary. Mediators are described in Section 5 in more detail.
Concepts constitute the basic elements of the agreed terminology for some problem domain. From a high level perspective, a concept – described by a concept definition – provides attributes with names and types. Furthermore, a concept can be a subconcept of several (possibly none) direct superconcepts as specified by the "isA"-relation.
Class concept
hasNonFunctionalProperty type nonFunctionalProperty
hasSuperConcept type concept
hasAttribute type attribute
hasDefinition type logicalExpression
|
non functional properties recommended are: Contributor, Coverage,
Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.attributes that represent named slots for data values for
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.
Class attribute
hasNonFunctionalProperty type nonFunctionalProperty
hasRange type concept
|
non functional properties recommended are: Contributor, Coverage, Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.concept that serves as an integrity constraint
on the values of the attribute.forAll ?x ( ?x memberOf C
implies l-expr(?x) )forAll ?x ( ?x memberOf C
impliedBy l-expr(?x) )forAll ?x ( ?x memberOf C
equivalent l-expr(?x) )
where l-expr(?x) is a logical expression with precisely
one free variable ?x.
In the first case, one gives a necessary condition for membership in the extension of the concept; in the second case, one gives a sufficient condition and in the third case, we have a sufficient and necessary condition for an object being an element of the extension of the concept.
Relations are used in order to model interdependencies
between several concepts (respectively instances of these concepts).
Class relation
hasNonFunctionalProperty type nonFunctionalProperty
hasSuperRelations type relation
hasParameters type parameter
hasDefinition type logicalExpression
|
non functional properties recommended are: Contributor, Coverage,
Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.relations of which the defined relation
is declared as being a subrelation. Being a subrelation of some other
relation in particular means that the relation inherits the signature
of this superrelation and the corresponding constraints. Furthermore,
the set of tuples belonging to the relation (the extension of the
relation, resp.) is a subset of each of the extensions of the
superrelations.Class parameter
hasNonFunctionalProperty type nonFunctionalProperty
hasDomain type concept
|
non functional properties recommended are: Contributor, Coverage, Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.concept constraining the possible values that
the parameter can take.logicalExpression defining the set of instances (n-ary
tuples, if n is the arity of the relation) of the relation. If the
parameters are specified the relation is represented by a n-ary
predicate symbol with named arguments parameters of the relation) where
the identifier of the relation is used as the name of the predicate
symbol. If R is the identifier denoting the relation and the parameters
are specified then the logical expression takes one of the following
forms:
forAll ?v1,...,?vn ( R[p1
hasValue ?v1,...,pn hasValue ?vn]
implies l-expr(?v1,...,?vn) )forAll ?v1,...,?vn ( R[p1
hasValue ?v1,...,pn hasValue ?vn]
impliedBy l-expr(?v1,...,?vn) )forAll ?v1,...,?vn ( R[p1
hasValue ?v1,...,pn hasValue ?vn]
equivalent l-expr(?v1,...,?vn) )If the parameters are not specified the relation is represented by a predicate symbol where the identifier of the relation is used as the name of the predicate symbol. If R is the identifier denoting the relation and the parameters are not specified then the logical expression takes one of the following forms:
forAll ?v1,...,?vn ( R(?v1,...,?vn)
implies l-expr(?v1,...,?vn) )forAll ?v1,...,?vn ( R(?v1,...,?vn)
impliedBy l-expr(?v1,...,?vn) )forAll ?v1,...,?vn ( R(?v1,...,?vn)
equivalent l-expr(?v1,...,?vn) )l-expr(?v1,...,?vn) is a logical expression with
precisely ?v1,...,?vn as its free variables and
p1,...,pn are the names of the parameters of the
relation.
Using implies, one gives a necessary condition for
instances ?v1,...,?vn to be related; using
impliedBy, one gives a sufficient condition and using
equivalent, we have a sufficient and necessary condition
for instances ?v1,...,?vn being related.
A function is a special relation, with a unary range and a
n-ary domain (parameters inherited from relation),
where the range specifies the return value. In contrast to a function symbol,
a function is not only a syntactical entity but has some semantics that
allows to actually evaluate the function if one considers concrete input
values for the parameters of the function. That means, that we actually can
replace the (ground) function term in some expression by its concrete value.
Function can be used for instance to represent and exploit built-in
predicates of common datatypes. Their semantics can be captured externally by
means of an oracle or it can be formalized by assigning a logical expression
to the definedBy property inherited from
relation.
Class function sub-Class relation
hasRange type concept
|
concept constraining the possible return values of the
function.The logical representation of a function is almost the same as for
relations, whereby the result value of a function (resp. the value of a
function term) has to be represented explicitly: the function is represented
by an (n+1)-ary predicate symbol with named arguments (see Section 7) (where
n is the number of arguments of the function) where the identifier of the
function is used as the name of the predicate. In particular, the names of
the parameters of the corresponding relation symbol are the names of the
parameters of the function as well as one additional parameter
range for denoting the value of the function term with the given
parameter values. In Case the paramters are not specified the
function is represented by an predicate symbol with ordered arguments and by
convention the first argument specifies the value of the function term with
given argument values.
If F is the identifier denoting the function and p1,...,pn is the set of
parameters of the function then the logical expression for defining the
semantics of the function (inherited from relation) can for
example take the form
forAll ?v1,...,?vn,?res
( F[p1 hasValue ?v1,...,pn hasValue ?vn,
result hasValue ?res] equivalent
l-expr(?v1,...,?vn,?res) )
where l-expr(?v1,...,?vn,?res) is a logical expression with
precisely ?v1,...,?vn,?res as its free variables
and p1,...,pn are the names of the parameters of the function.
Clearly, result may not be used as the name for a parameter of a
function in order to prevent ambiguities.
Instances are either defined explicitly or by a link to an
instance store, i.e., an external storage of instances and their values.
An explicit definition of instances of concepts is as follows:
Class instance
hasNonFunctionalProperty type nonFunctionalProperty
hasType type concept
hasAttributeValues type attributeValue
|
non functional properties recommended are: Contributor, Coverage,
Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.concept to which the instance belongs to ([1]).attributeValues for the single attributes defined in
the concept. For each attribute defined for the concept
this instance is assigned to there can be a corresponding attribute
value. These value have to be compatible with the corresponding type
declaration in the concept definition.
Class attributeValue
hasAttribute type attribute
|
attribute this value refers to.Instances of relations (with arity n) can be seen as n-tuples of instances of the concepts which are specified as the parameters of the relation. Thus we use the following definition for instances of relations:
Class relationInstance
hasNonFunctionalProperty type nonFunctionalProperty
hasType type relation
hasParameterValues type parameterValue
|
non functional properties recommended are: Contributor, Coverage,
Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.relation this instance belongs to ([2]).parameterValues specifying the
single instances that are related according to this relation instance.
The list of parameter values of the instance has to be compatible wrt.
names and range constraints of that are specified in the corresponding
relation.
Class parameterValue
hasParameter type parameter
|
parameter this value refers to.A detailed discussion and a concrete proposal on how to integrate large sets of instance data in an ontology model can be found in DIP Deliverable D2.2 [Kiryakov et. al., 2004]. Basically, the approach there is to integrate large sets of instances which are already existing on some storage devices by means of sending queries to external storage devices or oracles.
An axiom is considered to be a logical expression together
with its non functional properties.
Class axiom
hasNonFunctionalProperty type nonFunctionalProperty
hasDefinition type logicalExpression
|
non functional properties recommended are: Contributor, Coverage,
Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.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:
Class mediator
hasNonFunctionalProperty type nonFunctionalProperty
hasImportedOntology type ontology
hasSource type {ontology, mediator}
hasTarget type {ontology, mediator}
hasMediationService type implementation
|
non functional properties recommended are: Accuracy, Contributor,
Coverage, Creator, Date, Description, Financial, Format, Identifier, Language, Network-related QoS, Owner,
Performance, Publisher, Relation, Reliability, Rights, Robustness, Scalability, Security,
Source, Subject, Title, Transactional, Trust, Type, Version.mediationService points to a service that actually
implements the mediation.Non functional properties are used in the definition of WSMO elements. Which non functional properties apply to which WSMO element is specified in the description of each WSMO element. We do not enforce restrictions on the range value type (and thus also omit the range restriction in the following listing) but in some cases we do provide additional recommendations in the textual description.
Non-functional properties are defined in the following way:
Class nonFunctionalProperty
hasAccuracy type accuracy
hasContributer type dc:contributor
hasCoverage type dc:coverage
hasCreator type dc:creator
hasDate type dc:date
hasDescription type dc:description
hasFinancial type financial
hasFormat type dc:format
hasIdentifier type dc:identifier
hasLanguage type dc:language
hasNetworkRelatedQoS type networkRelatedQoS
hasOwner type owner
hasPerformance type performance
hasPublisher type dc:publisher
hasRelation type dc:relation
hasReliability type reliability
hasRights type dc:rights
hasRobustness type robustness
hasScalability type scalability
hasSecurity type security
hasSource type dc:source
hasSubject type dc:subject
hastitle type dc:title
hasTransactional type transactional
hasTrust type trust
hasType type dc:type
hasVersion type version
|
dc:contributor include a person, an
organization, or a service. The Dublin Core specification recommends,
that typically, the name of a dc:contributor should be
used to indicate the entity.foaf:Agent as value type [Brickley &
Miller, 2004].dc: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).dc:creator include a person, an
organization, or a service. The Dublin Core specification recommends,
that typically, the name of a dc:creator should be used to
indicate the entity.foaf:Agent as value type [Brickley &
Miller, 2004].dc:date will be associated with the creation or
availability of the element.dc: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.dc: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.dc:identifier in order to allow Dublin Core meta data
aware applications the processing of that information.dc:publisher include a person, an organization, or a
service. The Dublin Core specification recommends, that typically, the
name of a dc:publisher should be used to indicate the
entity.foaf:Agent as value type [Brickley &
Miller, 2004].dc: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.dc: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.dc: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.dc:title will be
a name by which the element is formally known.dc:type includes terms describing general categories,
functions, genres, or aggregation levels for content.In the previous chapters, we have presented a meta model for a language-neutral ontology API. In this chapter we clarify the use of such an API. We clarify both the use of the meta model in order to achieve inter-operation between different ontology languages and the relation between the meta model and an API.
The meta model presented in this document can not straightforwardly be implemented as a concrete API for all possible ontology languages. In fact, it is not possible, even with this meta model, to use the same concrete API for different ontology language, because of the particularities of the different ontology languages.
Different ontology languages have different syntax and different semantics. This makes it impossible to entirely use the same concrete API for these different languages. However, the different ontology languages all share the concepts in the meta model presented in the previous chapter. Each ontology language can be used to specify concepts, relations, axioms and instances. This shared meta model provides a basis for inter-operation between different ontology languages.
Each ontology language will require a different concrete API. However, the only difference between the different concrete APIs should be the logical expression, which is specified in the axiom definition (cf. Section 2.8). Because the larger part of the API is shared between ontology languages, it should be easy for a tool to switch between different implementations, which use different ontology languages, but which do commit to the same meta model.
The use of a common meta-model enables tools to abstract away (to some extent) from the particularities of ontology languages.
This document presents a meta model for a language-neutral API for Ontology interchange that conforms to the Web Service Modeling Ontology WSMO [Roman et al., 2004], which is currently under development in the context of the SDK project cluster. Future changes and updates in [Roman et al., 2004] will be reflected in this document as well.
A concrete API, based on the meta model presented in this document, is currently under development in the context of the DIP (http://dip.semanticweb.org/) and SEKT (http://sekt.semanticweb.org/) projects.
[Baader et al., 2003] F. Baader, D. Calvanese, and D. McGuinness: The Description Logic Handbook, Cambridge University Press, 2003.
[Biron & Malhotra, 2001] P. V. Biron and A. Malhotra: XML Schema Part 2: Datatypes, W3C Recommendation 02, 2001, avaliable at: http://www.w3.org/TR/xmlschema-2/.
[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).
[Brickley & Miller, 2004] D. Brickley and L. Miller: FOAF Vocabulary Specification, available at: http://xmlns.com/foaf/0.1/.
[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.
[Gruber, 1993] T. Gruber: A translation approach to portable ontology specifications,Knowledge Acquisition, 5:199-220, 1993.
[IANA, 2002] Intenet Assigned Number Authority: MIME Media Types, available at: http://www.iana.org/assignments/media-types/, February 2002.
[ISO8601, 2004] International Organization for Standardization (ISO): ISO 8601:2000. Representation of dates and times. Second edition, 2004-06-08. Reference number. Geneva: International Organization for Standardization, 2004. Available from http://www.iso.ch.
[Kiryakov et. al., 2004] A. Kiryakov, D. Ognyanov, and V. Kirov: A framework for representing ontologies consisting of several thousand concepts definitions, Project Deliverable D2.2 of DIP, June 2004.
[O`Sullivan et al., 2002] J. O`Sullivan, D. Edmond, and A. Ter Hofstede: What is a Service?: Towards Accurate Description of Non-Functional Properties, Distributed and ParallelDatabases, 12:117-133, 2002.
[Rajesh & Arulazi, 2003] S. Rajesh and D. Arulazi: Quality of Service for Web Services-Demystification, Limitations, and Best Practices, March 2003. (See http://www.developer.com/services/article.php/2027911.)
[Roman et al., 2004] D. Roman, U. Keller, H. Lausen (eds.): Web Service Modeling Ontology - Standard (WSMO - Standard), version 1.1 available at http://www.wsmo.org/2004/d2/v1.1/.
[Rumbaugh et al., 1998] J. Rumbaugh, I. Jacobson, and G. Booch: The Unified Modeling Language Reference Manual, Object Technology Series, Addison-Wesley, 1998.
[OMG, 2004] The Object Management Group: Meta-Object Facility, 2004. Available at http://www.omg.org/technology/documents/formal/mof.htm.
[ISO639, 1988] International Organization for Standardization (ISO): ISO 639:1988 (E/F). Code for the Representation of Names of Languages. First edition, 1988-04-01. Reference number: ISO 639:1988 (E/F). Geneva: International Organization for Standardization, 1988. iii + 17 pages.
[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, InfraWebs, SEKT, SWWS, ASG and Esperonto; by Science Foundation Ireland under the DERI-Lion project; by the Vienna city government under the CoOperate programme and by the FIT-IT (Forschung, Innovation, Technologie - Informationstechnologie) under the projects RW˛ and TSC.
The editors would like to thank to all the members of the WSML and OMWG working group for their advice and input into this document.
[1] An instance can be an instance of several concepts by repeating the statement.
[2] A relation instance can be an instance of several relations by repeating the statement.
$Date: 2004/11/17 09:47:25 $