Issues List of Semantic Annotations for WSDL

In "Bottom Level Annotation..." subsection of 2.2 there's a snippet of
schema that defines modelReference as of type xs:anyURI, yet many
examples give values like rosetta:RequestPurchaseOrder which seem to be
intended as QNames, yet other examples give values like
POOntology#Receiver which seem to be meant to be relative URIs.

Technically, every QName is syntactically a URI, so we cannot have both,
we must decide if the value is URI or if it is QName. I suggest that we
go with URI.

Additionally, we might consider making the attribute type a list of URIs
so that multiple annotations are allowed - one element can be modeled
semantically both in OWL and in a different semantic language, and the
processor could choose what it supports.

modelReference type is anyURI, issue 5 open for multiplicity of modelReference values

[meeting minutes]

Hi, to bring one possibly contentious issue in the open, I suggest that
we consider whether we want to allow embedded semantic descriptions or
whether we want to restrict SAWSDL to just URI references to external
things?

Currently we have modelReference and schemaMapping that contain a URI. 
I see a number of additional options that are not necessarily exclusive:

Adopted option 1 - documenting that semantic models and other data can be embedded as general extensions in the WSDL document and pointed to using ID or other applicable XPointer mechanisms.

[meeting minutes]

The modelReference attribute points to a concept in some semantic model and
SAWSDL is independent of the language used to express that model.  The
question is: Do we need to identify the language as part of the annotation?
In other words, can a tool that is processing the WSDL file determine what
kind of a model (OWL, WSML, ODM...) is at the URI pointed to by the
modelReference?  I can think of three answers:

adopted option 1) to say nothing, leave to the Web (see email)

[meeting minutes]

at the risk of opening up an out-of-scope item for discussion again, I
would like to bring up the issue of support for out-of-band annotation
approach(es) that was discussed earlier on SWS interest group. One can
create and maintain separate files for associating annotations with WSDL
files. This could be an alternate approach to modifying the WSDL to
associate annotations. (eg: X-path expressions could be used in the
out-of-band approach to associate annotations with elements in a WSDL
file). Service registry developers and vendors may find this very useful
because they may want to use these files for keeping other metadata about
WSDL files and this allows them to keep it all in one place. Customers that
already have many WSDLs may also prefer this approach than going back and
modifying all their WSDLs.  This could aid in adoption as well. We could
support this in addition to the approach we are already taking with
extending WSDLs.

Issue out of scope, postponed until the main specification is in CR, then it will be reconsidered.

[meeting minutes]

Spec now contains section 2.4 on external annotations.

Additionally, we might consider making the attribute type a list of URIs
so that multiple annotations are allowed - one element can be modeled
semantically both in OWL and in a different semantic language, and the
processor could choose what it supports.

Support multiple modelReferences as a list of URIs, spin off issues 17 - Do we need annotationContext? and 18 - Relation of multiple modelReferences.

[meeting minutes]

I think we should clarify schemaMapping concept a bit more in the spec. It
is currently a bit confused between data mapping and schema mapping (We
felt that it needed more work even while working on WSDL-S). In SAWSDL we
are concerned with adding semantic annotations for the (abstract)
interfaces of Web services. The purpose of these annotations is to enable
discovery and semantic matching - not invocation. There are many more
things that need to happen before actual invocations can be made even if
semantic similarity is established via discovery and semantic matching. For
example, even if we match UPC and SKU as semantically similar concepts
(because both are unique identifiers for items), a UPC code cant pass off
for an SKU during the invocation (may be the # of digits are different and
may need some transformation function). But we shouldnt confuse this
transformation that needs to take place between two WSDL elements (in this
case UPC element in one WSDL to SKU element in the other WSDL) with the
semantic annotations of elements in WSDL. For instance, the semantic
annotations for UPC and SKU could be <someontology>#UniqueIdentifier.
Therefore, specifying things like concatenating the values of first name
and last name to map to an ontology concept called <someont>#name via
an XSLT transformation is too low level information for semantic
annotations (XSLT is for transforming XML documents rather than schemas). I
think RDF mappings would be more appropriate for representing
schemaMapping. I understand that we dont prescribe the language that users
would like to use for specifying these schema mappings but the examples
that we give in the spec should be consistent with the concepts and
recommended best practices. I think we should revisit the examples for
schema mapping and consider RDF mappings. Thoughts?

From the xml schema the schemaMapping attribute can be attached to
anything (element, complexType, simpleType, ...). It is just that the
spec only talks about the possibility of attaching it to complexType.

schemaMapping describes mapping from instances of the schema to instances of the semantic model

[meeting minutes]

SchemaMapping is split into 2 attributes, loweringSchemaMapping and liftingSchemaMapping, for the two directions of transformation

[meeting minutes]

we describe only putting schemaMapping attributes on global element declarations, global simple and complex type definitions

[meeting minutes]

A complex type currently can have both a modelReference and a
schemaMapping. Also there is an implicit association between the
modelReference and schemaMapping.
...
If we want to support multiple annotations, say
one for OWL and the other for WSML this association would be hard to keep
track of. There are multiple ways to deal with this.
   (a) just add multiple modelReferences and schemaMappings and let the
      tools figure out the associations.
   (b) use whatever mechanism we come up with to identify the type of a
      model, we could use the same here and keep things consistent.

schema mappings are alternatives, model references all apply, we do not specify any other relationship between them

[meeting minutes]

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 dont arise at all.

we describe only putting schemaMapping attributes on global element declarations, global simple and complex type definitions, and if schemaMapping is specified on the element declaration (including empty value ""), it precludes the schemaMapping (if any) on the type of the element, and vice versa, if the element does not specify a schemaMapping, the schemaMapping of its type applies

[meeting minutes]

Why was the example at the beginning taken out? I usually find most specs
very reader unfriendly. An example upfront is a great way to introduce the
ideas. I strongly believe that we should have a full example at the
beginning.

two examples expected, one simple in introduction, one large and complete in appendix

[meeting minutes]

We are about to extend WSDL with pointers to semantic
annotation... Why do we make the distinction between
<modelReference> for operation and <category> for interface?

category annotation moved to modelReference, we will provide non-normative example ontology for capturing URI and code to point to a category

[meeting minutes]

In section 2:

The document currently distinguishes among "simple type" data and "complex
type" data, argueing that only in the former case can the annotation be
mentioned aside of the data.

I think that some complex types may prove sufficiently general to be used in
varied semantical concepts. If you think of a "Point" type for instance
(having an "x" and a "y"), it may be a coordinate in a geographic information
system, or else the location of the upper right corner of a rectangle in a
diagram, etc...

So I think that in some cases, complex type data can be annotated from the
outside, very mutch like simple type data.

Closed, subsumed by other issue resolutions, see especially issues 6 and 8. Distinction between simple and complex types only made to speak about annotations of members of complex type.

[meeting minutes]

In WSDL 1.1 port types are extensions of  
"tExtensibleAttributesDocumented". Hence, it is not possible to add  
service categories to them.

Closed as obsolete because we dropped the XML element <category> in favor of model references

[meeting minutes]

I would suggest to also specify a mechanism similar to xmi:schemaLocation
that gives a hint to the client processor where to resolve the logical URI
used in the references. Such an attribute could be named
sawsdl:modelLocation.

we won't add modelLocation, we will summarize good practices for finding models

[meeting minutes]

the main spec should not (or only in the appendix) include details on the
possible mapping languages, since that would get two complex (and distracts
from the core)

we will have normative generic text about the inputs and outputs of the schema mapping processors

[meeting minutes]

our current schema uses type xs:NCName for category name attribute.
The type NCName exists for XML element and attribute local names, in
particular it must not contain a colon ':'. It doesn't seem that our
category name needs to have this restriction as I don't believe we
intend category names to be XML element local names.

I'd suggest that we should use type xs:string for category names. If a
particular taxonomy does use its category names for XML element or
attribute local names, its category names will be restricted to a subset
of what we allow, which will not be a problem.

make type of category name an xs:string

[meeting minutes]

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?

Closed with no action - withdrawn.

[meeting minutes]

Do we have a use case for adopting annotation contexts?
A simple example of what multiple annotation/multiple
mapping/annotation contexts might look like:

<sawsdl:annotationContext id="sawsdlcxt:lh0.0.a" author="Laurent Henocque" version="0.0.alpha" date="06/05/26">
...
<wsdl:operation name="buyBook" pattern="http://www.w3.org/2006/01/wsdl/in-out">

        <sawsdl:modelReference context="sawsdlcxt:lh0.0.a" ref="http://example.org/ontologies/purchaseorder#Order">
                <sawsdl:schemaMapping="http://example.org/examples/buyBook2Order.xsl">
                <sawsdl:schemaMapping="http://example.org/examples/buyBook2Order.rdf">
        </sawsdl:modelReference>
...
</wsdl:operation>

Closed with no action

[meeting minutes]

What is the relation between multiple modelReferences on a single WSDL component, if any?

all model references apply, but we will not specify any relationship between them

[meeting minutes]

(not from the email) Should the SAWSDL specification say anything about the interoperation/relation between SAWSDL and the UDDI registry?

we will say that if a UDDI taxonomy URI is used to categorize a WSDL interface; it should be consistent with where the WSDL is filed within the UDDI registry; for example, when the WSDL is put into UDDI, the tModel could automatically have that categorization

[meeting minutes]

I noticed that you did not specified any normalized URIs for  
referencing NAICS, UNSPNC or GICS taxonomies.
Wouldn't it be great to use the ones that are specified in 
http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm ?
Like http://www.uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#NAICS  
for NAICS
or http://www.uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#UNSPSC  
for UNSPNC ?

This way i would be able to map the categorization information  
provided by a SAWSDL service definition by directly using the  
standard UDDI taxonomy tModels (just by matching URIs when mapping to  
UDDI) !

Moved UDDI parts to appendix D, adding concrete UDDI-specific URIs.

[meeting minutes]

What we need to however, is to prepare for smooth evolution. I hence
strongly support lifting modelReferences from attributes to elements, as you
corrected me:

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

In so doing, we would smoothly prepare for evolution or extension by extra
attributes, hence allowing to defer choices relevant with the relationship
between modelReferences.

Closed with no action for lack of justification.

[meeting minutes]

revisit section on WSDL 1.1 mapping after the main parts of the spec are done (issue open to serve as reminder)

add WSDL1.1 operation modelReferences via this XML syntax: <operation ... ><sawsdl:attrExtensions sawsdl:modelReference="..."/>...</operation>

[meeting minutes]

what is the relationship of interface annotations in face of WSDL 2 interface extension

model references from extended interfaces also apply on extending interface

[meeting minutes]

efficiency of resolving the type of model being referenced

Issue postponed until the main specification is in LC, then it will be reconsidered.

[meeting minutes]

Issue closed due to absence of concrete issue or suggestion.

The section about schema mappings in our spec should contain some motivatory text that shows the purpose of these annotations.

Added to specification.

[meeting minutes]

First, in the SAWSDL spec, we have currently mentioned that interfaces can
have modelReferences and these modelReferences can be used to specify
categorization information that could be used to categorize a service in a
registry. A WSDL interface can have multiple operations. If we specify
categorization information at a WSDL interface level does that mean that
all the operations under that interface have to be published to the same
category? That would be a reasonable thing to do but that is not explicitly
stated in the spec. We may want to add something to clarify this.

Second, what if someone wants to classify the operations within an
interface under different categories in a registry. That should be possible
with the current mechanisms. Basically, a user would then use the same
'modelReference' mechanism at the level of an operation to specify
categorization information. But in the spec we specifically mention about
adding categorization information only at the interface level but not at
the operation level. We may want to clarify this and add some documentation
that talks about the fact that categorization can be specified at the level
of an operation as well.

Finally, if categorization information is specified both at operation level
and interface level, we have to add precedence rules. I think the
categorization information at the operation level should have higher
precedence.

Add categorization text for operation with no inheritance or propagation rules

[meeting minutes]

I noticed that our spec doesn't
actually add properties to WSDL components, if this requirement from our
charter is to be understood using the formal terms "component" and
"property" from WSDL 2.0.

Added by the editors.

[meeting minutes]

Should we have semantic annotations on faults?

[meeting minutes]

Yes, similarly to how we annotate operations.

[meeting minutes]

Accepted comments as editorial, resulting in some clarifications, esp. on faults.

[meeting minutes]

Editorial changes done.

[meeting minutes]

done

[meeting minutes]

the semantics may be different depending on policy choices on the same endpoint, embedding policy in SAWSDL annotations would enable this, this could be described in the usage guide

No text to be added to the spec or usage guide.

[meeting minutes]

Many people in the audience felt that they would be using SAWSDL
modelReferences for representing preconditions and effects associated with
Web services and that they would find the usage guide incomplete
without at least a brief discussion on preconditions and effects and a few
examples to show how to do it (sort of like how we show examples for
publishing Web services in registries)

added Usage Guide section 3.7 about operation conditions

[meeting minutes]