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, 13 Jun 2006 11:27:49 +0200
Message-ID: <448E8515.3020203@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

Hi, below are a few pragmatic moves:
(related to multiple model references and not simple/complex types as the subject suggests)

Jacek Kopecky wrote:
> Laurent, 
> 
> On Tue, 2006-06-06 at 22:19 +0200, Laurent Henocque wrote:
>> 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 :-))
> 
> Sorry to say that this is not really XML. We could possibly turn
> sawsdl:modelReference from an attribute to an element, then it would be
> something like 
> 
> <element name="fullName" type="xsd:string">
>      <sawsdl:modelReference>ontology#FullName</sawsdl:modelReference>
>      <sawsdl:modelReference>ontology#FirstName</sawsdl:modelReference>
>      <sawsdl:modelReference>ontology#LastName</sawsdl:modelReference>
> </element>
> 
> However, there seems to be a problem with XML Schema extensibility that
> would complicate matters. 

is this only complex, or impossible?

I'd say that a single attribute with multiple
> values separated by white space is better, and it would have the same
> expressiveness.

I think that in the context of xml, designed to allow for structuring documents that are easy to parse in the end, it is
awkward to get down to string parsing to tokenize unstructured elements all the time. ?
If we decide to attach mapping information to references as I suggested, your proposed syntax would not suffice. So I
guess that a decision must be taken on that subject beforehand.

> 
>>> 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.
> 
> Well, so far we didn't constrain the semantic models that we point to
> much, and you would say that what's pointed to is, in some way, a class.
> I could imagine using modelReference on interface or operation to point
> to WSML webService construct, which may or may not be viewed as a
> class-like thing, depending on how you look. I fear it could be hard to
> write an unambiguous specification without constraining the models too
> much. But I welcome concrete proposals. 8-)
> 

I understand that we don't know yet the usage that will be made of modelReferences. It may be the case that the feature
becomes massively used for attaching tags, without any further semantic beyond string equality. I am hence accepting to
backtrack from my suggestions.

The presence or absence of a schema mapping attached to a modelReference provides enough information on the
functional/bijective status of the mapping if any.

>>> 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.
> 
> Any concrete suggestions for the WG to consider? 8-)

See above, I backtrack from this. I agree not to emphasize a formal or logical meaning of what annotations are. I agree
that they CAN be semantic, but that they do not HAVE to.

> 
>>> 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?
> 
> Apart from the fact that so far we do not actually define what
> modelReference actually and practically means, do you have a situation
> in mind that would not work if we allowed modelReference to point to all
> those parts?

This may forbid lowering, unless mappings can span across several references as discussed at the end of this email.

> 
> I think I can see a situation where such multiple annotations like
> <element name="fullName" type="xsd:string" 
>   sawsdl:modelReference="ontology#FullName ontology#FirstName ontology#LastName"/>
> would in fact be useful:
> 
> Let's assume something like this: we use a schema that conflates
> fullName in one string, and that we use an ontology that defines only
> firstName and lastName, not fullName. Because both the schema and the
> ontology are shared, we cannot change them to introduce fullName
> concept. We can introduce a new ontology that extends the old one and
> adds fullName that contains both lastName and firstName.
> 
> If we only annotate the string with fullName, there may be applications
> out there that are not aware of our new ontology* and therefore will
> ignore the fullName, yet they might benefit from annotations pointing to
> lastName and firstName separately, with a schemaMapping to help with the
> actual transformation.

How can an application be 'unaware' of a concept accessible via its uri???

Btw, my above comment makes me agree with you: if solely annotations to partial concepts are available, then
biderectional mapping cannot (may not?) be possible. The implementor accepts to pay this price.

I see one benefit of your proposal: it can be useless to populate the 'ontological space' with objects that only
represent aggregates of others. In my opinion, the lack of such aggregate concepts may pose problems to composers (it
certainly currently does), but this is not necessarily impossible to tackle in the end.

The new emerging issue in that context is that an annotation should be able to propose a mapping that combines two or
more concepts into one single aggregate data. If this is the case, my request for attaching mappings to model references
 must be dropped, since a mapping may span across several such references.

Laurent

> 
> (*) I'm not sure if the reasoners are not supposed to be able to learn
> about our new ontology, but there may be trust issues involved.
> 
> Hope this makes sense,
> 
> 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
************************************************************************
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEjoUUIF1tz5h+GDARAsVgAJ9J++IsDFrMWZcNRJnhWcyakgrCEwCfVKt/
2W2mgNQsuRXD61SBijeR2hA=
=uGyg
-----END PGP SIGNATURE-----
Received on Tuesday, 13 June 2006 09:35:09 UTC

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