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

Holger brings up a good point.  We need to think about issues 6 and 11,
while keeping in mind how the current approach led to the rules in issue 8.

The fundamental problem is that a type (simple or complex) may need to be
annotated by multiple concepts in an ontology, as in our example in which a
"person name" field is both a "first name" and a "last name".

I think Rama correctly points out that schema type to Ontology mapping
should be separated from run-time parameter data mapping.  The current spec
attempts to address both with one concept.  The focus of our spec is
establishing a complete annotation of the semantics of the operation inputs
and outputs.  I will focus on that.

One approach is to see if extensions to the modelReference approach can
address the issue.  Rama proposed using multiple URIs as had been proposed
for a different purpose in issue 5.   This might work, but I will point out
a few questions.

-- How do you tell if the URI's point to multiple annotations for this
field, or an alternative concept in another semantic modelling language (as
was discussed in issue 5)?
-- Should the list of references be treated as a conjunction?  Does that
handle all the cases covered by the more general schemaMapping approach or
would we have to introduce operators (I hope we don't have to do that).
-- In his comments, Laurent pointed out , "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."  So, perhaps an annotation on each of the
xsd:element tags that reference the complex type will be needed. But
doesn't that get us back into rules about conflicts between top-level and
leaf-level annotations?

If a variation of the modelReference approach can address these issues, it
would be a great simplification to the spec.

Regards,
Joel
public-ws-semann-request@w3.org wrote on 05/12/2006 09:46:36 AM:

> Hi all,
>
> I agree with the problems those rules introduce, however before going
> deeper into this (issue 8) I would first discuss more on the overall
> concept of schemaMapping (issue 6/11).
>
> Also the at present schemaMapping is mentioned in the spec only for the
> type level is confusing to me (although the sawsdl schema does not
> prohibit it elsewhere).
>
> best
>   Holger
>
>
> Joel Farrell wrote:
> > Rama,
> >
> > I agree that we should add rigor and clarity to the resolution rules.
If
> > you have some possible suggestions, please send them along.  I don't
think
> > we can eliminate the need for these rules since there are valid reasons
for
> > putting annotations at both levels.  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
>
>
> --
> Holger Lausen
>
> Digital Enterprise Research Institute (DERI)
> http://www.deri.org/

>
> Tel:   +43 512 5076464
> Email: holger.lausen@deri.org
>
> [attachment "signature.asc" deleted by Joel Farrell/Cambridge/IBM]

Received on Friday, 12 May 2006 14:53:52 UTC