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