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

Re: why distinguish between simple and complex types? (issue 11)

From: Laurent Henocque <laurent.henocque@gmail.com>
Date: Tue, 06 Jun 2006 22:19:45 +0200
Message-ID: <4485E361.3070302@gmail.com>
To: Jacek Kopecky <jacek.kopecky@deri.org>
CC: Rama Akkiraju <akkiraju@us.ibm.com>, SAWSDL public list <public-ws-semann@w3.org>

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



Jacek Kopecky wrote:
> Laurent,
> 
> I wonder why you disagree with 
> 
>  <element name="fullName" type="xsd:string" 
>     sawsdl:modelReference="ontology#FullName ontology#FirstName ontology#LastName"/>
> 
> (Note that XML disallows multiple instances of an attribute with the
> same name, instead multiple modelReferences can be a URI list like
> above.)

ok, but we can have
<element name="fullName" type="xsd:string">
     <sawsdl:modelReference="ontology#FullName">
     <sawsdl:modelReference="ontology#FirstName">
     <sawsdl:modelReference="ontology#LastName">
</element>
can't we? (just to make sure :-))

I dislike this because I understand FullName as an aggregate of FirstName and LastName, and I believe that holding the
knowledge of this fact is precisely the purpose of the ontology. So it's like we're mixin two layers. Going from a full
name to a first name is a 'data extraction'. I think the work of deciding that a partial mapping can be achieved must be
left to reasoning mechanisms.

However, I strongly support multiple references, and I would'nt like to be overzealous here.

> 
> It seems that you have in mind some kind of specification of what
> modelReference actually means, related to your request about
> schemaMapping being a bijection.

Yes, I tend to think that an element is an instantiation for its modelReference(s). From a software engineering
standpoint, I would feel very comfortable for explaining what semantic annotations are if I could say:

"if you annotate element E with concept C, you mean that this E is a kind of C" (as we are used to for inheritance for
example)

I cannot say "a 'fullName' is an 'ontology#FirstName'" nor the opposite.

If we are to keep this possibility, I vote for making it explicit, so that searching tools are not mislead.

> 
> I always viewed modelReference as something relatively vague, like "this
> schema or wsdl component describes a thing that is also described by the
> model reference", which in case of composite values could also mean that
> the model reference describes a part of (or a bigger thing than) the
> schema or wsdl component.
I think the group must formulate a very precise statement about what it means to 'semantically annotate', because I do
not agree with your point. If you remove 'semantically', ok, but here, no.
> 
> For example, on WSDL operation level, one model reference could describe
> the precondition, other could describe the effect; and similarly on a
> composite simpleType (like the fullName above) one model reference could
> describe the last name part and other could describe the first name
> part.

I'd rather use one model reference to describe an 'aggregation of' the first name and last name. If a string is
structured, why would we lose this structure in the semantics? This seems counterproductive, don't you think?

Laurent

> 
> We may have another issue here, on which many of the current issues
> would be dependent.
> 
> Hope it makes sense,
> 
> Jacek
> 
> 
> On Tue, 2006-06-06 at 14:56 +0200, Laurent Henocque wrote:
> I am also convinced that any complex data can be serialized in a string (names, dates, or more) and hence the
> distinction between "simple" and "complex" has no semantical grounds but simply amounts to syntax.
> 
> I would also like to comment on your earlier suggestions (I am sorry a large number of issues seem to interact)
> 
> * references to "partial matches"
> 
> Going back to your several emails, I have the feeling that there may exist a confusion between references/mappings and
> mediators. In my opinion, when annotating a WS, you should not have to list all possible mediations that exist from the
> "main" designated reference to any other "related" type, even if as you said, this might be inserted automatically. To
> support this, I would raise the dangerous issue that the introduction of a mediation from "Date" to "someType" would
> suppose to update all the SAWSDLs that have Dates inside...
> 
> So I fully disagree with this:
> 
>>>> <element name="fullName" type=xsd:string
>>>> sawsdl:modelReference="ontology#FullName"
>>>> sawsdl:modelReference="ontology#FirstName"
>>>> sawsdl:modelReference="ontology#LastName"/>
> and would solely expect this:
> 
>>>> <element name="fullName" type=xsd:string
>>>> sawsdl:modelReference="ontology#FullName"/>
> But, this raises a very interesting issue (Jacek I sent a separate email for this):
> When annotating an element: do we need to enforce the condition that there exists a one to one between the element type
> space and the set of ontology instances?
> If negative: what happens when a mapping raises an error? Do we have to provide hooks for error handlers in the
> specification?
> 
> (the example above illustrates this: it is not possible to convert from a first fame to a full name)
> 
> * Lifting and lowering mappings
> 
> I think that we want semantics because we want to deal with discovery and mediation issues at an abstract, ontological
> level. Henceforth, when attaching a modelReference to a WSDL element, my view would be that what is potentially needed
> for invocation are both:
> * lifting mappings : they take plain data and convert them to instances in the corresponding ontology. My understanding
> is that at our level, we cannot make a single guess as to what this target ontology might look like. So a mapping can
> solely ny a URI.
> * lowering mappings : (again a URI) that take an ontology instance an convert it to data at the WSDL level.
> 
> ('lifting', 'lowering' and 'mediation' belong to the DIP project's terminology)
> 
> Having this allows WS to interact via the logical system during invocation or composition by sequences: lifting /
> mediation / lowering. Note that this intuition is the main argument for attaching mappings to the references they
> "implement". However, the statement of mappings (to and from type/reference) could be made globally in the
> specification, since this information is shared across all occurences of the "type".
> 
> * Discovery
> 
> Thinking about discovery: how a WS having a partially matching type can be discovered is beyond the scope of the SAWSDL
> WG, since it amounts to reasoning. In fact, if one is looking for a "lastName", a query to her favorite reasoner should
> come out with a ranking of matching ontologies sorted by relevance. Then a query to the WS repository would return  the
> targets, accordingly sorted.
> 
> Laurent
> 
> 
> 
> Rama Akkiraju wrote:
>>>> Well, may be we don't need to distinguish simple and complex types after
>>>> all. I sent that previous note too soon. :-). Here is a counter example
>>>> where a simple type may also need a schema mapping (not necessarily for
>>>> discovery but to support invocation)
>>>>
>>>>
>>>> <element name="fullName" type=xsd:string />
>>>>
>>>> Say that in the ontology, there is a class called 'FullName' with two
>>>> subparts 'FirstName' and 'LastName'. Then this simple type can be annotated
>>>> in mulitple ways.
>>>>
>>>> <element name="fullName" type=xsd:string
>>>> sawsdl:modelReference="ontology#FullName" />
>>>>
>>>> or
>>>>
>>>> <element name="fullName" type=xsd:string
>>>> sawsdl:modelReference="ontology#FullName"
>>>> sawsdl:modelReference="ontology#FirstName"
>>>> sawsdl:modelReference="ontology#LastName"/>
>>>>
>>>> Both these above options are useful in discovery but may not be useful in
>>>> invocation if the service interface to be matched with has elements
>>>> 'firstName' and 'lastName')
>>>>
>>>> or
>>>>
>>>> <element name="fullName" type=xsd:string
>>>> sawsdl:modelReference="ontology#FullName"
>>>> sawsdl:modelReference="ontology#FirstName"
>>>> sawsdl:modelReference="ontology#LastName"
>>>> sawsdl:schemaMapping="URI#FullNameTokenizationLogicToMapToFirstNameAndLastName"/>
>>>>
>>>> This one has all the modelReferences that could aid in discovery and also
>>>> has a string tokenization transformation function that provides explicit
>>>> mappings to first name and last name.
>>>>
>>>> Regards
>>>> Rama Akkiraju
>>>>
>>>> Rama Akkiraju/Watson/IBM wrote on 06/05/2006 05:59:03 PM:
>>>>
>>>>> Kunal,
>>>>>
>>>>> Were you referring to precedence issues on these two examples?
>>>>> because if so, these examples don't really present such issue. In
>>>>> example 1, complex type annotaton doesn't really say anything about
>>>>> what annotations apply to leaf node elements. So, there is no conflict.
>>>>>
>>>>> I think when you mention conflicts you are talking about in the
>>>>> context where a schema mapping is specified at a complex type in
>>>>> addition to model references on the contained elements. If so, if I
>>>>> understand you correctly you are making two independent points in
>>>>> this e-mail. Is that correct?
>>>>>
>>>>> So, here is a summary of  why we need to distinguish between simple
>>>>> and complex types based on all the discussions.
>>>>>
>>>>> a simple type can only have model references and no schema mappings
>>>>> where as a complex type can have both model references and schema
>>>>> mappings. These schema mappings specified at a complex type can have
>>>>> an implication on the model references of simple types contained in
>>>>> a complex type. That's why we need to differentiate simple and complex
>>>> types.
>>>>> Regards
>>>>> Rama Akkiraju
>>>>>
>>>>> kunal.verma1@gmail.com wrote on 06/05/2006 05:25:13 PM:
>>>>>
>>>>>> Jacek,
>>>>>>
>>>>>> From our point of view, it would be nice to be able to annotate
>>>>>> complexTypes, elements and simpleTypes. Jacek's example illustrates
>>>>>> the first two (note, we changed the outer element to complexType).
>>>>>> The second example illustrates the use of a simpleType.
>>>>>>
>>>>>> Example 1:
>>>>>>
>>>>>> <complexType name="Name" sawsdl:modelReference="ontology#name">
>>>>>>    <sequence>
>>>>>>       <element name="Title" sawsdl:modelReference="ontology#title"/>
>>>>>>       <element name="First"
>>>> sawsdl:modelReference="ontology#firstName"/>
>>>>>>       <element name="Last"
>>>> sawsdl:modelReference="ontology#familyName"/>
>>>>>>    </sequence>
>>>>>> </complexType>
>>>>>>
>>>>>> Example 2:
>>>>>>
>>>>>> <xs:simpleType name="fahrenheitWaterTemp"
>>>>>>    sawsdl:modelReference="ontology#FahrenheitWaterTemperature">
>>>>>>    <xs:restriction base="xs:number">
>>>>>>       <xs:fractionDigits value="2"/>
>>>>>>       <xs:minExclusive value="0.00"/>
>>>>>>       <xs:maxExclusive value="100.00"/>
>>>>>>    </xs:restriction>
>>>>>> </xs:simpleType>
>>>>>>
>>>>>> Finally, allowing annotations for both elements and complexTypes
>>>>>> begs the question of which takes precedence when used together. As
>>>>>> pointed out by Laurent in http://lists.w3.org/Archives/P
>>>>>> ublic/public-ws-semann/2006May/ 0043, the approach of giving the
>>>>>> element annotation precedence over the type annotation seems like
>>>>>> the way to go.
>>>>>>
>>>>>> "If some internal annotation exists for a complex type as well, any
>>>>>> "where used" annotation takes precedence over the internal one."
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> John Miller and Kunal Verma
>>>>>>
>>>>>>
>>>>>> On 6/5/06, Jacek Kopecky <jacek.kopecky@deri.org > wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> below is an excerpt from Rama's analysis of the relation of
>>>>>>> modelReference and schemaMapping. The quoted part restricts
>>>>>>> modelReferences to be allowed only on schema leaf elements.
>>>>>>>
>>>>>>> On Sun, 2006-06-04 at 13:40 -0400, Rama Akkiraju wrote:
>>>>>>>> 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.
>>>>>>> Rama, I wonder why you have the restriction?
>>>>>>>
>>>>>>> Using the common structured name example, one could have something
>>>> like
>>>>>>> this:
>>>>>>>
>>>>>>> <element name="Name" sawsdl:modelReference="ontology#name">
>>>>>>>   <sequence>
>>>>>>>     <element name="Title" sawsdl:modelReference="ontology#title"/>
>>>>>>>     <element name="First"
>>>> sawsdl:modelReference="ontology#firstName"/>
>>>>>>>     <element name="Last"
>>>> sawsdl:modelReference="ontology#familyName"/>
>>>>>>>   </sequence>
>>>>>>> </element>
>>>>>>>
>>>>>>> Basically, there is a trivial one-to-one correspondence between the
>>>>>>> element Name and the ontology class "name". Do you think that
>>>> expressing
>>>>>>> this correspondence with modelReference may be harmful?
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Jacek
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>>
> --
> *************************************************************************
> 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
> ************************************************************************
>>

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

iD8DBQFEheNhIF1tz5h+GDARAv6qAJ9Ui0emmuCDIpMQqHISp+nyCcnZ8wCfQ5rL
Omy/SAH6okXJ/H9aH65fm/w=
=gdA8
-----END PGP SIGNATURE-----
Received on Tuesday, 6 June 2006 20:19:56 UTC

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