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.

3.1.5 Object Classification

Any RegistryObject may be classified using any number of Classification instance. A Classification instance references an instance of a ClassificationNode as defined by [ebRIM]. The ClassificationNode represents a value within the ClassificationScheme. The ClassificationScheme represents the classification taxonomy.

<rim:LocalizedString value="ACME makes Java. Provider of free Java software." xml:lang="en-US"/>

3.1.6 Object Association

Any RegistryObject MAY be associated with any other RegistryObject using an Association instance where one object is the sourceObject and the other is the targetObject of the Association instance. An Association instance MAY have an associationType which defines the nature of the association.

There are a number of predefined Association Types that a registry must support to be [ebRIM] compliant. These canonical association types are defined as a ClassificationScheme called AssociationType. The SubmitObjectsRequest document of the AssociationType Classification scheme is available at:

The following example shows an Association between the ACME Organization instance and a Service instance with the associationType of “OffersService”. This indicates that ACME Organization offers the specified service (Service instance is not shown).

3.1.7 Object References To Web Content

Any RegistryObject MAY reference web content that are maintained outside the registry using association to an ExternalLink instance that contains the URL to the external web content. The following example shows the ACME Organization with an Association to an ExternalLink instance which contains the URL to ACME’s web site. The associationType of the Association MUST be of type “ExternallyLinks” as defined by [ebRIM].

3.1.8 Object Packaging

RegistryObjects may be packaged or organized in a hierarchical structure using a familiar file and folder metaphor. RegistryPackage instances serve as folders while RegistryObject instances serve as files in this metaphor. A RegistryPackage instances groups logically related RegistryObject instances together as members of that RegistryPackage.

The following example creates a RegistryPackage for Services offered by ACME Organization organized in RegistryPackages according to the nature of the Service. Each Service is referenced using the ObjectRef type defined by [ebRIM].

3.1.9 ExtrinsicObject

ExtrinsicObjects provide metadata that describes submitted content whose type is not intrinsically known to the registry and therefore MUST be described by means of additional attributes (e.g., mime type). Examples of content described by ExtrinsicObject include Collaboration Protocol Profiles, Business Process descriptions, and schemas.

3.1.10 Service Description

Service description MAY be defined within the registry using the Service, ServiceBinding and SpecificationLink classes defined by [ebRIM]. This MAY be used to publish service descriptions such as WSDL and ebXML CPP/A.

3.2 Overview of [ebRS]

The [ebRS] specification defines the interfaces supported by an ebXML Registry and their bindings to protocols such as SOAP and HTTP.

4 Representing OWL Lite Constructs in ebRIM

It is important to note that although the mapping described in this section is complex, this complexity is hidden from the ebXML registry user because the needed stored queries MUST already be available in the Registry as described in Chapter 6. As this profile aims to enhance ebXML registry semantics without causing any changes in the core ebXML Registry architecture specification [ebRIM], [ebRS], the stored queries proposed in this specification SHOULD be submitted to the ebXML Registry by using the Stored Query API of [ebRS].

The following ebRIM standard relational schema is used in coding the stored queries throughout this document.

ClassificationNode(accessControlPolicy, id, lid, home, objectType, code, parent, path,versionName, comment_...)

Association(accessControlPolicy, id, lid, home, objectType, associationType, sourceObject, targetObject, isConfirmedBySourceOwner,versionName, comment_ isConfirmedByTargetOwner,...)

Classification (id, objectType, lid, home, classificationNode, versionName, comment_, classificationScheme, classifiedObject, nodeRepresentation,...);

Detailed explanation on how to represent some of the OWL Lite constructs in ebRIM is available from [Dogac, et. al. 2005]. Furthermore, [Dogac et. al. 2006] provides an implementation using the work presented in this document for healthcare applications.

4.1 Representing RDF Schema Features in ebRIM

4.1.1 owl:Class → rim:ClassificationNode

An owl:Class MUST be mapped to a rim:ClassificationNode as shown in the following examples:

4.1.2 rdf:Property → rim:Association Type HasProperty

A new ebRIM Association Type called “HasProperty” MUST be defined. The domain of an rdf:Property, rdfs:domain, is the sourceObject in this Association Type and the range of an rdf:Property which is rdfs:range, is the targetObject of the Association Type. Consider the following example which defines an rdf:Property instance called “hasAirport" whose domain is “City" and whose range is “Airport" classes:

<rim:Association id=${hasAirport} associationType='urn:oasis:names:tc:ebxml- regrep:profile:webontology:AssociationType:OWL:HasProperty'

OWL specializes RDF Property to owl:ObjectProperty and owl:DatatypeProperty which are discussed in the sections 4.3.1 and 4.3.2.

4.1.3 rdfs:subPropertyOf → rim:Association Type SubPropertyOf

In OWL, properties can be organized into property hierarchies by declaring a property to be a subPropertyOf another property. As shown in the following example, “creditCardPayment“ property may be a “subPropertyOf” the property “paymentMethods”:

A new ebXML RIM Association Type called “SubPropertyOf” MUST be defined to represent rdfs:subPropertyOf in ebRIM.

To express this semantics through ebXML RIM constructs, " creditCardPayment" Association is associated with the "paymentMethods” the newly created "SubPropertyOf" ebXML Association Type as shown in the following:

<rim:Association id=${subPropertyOfID} associationType='urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:SubPropertyOf'

Such a semantic enhancement brings the following processing need: given a property, it should be possible to retrieve all of its super properties as described in Section 6.1.

4.1.4 rdfs:subClassOf → rim:Association Type SubClassOf

OWL relies on RDF Schema for building class hierarchies through the use of "rdfs:subClassOf" property and allows multiple inheritance. In ebXML, a class hierarchy is represented by a ClassificationScheme. A ClassificationScheme is constructed by connecting a ClassificationNode to its super class by using the “parent" attribute of the ClassificationNode. However it is not possible to associate a ClassificationNode with more than one different super classes by using “parent” attribute. In other words, an ebXML Class hierarchy has a tree structure and therefore is not readily available to express multiple inheritance. There is a need for additional mechanisms to express multiple inheritance in ebXML RIM. Therefore, a new Association Type called "SubClassOf" MUST be defined in the Registry.

In the following OWL example, "AirReservationServices" service inherits both from "AirServices" service and OWL-S ServiceProfile class.

To express this semantics through ebXML RIM constructs, "AirReservationServices" ClassificationNode is associated both with the "OWL-S Profile" and "AirServices" ClassificationNodes through the "targetObject" and "sourceObject" attributes of the two instances of the newly created "SubClassOf" ebXML Association Type as shown in the following:

<rim:Association id=${subClassOf} associationType='urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:SubClassOf'

<rim:Association id=${subClassOf2} associationType='urn:oasis:names:tc:ebxml- regrep:profile:webontology:AssociationType:OWL:SubClassOf'

Once such a semantics is defined, there is a need to process the objects in the registry according to the semantics implied; that is, given a class, it should be possible to retrieve all of its subclasses and/or all of its super classes. By making the required adhoc queries available in the registry, this need can be readily served as described in Sections 6.2, 6.3, 6.4 and 6.5.

4.1.5 owl:Individual → rim:ExtrinsicObject

A class in OWL defines a group of individuals that belong together because they share some properties [McGuinness, Harmelen]. For example, "TravelService" class may have the property "paymentMethod" whose range may be "PossiblePaymentMethods" class as shown in the following example:

In OWL, individuals are instances of classes. For example, an instance of "TravelWebService" class may be "MyTravelWebService". Properties may be used to relate one individual to another. For example, "MyTravelService" inherits "paymentMethod" property and this property may map to an instance of "PossiblePaymentMethods" class, such as "Cash" as shown in the following example:

In ebXML Registry the class instances can be stored in the Registry or in the Repository. This profile recommends to store class instances in the Repository and to describe their metadata through ExtrinsicObjects in the Registry.

4.2 Representing OWL (In)Equality Constructs in ebXML RIM

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

In ebXML, the predefined "EquivalentTo" Association Type expresses the fact that the source RegistryObject is equivalent to target RegistryObject. Therefore, "EquivalentTo" association MUST be used to express "owl:equivalentClass" and "owl:equivalentProperty" properties since classes and properties are all ebXML RegistryObjects.

The adhoc query for retrieving all the equivalent classes of a given ClassificationNode is represented in Section 6.6. Additionally the adhoc query to retrieve all the equivalent properties (Association Type) of a given property (Association Type) is presented in Section 6.7

4.2.2 owl:sameAs → rim:Association Type SameAs

ebXML Registry contains the metadata of the objects stored in the repository. This profile recommends that the instances to be stored in repository and to be represented through “ExtrinsicObjects” in the registry.

owl:sameAs construct is used to indicate that two instances in a knowledge base are the same. This construct may be used to create a number of different names that refer to the same individual.

This translates into two "ExtrinsicObjects" in the ebXML registry to be the same. For this purpose a new Association Type called "SameAs" MUST be defined in the ebXML registry.

<rim:Association id=${sameAs1} associationType='urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:SameAs'

sourceObject= ${MyAirReservationService} targetObject=${THYAirReservationService} >

Furthermore, the adhoc query presented in Section 6.8 MUST be available in the registry to retrieve all the "ExtrinsicObjects" defined to be the same with a given ExtrinsicObject.

4.2.3 owl:differentFrom → rim:Association Type DifferentFrom

owl:differentFrom construct is used to indicate that two instances in a knowledge base are different from one another. Explicitly stating that individuals are different can be important when using languages such as OWL (and RDF) that do not assume that individuals have one and only one name [McGuinness, Harmelen].

This translates into declaring two "ExtrinsicObjects" in the ebXML registry to be different from each other. For this purpose a new Association Type "DifferentFrom" MUST be defined in the ebXML registry to explicitly indicate that the sourceRegistryObject is different from the targetRegistryObject.

<rim:Association id=${differentFrom1} associationType='urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:DifferentFrom'

sourceObject= ${MyAirReservationService} targetObject=${THYAirReservationService} >

4.2.4 owl:AllDifferent

owl:AllDifferent is a special built-in OWL class, for which the property owl:distinctMembers is defined, which links an instance of owl:AllDifferent to a list of individuals. The AllDifferent construct is particularly useful when there are sets of distinct objects and when modelers are interested in enforcing the unique names assumption within those sets of objects [McGuinness, Harmelen].

The following example states that the three instances of the “WebService” collection are all different from one another:

owl:AllDifferent SHOULD be represented in ebRIM as follows: the RegistryObjects under consideration SHOULD be grouped as a RegistryPackage whose id is ${Collection}. Then the RegistryObjects in the collection MUST be associated with this RegistryPackage with “HasMember” Association Type. One slot of the registry package MUST be used to indicate that all members are different.

<rim:Slot name=urn:oasis:names:tc:ebxml-regrep:profile:webontology:slot:packagetype>

associationType = "urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember" sourceObject = ${Collection}

associationType = "urn:oasis:names:tc:ebxml-regrep:HasMember" sourceObject = ${Collection}

The adhoc query presented in Section 6.10 can be used to process this semantics.

4.3 Representing OWL Property Characteristics in ebRIM

4.3.1 owl:ObjectProperty → rim:Association Type objectProperty

To represent OWL ObjectProperty in ebXML, a new type of Association called “ObjectProperty" MUST be defined. Consider the following example which defines an object property “hasAirport" whose domain is “City" and whose range is “Airport":

<rim:Association id=${hasAirport} associationType='urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:ObjectProperty'

Once such objectProperty definitions are stored in the ebXML registry, they can be retrieved through ebXML query facilities by the user. The adhoc queries presented in Section 6.11 and 6.12 MUST be available in the registry to facilitate this access.

4.3.2 owl:DatatypeProperty → rim:Association Type DatatypeProperty

Similarly, to represent OWL DatatypeProperty in ebXML, a new Association Type called “DatatypeProperty" MUST be defined. Consider the following example which defines an datatype property “hasPrice" whose domain is the “AirReservationServices" and whose range is “XMLSchema nonNegativeInteger". How OWL XML Schema types are handled in ebXML RIM is described in Section 4.9.

<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema/nonNegativeInteger"/>

<rim:Association id=${hasPrice} associationType='urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:DatatypeProperty'

sourceObject= ${AirReservationServices} targetObject=urn:www.w3.org:2001:XMLSchema:nonNegativeInteger >

The adhoc query presented in Section 6.14 MUST be available in the registry to facilitate the direct access to datatype properties of a given classification node.

4.3.3 owl:TransitiveProperty → rim:Association Type TransitiveProperty

In OWL, if a property, P, is specified as transitive then for any x, y, and z:P(x,y) and P(y,z) implies P(x,z) [McGuinness, Harmelen]. Transitive property is a subproperty of ObjectProperty and MUST be defined as a new Association Type called “TransitiveProperty” in ebRIM.

Consider the following example where "succeeds" is defined as a transitive property of “TravelWebService" class:

<rim:Association id=${succeeds} associationType='urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:TransitiveProperty'

Assume the following two definitions which declare three Web service instances from TravelWebService class where "MyHotelAvailabilityService" service succeeds "MyAirReservationService" and "MyInsuranceService" succeeds “MyHotelAvailabilityService". Since "succeeds" is a transitive property, it follows that "MyInsuranceService" succeeds "MyAirReservationService" although this fact is not explicitly stated.

To make any use of this transitive property in ebXML registries, coding is necessary to find out the implied information. The adhoc query presented in Section 6.16 MUST be available in the registry to handle this semantics.

4.3.4 owl:inverseOf → rim:Association Type InverseOf

In OWL, one property may be stated to be the inverse of another property. If the property P1 is stated to be the inverse of the property P2, then if X is related to Y by the P2 property, then Y is related to X by the P1 property [McGuinness, Harmelen].

Consider, for example, the "succeeds" property defined in Section 4.3.3. To denote that a certain Web service instance precedes another during execution, we may define the "precedes" property as an inverse of the "succeeds" property as follows:

<rim:Association id=${inverseOf1} associationType='urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:InverseOf'

Assume that we want to find all the Web services which can succeed a given Web service. In such a case, we need not only find all the Web services which succeeds this given Web service, that is the target objects of "succeeds" Association instance, but we also need to find all the sourceObjects of the "precedes" Association instance since "precedes" is declared to be the "inverseOf" succeeds Association instance. This can be achieved through the adhoc query presented in Section 6.19.

Alternatively, one might use the additional semantics that this profile supports would be to cause inferred information to be produced and stored along with new data as that new data was inserted into the reg/rep. There is a trade off here: in this way, the extra work of inferring is only done at insertion/update time, instead of at query time. However, an insertion or an update will require all the inferred data to be inserted whether it will be used or not and hence will cause considerable maintenance overhead.

4.3.5 owl:SymmetricProperty→ rim:Association Type SymmetricProperty

In OWL, if a property is symmetric, then if the pair (x,y) is an instance of the symmetric property P, then the pair (y,x) is also an instance of P [McGuinness, Harmelen]. Symmetric property is a subproperty of ObjectProperty in OWL. Consider the OWL class “WebService” and the “complements” symmetric property:

<rim:Association id=${complements} associationType='urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:SymetricProperty'

Given that HotelReservationWebService complements AirReservationWebService, it is possible to deduce that AirReservationWebService complements HotelReservationWebService.

owl:SymmetricProperty MUST be defined as a new type of Association in ebRIM called “SymmetricProperty”. Furthermore the adhoc query presented in Section 6.20 MUST be available in the Registry to retrieve symmetric Associations of a ClassificationNode.

4.3.6 owl:FunctionalProperty→ rim:Association Type FunctionalProperty

In OWL, if a property is a FunctionalProperty, then it has no more than one value for each individual (it may have no values for an individual) [McGuinness, Harmelen]. The range of a FunctionalProperty can be either an Object or a datatype. Consider, for example, the “hasPrice” Functional property which has a unique price:

<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema/nonNegativeInteger"/>

<rim:Association id=${hasPrice} associationType='urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:FunctionalProperty'

sourceObject= ${AirReservationServices} targetObject=${uurn:www.w3.org:2001:XMLSchema:nonNegativeInteger} >

ebXML RIM MUST contain a new Association Type called “FunctionalProperty” to express this semantics. Furthermore the he adhoc query presented in Section 6.21 MUST be available in the Registry to retrieve functional Associations of a ClassificationNode.

4.3.7 owl:InverseFunctionalProperty→ rim:Association Type InverseFunctionalProperty

In OWL, if a property is inverse functional then the inverse of the property is functional. Thus the inverse of the property has at most one value for each individual [McGuinness, Harmelen]. InverseFunctional properties (IFPs) are like keys. An individual filling the range role in an inverseFunctional property instance identifies the individual in the domain role of that same property instance. In other words, if a semantic web tool encounters two individuals with the same value for an inverseFunctional property, it can be inferred that they are actually the same individual.

As an example, the ObjectProperty “finalDestination” indicates that each flight arrives to only one airport as its final destination.

<rim:Association id=${finalDestination} associationType='urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:InverseFunctionalProperty'

ebRIM MUST contain a new Association Type called “InverseFunctionalProperty” to express this semantics. Furthermore the adhoc query presented in Section 6.22 MUST be available in the Registry to retrieve inverse functional Associations of a ClassificationNode.

4.4 OWL Property Restrictions in ebXML RIM

An important construct of OWL is "owl:Restriction". In RDF, a property has a global scope, that is, no matter what class the property is applied to, the range of the property is the same. "owl:Restriction", on the other hand, has a local scope; restriction is applied on the property within the scope of the class where it is defined. This makes property definitions more reusable by factoring out class specific characteristics of the property into the class description.

For example, we may define a property "paymentMethod" for travel Web services in general and we may state that the range of this property is the class "PossiblePaymentMethods". Then, for "AirReservationServices", we may wish to restrict "paymentMethod" property to, say, "CreditCard" class as demonstrated in the following two examples:

A new Association Type of “restriction” SHOULD be defined to represent OWL restriction. A slot of this Association Type SHOULD indicate the whether the restriction is “allValuesFrom” or “someValuesFrom”. When such restriction is submitted to the system, the registry MUST create a new Association instance, say, “paymentMethod_1” of AssociationType “ObjectProperty” is created whose sourceObject is "AirReservationServices" and the targetObject is "CreditCard". “paymentMethod_1” Association instance is related with the “paymentMethod” Association instance by using an instance of the Association Type “Restriction” as shown in the following example:

"urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:ObjectProperty"

"urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:Restriction"

<rim:Slot name="urn:oasis:names:tc:ebxml-regrep:profile:webontology:slot:restrictionType">

Obviously, this serves the purpose of reusing the "paymentMethod" property. Otherwise, a new property "paymentMethodCC" can be defined between "AirReservationServices" and the "CreditCard" classes as shown in the following:

4.5 Representing OWL Restricted Cardinality in ebXML RIM

4.5.1 owl:minCardinality (only 0 or 1)

In OWL, cardinality is stated on a property with respect to a particular class. If a minCardinality of 1 is stated on a property with respect to a class, then any instance of the class will have at least one value for the restricted property. This restriction is another way of saying that the property is required to have a value for all instances of the class. In OWL Lite, the only minimum cardinalities allowed are 0 or 1. A minimum cardinality of zero on a property just states (in the absence of any more specific information) that the property is optional with respect to a class [McGuinness, Harmelen].

Consider for example the following OWL code which states that each instance of a “WebService” class must have at least one price:

<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger"> 1 </owl:minCardinality>

In ebXML RIM, cardinalities of Association Types MUST be defined by associating a minCardinality slot with the Association Types as shown in the following example:

associationType = "urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:ObjectProperty" sourceObject = ${WebService}

<rim:Slot name="urn:oasis:names:tc:ebxml-regrep:profile:webontology:slot:minCardinality">

4.5.2 owl:maxCardinality (only 0 or 1)

In OWL, cardinality is stated on a property with respect to a particular class. If a maxCardinality of 1 is stated on a property with respect to a class, then any instance of that class will be related to at most one individual by that property. A maxCardinality 1 restriction is sometimes called a functional or unique property. It may be useful to state that certain classes have no values for a particular property. This situation is represented by a maximum cardinality of zero on the property [McGuinness, Harmelen].

Consider for example the following OWL code which states that each instance of a “WebService” class can have at most one price:

<owl:maxCardinality rdf:datatype="&xsd;nonNegativeInteger"> 1 </owl:maxCardinality>

In ebXML RIM, cardinalities of Association Types MUST be defined by associating a maxCardinality slot with the Association Types as shown in the following example:

associationType = "urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:ObjectProperty" sourceObject = ${WebService}"

<rim:Slot name="urn:oasis:names:tc:ebxml-regrep:profile:webontology:slot:maxCardinality">

4.5.3 owl:cardinality (only 0 or 1)

In OWL Lite, cardinality is provided as a convenience when it is useful to state that a property on a class has both minCardinality 0 and maxCardinality 0 or both minCardinality 1 and maxCardinality 1 [McGuinness, Harmelen].

Consider for example the following OWL code which states that each instance of a “WebService” class must have exactly one price:

In ebXML RIM, cardinalities of Association Types MUST be defined by associating a Cardinality slot with the Association Types as shown in the following example:

associationType = "urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:ObjectProperty" sourceObject = ${WebService}

<rim:Slot name="urn:oasis:names:tc:ebxml-regrep:profile:webontology:slot:cardinality">

4.6 Representing OWL Class Intersection in ebXML RIM

OWL provides the means to manipulate class extensions using basic set operators. In OWL lite, only “owl:intersectionOf” is available which defines a class that consists of exactly all objects that belong to all the classes specified in the intersection definition. In the following example, "AirReservationServices" is defined as the intersection of "AirServices" and "ReservationServices":

<rim:ClassificationNode id = ${AirReservationServices} code = "AirReservationServices”>

<rim:Slot name=urn:oasis:names:tc:ebxml- regrep:profile:webontology:slot:intersectionOf>

When such a representation is used to create a complex class (a new ClassificationNode) in RIM, it becomes possible to infer that the objects (instances) classified by all of the classes (ClassificationNodes) specified in the Intersection definition, are also classified by this complex class. The adhoc query presented in Section 6.23 MUST be available in the ebXML Registry to retrieve the direct instances of the complex class and also the instances of the intersection of the classes.

4.7 Representing OWL Versioning in ebXML RIM

4.7.1 owl:versionInfo, owl:priorVersion

An owl:versionInfo statement generally has as its object a string giving information about this version, for example RCS/CVS keywords. This statement does not contribute to the logical meaning of the ontology other than that given by the RDF(S) model theory [McGuinness, Harmelen].

An owl:priorVersion statement contains a reference to another ontology. This identifies the specified ontology as a prior version of the containing ontology [McGuinness, Harmelen].

In ebXML, 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. Therefore, almost for all the RegistryObjects the version information is kept through “versionName” and “comment” attributes of the “VersionInfo” ebRIM Class.

“owl:version” information MUST be stored in the “versionName” and “comment” attributes of the VersionInfo ebRIM class.

It should be noted that in freebXML implementation the versionInfo is flattened and the “versionName” and “comment_” are provided as direct attributes of database tables.

4.8 Representing OWL Annotation Properties in ebXML RIM

4.8.1 rdfs:label

rdfs:label is an instance of rdf:Property that may be used to provide a human-readable version of a resource's name [Brickley, Guha].

In ebXML RIM, human readable names of resources are provided through rim:Name. rdfs:label MUST be expressed through rim:Name.

<rim:ClassificationNode id = ${AirReservationServices} code = 'AirReservationServices'>

4.8.2 rdfs:comment

rdfs:comment is an instance of rdf:Property that may be used to provide a human-readable description of a resource [Brickley, Guha].

<rim:ClassificationNode id = ${AirReservationServices} code = 'AirReservationServices'>

4.8.3 rdfs:seeAlso

rdfs:seeAlso is an instance of rdf:Property that is used to indicate a resource that might provide additional information about the subject resource [Brickley, Guha].

This construct MUST be expressed in ebXML RIM by defining a new Association Type called “SeeAlso” to express this semantics.

<rim:ClassificationNode id = ${AirReservationServices} code = 'AirReservationServices'>

associationType = 'urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:SeeAlso'

4.9 OWL Datatypes in ebXML RIM

OWL allows the use of XML Schema datatypes to describe part of the datatype domain by simply including their URIs within an OWL ontology [McGuinness, Harmelen]. In ebXML, XML Schema datatypes MAY be used by providing an external link from the registry.

The following example demonstrates how XML Schema datatype “integer” can be referenced through an ExternalLink whose id is 'urn:www.w3.org:2001:XMLSchema:integer' and how to define a DatatypeProperty, namely, “hasPrice”, whose target object is the defined to be ExternalLink 'integer':

<rim:Association id = ${hasPrice} associationType = 'urn:oasis:names:tc:ebxml- regrep:AssociationType:DatatypeProperty'

5 Cataloging Service Profile

The ebXML Regitsry provides the ability for a content cataloging service to be configured for any type of content. The cataloging service serves the following purposes:

An OWL document, when published to an ebXML Registry implementing the OWL Profile, MUST be cataloged as specified in this section using a OWL Content Cataloging Service as defined by [ebRS].

5.1 Invocation Control File

The OWL cataloging service MAY optionally support an invocation control file that declaratively specifies the transforms necessary to catalog published OWL documents.

5.2 Input Metadata

The OWL cataloging service MUST be pre-configured to be automatically invoked when the following types of metadata are published, as defined by the [ebRS] specifications.

These are the only types of metadata that MAY describe a OWL document being published:

5.3 Input Content

The OWL cataloging service expects an OWL document as its input content. The input content MUST be processed by the OWL cataloging service regardless of whether it is a RepositoryItem for an ExtrinsicObject or whether it is content external to repository that is referenced by an ExternalLink.

5.4 Output Metadata

This section describes the metadata produced by the OWL cataloging service produces as output.

5.4.1 owl:Class → rim:ClassificationNode

The OWL Cataloging service MUST automatically produce a rim:ClassificationNode instance for each owl:class element within the input OWL or its imports, as specified in the owl:Class → rim:ClassificationNode mapping earlier in this document.

5.4.2 rdf:Property → rim:Association Type HasProperty

The OWL Cataloging service MUST automatically produce an rim:Association instance with associationType HasProperty for each rdf:Property element within the input OWL or its imports, as specified in the rdf:Property → rim:Association Type HasProperty mapping earlier in this document.

5.4.3 rdfs:subPropertyOf → rim:Association Type SubPropertyOf

The OWL Cataloging service MUST automatically produce an rim:Association instance with associationType SubPropertyOf for each rdfs:subPropertyOf element within the input OWL or its imports, as specified in the rdfs:subPropertyOf → rim:Association Type SubPropertyOf mapping earlier in this document.

5.4.4 rdfs:subClassOf → rim:Association Type subClassOf

The OWL Cataloging service MUST automatically produce an rim:Association instance with associationType subClassOf for each rdfs:subClassOf element within the input OWL or its imports, as specified in the rdfs:subClassOf → rim:Association Type subClassOf mapping earlier in this document.

5.4.5 owl:Individual → rim:ExtrinsicObject

The OWL Cataloging service MUST automatically produce rim:ExtrinsicObject instances for each owl:Individual element within the input OWL or its imports, as specified in the owl:Individual → rim:ExtrinsicObject mapping earlier in this document.

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

The OWL Cataloging service MUST automatically produce rim:Association instances with associationType EquivalentTo for each owl:equivalentClass or owl:equivalentProperty element within the input OWL or its imports, as specified in the owl:equivalentClass, owl:equivalantProperty → rim:Association Type EquivalantTo mapping earlier in this document.

5.4.7 owl:sameAs → rim:Association Type SameAs

The OWL Cataloging service MUST automatically produce rim:Association instances with associationType SameAs for each owl:sameAs element within the input OWL or its imports, as specified in the owl:sameAs → rim:Association Type SameAs mapping earlier in this document.

5.4.8 owl:differentFrom → rim:Association Type DifferentFrom

The OWL Cataloging service MUST automatically produce rim:Association instances with associationType DifferentFrom for each owl:differentFrom element within the input OWL or its imports, as specified in the owl:differentFrom → rim:Association Type DifferentFrom mapping earlier in this document.

5.4.9 owl:AllDifferent → rim:RegistryPackage

The OWL Cataloging service MUST automatically produce rim:RegistryPackage instances for each owl:AllDifferent element within the input OWL or its imports, as specified in the owl:AllDifferent → rim:RegistryPackage mapping earlier in this document.

5.4.10 owl:ObjectProperty → rim:Association Type ObjectProperty

The OWL Cataloging service MUST automatically produce rim:Association instances with associationType ObjectProperty for each owl:ObjectProperty element within the input OWL or its imports, as specified in the owl:ObjectProperty → rim:Association Type ObjectProperty mapping earlier in this document.

5.4.11 owl:DatatypeProperty → rim:Association Type DatatypeProperty

The OWL Cataloging service MUST automatically produce rim:Association instances with associationType datatypeProperty for each owl:DatatypeProperty element within the input OWL or its imports, as specified in the owl:DatatypeProperty → rim:Association Type datatypeProperty mapping earlier in this document.

5.4.12 owl:TransitiveProperty → rim:Association Type TransitiveProperty

The OWL Cataloging service MUST automatically produce rim:Association instances with associationType TransitiveProperty for each owl:TransitiveProperty element within the input OWL or its imports, as specified in the owl:TransitiveProperty → rim:Association Type TransitiveProperty mapping earlier in this document.

5.4.13 owl:inverseOf → rim:Association Type InverseOf

The OWL Cataloging service MUST automatically produce rim:Association instances with associationType InverseOf for each owl:inverseOf element within the input OWL or its imports, as specified in the owl:inverseOf → rim:Association Type InverseOf mapping earlier in this document.

5.4.14 owl:SymmetricProperty→ rim:Association Type SymetricProperty

The OWL Cataloging service MUST automatically produce rim:Association instances with associationType SymetricProperty for each owl:SymetricProperty element within the input OWL or its imports, as specified in the owl:SymetricProperty → rim:Association Type SymetricProperty mapping earlier in this document.

5.4.15 owl:FunctionalProperty→ rim:Association Type FunctionalProperty

The OWL Cataloging service MUST automatically produce rim:Association instances with associationType FunctionalProperty for each owl:FunctionalProperty element within the input OWL or its imports, as specified in the owl:FunctionalProperty → rim:Association Type FunctionalProperty mapping earlier in this document.

5.4.16 owl:InverseFunctionalProperty→ rim:Association Type InverseFunctionalProperty

The OWL Cataloging service MUST automatically produce rim:Association instances with associationType InverseFunctionalProperty for each owl:InverseFunctionalProperty element within the input OWL or its imports, as specified in the owl:InverseFunctionalProperty → rim:Association Type InverseFunctionalProperty mapping earlier in this document.

5.4.17 owl:minCardinality (only 0 or 1)

The OWL Cataloging service MUST automatically add a slot with name minCardinality to the relevant rim:Association instances for each owl:minCardinality element within the input OWL or its imports, as specified in section 4.5.1 where how to represent owl:minCardinality is described.

5.4.18 owl:maxCardinality (only 0 or 1)

The OWL Cataloging service MUST automatically add a slot with name maxCardinality to the relevant rim:Association instances for each owl:maxCardinality element within the input OWL or its imports, as specified in section 4.5.2 where how to represent owl:maxCardinality is described.

5.4.19 owl:cardinality

The OWL Cataloging service MUST automatically add a slot with name cardinality to the relevant rim:Association instances for each owl:cardinality element within the input OWL or its imports, as specified in section 4.5.3 where how to represent owl:cardinality is described.

5.4.20 owl:intersectionOf

The OWL Cataloging service MUST automatically produce a rim:RegistryPackage and a rim:Association instances with type IntersectionOf for each owl:intersectionOf element within the input OWL or its imports, as specified in section 4.6 where how to represent owl:intersectionOf is described.

5.4.21 rdfs:label

The OWL Cataloging service MUST automatically produce a rim:Name instance for each rdfs:label element within the input OWL or its imports, as specified in section 4.8.1 where how to represent rdfs:label is described.

5.4.22 rdfs:comment

The OWL Cataloging service MUST automatically produce a rim:Description instance for each rdfs:comment element within the input OWL or its imports, as specified in section 4.8.2 where how to represent rdfs:comment is described.

5.4.23 rdfs:seeAlso

The OWL Cataloging service MUST automatically produce a rim:ExternalLink and a rim:Association with type SeeAlso instances for each rdfs:seeAlso element within the input OWL or its imports, as specified in section 4.8.3 where how to represent rdfs:seeAlso is described.

6 Discovery Profile

The ebXML Registry provides the ability for a user defined parameterized queries to be configured for each type of content. The queries may be as complex or simple as the discovery use case requires. The complexity of the parameterized queries may hidden from the registry client by storing them within the ebXML Registry as instances of the AdhocQuery class, and being invoked by simply providing their parameters. Query parameters are often pattern strings that may contain wildcard characters '%' (matches any number of characters) and '_' (matches exactly one character) as described by [ebRS].

An ebXML Registry SHOULD provide a graphical user interface that displays any configured parameterized query as a form which contains an appropriate field for entering each query parameter.

This chapter defines the queries that MUST be supported by an ebXML Registry implementing the OWL Profile for processing the semantics provided in the OWL content. An implementation MAY also support additional discovery queries for OWL content, some of which have already identified in this section.

The queries defined in this chapter are parameterized queries stored in the Registry as instances of the AdhocQuery type, in the same manner as any other RegistryObject.

In the subsequent section each query is described simply in terms of its supported parameters that serve as its search criteria. The actual AdhocQuery instances are much more complex in comparison but they are not exposed to the client making the query. Details on these queries are specified canonically in section 7.3 .

Some of the queries that are necessary to process the semantics involved in OWL documents requires SQL recursion mechanism which is available through SQL 99 Standard. Since SQL 92, does not support recursion mechanism, those queries are stated to be implemented optionally. Additionally for these types of discovery queries, references to the “stored procedures” are presented in Section 7.3 for the interested users.

6.1 All SuperProperties Discovery Query

As presented in Section 4.1.3, a new ebXML RIM Association Type called “SubPropertyOf” MUST be defined to represent rdfs:subPropertyOf in ebRIM. Such a semantic enhancement brings the following processing need: given a property, it should be possible to retrieve all of its super properties. This requires a recursion mechanism in SQL queries.

The AllSuperProperties discovery query MAY be implemented by an ebXML Registry implementing this profile. It allows the discovery of all super properties of a given property instance (Association instance in ebXML terminology) recursively in a property hierarchy (hierarchy of Association Types) in an ebXML Registry implementation supporting recursion. The canonical query corresponding to this discovery query is presented in Section 7.3.1.

6.1.1 Parameter $propertyName

This parameter's value SHALL specify a string containing a pattern to match against the name attribute value of Associations that have associationType of Property.

6.1.2 Example of All SuperProperties Discovery Query

The following example illustrates how to find all the super properties of a given property having a name containing “creditCardPayment” if the query is implemented as an AdHoc Query.

<rim:Value>urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindAllSuperProperties</rim:Value>

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

6.2 Immediate SuperClass Discovery Query

The Immediate SuperClass discovery query MUST be implemented by an ebXML Registry implementing this profile. It allows the discovery of all of the immediate super classes of a given class. The canonical query corresponding to this discovery query is presented in Section7.3.2.

6.2.1 Parameter $className

This parameter's value SHALL specify a string containing a pattern to match against the name attribute value of ClassificationNodes.

6.2.2 Example of Immediate SuperClass Discovery Query

The following example illustrates how to find all the immediate super classes of a given class that have a name containing the string “AirReservationServices” .

<rim:Value>urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindImmediateSuperClasses</rim:Value>

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

6.3 Immediate SubClass Discovery Query

The Immediate SubClass discovery query MUST be implemented by an ebXML Registry implementing this profile. It allows the discovery of all of the immediate subclasses of a given class. The canonical query corresponding to this discovery query is presented in Section 7.3.3.

6.3.1 Parameter $className

This parameter's value SHALL specify a string containing a pattern to match against the name attribute value of ClassificationNode.

6.3.2 Example of Immediate SubClasss Discovery Query

The following example illustrates how to find all the immediate subclasses of a given class that have a name containing the string “AirServices” .

<rim:Value>urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindImmediateSubClasses</rim:Value>

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

6.4 All SuperClasses Discovery Query

It should be noted that, given a class, finding its immediate subclasses, super classes is necessary but not sufficient. Given a class, it should be possible to retrieve all of its subclasses, and all of its super classes. This requires a recursion mechanism in SQL queries.

The All SuperClasses discovery query MAY be implemented by an ebXML Registry implementing this profile. It allows the discovery of all super classes of a given ClassificationNode recursively in an ebXML Registry implementation supporting recursion. The canonical query corresponding to this discovery query is presented in Section 7.3.4.

6.4.1 Parameter $className

This parameter's value SHALL specify a string containing a pattern to match against the name attribute value of ClassificationNode.

6.4.2 Example of All SuperClasses Discovery Query

The following example illustrates how to find all the super classes of a given class recursively that have a name containing the string “AirReservationServices” if the query is implemented as an Adhoc Query .

<rim:Value>urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindAllSuperClasses</rim:Value>

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

6.5 All SubClasses Discovery Query

The All SubClasses discovery query MAY be implemented by an ebXML Registry implementing this profile. It allows the discovery of all subclasses of a given ClassificationNode recursively in an ebXML Registry implementation supporting recursion. The canonical query corresponding to this discovery query is presented in Section 7.3.5.

6.5.1 Parameter $className

This parameter's value SHALL specify a string containing a pattern to match against the name attribute value of ClassificationNode.

6.5.2 Example of All SubClassses Discovery Query

The following example illustrates how to find all the subclasses of a given class recursively that have a name containing the string “AirServices” , if the query is implemented as an Adhoc Query.

<rim:Value>urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindAllSubClasses</rim:Value>

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

6.6 EquivalentClasses Discovery Query

The EquivalentClasses discovery query MUST be implemented by an ebXML Registry implementing this profile. It allows the discovery of all the equivalent classes of a given ClassificatioNode.

6.6.1 Parameter $className

This parameter's value SHALL specify a string containing a pattern to match against the name attribute value of ClassificationNodes.

6.6.2 Example of EquivalentClasses Discovery Query

The following example illustrates how to find all the equivalent classes of a given class that have a name containing the string “AirServices” .

<rim:Value>urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindEquivalentClasses</rim:Value>

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

6.7 EquivalentProperties Discovery Query

The EquivalentProperties discovery query MUST be implemented by an ebXML Registry implementing this profile. It allows the discovery of all the equivalent properties of a given Association that have associationType of Property. The canonical query corresponding to this discovery query is presented in Section 7.3.7.

6.7.1 Parameter $propertyName

This parameter's value SHALL specify a string containing a pattern to match against the name attribute value of Associations that have associationType of Property

6.7.2 Example of EquivalentProperties Discovery Query

The following example illustrates how to find all the equivalent properties(Association Type) of a given property (Association Type) that have a name containing the string “paymentMethods” .

<rim:Value>urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindEquivalentProperties</rim:Value>

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

6.8 SameExtrinsicObjects Discovery Query

The SameExtrinsicObjects discovery query MUST be implemented by an ebXML Registry implementing this profile. It allows the discovery of all the "ExtrinsicObjects" defined to be the same with a given ExtrinsicObject. The canonical query corresponding to this discovery query is presented in Section 7.3.8.

6.8.1 Parameter $extrinsicObjectName

This parameter's value SHALL specify a string containing a pattern to match against the name attribute value of ExtrinsicObjects.

6.8.2 Example of SameExtrinsicObjects Discovery Query

The following example illustrates how to find all the ExtrinsicObjects that are defined to be the same as the ExtrinsicObject that have a name containing the string “MyDocument” .

<rim:Value>urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindTheSameExtrinsicObjects</rim:Value>

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

6.9 DifferentExtrinsicObjects Discovery Query

The DifferentExtrinsicObjects discovery query MUST be implemented by an ebXML Registry implementing this profile. It allows the discovery of all the "ExtrinsicObjects" defined to be the different from a given ExtrinsicObject. The canonical query corresponding to this discovery query is presented in Section 7.3.9.

6.9.1 Parameter $extrinsicObjectName

This parameter's value SHALL specify a string containing a pattern to match against the name attribute value of ExtrinsicObjects.

6.9.2 Example of DifferentExtrinsicObjects Discovery Query

The following example illustrates how to find all the ExtrinsicObjects that are defined to be different from the ExtrinsicObject that have a name containing the string “MyDocument” .

<rim:Value>urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindDifferentExtrinsicObjects</rim:Value>

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

6.10 AllDifferentRegistryObject Discovery Query

The AllDifferentRegistryObjects discovery query MUST be implemented by an ebXML Registry implementing this profile. Given a RegistryObject, it allows the discovery of all the other member "RegistryObjects" of a Registry package that are defined to be the different from each other through a allDifferent slot. The canonical query corresponding to this discovery query is presented in Section 7.3.10.

6.10.1 Parameter $registryObjectName

This parameter's value SHALL specify a string containing a pattern to match against the name attribute value of RegistryObjects.

6.10.2 Example of AllDifferentRegistryObjects Discovery Query

The following example illustrates how to find all the RegistryObjects that are defined to be different from the RegistryObject that have a name containing the string “MyDocument” .

<rim:Value>urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindAllDifferent</rim:Value>

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

6.11 ObjectProperties Discovery Query

The ObjectProperties discovery query MUST be implemented by an ebXML Registry implementing this profile. It allows the discovery of all of the objectProperties of a given classification node. The canonical query corresponding to this discovery query is presented in Section 7.3.11.

6.11.1 Parameter $className

This parameter's value SHALL specify a string containing a pattern to match against the name attribute value of ClassificationNodes.

6.11.2 Example of ObjectProperties Discovery Query

The following example illustrates how to find all the object properties of a given classification node having a name containing “AirServices” .

<rim:Value>urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindObjectProperties</rim:Value>

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

6.12 ImmediateInheritedObjectProperties Discovery Query

The ImmediateInheritedObjectProperties discovery query MUST be implemented by an ebXML Registry implementing this profile. It allows the discovery of all of the objectProperties of a given classification node including the ones inherited from its immediate super classes. The canonical query corresponding to this discovery query is presented in Section 7.3.12.

6.12.1 Parameter $className

This parameter's value SHALL specify a string containing a pattern to match against the name attribute value of ClassificationNodes.

6.12.2 Example of ImmediateInheritedObjectProperties Discovery Query

The following example illustrates how to find all the object properties of a given classification node having a name containing “AirServices” including the ones inherited from its immediate super classes.

<rim:Value>urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindImmediateInheritedObjectProperties</rim:Value>

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

6.13 AllInheritedObjectProperties Discovery Query

It should be noted that, given a class, finding the object properties inherited from immediate super classes is necessary but not sufficient. Given a class, it should be possible to retrieve all of the object properties inherited from its super classes. This requires a recursion mechanism in SQL queries.

The AllInheritedObjectProperties discovery query MAY be implemented by an ebXML Registry implementing this profile. It allows the discovery of all inherited ObjectProperties recursively of a given ClassificationNode in a ClassificationScheme in an ebXML Registry implementation supporting recursion.

The canonical query corresponding to this discovery query is presented in Section 7.3.13.

6.13.1 Parameter $className

This parameter's value SHALL specify a string containing a pattern to match against the name attribute value of ClassificationNodes.

6.13.2 Example of AllInheritedObjectProperties Discovery Query

The following example illustrates how to find all the object properties of a given classification node having a name containing “AirReservationServices” including the ones inherited from all of its super classes recursively, if the query is implemented as an Adhoc Query.

<rim:Value>urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindAllInheritedObjectProperties</rim:Value>

<rim:Value>urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindAll InheritedObjectProperties</rim:Value>

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

6.14 DatatypeProperties Discovery Query

The DatatypeProperties discovery query MUST be implemented by an ebXML Registry implementing this profile. It allows the discovery of all of the datatypeProperties of a given classification node. The canonical query corresponding to this discovery query is presented in Section 7.3.14.

6.14.1 Parameter $className

This parameter's value SHALL specify a string containing a pattern to match against the name attribute value of ClassificationNodes.

6.14.2 Example of DatatypeProperties Discovery Query

The following example illustrates how to find all the datatype properties of a given classification node having a name containing “AirReservationServices” .

<rim:Value>urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindDatatypeProperties</rim:Value>

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

6.15 AllInheritedDatatypeProperties Discovery Query

It should be noted that, given a class, finding the datatype properties inherited from immediate super classes is necessary but not sufficient. Given a class, it should be possible to retrieve all of the datatype properties inherited from its super classes. This requires a recursion mechanism in SQL queries.

The AllInheritedDatatypeProperties discovery query MAY be implemented by an ebXML Registry implementing this profile. It allows the discovery of all inherited DatatypeProperties recursively of a given ClassificationNode in a ClassificationScheme in an ebXML Registry implementation supporting recursion. The canonical query corresponding to this discovery query is presented in Section 7.3.15.

6.15.1 Parameter $className

This parameter's value SHALL specify a string containing a pattern to match against the name attribute value of ClassificationNodes.

6.15.2 Example of AllInheritedDatatypeProperties Discovery Query

The following example illustrates how to find all the datatype properties of a given classification node having a name containing “AirReservationServices” including the ones inherited from all of its super classes recursively, if the query is implemented as an Adhoc Query.

<rim:Value>urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindAllInheritedDatatypeProperties</rim:Value>

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

6.16 TransitiveRelationships Discovery Query

To make any use of the transitive property in ebXML registries, coding is necessary to find out the implied information. The TransitiveRelationships discovery query MUST be implemented by an ebXML Registry implementing this profile to handle this semantics.

Given a class which is a source of a transitive property, this discovery query retrieves not only the target objects of a given transitive property, but if the target objects have the same property, it retrieves their target objects too. The canonical query corresponding to this discovery query is presented in Section 7.3.16.

6.16.1 Parameter $className

This parameter's value SHALL specify a string containing a pattern to match against the name attribute value of ClassificationNodes.

6.16.2 Parameter $propertyName

This parameter's value SHALL specify a string containing a pattern match against the name attribute value of Associations that have associationType of Property

6.16.3 Example of TransitiveRelationships Discovery Query

The following example illustrates how to retrieve all the target objects of the “succeeds” property of the “AirReservationServices” including the target objects implied by a transitive property relationship.

<rim:Value>urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindTransitiveRelationships</rim:Value>

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

6.17 TargetObjects Discovery Query

The TargetObjects discovery query MUST be implemented by an ebXML Registry implementing this profile. It allows the discovery of the targetObjects from the Registry, given a Classification Node (sourceObject) and a property name (Association Type). The canonical query corresponding to this discovery query is presented in Section 7.3.17.

6.17.1 Parameter $className

This parameter's value SHALL specify a string containing a pattern to match against the name attribute value of ClassificationNodes.

6.17.2 Parameter $propertyName

This parameter's value SHALL specify a string containing a pattern match against the name attribute value of Associations that have associationType of Property.

6.17.3 Example of TargetObjects Discovery Query

The following example illustrates how to retrieve all the target objects of the “paymentMethod” property of the “AirReservationServices”.

<rim:Value>urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindTargetObjects</rim:Value>

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

6.18 TargetObjectsInverseOf Discovery Query

The TargetObjectsInverseOf discovery query MUST be implemented by an ebXML Registry implementing this profile. Given a Classification Node (sourceObject) and a property name (Association Type), this query retrieves the source objects of the properties which are stated to be inverseOf the property name given as a parameter, and considering the Classification Node name as the targetObject of these properties. The canonical query corresponding to this discovery query is presented in Section 7.3.18.

6.18.1 Parameter $className

This parameter's value SHALL specify a string containing a pattern to match against the name attribute value of ClassificationNodes.

6.18.2 Parameter $propertyName

This parameter's value SHALL specify a string containing a pattern match against the name attribute value of Associations that have associationType of Property.

6.18.3 Example of TargetObjectsInverseOf Discovery Query

The following example illustrates how to retrieve all the source objects of the properties which are stated to the the inverseOf the property “succeeds”, considering the “AirReservationServices” as the target object of these properties.

<rim:Value>urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindTOinverseOf</rim:Value>

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

6.19 InverseRanges Discovery Query

The InverseRanges discovery query MUST be implemented by an ebXML Registry implementing this profile to handle this semantics. Given a Classification Node (sourceObject) and a property name (Association Type), this query retrieves not only the target objects of this property, but also the source objects of the properties which are stated to be inverseOf the property name given as a parameter, and considering the Classification Node name as the targetObject of these properties. This query can be thought as the union of the queries presented in Sections 6.17and 6.18. The canonical query corresponding to this discovery query is presented in Section 7.3.19.

6.19.1 Parameter $className

This parameter's value SHALL specify a string containing a pattern to match against the name attribute value of ClassificationNodes.

6.19.2 Parameter $propertyName

This parameter's value SHALL specify a string containing a pattern match against the name attribute value of Associations that have associationType of Property

6.19.3 Example of InverseRanges Discovery Query

The following example illustrates how to retrieve all the services that “succeeds” “AirReservationServices” by also making use of its “preceeds" property.

<rim:Value>urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindInverseRanges</rim:Value>

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

6.20 SymmetricProperties Discovery Query

The SymmetricProperties discovery query MUST be implemented by an ebXML Registry implementing this profile. It allows the discovery of all of the Symmetric Properties of a given classification node. The canonical query corresponding to this discovery query is presented in Section 7.3.20.

6.20.1 Parameter $className

This parameter's value SHALL specify a string containing a pattern to match against the name attribute value of ClassificationNodes.

6.20.2 Example of SymmetricProperties Discovery Query

The following example illustrates how to find all the symmetric properties of a given classification node having a name containing “AirReservationServices” .

<rim:Value>urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindSymmetricProperties</rim:Value>

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

6.21 FunctionalProperties Discovery Query

The FunctionalProperties discovery query MUST be implemented by an ebXML Registry implementing this profile. It allows the discovery of all of the Functional Properties of a given classification node. The canonical query corresponding to this discovery query is presented in Section 7.3.21.

6.21.1 Parameter $className

This parameter's value SHALL specify a string containing a pattern to match against the name attribute value of ClassificationNodes.

6.21.2 Example of FunctionalProperties Discovery Query

The following example illustrates how to find all the functional properties of a given classification node having a name containing “AirReservationServices” .

<rim:Value>urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindFunctionalProperties</rim:Value>

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

6.22 InverseFunctionalProperties Discovery Query

The InverseFunctionalProperties discovery query MUST be implemented by an ebXML Registry implementing this profile. It allows the discovery of all of the Inverse Functional Properties of a given classification node. The canonical query corresponding to this discovery query is presented in Section 7.3.22.

6.22.1 Parameter $className

This parameter's value SHALL specify a string containing a pattern to match against the name attribute value of ClassificationNodes.

6.22.2 Example of InverseFunctionalProperties Discovery Query

The following example illustrates how to find all the inverse functional properties of a given classification node having a name containing “AirReservationServices” .

<rim:Value>urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindInverseFunctionalProperties</rim:Value>

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

6.23 Instances Discovery Query

When an intersection definition is used to create a complex class (a new ClassificationNode) in RIM as described in Section 4.6, it becomes possible to infer that the objects (instances) classified by all of the classes (ClassificationNodes) specified in the Intersection definition, are also classified by this complex class.

The Instances discovery query MUST be implemented by an ebXML Registry implementing this profile. It allows the discovery of all of the direct instances of a given classification node and if it is a complex class which is an intersection two classes, it also allows to retrieve the intersection of the instances of both of the classes involved in the intersection definition. The canonical query corresponding to this discovery query is presented in Section 7.3.23.

6.23.1 Parameter $className

This parameter's value SHALL specify a string containing a pattern to match against the name attribute value of ClassificationNodes.

6.23.2 Example of Instances Discovery Query

Consider the “AirReservationServices” definition presented in Section 4.6. The following example illustrates how to find all the direct instances of the “AirReservationServices” and also the instances classified by both “AirServices” and also the “ReservationServices”.

<rim:Value>urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindInstances</rim:Value>

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

7 Canonical Metadata Definitions

7.1 ObjectType Extensions

The following new extensions to the canonical ObjectType ClassificationScheme are described by this profile:

<rim:ClassificationNode parent="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExtrinsicObject" lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:ObjectType:RegistryObject:ExtrinsicObject:OWL" code="OWL" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:ObjectType:RegistryObject:ExtrinsicObject:OWL">

7.2 AssociationType Extensions

The following new extensions to the AssociationType ClassificationScheme are described by this profile:

<rim:ClassificationNode parent="urn:oasis:names:tc:ebxml-regrep:classificationScheme:AssociationType" lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL" code="OWL" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL">

<rim:ClassificationNode parent="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL" lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:ObjectProperty" code="ObjectProperty" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:ObjectProperty">

<rim:ClassificationNode parent="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL" lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:HasProperty" code="Property" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:HasProperty">

<rim:ClassificationNode parent="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL" lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:SubPropertyOf" code="SubPropertyOf" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:SubPropertyOf">

<rim:ClassificationNode parent="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL" lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:SubClassOf" code="SubClassOf" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:SubClassOf">

<rim:ClassificationNode parent="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL " lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:IntersectionOf" code="IntersectionOf" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:IntersectionOf">

<rim:ClassificationNode parent="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL" lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:SameAs" code="SameAs" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:SameAs">

<rim:ClassificationNode parent="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL " lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:Restriction" code="restriction" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:Restriction">

<rim:ClassificationNode parent="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL " lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:DifferentFrom" code="DifferentFrom" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:DifferentFrom">

<rim:ClassificationNode parent="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL " lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:DatatypeProperty" code="DatatypeProperty" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:DatatypeProperty">

<rim:ClassificationNode parent="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL " lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:TransitiveProperty" code="TransitiveProperty" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:TransitiveProperty">

<rim:ClassificationNode parent="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL " lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:InverseOf" code="InverseOf" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:InverseOf">

<rim:ClassificationNode parent="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL " lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:SymmetricProperty" code="SymmetricProperty" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:SymmetricProperty">

<rim:ClassificationNode parent="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL " lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:FunctionalProperty" code="FunctionalProperty" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:FunctionalProperty">

<rim:ClassificationNode parent=”urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL " lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:InverseFunctionalProperty" code="InverseFunctionalProperty" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:InverseFunctionalProperty">

<rim:ClassificationNode parent=”urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL " lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:SeeAlso" code="SeeAlso" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:SeeAlso">

7.3 Canonical Queries

The following new canonical queries are described by this profile. Note that while these queries are complex, the complexity is hidden from clients by exposing only the query parameters to them.

7.3.1 All SuperProperties Discovery Query

Recursion is not supported by SQL-92, for this reason the stored procedure for this query coded in SQL 99 Standard is available from:

7.3.2 Immediate SuperClass Discovery Query

<rim:AdhocQuery lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindImmediateSuperClasses" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindImmediateSuperClasses">

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

WHERE A.associationType LIKE ''urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:SubClassOf'' AND

7.3.3 Immediate SubClass Discovery Query

<rim:AdhocQuery lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindImmediateSubClasses" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindImmediateSubClasses">

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

WHERE A.associationType LIKE ''urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:SubClassOf'' AND

7.3.4 All SuperClasses Discovery Query

Recursion is not supported by SQL-92, for this reason the stored procedure for this query coded in SQL 99 Standard is available from:

7.3.5 All SubClasses Discovery Query

Recursion is not supported by SQL-92, for this reason the stored procedure for this query coded in SQL 99 Standard is available from:

7.3.6 EquivalentClasses Discovery Query

<rim:AdhocQuery lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindEquivalentClasses" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindEquivalentClasses">

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

WHERE A.associationType LIKE ''urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:EquivalentTo'' AND

Adhoc Query retrieving all the equivalent classes of a given classification node

7.3.7 EquivalentProperties Discovery Query

<rim:AdhocQuery lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindEquivalentProperties" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindEquivalentProperties">

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

WHERE A1.associationType LIKE ''urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:EquivalentTo'' AND

Adhoc Query retrieving all the equivalent Association Type of a given Association Type

7.3.8 SameExtrinsicObjects Discovery Query

<rim:AdhocQuery lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindTheSameExtrinsicObjects" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindTheSameExtrinsicObjects">

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

WHERE A.associationType LIKE ''urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:SameAs'' AND

Adhoc Query retrieving all the "ExtrinsicObjects" defined to be the same with a given ExtrinsicObject

7.3.9 DifferentExtrinsicObjects Discovery Query

<rim:AdhocQuery lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindDifferentExtrinsicObjects" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindDifferentExtrinsicObjects">

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

WHERE A.associationType LIKE ''urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:DifferentFrom'' AND

Adhoc Query retrieving all the "ExtrinsicObjects" defined to be different from a given ExtrinsicObject

7.3.10 AllDifferentRegistryObject Discovery Query

<rim:AdhocQuery lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindAllDifferent" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindAllDifferent">

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

FROM RegistryObject RO2, Association A1, Association A2, Name_ N, RegistryObject RO,

WHERE A1.associationType LIKE ''urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:HasMember'' AND

A2.associationType LIKE ''urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:HasMember'' AND

Adhoc Query retrieving all the "RegistryObjects" defined to be different from a given RegistryObject through a “allDifferent” construct

7.3.11 ObjectProperties Discovery Query

<rim:AdhocQuery lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindObjectProperties" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindObjectProperties">

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

WHERE A.associationType LIKE ''urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:ObjectProperty'' AND

Adhoc Query retrieving all the object properties of a given classification node

7.3.12 ImmediateInheritedObjectProperties Discovery Query

<rim:AdhocQuery lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindImmediateInheritedObjectProperties" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindImmediateInheritedObjectProperties">

<rim:LocalizedString value="label.FindImmediateInheritedObjectProperties.desc"/>

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

FROM Association A, Name_ N, ClassificationNode C1, ClassificationNode C2, Association A2

WHERE A.associationType LIKE ''urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:SubClassOf'' AND

A2.associationType LIKE ''urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:ObjectProperty'' AND

Adhoc Query retrieving all of the properties of a given classification node including the ones inherited from its immediate super classes

7.3.13 AllInheritedObjectProperties Discovery Query

Recursion is not supported by SQL-92, for this reason the stored procedure for this query coded in SQL 99 Standard is available from:

7.3.14 DatatypeProperties Discovery Query

<rim:AdhocQuery lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindDatatypeProperties" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindDatatypeProperties">

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

WHERE A.associationType LIKE ''urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:DatatypeProperty'' AND

Adhoc Query retrieving all the datatype properties of a given classification node

7.3.15 AllInheritedDatatypeProperties Discovery Query

Recursion is not supported by SQL-92, for this reason the stored procedure for this query coded in SQL 99 Standard is available from:

7.3.16 TransitiveRelationships Discovery Query

<rim:AdhocQuery lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindTransitiveRelationships" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindTransitiveRelationships">

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

FROM ClassificationNode C, Association A1, Association A2, Name_ N1, Name_ N2, Name_ N3

WHERE A1.associationType LIKE ''urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:TransitiveProperty'' AND

A2.associationType LIKE ''urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:TransitiveProperty'' AND

WHERE A1.associationType LIKE ''urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:TransitiveProperty'' AND

Adhoc Query retrieving the objects in transitive relationship with a given object

7.3.17 TargetObjects Discovery Query

<rim:AdhocQuery lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindTargetObjects" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindTargetObjects">

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

FROM ClassificationNode C2, Association A, Name_ N, Name_ N2, ClassificationNode C1

Adhoc Query retrieving the Target Objects from the Registry, given a Source Object and an Association

7.3.18 TargetObjectsInverseOf Discovery Query

<rim:AdhocQuery lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindTOinverseOf" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindTOinverseOf">

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

FROM ClassificationNode C2, Association A1, Association A2, Association A3, Name_ N, Name_ N2, ClassificationNode C1

WHERE A2.associationType LIKE ''urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:InverseOf'' AND

Adhoc query retrieving the Source Objects of an Association which is in "inverseOf" relationship to this Association

7.3.19 InverseRanges Discovery Query

<rim:AdhocQuery lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindInverseRanges" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindInverseRanges">

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

FROM Association A, Name_ N, Name_ N2, ClassificationNode C1, ClassificationNode C2

FROM ClassificationNode C2, Association A1, Association A2, Association A3, Name_ N, NAME_ N2, ClassificationNode C1

WHERE A2.associationType LIKE ''urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:InverseOf'' AND

7.3.20 SymmetricProperties Discovery Query

<rim:AdhocQuery lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindSymmetricProperties" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindSymmetricProperties">

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

WHERE A.associationType LIKE ''urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:SymmetricProperty'' AND

Adhoc Query retrieving all the Symmetric properties of a given classification node

7.3.21 FunctionalProperties Discovery Query

<rim:AdhocQuery lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindFunctionalProperties" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindFunctionalProperties">

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

WHERE A.associationType LIKE ''urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:FunctionalProperty'' AND

Adhoc Query retrieving all the Functional properties of a given classification node

7.3.22 InverseFunctionalProperties Discovery Query

<rim:AdhocQuery lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindInverseFunctionalProperties" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindInverseFunctionalProperties">

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

WHERE A.associationType LIKE ''urn:oasis:names:tc:ebxml-regrep:profile:webontology:AssociationType:OWL:InverseFunctionalProperty'' AND

Adhoc Query retrieving all the Inverse Functional properties of a given classification node

7.3.23 Instances Discovery Query Discovery Query

<rim:AdhocQuery lid="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindInstances" id="urn:oasis:names:tc:ebxml-regrep:profile:webontology:query:FindInstances">

<rim:QueryExpression queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92">

S1.name_ LIKE ''urn:oasis:names:tc:ebxml- regrep:profile:webontology:slot:intersectionOf ''

8 OWL Profile References

8.1 Normative References

Bechhofer, S., Harmelen, F., Hendler, J., Horrocks, I., McGuinness, D. L., Patel-Schneider, P. F., Stein, L. A., OWL Web Ontology Language Reference, W3C Recommendation 10 February 2004

[Brickley, Guha] Brickley, D., Guha, R.V., RDF Vocabulary Description Language 1.0: RDF Schema

[ebRR-DPT] Deployment Profile Template For ebXML Registry 3.0 OASIS Specifications V_0.1.2

[ebMS-DPT] Deployment Profile Template For OASIS Specification ebXML Message Service 2.0

[McGuinness, Harmelen] McGuinness, D. L., Harmelen, F., OWL Web Ontology Language Overview,

[SQL 92] SQL ISO/IEC 9075:1992 Information technology - Database languages - SQL.

[SQL 99] ISO/IEC 9075:1999(E) Information technology - Database languages – SQL.

8.2 Informative References

[Dogac, et. al. 2005] Dogac A., Kabak Y., Laleci G. C. Mattocks, F. Najmi, J. Pollock

Distributed and Parallel Databases Journal, Springer-Verlag, Vol. 18, No. 1, July 2005, pp. 9-36.

[Dogac et. al. 2006] Dogac A., Laleci G., Kabak Y., Unal S., Beale T., Heard S., Elkin P., Najmi F., Mattocks C., Webber D., Kernberg M.

Exploiting ebXML Registry Semantic Constructs for Handling Archetype Metadata in Healthcare Informatics

International Journal of Metadata, Semantics and Ontologies, Volume 1, No. 1, 2006.

[IMPL] ebXML Registry 3.0 Implementations
freebXML Registry: A royalty free, open source ebXML Registry Implementation
http://ebxmlrr.sourceforge.net

Berners-Lee, T., Hendler, J., Lassila, O., "The Semantic Web", Scientific American, May 2001.

Name	Affiliation
Farrukh Najmi	Sun Micro Systems
Carl Mattocks	MetLife
Jeff Pollock	Network Inference
Evan Wallace	NIST
Dave RR Webber	Individual
Nikola Stojanovic	GS1 US
Ivan Bedini	France Telecom
Yildiray Kabak	-
Gokce Banu Laleci	-