W3C home > Mailing lists > Public > public-ws-semann@w3.org > June 2006

Re: schemaMapping issues breakdown (issue 6)

From: Rama Akkiraju <akkiraju@us.ibm.com>
Date: Mon, 5 Jun 2006 17:46:22 -0400
To: Jacek Kopecky <jacek.kopecky@deri.org>
Cc: SAWSDL public list <public-ws-semann@w3.org>
Message-ID: <OF414E0940.53B2DD83-ON85257184.00764233-85257184.00779AA0@us.ibm.com>

Jack,

Yes. I mostly agreed with what you said and provided examples and
background context. There is one point of clarification in the conclusion.
Where you characterized the issue as:

> > > 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".)


Here I felt that we need to provide schema-level mapping to support
data-level transformations. So, it's not really that we need to decide
whether we want one or the other. We just need to support one to enable the
other. This got me thinking what you were really trying to say perhaps was
to make the distinction between discovery and interface mapping. That's why
I provided that additional context to refine the conclusion.

The approach is very close to WSDL-S as is actually. The main distinction
is to call out explicitly what function modelReferences at each level
(simple types and complex types) are meant to serve so that the conflicts
can be avoided by separating out their name domains. In addition, hopefully
it adds some more clarity on how to interpret model references in
many-to-one and one-to-many cases (in the latter case using multiple
modelReferences).


Regards
Rama Akkiraju



Jacek Kopecky <jacek.kopecky@deri.org> wrote on 06/05/2006 01:47:43 PM:

> Rama,
>
> thanks for your very detailed analysis. If I'm reading it right, you
> almost agree with the results of my analysis, only you discuss the whole
> picture, not only schema mapping.
>
> I believe your discoveryModelReference is basically modelReference as we
> have it, and your interfaceMappingModelReference is basically
> schemaMapping as we have it. Maybe it's just that I'm used to them, but
> I think our current names are actually preferable as they are simpler
> and the intended use (discovery, interface mapping) should be explained
> in the text. So I think we could take parts of your email and use them
> to explain our modelReference and schemaMapping annotations, and we
> might be able to close issue 6.
>
> In your analysis you basically provide a use case for multiple
> modelReferences - this may help us resolve issue 5.
>
> On the other hand, you also assume that modelReference would not be
> allowed on complex types, which is the gist of issue 11. I will send
> another email in a separate thread to discuss this.
>
> In any case, your proposal will be on tomorrow's agenda.
>
> Thanks again,
>
> Jacek
>
> On Sun, 2006-06-04 at 13:40 -0400, Rama Akkiraju wrote:
> > 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 Monday, 5 June 2006 21:46:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:58:45 UTC