Re: schemaMapping issues breakdown (issue 6)

Jack,

Let me present a slightly different way of looking at schema mapping issue.
The way I think of it is that we need schema-level mappings to support
data-level transformations. Although the end goal of service invocation is
to achieve data transformation, it is not practical to specify these
transformations on every XML document instance and ontology instance.
Therefore, we have to provide these mappings at schema-level to support
data-level transformations.

Given this perspective, below I analyzed the schema mapping issue slightly
differently. Here are my thoughts on this issue and a concrete proposal.
I'm sorry it's a bit long but I hope this e-mail provides useful context on
the schema mapping issue for SAWSDL for readers who aren't that familiar
with it before.

I think we all are agreeing that from the point of view of semantic
annotation support we need to distinguish two stages in Web service
matching:

 (1) Service Discovery:  A stage where rough service functionality matching
is performed. To achieve this, typically tools would look for semantically
similar services to come up with a good consideration set. At this stage,
tools may not need to care so much about detailed interface mappings but
may only care about determining if a given service is in the same ball park
of what one is looking for - as in talking the same language and terms and
in general some good chunk of the # of inputs and outputs are related
semantically.

(2) Service Interface mapping: A stage where detailed interface mappings
have to be inferred inorder to generate the code to enable service
invocation. I differentiate between service invocation and service
interface mapping. Invocation is a runtime activity. We are not necessarily
concerned with providing support for how to invoke a service. That's what
bindings and other details in WSDL are for. What we are really talking
about is to provide semantic annotations in WSDL such that service
interfaces can be mapped better so that automation tools can generate the
code required to enable invocation. So, I prefer to stay away from using
service invocation when we talk about semantic annotation support and stick
with interface mapping.

Below, I examine these two scenarios in more detail using the four cases of
semantic associations that may occur between an XML schema and an ontology
that we would have to consider:  (a) one-to-one (b) one-to-many (c)
many-to-one (d) many-to-many

Before I go on,  for the purposes of SAWSDL annotations, let me define some
terms that I will use below in the discussion.

Definition of Simple modelReference:
ModelReferences that point to a single concept in the ontology via
one-to-one association. Simple modelReferences are specified at the level
of individual (leaf) elements in an XSD.

Definition of Complex modelReference:
ModelReferences that point to: (a) either complex expressions (written in
some language) that specify some kind of complex transformation between one
or more XML schema elements and one or more ontological concepts or (b)
some process that encodes the transformation in some form (a BPEL process
(abstract or executable), or code written in some programming language
(Java, C, C++ etc)). Complex modelReferences can be specified either at the
level of individual leaf elements in an XSD or at the level of a container
(such as a complex type) that contains many individual leaf elements or
other containers.


Semantic Annotations for Service Discovery
----------------------------------------------------------------
Objective:
To provide mechanisms to encode semantic annotations in WSDL documents such
that automation tools performing service discovery can use these
annotations to find better service matches during discovery.

Hypothesis:
To provide 'preliminary semantic annotation support' to achieve better
service discovery, simple modelReferences between XSD elements and
ontological concepts may be enough. Transformations could be an overkill
for this. So, from SAWSDL point-of-view simple modelReferences may be
enough for this.  [Please note that this is not to say that all
implementations of service discovery have to rely on these simple
modelReferences alone. Some tools may choose to implement detailed
interface mapping as part of service discovery to achieve more precise
service matches - in which case, they would like interface mapping
information as well]. That's why, I qualify the hypothesis with
'preliminary annotation support' for service discovery.]

Let us see if this hypothesis holds good for four cases: (a) one-to-one (b)
one-to-many (c) many-to-one (d) many-to-many

Case a) one-to-one:
This is simple. Just use 'modelReference' on the element to point to the
concept in the ontology.

Case b) one-to-many:
A contrived example but nevertheless could happen.

Say that an ontology <http://xyz.com/ontologies/nameontology.owl> says:
'Person hasProperty Title'
'Person hasProperty FirstName'
'Person hasProperty MiddleName'
'Person hasProperty LastName'

Say that a WSDL has an input element 'fullName', then we could annotate
this 'fullName' concept with multiple simple modelReferences
'nameontology#Title', 'nameontology#FirstName', 'nameontology#MiddleName',
'nameontology#LastName', This is so because if we are matching a WSDL with
an element 'fullName' and another WSDL with an element 'MiddleName' there
is some relationship between these two terms even if they are  not exactly
the same.

The purpose of doing this is that during matching, this 'fullName' concept
could be considered a loosely related to any of the concepts 'Title',
'FirstName', 'MiddleName' and 'LastName'.

Case c) many-to-one
Reverse the example in case b). So, now the ontology has only one concept
'FullName' and the WSDL has multiple elements: 'Title', 'FirstName',
'MiddleName', and 'LastName'. So, each of the WSDL elements can now have a
single simple modelReference and all of them point to
'nameontology#FullName'.

Case d) many-to-many
many-to-many mappings can be considered as many one-to-many or many
many-to-one mappings . Therefore, for each concept, there could be multiple
modelReferences.

Summary:
To help achieve better service matches during service discovery we need to
support a mechanism to provide  ontology concept references for all
elements in a WSDL/XSD. This will help in achieving rough service
functionality matching without spending too much effort in deciphering
detailed transformations and mappings. So, from SAWSDL point-of-view this
means providing semantic support via simple modelReferences on individual
elements of an XSD is sufficient for this.

Semantic Annotations for Interface Mapping
-----------------------------------------------------------------

Objective:
To provide mechanisms to encode semantic annotations in WSDL documents such
that automation tools generating code to achieve service invocation can use
these annotations to achieve better mapping of service interfaces.

Hypothesis:
To provide semantic annotation support to achieve detailed service
discovery and/or better interface mapping (with the ultimate goal of
achieving service invocation) simple modelReferences on individual elements
in XSD is NOT enough. Schema-level mappings have to be specified in order
to achieve data-level transformations. This requires complex
modelReferences (see the definition of complex modelReferences above).

Let's take the same four scenarios to see whether this hypothesis holds
good.

Case a) one-to-one
A simple association will do. So, simple modelReferences on individual
elements will work.

Case b) one-to-many
Example 1: To address the case of  'fullName' element in WSDL/XSD mapping
to multiple concepts in the ontology (title, first name, last name, middle
name etc) we may have to use some sort of 'split' function (in the case of
strings it could be 'substring' function).

Example 2: A WSDL input element has a term 'Force'. The corresponding
ontology has the concepts 'mass' and 'acceleration'.  This example requires
datamapping on 'Force' element in the WSDL to show 'vector product'
operation between 'mass' and 'acceleration' concepts in the ontology.

For supporting one-to-many case,  we need a complex modelReference because
a simple one-to-one association between XSD elements and ontological
concepts does not exist. In the case of example 1, some sort of word
tokenization has to be performed, This is more easily specified in some
mediation code than in a logical expression - which can be specified as a
complex modelReference and it could point to that mediation code. In the
case of example 2, logical expression may suffice and it could also be
represented using complex modelReference.

Case c) many-to-one
Example 1: Again using the 'name' example, if a WSDL has elements 'Title',
'FirstName', 'MiddleName', and 'LastName' some sort of 'join' or
'concatenate' function has to be specified to map these elements to the
ontological concept 'FullName'.

Example 2: A service takes 'mass' and 'acceleration' as inputs but the
ontology it is referencing only has concept 'Force'. The transformation has
to specify a 'vector product' operator between 'mass' and 'acceleration' to
map the value to the value of 'force' concept.

In both these cases, single modelReferences on individual WSDL input and
output elements is not going be helpful. The mappings have to be given at a
higher level that contains these two input elements. These mappings have to
be specified using complex modelReferences (in the first case, it would be
a string 'concatenation' function, in the second case it would be a 'vector
product' operator).

Case d) many-to-many
Again this can be treated as many one-to-many or many many-to-one mappings.
So, the solutions to case b) and case c) apply here as well.

Summary: To provide semantic annotations that could aid in service
interface mapping we need to provide mechanisms that can refer to complex
transformations that may be required between the interface elements of a
service and the concepts in an ontology. So, from SAWSDL point-of-view this
means providing semantic support via complex modelReferences either on
individual elements in the XSD or on the container elements (such as compex
types) of an XSD is required. Simple modelReferences on individual elements
is NOT sufficient.


> The conclusion is that we have to decide whether we want schema-level
> mapping and whether we want data-level mapping, then what directions for
> the mapping(s) we want to handle. (I'd say "no, yes, both".)


Conclusion
--------------------
So, given my statement that schema-level mapping is needed to support
data-level transformations,  I will refine the conclusion you proposed to
keep it at high level (without any reference to schema or data mappings
yet). The options we have are:

1. Support semantic annotations for discovery only
2. Support semanti annotations for interface mapping only (annotations for
discovery can be inferred from tools using the interface mapping
annotations)
      2a. Support semantic annotations in only one direction (XML Schema to
ontology Upcasting)
      2b. Support semantic annotations in both directions (XML Schema ->
Ontology (Upcasting) and Ontology -> XML Schema (downcasting))
3. Support semantic annotations for both discovery and interface mapping


Concrete proposal for SAWSDL
---------------------------------------------------
I think we should support all options. One of the main reasons for my
raising schema mapping as an issue for SAWSDL is that in WSDL-S, we have
specified a bunch of rules for avoiding conflicts between modelReferences
specified at individual (leaf) node elements and the ones that would be
specified at the complex type that contains that leaf node element. These
rules are hard to enforce and could create conflicts if ignored. So, here I
propose a simple solution to avoid this issue and still support annotations
for both discovery and interface mapping.

The main concept of the proposal is to separate the annotations meant for
discovery from those meant for interface mapping. Specifically,

1. Call the simple modelReferences on individual elements (simple types in
XSD) that are meant to support discovery as 'discoveryModelReferences'
2. Call the complex modelReferences that are meant to point to schema-level
mappings for data-level transformations as
'interfaceMappingModelReferences'. As discussed these complex
modelReferences can be specified either on individual elements  or on
container elements.

Let me again illustrate how my proposal would work for all four cases:  (a)
one-to-one (b) one-to-many (c) many-to-one (d) many-to-many and also to see
whether or this proposal helps avoid specifying the conflict resolution
rules.

Case a) one-to-one
Say that an XSD concept has a 'name' element and it is associated with the
concept 'Name' in the ontology. Then, the XSD element 'name' will have a
'discoveryModelReference= 'OntologyNS#Name'. If no
'interfaceMappingModelReference' is given the same concept that is given as
'discoveryModelReference' could be treated as the concept for interface
mapping as well. Since this is one-to-one case, this is a reasonable
assumption.

<xsd:element name="name"  type="string"
sawsdl:discoveryModelReference="NameOntology#Name"/>

Case b) one-to-many
To address the case of  'fullName' element in WSDL/XSD mapping to multiple
concepts in the ontology (title, first name, last name, middle name etc),
the proposal would work as follows.

<xsd:element name="fullName"  type="string"
            <!-- The following discoveryModelReferences are pointing to all
relevant concepts in the ontology that has anything to do with Full Name
-->
            sawsdl:discoveryModelReference="NameOntology#Title"
            sawsdl:discoveryModelReference="NameOntology#FirstName"
            sawsdl:discoveryModelReference="NameOntology#MiddleName"
            sawsdl:discoveryModelReference="NameOntology#LastName"

            <!-- The following interfaceMappingModelReference points to a
complex transformation that is specified in NameSchemaMapping namespace
under the subsection FullNameMapping -->

sawsdl:interfaceMappingModelReference="NameSchemaMapping#FullNameMapping"/>

Note: This example is assuming that we will support multiple
modelReferences on an XSD element. That is a separate issue and I do not
want to discuss that here.

Case c) many-to-one

To address the case where the XSD contains the individual parts of a name
(title, first name, last name, middle name etc) and the ontology contains a
concept 'FullName'. the proposal would work as follows. (Please note that
this is illustrated only conceptually. I have to check whether a
complexType in an XSD is extensible as shown below or not. If not, it is a
matter of implementation detail to figure out where to associate the
annotations)

<!-- The following interfaceMappingModelReference points to a complex
transformation that is specified in NameSchemaMapping namespace under the
subsection NameMapping -->
<complexType name="Name"
sawsdl:interfaceMappingModelReference="NameSchemaMapping#NameMapping">
              <all>

<!-- The following discoveryModelReferences are all pointing to one concept
'FullName' in the ontology because they are sub parts of an ontology. As
discussed for discovery purposes it may be enough to note that all these
elements are related to FullName concept  -->

                <element name="title"  type="string"
sawsdl:discoveryModelReference="NameOntology#FullName"/>
                <element name="firstName"  type="string"
sawsdl:discoveryModelReference="NameOntology#FullName"/>
                <element name="lastName" type="string"
sawsdl:discoveryModelReference="NameOntology#FullName"/>
                <element name="middleName" type="string"
sawsdl:discoveryModelReference="NameOntology#FullName"/>

              </all>
           </complexType>


Case d) many-to-many

Many-to-Many can be addressed using solutions provided for cases (b) and
(c).

Advantages of the proposal
----------------------------------------------
1. It is simple
2. Cleanly separates out the discovery space from interfacemapping space.
So, the tools can decide which annotations they want to look at.
3. No need to specify any prioritization rules to avoid conflicts

Disadvantages of the proposal
----------------------------------------------
1. Too much work on part of the user providing the annotations to
individually annotate each element as well as provide complex
transformations if they would like to provide annotations to support both
discovery and interface mapping.

I would like to address this disadvantage by saying that utility tools can
be written to generate the discovery level annotations from
interfacemapping annotations. This is not hard to do. The key point is to
provide mechanisms such that both simple annotations and complex
transformations are supported. How these get generated is a different
problem.


Regards
Rama Akkiraju


public-ws-semann-request@w3.org wrote on 05/23/2006 11:51:28 AM:

>
> Hi all,
>
> here's an attempt to break down what I think are the separate issues in
> clarifying schemaMapping (issue 6 [1]). This email is written with my
> chair hat off. 8-)
>
> I assume that schemaMapping attribute points to a document that
> specifies a transformation. It seems that there are two orthogonal sets
> of options that we need to consider. Wherever I use RDF below I mean any
> ontological data language (can be RDF, WSML or any such language of
> choice).
>
> 1) The transformation is a) between an XML Schema on one side and an
> ontology on the other side (schema-level mapping) or b) between XML
> document conforming to the XML Schema on one side and RDF data that uses
> some ontology on the other side (data-level, runtime mapping).
>
> I believe option a) above is not useful because the XML Schema in WSDL
> is given and static, the transformation is as static, so the result is
> also static, and therefore it can be saved somewhere and pointed to
> using modelReference, as opposed to requiring the processor to take the
> schema, run the transformation, and arrive at the same result every
> time. Therefore I assume 1b for the formulation and discussion of the
> following aspect:

> 2) The transformation goes a) from XML to RDF, b) from RDF to XML, or
> c) both ways.
>
> Since I dismissed the option 1a above, schemaMapping cannot be used
> easily for discovery, instead it could be used when a service is
> discovered to work with the necessary semantic terms, and then the
> client that has instances of those terms wants to invoke the service so
> it has to transform between its semantic data and the XML that the
> service requires.

> I believe that we need to consider both directions because the service
> both consumes and produces XML messages, so messages for the service
> have to be created from semantic data, and messages from the service
> need to be parsed back into semantic data.
>
> Depending on whether SAWSDL wants to enable invocation or only discovery
> (and composition, which uses similar data), we may keep or drop
> schemaMapping, and if we keep it, we may need to talk about which
> directions of the mapping it should handle.
>
> The conclusion is that we have to decide whether we want schema-level
> mapping and whether we want data-level mapping, then what directions for
> the mapping(s) we want to handle. (I'd say "no, yes, both".)
>
> Hope it makes sense,
>
> Jacek Kopecky
>
> [1] http://www.w3.org/2002/ws/sawsdl/issues/#x6
>
>

Received on Sunday, 4 June 2006 17:41:23 UTC