Re: Some items for discussion (Issue 8: Conflict Resolution Rules)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

There are several interleaving issues here. Yes, this is related with the schema mapping discussion, and yes, this is
connected to issue 11. As Rama points, knowing the "concepts" of elements of some data structure does not provide means
to properly match data. Thinking about usual programming, we need both the type, and a unique name, for function
parameters.

Here are a number of "atomic" intuitions, rather abruptly presented...

- - the claim that a type implements (or "belongs to") a concept must be backed by a mapping.
- - the concept membership claim needs not be repeated each time a service uses the type, and can hence be internally
attached to the type definition (at toplevel).
- - because the same type can be attached to different concepts in a changing ontology world, I suggest that we bind the
model/mapping pair together in a structure, when the annotation is performed at toplevel of a complex type
- - however the same complex type can be used for different concepts, even in a single wsdl file, so there is a need for
"external" annotation as well
- - equally, if a type is to be used as a concept instance which is not documented in the type definition, then the user
may "externally" claim membership to the concept, and support this claim by a mapping too.
- - in case a type must be externally annotated (yet from within a wsdl spec), the mapping that backs the claim might be
declared only once (probably in the "context":see below), using a triple <type, concept,mapping>
- - we may not consider that attaching concepts to WSDL elements can be performed in isolation. I would rather support the
idea that when annotating a web service, we do this by picking concepts that belong to one or several ontological
"scopes", and that this is done globally. Of course a "scope" is well defined by the leading part of all concept URIs.
- - according to what precedes, I would suppose that when annotating some WSDL, I might start by declaring an annotation
"context" (basically a number, or a unique name for the global annotation, for internal use alone), itself declaring one
or several ontological "scopes" (and maybe several <T,C,M> triples).
- - then, each annotation would be a quadruple:
<(reference to context, reference to scope, concept, mapping>. (mapping is optional if globally declared)
This allows for freely attaching as many semantic annotations to a wsdl file as required. (The "context" is local to the
wsdl file. Again, the scope and concept can obviously be grouped together in a URI).
- - at leaf level in a complex type, a simple uninterpreted data like a string may be mapped to a complex concept
(consider a date for instance). Hence at leaf level, we may need to support concept membership claims with mappings or
transformations as well. This can be used probably solely for documentation purposes (hence discovery/composition) since:
- - leaf annotation alone tells us little or nothing about the concept attached to the complex type as a whole. To believe
the contrary, one supposes that there exists a possibility to infer the global concept from the elementary ones, which
is obviously irrealistic (the development of new concepts from existing base elements will ruin this possibility).
- - hence a type that has no global annotation should be considered as NON annotated.
- - rule 1 is irrelevant: if a concept is attached to a complex type, then the mapping MUST agree with the (optional)
concepts attached to leaf elements that occur in the same context (i.e. belong to the "same" annotation). However, the
mapping does not care about the leaf annotations: so from an operational standpoint, rule 1 is true...
- - in rule 2 the first sentence is true.
- - in rule 2 the first part of the second sentence is true.
- - in rule 2 I think that the second part of the second sentence ("or ws:schemaMapping has to be used to specify ...") is
wrong: a mapping is a transformation process that cannot be used to "specify", even though I agree it achieves this
implicitly.
- - question: could a mapping be made available as a URI to a program that DOES the mapping: in which case, a mapping for
a complex type could never serve as a "specification".
- - I do not understand well rule 3. Maybe a concrete example would help. I guess it means that mapping can be recursive.
I am tempted to think that this is overoptimistic. In many cases certainly, the mapping to a concept of a complex type
containing sub-complex types will break the original (data) structure.
- - most probably the so called "rules" are not "rules", and there is no need to prioritize them.

Just my "two cents",
Laurent

Rama Akkiraju wrote:
> Joel,
> 
> 
> public-ws-semann-request@w3.org wrote on 05/11/2006 04:12:01 PM:
> 
>> Rama,
>>
>> I agree that we should add rigor and clarity to the resolution rules. If
>> you have some possible suggestions, please send them along.
> 
> One possible suggestion - which I have already made,  is to design things
> in such a way that conflicts don't arise at all. Let me explain below.
> 
>> I don't think we can eliminate the need for these rules since there are
> valid reasons for
>> putting annotations at both levels.
> 
> May be we can eliminate the need for these rules after all if we don't
> provide multiple ways of annotating the complex type. For example in the
> current spec under the heading 'Annotating Complex types' we say that the
> reason why leaf level annotations are not enough is because this approach
> assumes one-to-one correspondence between the schema elements and the
> concepts in the domain model and that may not be the case if we want to
> support one-to-many and many-to-one mappings. If we think about this,
> One-to-many can be supported as is because we are going to support adding
> multiple annotations to the same element via list. With regards to
> many-to-one mappings, we introduced this primarily to support XSLT type of
> mappings where we can say 'first name' and 'last name' elements in this
> WSDL concatenated together matches 'name' concept in that domain model. But
> in Issue 6 'Clarification of SchemaMapping concept', I raised this point
> that we probably should only focus on schema mapping in SAWSDL - not data
> mapping. If that is the case, then, many-to-one mappings can be dealt with
> via leaf annotations. Because if we don't care about how the data values
> get mapped then in the first name and last name example, at SAWSDL level,
> both 'first name' and 'last name' will have 'name' concept as the semantic
> annotation. This should work fine if we really mean these annotations to be
> annotations at semantic level but not at data level.  If we go with this
> approach, we would essentially be not making any distinction between simple
> types and complex types in the spec  - which I believe is also the point
> Laurent raised in his issue # 11. Then the conflict resolution rules can be
> avoided altogether because there would not be any conflicts.
> 
> 
>> I am unaware of a way to enforce the
>> rules.  The schema will not help here and we don't have much else at our
>> disposal.
>>
>>> Item: Conflict Resolution Rules (at the bottom of the section 2 in the
>>> spec):
>>> At the bottom of the section 2, we specify a bunch of rules to resolve
>>> conflicts. Is there a way to formalize these rules or enforce them via
>> the
>>> spec? Or may be we should think about designing things in such a way
> that
>>> conflicts don’t arise at all.
>> Regards,
>> Joel
> 
> 
> 
> 
> Regards
> Rama Akkiraju

- --
*************************************************************************
Laurent Henocque
Maître de Conférences Hdr
tel: +33 6 83 88 20 01
Enseignant à l'Ecole Supérieure d'Ingénieurs de Luminy - Marseille
    http://www.esil.univ-mrs.fr
Chercheur au Laboratoire des Sciences de l'Information et des Systèmes - Marseille
    http://www.lsis.org

clé publique open pgp / open pgp public key :
http://www.esil.univ-mrs.fr/~henocque/0x987E183.pub.asc
************************************************************************
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEZEr8IF1tz5h+GDARAs+xAJ9Jr+Why22EfP32bVjqfRNH6FcDswCdFUhz
Hxmt+Gnb1uYXviJZfMBd+nY=
=HPpB
-----END PGP SIGNATURE-----

Received on Friday, 12 May 2006 08:44:26 UTC