A Language Neutral Model for Ontology Interchange

Introduction

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:

• every Attribute has its "multiplicity" set to multi-valued by default; when an Attribute requires its "multiplicity" to be set to "single-valued", this will be explicitly stated in the listings.
• for some WSMO elements there is the need to define attributes taking values from the union of several types, a feature that is not directly supported by MOF metamodelling constructs; this can be simulated in MOF by defining a new Class as super-Class of all the types required in the definition of the attribute (that represents the union of the single types), with the Constraint that each instance of this new Class is an instance of at least one of the types which are used in the union; to define this new Class in WSMO, we use curly parenthesis, enumerating the Classes representing the required types of the definition of the attribute in between.

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.

Ontologies

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

Non functional properties

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.

Imported Ontologies

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.

Used mediators

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

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 muliplicity = single-valued

Non functional properties

The non functional properties recommended are: Contributor, Coverage, Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.

Super-concepts

There can be a finite number of concepts that serve as a superConcepts for some concept. Being a sub-concept of some other concept in particular means that a concept inherits the signature of this superconcept and the corresponding constraints. Furthermore, all instances of a concept are also instances of each of its superconcepts.

Attributes

Each concept provides a (possibly empty) set of 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.

Listing 3. Attribute definition

Class attribute hasNonFunctionalProperty type nonFunctionalProperty hasRange type concept muliplicity = single-valued

Non functional properties

The non functional properties recommended are: Contributor, Coverage, Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.

Range

A concept that serves as an integrity constraint on the values of the attribute.

Defined by

A logical expression which can be used to define the semantics of the concept formally. More precisely, the logical expression defines (or restricts, resp.) the extension (i.e. the set of instances) of the concept. If C is the identifier denoting the concept then the logical expression takes one of the following forms

• 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

Relations are used in order to model interdependencies between several concepts (respectively instances of these concepts).

Listing 4. Relation definition

Class relation hasNonFunctionalProperty type nonFunctionalProperty hasSuperRelations type relation hasParameters type parameter hasDefinition type logicalExpression muliplicity = single-valued

Non functional properties

The non functional properties recommended are: Contributor, Coverage, Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.

Superrelations

A finite set of 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.

Parameters

The list of parameters.

Listing 5. Parameter definition

Class parameter hasNonFunctionalProperty type nonFunctionalProperty hasDomain type concept muliplicity = single-valued

Non functional properties

The non functional properties recommended are: Contributor, Coverage, Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.

Domain

A concept constraining the possible values that the parameter can take.

Defined by

A 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.

Functions

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.

Listing 6. Function definition

Class function sub-Class relation hasRange type concept muliplicity = single-valued

Range

A 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, resultmay not be used as the name for a parameter of a function in order to prevent ambiguities.

Instances

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:

Listing 7. Instance definition

Class instance hasNonFunctionalProperty type nonFunctionalProperty hasType type concept hasAttributeValues type attributeValue

Non functional properties

The non functional properties recommended are: Contributor, Coverage, Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.

Type

The concept to which the instance belongs to ([1]).

Attribute values

The 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.

Listing 8. Attribute value definition

Class attributeValue hasAttribute type attribute muliplicity = single-valued hasValue type {URIRefernce, Literal, AnonymousId}

Attribute

The attribute this value refers to.

Value

An URI reference, literal or anonymous id representing the actual value of an instance for a specific attribute.

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:

Listing 9. Relation instance definition

Class relationInstance hasNonFunctionalProperty type nonFunctionalProperty hasType type relation hasParameterValues type parameterValue

Non functional properties

The non functional properties recommended are: Contributor, Coverage, Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.

Type

The relation this instance belongs to ([2]).

Parameter values

A set of 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.

Listing 10. Parameter value definition

Class parameterValue hasParameter type parameter muliplicity = single-valued hasValue type {URIRefernce, Literal, AnonymousId}

Parameter

The parameter this value refers to.

Value

An URI reference, literal or anonymous id representing the actual value of an instance for a specific attribute.

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.

Axioms

An axiom is considered to be a logical expression together with its non functional properties.

Listing 11. Axiom definition

Class axiom hasNonFunctionalProperty type nonFunctionalProperty hasDefinition type logicalExpression

Non functional properties

The non functional properties recommended are: Contributor, Coverage, Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.

Defined by

The actual statement captured by the axiom is defined by an formula in a logical language.

Mediators

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 12. Mediators definition

Class mediator hasNonFunctionalProperty type nonFunctionalProperty hasImportedOntology type ontology hasSource type {ontology, mediator} hasTarget type {ontology, mediator} hasMediationService type implementation

Non functional properties

The 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.

Imported Ontologies

It is used to import ontologies as long as no conflicts are needed to be resolved.

Source

The source components define entities that are the sources of the mediator.

Target

The target component defines the entity that is the targets of the mediator.

Mediation Service

The mediationService points to a service that actually implements the mediation.

Non functional properties

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:

Listing 13. Non functional properties definition

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

Accuracy

It represents the error rate generated by the service. It can be measured by the numbers of errors generated in a certain time interval.

Contributor

An entity responsible for making contributions to the content of the element. Examples of 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. WSMO Recommendation: In order to point unambiguously to a specific resource we recommend the use an instance of foaf:Agent as value type [Brickley & Miller, 2004].

Coverage

The extent or scope of the content of the element. Typically, 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). WSMO Recommendation: For more complex applications, consideration should be given to using an encoding scheme that supports appropriate specification of information, such as DCMI Period, DCMI Box or DCMI Point.

Creator

An entity primarily responsible for creating the content of the element. Examples of 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. WSMO Recommendation: In order to point unambiguously to a specific resource we recommend the use an instance of foaf:Agent as value type [Brickley & Miller, 2004].

Date

A date of an event in the life cycle of the element. Typically, dc:date will be associated with the creation or availability of the element. WSMO Recommendation: We recommend to use the an encoding defined in the ISO Standard 8601:2000 [ISO8601, 2004] for date and time notation. A short introduction on the standard can be found here. This standard is also used by the the XML Schema Definition (YYYY-MM-DD) [Biron & Malhotra, 2001] and thus one is automatically compliant with XML Schema too.

Description

An account of the content of the element. Examples of 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.

Financial

It represents the cost-related and charging-related properties of a service [O`Sullivan et al., 2002]. This property is a complex property, which includes charging styles (e.g. per request or delivery, per unit of measure or granularity etc.), aspects of settlement like the settlement model (transactional vs. rental) and a settlement contract, payment obligations and payment instruments.

Format

A physical or digital manifestation of the element. Typically, 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. WSMO Recommendation: We recommend to use types defined in the list of Internet Media Types [IANA, 2002] by the IANA (Internet Assigned Numbers Authority)

Identifier

An unambiguous reference to the element within a given context. Recommended best practice is to identify the element by means of a string or number conforming to a formal identification system. In Dublin Core formal identification systems include but are not limited to the Uniform element Identifier (URI) (including the Uniform element Locator (URL)), the Digital Object Identifier (DOI) and the International Standard Book Number (ISBN). WSMO Recommendation: We recommend to use URIs as Identifier, depending on the particular syntax the identity information of an element might already be given, however it might be repeated in dc:identifier in order to allow Dublin Core meta data aware applications the processing of that information.

Language

A language of the intellectual content of the element. WSMO Recommendation: We recommend to use the language tags defined in the ISO Standard 639 [ISO639, 1988], e.g. "en-GB", in addition the logical language used to express the content should be mentioned, for example this can be OWL.

Network-related QoS

They represent the QoS mechanisms operating in the transport network which are independent of the service. They can be measured by network delay, delay variation and/or message loss.

Owner

A person or organization to which a particular WSMO element belongs.

Performance

It represents how fast a service request can be completed. According to [Rajesh & Arulazi, 2003] performance can be measured in terms of throughput, latency, execution time, and transaction time. The response time of a service can also be a measure of the performance. High quality services should provide higher throughput, lower latency, lower execution time, faster transaction time and faster response time.

Publisher

An entity responsible for making the element available. Examples of 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. WSMO Recommendation: In order to point unambiguously to a specific resource we recommend the use an instance of foaf:Agent as value type [Brickley & Miller, 2004].

Relation

A reference to a related element. Recommended best practice is to identify the referenced element by means of a string or number conforming to a formal identification system. WSMO Recommendation: We recommend to use URIs as Identifier where possible. In particular, this property can be used to define namespaces that can be used in all child elements of the element to which this non functional property is assigned to.

Reliability

It represents the ability of a service to perform its functions (to maintain its service quality). It can be measured by the number of failures of the service in a certain time internal.

Rights

Information about rights held in and over the element. Typically, 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.

Robustness

It represents the ability of the service to function correctly in the presence of incomplete or invalid inputs. It can be measured by the number of incomplete or invalid inputs for which the service still function correctly.

Scalability

It represents the ability of the service to process more requests in a certain time interval. It can be measured by the number of solved requests in a certain time interval.

Security

It represents the ability of a service to provide authentication (entities - users or other services - who can access service and data should be authenticated), authorization (entities should be authorized so that they only can access the protected services), confidentiality (data should be treated properly so that only authorized entities can access or modify the data), traceability/auditability (it should be possible to trace the history of a service when a request was serviced), data encryption (data should be encrypted), and non-repudiation (an entity cannot deny requesting a service or data after the fact).

Source

A reference to an element from which the present element is derived. The present element may be derived from the 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. WSMO Recommendation: We recommend to use URIs as Identifier where possible.

Subject

A topic of the content of the element. Typically, 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.

Title

A name given to an element. Typically, dc:title will be a name by which the element is formally known.

Trust

It represents the trust worthiness of the service or an ontology.

Type

The nature or genre of the content of the element. The dc:type includes terms describing general categories, functions, genres, or aggregation levels for content. WSMO Recommendation: We recommend to use an URI encoding to point to the namespace or document describing the type, e.g. for a domain ontology expressed in WSMO, one would use: http://www.wsmo.org/2004/d2/#ontologies.

Version

As many properties of an element might change in time, an identifier of the element at a certain moment in time is needed. WSMO Recommendation: If applicable we recommend to use the revision numbers of a version control system. Such a system can be for example CVS (Concurrent Version System), that automatically keeps track of the different revisions of a document, an example CVS version Tag looks like: "$Revision: 1.4 $".

Use of the Language Neutral Ontology API

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.

Conclusions and further directions

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.

References

[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.