This document defines the ebXML Registry profile for publishing, management, discovery and reuse of OWL Lite Ontologies.

This document was last revised or approved by the ebXML Registry TC on the above date. The level of approval is also listed above. Check the current location noted above for possible later revisions of this document. This document is updated periodically on no particular schedule.

Technical Committee members should send comments on this specification to the Technical Committee's email list. Others should send comments to the Technical Committee by using the "Send A Comment" button on the Technical Committee's web page at

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director. OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

1 Table of Contents

1 Table of Contents 3

1Introduction 10

1.1 Terminology 11

1.2 Conventions 11

1.3 Recommended Enhancements 11

2 OWL Overview 12

2.1 Semantic Web Languages upon which OWL is Layered 12

2.2 OWL Lite Constructs 13

2.2.1 RDF Schema Features 13

2.2.2 (In)Equality 13

2.2.3 Property Characteristics 13

2.2.4 Property Restrictions 13

2.2.5 Restricted Cardinality 13

2.2.6 Class Intersection 13

2.2.7 Versioning 14

2.2.8 Annotation Properties 14

2.2.9 Datatypes 14

2.3 OWL DL Constructs 14

2.3.1 Class Axioms 14

2.3.2 Boolean Combinations of Class Expressions 14

2.3.3 Arbitrary Cardinality 14

2.3.4 Filler Information 14

3 ebXML Registry Overview 15

3.1 Overview of [ebRIM] 15

3.1.1 RegistryObject 16

3.1.2 Object Identification 16

3.1.3 Object Naming and Description 17

3.1.4 Object Attributes 17

3.1.4.1 Slot Attributes 17

3.1.5 Object Classification 18

3.1.6 Object Association 18

3.1.7 Object References To Web Content 19

3.1.8 Object Packaging 19

3.1.9 ExtrinsicObject 20

3.1.10 Service Description 20

3.2 Overview of [ebRS] 20

4 Representing OWL Lite Constructs in ebRIM 21

4.1 Representing RDF Schema Features in ebRIM 21

4.1.1 owl:Class → rim:ClassificationNode 21

4.1.2 rdf:Property → rim:Association Type HasProperty 21

4.1.3 rdfs:subPropertyOf → rim:Association Type SubPropertyOf 22

4.1.4 rdfs:subClassOf → rim:Association Type SubClassOf 22

4.1.5 owl:Individual → rim:ExtrinsicObject 23

4.2 Representing OWL (In)Equality Constructs in ebXML RIM 24

4.2.1 owl:equivalentClass, owl:equivalentPropery → rim:Association Type EquivalentTo 24

4.2.2 owl:sameAs → rim:Association Type SameAs 24

4.2.3 owl:differentFrom → rim:Association Type DifferentFrom 24

4.2.4 owl:AllDifferent 25

4.3 Representing OWL Property Characteristics in ebRIM 26

4.3.1 owl:ObjectProperty → rim:Association Type objectProperty 26

4.3.2 owl:DatatypeProperty → rim:Association Type DatatypeProperty 26

4.3.3 owl:TransitiveProperty → rim:Association Type TransitiveProperty 26

4.3.4 owl:inverseOf → rim:Association Type InverseOf 27

4.3.5 owl:SymmetricProperty→ rim:Association Type SymmetricProperty 28

4.3.6 owl:FunctionalProperty→ rim:Association Type FunctionalProperty 28

4.3.7 owl:InverseFunctionalProperty→ rim:Association Type InverseFunctionalProperty 29

4.4 OWL Property Restrictions in ebXML RIM 29

4.5 Representing OWL Restricted Cardinality in ebXML RIM 30

4.5.1 owl:minCardinality (only 0 or 1) 30

4.5.2 owl:maxCardinality (only 0 or 1) 31

4.5.3 owl:cardinality (only 0 or 1) 32

4.6 Representing OWL Class Intersection in ebXML RIM 32

4.7 Representing OWL Versioning in ebXML RIM 33

4.7.1 owl:versionInfo, owl:priorVersion 33

4.8 Representing OWL Annotation Properties in ebXML RIM 34

4.8.1 rdfs:label 34

4.8.2 rdfs:comment 34

4.8.3 rdfs:seeAlso 34

4.9 OWL Datatypes in ebXML RIM 35

5 Cataloging Service Profile 36

5.1 Invocation Control File 36

5.2 Input Metadata 36

5.3 Input Content 36

5.4 Output Metadata 37

5.4.1 owl:Class → rim:ClassificationNode 37

5.4.2 rdf:Property → rim:Association Type HasProperty 37

5.4.3 rdfs:subPropertyOf → rim:Association Type SubPropertyOf 37

5.4.4 rdfs:subClassOf → rim:Association Type subClassOf 37

5.4.5 owl:Individual → rim:ExtrinsicObject 37

5.4.6 owl:equivalentClass, owl:equivalentPropery → rim:Association Type EquivalentTo 37

5.4.7 owl:sameAs → rim:Association Type SameAs 37

5.4.8 owl:differentFrom → rim:Association Type DifferentFrom 37

5.4.9 owl:AllDifferent → rim:RegistryPackage 37

5.4.10 owl:ObjectProperty → rim:Association Type ObjectProperty 38

5.4.11 owl:DatatypeProperty → rim:Association Type DatatypeProperty 38

5.4.12 owl:TransitiveProperty → rim:Association Type TransitiveProperty 38

5.4.13 owl:inverseOf → rim:Association Type InverseOf 38

5.4.14 owl:SymmetricProperty→ rim:Association Type SymetricProperty 38

5.4.15 owl:FunctionalProperty→ rim:Association Type FunctionalProperty 38

5.4.16 owl:InverseFunctionalProperty→ rim:Association Type InverseFunctionalProperty 38

5.4.17 owl:minCardinality (only 0 or 1) 38

5.4.18 owl:maxCardinality (only 0 or 1) 39

5.4.19 owl:cardinality 39

5.4.20 owl:intersectionOf 39

5.4.21 rdfs:label 39

5.4.22 rdfs:comment 39

5.4.23 rdfs:seeAlso 39

6 Discovery Profile 40

6.1 All SuperProperties Discovery Query 40

6.1.1 Parameter $propertyName 40

6.1.2 Example of All SuperProperties Discovery Query 40

6.2 Immediate SuperClass Discovery Query 41

6.2.1 Parameter $className 41

6.2.2 Example of Immediate SuperClass Discovery Query 41

6.3 Immediate SubClass Discovery Query 42

6.3.1 Parameter $className 42

6.3.2 Example of Immediate SubClasss Discovery Query 42

6.4 All SuperClasses Discovery Query 42

6.4.1 Parameter $className 43

6.4.2 Example of All SuperClasses Discovery Query 43

6.5 All SubClasses Discovery Query 43

6.5.1 Parameter $className 43

6.5.2 Example of All SubClassses Discovery Query 43

6.6 EquivalentClasses Discovery Query 44

6.6.1 Parameter $className 44

6.6.2 Example of EquivalentClasses Discovery Query 44

6.7 EquivalentProperties Discovery Query 45

6.7.1 Parameter $propertyName 45

6.7.2 Example of EquivalentProperties Discovery Query 45

6.8 SameExtrinsicObjects Discovery Query 46

6.8.1 Parameter $extrinsicObjectName 46

6.8.2 Example of SameExtrinsicObjects Discovery Query 46

6.9 DifferentExtrinsicObjects Discovery Query 46

6.9.1 Parameter $extrinsicObjectName 47

6.9.2 Example of DifferentExtrinsicObjects Discovery Query 47

6.10 AllDifferentRegistryObject Discovery Query 47

6.10.1 Parameter $registryObjectName 47

6.10.2 Example of AllDifferentRegistryObjects Discovery Query 47

6.11 ObjectProperties Discovery Query 48

6.11.1 Parameter $className 48

6.11.2 Example of ObjectProperties Discovery Query 48

6.12 ImmediateInheritedObjectProperties Discovery Query 49

6.12.1 Parameter $className 49

6.12.2 Example of ImmediateInheritedObjectProperties Discovery Query 49

6.13 AllInheritedObjectProperties Discovery Query 50

6.13.1 Parameter $className 50

6.13.2 Example of AllInheritedObjectProperties Discovery Query 50

6.14 DatatypeProperties Discovery Query 51

6.14.1 Parameter $className 51

6.14.2 Example of DatatypeProperties Discovery Query 51

6.15 AllInheritedDatatypeProperties Discovery Query 51

6.15.1 Parameter $className 52

6.15.2 Example of AllInheritedDatatypeProperties Discovery Query 52

6.16 TransitiveRelationships Discovery Query 52

6.16.1 Parameter $className 53

6.16.2 Parameter $propertyName 53

6.16.3 Example of TransitiveRelationships Discovery Query 53

6.17 TargetObjects Discovery Query 53

6.17.1 Parameter $className 54

6.17.2 Parameter $propertyName 54

6.17.3 Example of TargetObjects Discovery Query 54

6.18 TargetObjectsInverseOf Discovery Query 54

6.18.1 Parameter $className 55

6.18.2 Parameter $propertyName 55

6.18.3 Example of TargetObjectsInverseOf Discovery Query 55

6.19 InverseRanges Discovery Query 55

6.19.1 Parameter $className 56

6.19.2 Parameter $propertyName 56

6.19.3 Example of InverseRanges Discovery Query 56

6.20 SymmetricProperties Discovery Query 57

6.20.1 Parameter $className 57

6.20.2 Example of SymmetricProperties Discovery Query 57

6.21 FunctionalProperties Discovery Query 57

6.21.1 Parameter $className 58

6.21.2 Example of FunctionalProperties Discovery Query 58

6.22 InverseFunctionalProperties Discovery Query 58

6.22.1 Parameter $className 58

6.22.2 Example of InverseFunctionalProperties Discovery Query 58

6.23 Instances Discovery Query 59

6.23.1 Parameter $className 59

6.23.2 Example of Instances Discovery Query 59

7 Canonical Metadata Definitions 61

7.1 ObjectType Extensions 61

7.2 AssociationType Extensions 61

7.3 Canonical Queries 64

7.3.1 All SuperProperties Discovery Query 64

7.3.2 Immediate SuperClass Discovery Query 64

7.3.3 Immediate SubClass Discovery Query 64

7.3.4 All SuperClasses Discovery Query 65

7.3.5 All SubClasses Discovery Query 65

7.3.6 EquivalentClasses Discovery Query 65

7.3.7 EquivalentProperties Discovery Query 66

7.3.8 SameExtrinsicObjects Discovery Query 66

7.3.9 DifferentExtrinsicObjects Discovery Query 67

7.3.10 AllDifferentRegistryObject Discovery Query 67

7.3.11 ObjectProperties Discovery Query 68

7.3.12 ImmediateInheritedObjectProperties Discovery Query 68

7.3.13 AllInheritedObjectProperties Discovery Query 69

7.3.14 DatatypeProperties Discovery Query 69

7.3.15 AllInheritedDatatypeProperties Discovery Query 69

7.3.16 TransitiveRelationships Discovery Query 69

7.3.17 TargetObjects Discovery Query 70

7.3.18 TargetObjectsInverseOf Discovery Query 70

7.3.19 InverseRanges Discovery Query 71

7.3.20 SymmetricProperties Discovery Query 72

7.3.21 FunctionalProperties Discovery Query 72

7.3.22 InverseFunctionalProperties Discovery Query 72

7.3.23 Instances Discovery Query Discovery Query 73

8 OWL Profile References 75

8.1 Normative References 75

8.2 Informative References 76

Appendix A 76

1Introduction

The ebXML Registry holds the metadata for the RegistryObjects and the documents pointed at by the RegistryObjects reside in an ebXML repository. The basic semantic mechanisms of ebXML Registry are classification hierarchies (ClassificationScheme) consisting of ClassificationNodes and the Association Types among RegistryObjects. Furthermore, RegistryObjects can be assigned properties through a slot mechanism and RegistryObjects can be classified using instances of Classification, ClassificationScheme and ClassificationNodes. Given these constructs, considerable amount of semantics can be defined in the registry.

However, currently semantics is becoming a much broader issue than it used to be since several application domains are making use of ontologies to add knowledge to their data and applications [StaabStuder]. One of the driving forces for ontologies is the Semantic Web initiative [LeeHendler]. As a part of this initiative, W3C's Web Ontology Working Group defined Web Ontology Language [OWL].

Naturally, there is lot to be gained from using a standard ontology definition language, like OWL, to express semantics in ebXML registries.

This document normatively defines the ebXML Registry profile for Web Ontology Language (OWL) Lite. More specifically, this document normatively specifies how OWL Lite constructs SHOULD be represented by ebXML RIM constructs without causing any changes in the core ebXML Registry specifications [ebRIM], [ebRS]. Furthermore, this document normatively specifies the code to process some of the OWL semantics through parameterized stored procedures that SHOULD be made available from the ebXML Registry.

These predefined stored queries provide the necessary means to exploit the enhanced semantics stored in the Registry. Hence, an application program does not have to develop additional code to process this semantics. In this way, it becomes possible to retrieve not only explicit but also the implied knowledge through queries, the enhancements to the registry are generic and also the registry specification is kept intact. The capabilities provided, move the semantics support beyond what is currently available in ebXML registries and it does so by using a standard ontology language.

Finally it is worth noting that ontologies can play two major roles: One is to provide a source of shared and precisely defined terms which can be used in formalizing knowledge and relationship among objects in a domain of interest. The other is to reason about the ontologies. When an ontology language like OWL is mapped to a class hierarchy like the one in ebXML, the first role can directly be achieved. Furthermore some implicit information can be obtained by predefined parameterized queries. However, when we want full reasoning power, we need reasoners. Yet, OWL reasoners can not directly run on the ebXML registry because all the registry information is not stored in OWL syntax.

Although this Profile is reIated to ebXML Registry specifications and not to any particular implementation, in order to be able to give concrete examples, the freebXML Registry implementation is used.

1.1 Terminology

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in IETF RFC 2119 [RFC211].

The term “repository item” is used to refer to content (e.g., an XML document or a DTD) that resides in a repository for storage and safekeeping. Each repository item is described by a RegistryObject instance. The RegistryObject catalogs the RepositoryItem with metadata.

1.2 Conventions

Throughout the document the following conventions are employed to define the data structures used. The following text formatting conventions are used to aide readability:

UML diagrams are used as a way to concisely describe information models in a standard way. They are not intended to convey any specific Implementation or methodology requirements.

Listings may contain values that reference ebXML Registry objects by their id attribute. These id values uniquely identify the objects within the ebXML Registry. For convenience and better readability, these key values are replaced by meaningful textual variables to represent such id values.
For example, the following placeholder refers to the unique id defined for the canonical ClassificationNode that defines the Organization ObjectType defined in [ebRIM]:

1.3 Recommended Enhancements

In the current ebXML Registry implementation, when a stored query is submitted to the ebXML Registry, it is stored in the “AdhocQuery” relational table without validation:

AdhocQuery (id, lid, objectType, status, versionName, comment_, queryLanguage, query);

When a user tries to invoke this stored query through a AdhocQuery, ebRS parses the stored query and converts this stored query to the syntax acceptable by the underlying database. Furthermore currently ebRS supports the SQL 92 [SQL 92] standard which does not include the “recursion” mechanisms. Also, there seems to be problems in parsing queries involving UNION. Since some of the queries involved in this Profile requires recursion and UNION mechanisms of SQL, it may help if ebRS is extended to support SQL 99 standard [SQL 99].

2 OWL Overview

This chapter provides an overview of the Web Ontology Language [OWL]. Web Ontology Language [OWL] is a semantic markup language for publishing and sharing ontologies on the World Wide Web. OWL is derived from the DAML+OIL Web Ontology Language [DAML+OIL] and builds upon the Resource Description Framework [RDF].

Within the scope of this document, only OWL Lite constructs are considered and in the rest of the document, “OWL” is used to mean “OWL Lite” unless otherwise stated.

2.1 Semantic Web Languages upon which OWL is Layered

OWL is one of a set of languages defined for the Semantic Web. It occupies the Ontology layer of an architecture sometimes referred to as the Semantic Web Layer Cake. This moniker alludes to the fact that each language in the architecture sits on top of another while exposing some of the layer below is often seen of a wedding cake. OWL is situated in this architecture directly above the RDF Vocabulary Description Language: RDF Schema (RDFS) [RDFS]. RDFS is a language for defining vocabularies or models with which to describe or categorize resources in the semantic web. RDFS, in turn, sits atop the Resource Description Framework (RDF) [RDF]. RDF provides a basic data model, XML based transfer syntax, and other basic tools. The whole Semantic Web stack itself then sits atop XML technologies which are used for identification and syntax definition.

Commonly used Prefix	Namespace URI Reference
rdf	http://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfs	http://www.w3.org/2000/01/rdf-schema#
owl	http://www.w3.org/2002/07/owl#

The following section discusses elements of OWL along with a few elements of RDF and RDFS which are most important to users of OWL. In this section Terms from RDF and RDFS vocabularies are distinguished from OWL terms by the inclusion of the appropriate prefix as given in the Table 1.

2.2 OWL Lite Constructs

2.2.1 RDF Schema Features

2.2.2 (In)Equality

2.2.3 Property Characteristics

2.2.4 Property Restrictions

2.2.5 Restricted Cardinality

2.2.6 Class Intersection

2.2.7 Versioning

2.2.8 Annotation Properties

2.2.9 Datatypes

2.3

OWL
DL Constructs

2.3.1

Class
Axioms

2.3.2

Boolean
Combinations of Class Expressions

2.3.3 Arbitrary Cardinality

2.3.4

Filler
Information

3 ebXML Registry Overview

This chapter provides an overview of ebXML Registry Information Model [ebRIM] and an overview of the specific domain and/or application.

The information presented is informative and is not intended to replace the normative information defined by ebXML Registry.

3.1 Overview of [ebRIM]

This section is provided in the « Deployment Profile Template for ebXML V3 specs » and can be removed in a specific profile.

Normally only specifics topics needs to be developed here (but the profile editor can prefer to leave it)

This section summarizes the ebXML Registry Information Model [ebRIM]. This model is the target of the mapping defined in this document. The reader SHOULD read [CMRR] for a more detailed overview of ebXML Registry as a whole.

The ebXML registry defines a Registry Information Model [ebRIM] that specifies the standard metadata that may be submitted to the registry. Figure 1 presents the UML class diagram representing the Registry Information Model. Figure 2, shows the inheritance relationships in among the classes of the ebXML Registry Information Model.

3.1.1 RegistryObject

This is an abstract base class used by most classes in the model. It provides minimal

metadata for registry objects. The following sections use the Organization sub-class of RegistryObject as an example to illustrate features of the model.

3.1.2 Object Identification

The id attribute value MAY potentially be human friendly but MUST be a unique ID value within the registry.

Since a RegistryObject MAY have several versions, a logical id (called lid) is also defined which is unique for different logical objects. However the lid attribute value MUST be the same for all versions of the same logical object. The lid attribute value is a URN that, as well for id attribute, MAY potentially be human friendly:

A RegistryObject MAY also have any number of ExternalIdentifiers which may be any string value within an identified ClassificationScheme.

3.1.3 Object Naming and Description

A RegistryObject MAY have a name and a description which consists of one or more strings in one or more local languages. Name and description need not be unique across RegistryObjects.

3.1.4 Object Attributes

For each class in the model, [ebRIM] defines specific attributes. Examples of several of these attributes such as id, lid, name and description have already been introduced.

3.1.4.1 Slot Attributes

In addition the model provides a way to add custom attributes to any RegistryObject instance using instances of the Slot class. The Slot instance has a Slot name which holds the attribute name and MUST be unique within the set of Slot names in that RegistryObject. The Slot instance also has a ValueList that is a collection of one or more string values.

The following example shows how a custom attribute named “urn:acme:slot:NASDAQSymbol” and value “ACME” MAY be added to a RegistryObject using a Slot instance.