Issues List of Semantic Annotations for WSDL

This is the issues list for the documents of the Semantic Annotations for WSDL Working Group, now mainly the SAWSDL Usage Guide document.

See also the LC issues list for the 20060928 Last Call SAWSDL issues and the CR issues list for the 20070126 Candidate Recommendation SAWSDL issues, and the last call issues list for the 20070410 Last Call working draft.

Comments on these issues should be sent to [email protected].

Summary of Active Issues

ID Class Title Raised By
none

Summary of Resolved but not (fully) Implemented Issues

ID Class Title Raised By
none

List of Postponed Issues

ID Class Title Raised By
none

Detailed Issue List

ID Title Class Status Raised By
1 type of modelReference attribute? Design Closed Jacek Kopecky
Description:
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.
[email]
Resolution:

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

[meeting minutes]

2 embedding semantic descriptions? Design Closed Jacek Kopecky
Description:
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:
[email]
Resolution:

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]

3 Identifying type of model Design Closed Joel Farrell
Description:
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:
[email]
Resolution:

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

[meeting minutes]

4 externally defined semantic annotations Design Closed Rama Akkiraju
Description:
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.
[email] and [email]
Resolution:

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.

5 Multiplicity of modelReference value Design Closed Jacek Kopecky
Description:
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.
[email]
Resolution:

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

[meeting minutes]

6 Clarification of SchemaMapping concept Design Closed Rama Akkiraju
Description:
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?
[email]
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.
[email]
Resolution:

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]

7 Combining multiple modelReferences and schemaMappings Design Closed Rama Akkiraju
Description:
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.
[email]
Resolution:

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

[meeting minutes]

8 Conflict Resolution Rules Design Closed Rama Akkiraju
Description:
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.
[email]
see also the thread [email]
Resolution:

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]

9 Introductory full example Editorial Closed Rama Akkiraju
Description:
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.
[email]
Resolution:

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

[meeting minutes]

10 modelReference vs. category Design Closed Holger Lausen
Description:
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?
[email]
Resolution:

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

[meeting minutes]

11 why distinguish between basic and complex types? Design Closed Laurent Henocque
Description:
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.
[email]
Resolution:

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]

12 WSDL 1.1 extensibility? Design Closed Harald Meyer
Description:
In WSDL 1.1 port types are extensions of  
"tExtensibleAttributesDocumented". Hence, it is not possible to add  
service categories to them.
[email]
Resolution:

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

[meeting minutes]

13 adding sawsdl:modelLocation? Design Closed Holger Lausen
Description:
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.
[email]
Resolution:

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

[meeting minutes]

14 schemaMapping languages in appendix? Editorial Closed Holger Lausen
Description:
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)
[email]
Resolution:

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

[meeting minutes]

15 category name of type xs:NCName Design Closed Jacek Kopecky
Description:
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.
[email]
Resolution:

make type of category name an xs:string

[meeting minutes]

16 should mappings be bijections? Design Closed Laurent Henocque
Description:
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?
[email]
Resolution:

Closed with no action - withdrawn.

[meeting minutes]

17 Do we need annotationContext? Design Closed Laurent Henocque
Description: (spun off from issue 5)
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>
[email]
Resolution:

Closed with no action

[meeting minutes]

18 Relation of multiple modelReferences Design Closed Jacek Kopecky
Description: (spun off from issue 5)

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

Resolution:

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

[meeting minutes]

19 Interoperation between SAWSDL and UDDI Design Closed Pierre Châtel
Description:

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

[email]
Resolution:

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]

20 Using UDDI taxonomies as examples for interface categorization? Editorial Closed Pierre Châtel
Description:
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) !
[email]
Resolution:

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

[meeting minutes]

21 modelReference as element instead of attribute Design Closed Laurent Henocque
Description:
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.
[email]
Resolution:

Closed with no action for lack of justification.

[meeting minutes]

22 revisit section on WSDL 1.1 mapping Design Closed Jacek Kopecky
Description:

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

[meeting minutes]
Resolution:

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

[meeting minutes]

23 relationship of interface annotations in face of interface extension Design Closed Jacek Kopecky
Description:

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

[meeting minutes]
Resolution:

model references from extended interfaces also apply on extending interface

[meeting minutes]

24 efficiency of resolving the type of model Design Closed Laurent Henocque
Description:

efficiency of resolving the type of model being referenced

[meeting minutes]
Resolution:

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.

25 schemaMapping section should have motivatory text Editorial Closed Rama Akkiraju
Description:

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

[meeting minutes]
Resolution:

Added to specification.

[meeting minutes]

26 Clarification of documentation on Categorization information on WSDL interfaces Design Closed Rama Akkiraju
Description:
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.
[email]
Resolution:

Add categorization text for operation with no inheritance or propagation rules

[meeting minutes]

27 need to add WSDL 2 {property} syntax Editorial Closed Jacek Kopecky
Description:
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.
[email]
Resolution:

Added by the editors.

[meeting minutes]

28 Semantically annotating faults Design Closed working group
Description:

Should we have semantic annotations on faults?

[meeting minutes]

Resolution:

Yes, similarly to how we annotate operations.

[meeting minutes]

29 Editorial comments Editorial Closed John Miller
Description: [email]
Resolution:

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

[meeting minutes]

30 Clean up XSLT example in usage guide Editorial Closed Rama Akkiraju
Description: [meeting minutes]
Resolution:

Editorial changes done.

[meeting minutes]

31 Make all usage guide examples available as downloadable files Editorial Closed Rama Akkiraju
Description: [meeting minutes]
Resolution:

done

[meeting minutes]

32 Using WS-Policy as part of the semantic model Editorial Closed Karthik Gomadam
Description: (moved from LC issue 12)

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

Resolution:

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

[meeting minutes]

33 Examples for associating Preconditions and Effects with Web Services Design Closed Rama Akkiraju
Description: (moved from LC issue 14)
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)
[email]
Resolution:

added Usage Guide section 3.7 about operation conditions

[meeting minutes]

Table Legend

ID
Issue number
Title
Short title/name of the issue
Class
Design or Editorial
Status
One of: Active, Resolved (not yet implemented), Closed, Postponed
Raised by
Person who raised the issue
Description
Description of issue, possibly including link to origin of issue
Resolution
Short description of resolution, possibly including link to a more elaborate description
Maintained by Jacek Kopecky
$Date: 2007/08/22 17:03:02 $