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].
ID | Class | Title | Raised By |
---|---|---|---|
none |
ID | Class | Title | Raised By |
---|---|---|---|
none |
ID | Class | Title | Raised By |
---|---|---|---|
none |
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 |
||||
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. |
||||
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) |
||||
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. 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. |
||||
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 SchemaMapping is split into 2 attributes, loweringSchemaMapping and liftingSchemaMapping, for the two directions of transformation we describe only putting schemaMapping attributes on global element declarations, global simple and complex type definitions |
||||
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 |
||||
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 |
||||
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 |
||||
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 |
||||
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. |
||||
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 |
||||
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 |
||||
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 |
||||
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 |
||||
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. |
||||
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 |
||||
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 |
||||
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 |
||||
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. |
||||
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. |
||||
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> |
||||
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 |
||||
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. 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. |
||||
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 |
||||
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. |
||||
28 | Semantically annotating faults | Design | Closed | working group |
Description:
Should we have semantic annotations on faults? |
||||
Resolution:
Yes, similarly to how we annotate operations. |
||||
29 | Editorial comments | Editorial | Closed | John Miller |
Description: [email] | ||||
Resolution:
Accepted comments as editorial, resulting in some clarifications, esp. on faults. |
||||
30 | Clean up XSLT example in usage guide | Editorial | Closed | Rama Akkiraju |
Description: [meeting minutes] | ||||
Resolution:
Editorial changes done. |
||||
31 | Make all usage guide examples available as downloadable files | Editorial | Closed | Rama Akkiraju |
Description: [meeting minutes] | ||||
Resolution:
done |
||||
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. |
||||
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 |
Copyright © 2006 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.