<scribe> scribe: JoelF, CarlosP, ClaudioV
Jacek: Need to discuss our 12 or 13 issues and try to resolve them. If time, we need to discuss implementations so we can get closer to CR
... May add a review of Telecom Italia work to the agenda
Jacek: Issues 3 and 8 moving schemaMapping to another spec. Also OASIS TC wants the examples moved out of the spec.
Carlos: Saw person using SAWSDL to annotate XML Schema. We should show that this is good.
Amit: Many uses can be made, but need to focus on Web Services.
Carlos: For splitting out schemaMapping.
Jacek: Agree in principle, but that would make two even smaller specs. Instead we should emphasize other uses.
Joel: Could just show that XML is also a use case
Rama: True, that schemaMapping is applicable outside of our main use case, but are needed to be used together. Should keep together.
Jacek: Could address issue by changing the table of contents and perhaps renaming to "Semantic Annotations for WSDL and XML Schema."
... Would have a section for WSDL annotations and one for XML annotations.
Carine: Is not addressing the issue. We are just defining ways of pointing to mapping, not defining the mapping.
Jacek: Can at least emphasize that it applies to Schema.
Carine: should coordinate with XML Schema chair first.
<scribe> ACTION: Jacek to coordinate with XML Schema Working Group whether we may emphasize (even in the title) that we annotate XML Schema. [recorded in http://www.w3.org/2002/ws/sawsdl/minutes/20061113#action01]
Jacek: Emphasizing in TOC should not be a problem. Can reply to issue in this way and be sure he understood what we are doing.
Rama: Agree. This is a good resolution.
Jacek: So this will be resolution.
Rama: So we have annotating WSDL and annotating Schema. WSDL has only modelReference.
Tomas: Will W3C say we can talk more about Schema?
Jacek: Will be addressed by action item.
Tomas: XML people will not be looking at a Web Services spec.
Jacek: That is why I proposed renaming the document.
Carlos: Can XML group add a note to XML schema to point to our spec so XML people can see it.
Claudio: Related to the issue from OASIS that we are not really defining semantics.
Tomas: Can we put future work info in the spec?
Jacek: Can address as part of issue 11.
RESOLUTION: LC issue 3: Change TOC for WSDL annotation and Schema Annotation
Jacek: Issue 8 asks to factor out the examples. But, other W3C specs have examples and people like those more.
Rama: Should keep examples
Joel: agree. Don't need to justify the examples in the text.
Jacek: examples are for readability.
RESOLUTION: LC issue 8: No action. Will reply that examples are not use cases. They are for readability.
Jacek: Will send a single reply for all SEE TC issues.
Jacek: Issue 11, we need to say why we don't provide more than hooks.
Tomas: Maybe we say this is a stage one. First how to attach, second how to define.
Rama: He must not have read Usage Guide. It shows how it is useful.
Joel: We show what can be done using domain ontologies
Jacek: Service model or concrete language are not in scope. I talked to originator. He wants us to say this is not the end. Other
specs will come.
Amit: Proposing a W3C incubator on discovery. So this is just a starter.
Joel: Might not be appropriate for spec.
Amit: Should be working group information, not in spec.
Carlos: Don't open up to more discussion
Rama: Maybe put in examples.
Jacek: Can we put it on Working Group page?
Amit: Agree, and we can point to other work as well.
Jacek: On WG page put what people are working on and justification
<scribe> ACTION: Rama and Amit to send suggestions for group page text (can reuse http://lsdis.cs.uga.edu/projects/meteor-s/SAWSDL/ ) [recorded in http://www.w3.org/2002/ws/sawsdl/minutes/20061113#action02]
Joel: Should not say much in spec that is speculative.
Jacek: Small paragraph ok?
Joel: Yes.
Tomas: WG page should talk about the follow up work.
RESOLUTION: LC issue 11: Address this issue by updating group page by putting SAWSDL in context. Paragraph in beginning of spec saying just beginning and point to WG page. WG page can go further and Usage Guide can include much of the text from WG page.
Jacek: Issue 10, modelReference on service and endpoint. Might want to annotate different services with the same interface. Endpoints are in scope.
Joel: Problem is that we had a clean separation of semantic annotation of interface and WS-Policy assertions on services. This would be breaking it.
Rama: Maybe we can annotate endpoints and bindings and let people use that for what they want.
Jacek: Would not annotate binding. Complex entity, no applicable.
Tomas: we should define what it means on service.
Jacek: We allow on everything, we just only define the purpose for some components.
Carlos: Service annotations would be useful in discovery. Would have to be a refinement.
Jacek: we can only say all apply.
Claudio: I support.
Rama: what would we be annotating
Jacek: Service and endpoint. In WSDL 1.1, service and port.
Joel: Discovery scenario is valid, but that is what WS-PolicyAttachments and WS-Policy assertions are addressing. So, we still have to address the overlap.
Carlos: Need to specify side-effects and other attributes.
Joel: Policy addresses the "how do we use this service" problem - like "needs SSL," "Required PKI" etc.
Jacek: Policy supports alternatives we don't. Many things are not clean, must be discussed with Karthic this afternoon. Issue 10 relies on 12. We'll get back to both later.
Jacek: Issue 6 - including semantic models inside WSDL. Asking for us to support in-line semantic model. We have that, but it is not clear enough. Could clarify the example and discussion. Maybe adding this to the TOC would be helpful - 2.3 Embedding Semantic models.
Joel: Agree
Claudio: Agree.
Proposed RESOLUTION: Move example with additional description to a new section 2.3 Embedding Semantic Models
Carlos: Would be more difficult for parsers to process if we use <sawsdl:models>
Rama: But we cannot enforce. Models can be outside.
Jacek: But we can say that they have to be referred to in the models section. But, we don't have to define what a URI means in the Semantic Web world. So we don't have enforce that the models are available, so we don't need to have the container element. So clarification should be enough for the person who raised the issue.
Tomas: He wanted to replicate the semantics in the WSDL because it is easier to handle in his environment.
Joel: Our current approach does not cause a model to be processed unless it is referenced in a modelReference.
Carlos: Would make it cleaner and maybe avoid future problems.
Jacek: This is a semantic sugar issue. We can have two RDF statements in the WSDL file that says different things about the same resource. But people can give them different URIs. So the conflict problem does not exist unless the user made conflicting concepts.
... Other issue is inefficiencies.
Rama: Can still introduce inefficiencies, even with the models element.
Jacek: We have a scenario where we could have inefficiency. Could put a note in new 2.3 saying we do not introduce a model container to separate models applicable to SAWSDL and those that are not, and solicit implementation input.
RESOLUTION: LC issue 6: Move and expand example with additional description to a new section 2.3 Embedding Semantic Models including note above.
Jacek: Issue 4. example OWL missing classes. Should have editors check and fix.
RESOLUTION: LC issue 4: Editors check and fix.
Jacek: Issue 5. Editorial - explain schemaMapping example.
Rama: He didn't see that you don't need all three technologies. We should explain when we need SPARQL.
Jacek: Am working on paper on this. Can provide some text.
Joel: Editors can provide some explanation on the choice of technologies but we need Jacek to provide some guidance text.
<scribe> ACTION: Jacek to provide text on why we need to combine SPARQL with the other technologies in one direction and not the other. [recorded in http://www.w3.org/2002/ws/sawsdl/minutes/20061113#action03]
Jacek: Issue will be kept open until the new explanation is in place and the action is done.
Jacek: Issue 7. List of AnyURI is not an XML way of doing a list. He means change modelRefernce to an element and have it be repeated.
... We discussed that earlier. List is well know, supported way of doing what we need. Element would complicate the spec.
... Proposal - no change and respond that the method we use is well understood.
Rama: Element approach could help address performance issues. Have examples that might provide use cases. Keep open until this afternoon.
Jacek: How to annotate external XSDs using our ontologies?
... do we want it?
Ajith: Annotations are added as extension attributes to XSDs
... what if we don't own the XSD file, we can't modify it?
... This problem typically happen when several parties want to annotate the same XSD with their own ontologies.
Rama: valid scenario
Ajith: workaround 1 -> copy the schema and annotate the copy
... problem with keeping the schemas synchronized.
Joel: There are other reasons for adding external annotations
... is it in the scope of the WG?
Jacek: Annotating external schemas in the WSDL seems to be in the scope
... In some cases we can create a XS type restricting the original and annotate and use this one
... The original schema could evolve and we would be out of sync.
Rama: We can't avoid this
Joel: we can do multiple annotations
... What if someone wants to add some further annotations which are not agreed upon?
... There are two situations:
... 1-> Annotate something that does not have annotations and we don't have access to this XSD.
... 2-> Schema reuse by two different parties which are giving different annotations.
... 2nd situation can be taken as diff XSDs
Jacek: Seems like the use cases are based on some disagreement on the semantic model
... There is an existing solution in XSD by annotating types and not elements
Rama: This does not provide a solution for annotating the elements *within* complex types
Jacek: You can still do this by copying the schema (parts of it)
... It might be recommendable to copy the schema (mainly a workaround but still...)
... Objections on not having external annotations?
Carlos: This workaround is somehow going to lead to "dirty" workarounds that can lead to problems in the future
Claudio: This is very likely to happen in the real world
Jacek: If we have 2 wsdls where one imports another one, do we want to have external annotations in this case as well?
Rama: The same argument would apply
Tomas: Would there be a problem if there are other annotations?
Jacek: It would not override, it would add
Ajith: by annotating a schema you do not want to change the structure.
Jacek: If we want to add external annotations do we want to restrict ourselves to XSD or all
Rama, Carlos, Claudio: all
Jacek: we should not allow overriding annotations for this would break compatibility
... We need a concrete example on how external annotations would be done.
... Do we want to be able to add external annotations?
Rama: What do we mean by "external annotations"?
... Why is this any different?
Jacek: We have done it internally in the XSD and we cannot modify the external schema
Rama: 2 scenarios: a) we can modify the external file; b) we can't do that
... The scenario we are interested in is b)
Jacek: We need someone to give us some concrete proposal for doing this
Issue postponed until we have a concrete proposal to deal with external annotations for XSD and WSDL
Joel: This would necessitate another LC
Jacek: but this would probably happen also with services
... Would mean 3 weeks or a month more
... To be done by the end of November
Jacek: WS-P has support for alternatives which would lead to SAWSDL having alternatives which we do not support
Karthik: annotating transactions?
... Say we have multiple modelRefs to the same operation.
... Depending on what you send one ref or the other is relevant/applies
Joel: seems like you're trying to annotate the operation on the service and not on the interface
Karthik: I want to control which modelRef applies. Some sort of context
... Could be done on the basis of assertions: "if X then modelRef1 and modelRef3 apply"
Joel: is there an assertion language that supports this?
Karthik: WS-Policy
Jacek: we could use attExtensions inside a WS-Policy to cater for this
... This would not be encouraged nor necessary for being an implementation
Rama: policies can be applied anywhere and they can be external
Joel: this all seems to be applied to operations
... seems very close to preconditions and effects...
Jacek: we are here talking about having different preconditions and effects depending on different policies
Joel: we need an assertion language for semantic annotations
... do we really want to do this?
Rama: 2 points: a) we want to have diff annotations to the same schema
... b) when we have them, these might apply in different context/situations
Joel, Ajith: these are actually 2 diff situations
Ajith: e.g. PurchaseOrder for a memoryStick would not have the same security requirements as purchaseOrder for a big transaction
Jacek: there are actually 2 ways to see it: the security level could drive what you can do, or what you can do can drive the security...
Rama: the actual question is why are we revisiting the relationship with WS-Policy?
... Seems to be related to the efficiency solution
... Was already raised and dropped
Jacek: why and how were vague. Now we have a how, although the why is still vague
Rama: Karthik is providing a valid use case
... why do we jump directly to WS-Policy and we do not think about creating the modelRef element so that we can add a scope to it
Jacek: the question is: do we want to be able to say that diff modelRefs apply at different situations?
Joel: i.e. why is this still not good enough?
Rama: if we have concrete examples, they could be added to the usage guide without modifying the actual spec.
Karthik: trying to see how to add policy attachments at the modelRef level?
Jacek: if we do not have concrete proposals for issues 12,13 we will close them with no action and go into CR and then it will be harder to include this
--- Coffee Break ---
Joel: can we tie annotations to the diff parts of the schema that apply on the diff cases?
... would that work?
Jacek: that would do it without having to use WS-Policy
Rama: postpone until we have some tangible proposal?
... couldn't we add WS-Policy as part of the modelRef?
... we could use the URI for pointing to the something that defines the context in some way...
Karthik: this is important when it comes to implementation
Jacek: should not really matter -> its just an URI whatever this has
PROPOSAL: Close issue 12 by rephrasing from "putting SAWSDL inside WS-P" to "using WS-P as part of the modelRef" and rule out of scope for the spec (no action)
Rama: why is this out of scope?
... We could add this in the Usage guide
Jacek: we can take it out from the LC issues list and move it to the old issues list as the Usage Guide was not in LC
Karthik: different users will use this way of doing things differently which would affect interoperability...
Rama: we can't standardize every single thing...
RESOLUTION: LC Issue 12 is rephrased to "using WS-P as part of the modelRef" and closed as out of scope for the spec (no action), this issue will be opened for the Usage Guide in the main issues list
Jacek: there is a contention between us and WS-Policy
... Seems that the problem is that different services with the same interface could have different annotations?
Carlos: basically SEE TC is looking for a placeholder for services WSMO capabilities
... during the meeting I pointed out that there is a fundamental diff between a WSDL service and WSMO Services
... i.e. a WSMO Service is not necessarily a WSDL Service (the latter is implementation specific).
Tomas: SEE is looking for additional placeholders for capabilities which do not apply uniquely to the interface
Joel: what is a capability?
... Looks like that doesn't belong to service
Rama: independently from this, that does not clarify whether we want to annotate services or not
Jacek: we could clarify this with the SEE TC and then check whether we get some more issues or not
Joel: I think we should not and we should leave this to how implementations are handled in W3C i.e. WS-Pol
Rama: annotating at the service level could be useful for discovery
Jacek: extending interfaces (WSDL 2.0) could be useful
... and instead of annotating the service, they should annotate an extension of the WSDL interface the WSDL service implements
... and therefore we would not need to add this to the current spec
... shall we say that "we annotate XSD and interfaces in WSDL and we claim that no additional annotations are required for automating the tasks we want to support"?
Rama: who knows what will be required?
Jacek: they can use WS-Policy
... annotations on the interface can be used for preconditions and effects by putting a special order in the operations.
Carlos: we should reply to the SEE TC
RESOLUTION: LC Issue 10: we won't annotate services, it's not necessary for what we need
<scribe> ACTION: Carlos to reply to SEE TC that WSMO capability should be on WSDL interface, therefore we wouldn't do service annotations, and see if they agree [recorded in http://www.w3.org/2002/ws/sawsdl/minutes/20061113#action04]
RESOLUTION: LC Issue 7: stick to list of anyURI
Carlos: Main concern -> lack of information, SEE TC was expecting more
... but this is out of the scope of the WG
Joel: this stuff is very dependent on the semantic framework that is used
Jacek: our modelRefs can point to anything that can define the behavioural parts.
... How can we prevent readers from understanding "behavioral aspects" as Web Service Choreography?
Joel: what about "operational characteristics"?
Jacek: we might tell the SEE TC that we do not mean W3C WS Choreography.
... Therefore we decline to act on this
... Official reply: we do not intend to limit behavioral characteristics to Web Service Choreography since the readers would confuse it with the W3C Web Service Choregraphy, and the whole sentence that mentions behavioral characteristics is open to anything else anyway
... Mention that this could also include preconditions and effects.
RESOLUTION: LC Issue 9: we dont want to change it for it would be more confusing for our readers
<scribe> ACTION: Carlos to respond to issue LC 9 to SEE TC as well [recorded in http://www.w3.org/2002/ws/sawsdl/minutes/20061113#action05]
RESOLUTION: LC issue 14: handle this in the Usage Guide
Rama: people to send examples on preconditions and effects for other languages (WSML)
Jacek: Rama's email with the issue includes a solution for this...
... Basically it says that any relations of this kind should be in the semantic model
... email at http://lists.w3.org/Archives/Public/public-ws-semann/2006Nov/0001.html
RESOLUTION: LC issue 15: Adopt Rama's proposal (see email) -> No action
Rama: the point was that being something external, it looks like we could just gather them together and call this modelRef or smthg
Jacek: these are conceptually diff things, enough to be defined in distinct extensions
RESOLUTION: LC issue 16: model reference and schema mapping URIs point to different things, need to keep them distinct
<scribe> ACTION: Rama to formulate a reply to self on LC issues 14, 15 and 16 and seek agreement from original commentators [recorded in http://www.w3.org/2002/ws/sawsdl/minutes/20061113#action06]
Jacek: agenda: demos, implementation discussions, requirements and future works
Jacek: minutes from 2006/10/24 at http://www.w3.org/2002/ws/sawsdl/minutes/20061024
... minutes from 2006/10/31 at http://www.w3.org/2002/ws/sawsdl/minutes/20061031
RESOLUTION: minutes approved
Doug: shows LSDIS Eclipse based tools to create SAWSDL and publish on a UDDI registry
... It doesn't support schema mapping yet, there's SA-WSDL are published on a standard UDDI storing semantic info about the service in category bag it is then possible to browse UDDI registry to providing results along with matching scores
Amit: would like to ask the group what has to be done on the tool to make it usable by industry
RAMA: An eclipse based tool to perform semiautomatic matching between ws interfaces,
... you can download at http://www.alphaworks.ibm.com/tech/wssem but you have to run it upon WID 6.0 (BPEL engine)
Marin: We used WSMO4J extending it to build some SAWSDL api on top,
... The work leverage on wsmostudio http://www.wsmostudio.org we developed a SAWSDL editor open source under LGPL
... demo available at http://www.ontotext.com/wsmostudio/demo/sawsdl.htm
Carlos: leveraging on WSMO, the EU project SUPER is providing BPEL extensions to support semantic driven runtime compositions
Jacek: wrap up demos outcomes and think about implementation CR
... main intended uses of SAWSDL: discovery composition and matching
... identify main components needed: SWSDL api, single service matching, finer grained matching, discovery/composition, invocation, GUI, publishing tools, grounding specs
Thomas: we would like to ground some WSMO concept (choreography, pre post condition) to WSDL by means of SAWSDL
Jacek: lets identify main goals to be achieved using SAWSDL in terms of implementations: publishing, discovery, service composition, GUI to annotate, specs grounding WSDL tools
... see if the actual implementations LSDIS, IBM, ONTOTEXT, WSMX, IRS-III are addressing the goals try to fill a table...
... check if early implementations address the main functional elements to use SAWSDL in real world
Carlos: probably WSMX used in SUPER performs specs grounding adding annotation to WSDL used in a BPEL process and/or BPEL process itself
Jacek: annotating BPEL techniques would not be recommended could be a not proper way to use the spec
... further check if some implementation for invocation purposes uses lift/low schema mapping
... we cannot demonstrate integration among implementations so far
... every functional element of SAWSDL implementation (discovery, inv..) would require a specific spec but doesnt apply to specification grounding issue (this is up to implementers)
Joel: discussion's becoming confusing, we need to split the discussion what's to be done to push industrial adoption and what's to be done from W3C point of view to have consistent (proof of concept) implementation
Amith: would like to see W3C tackling pre post condition problem e.g. grounding OWL-S by means of SAWSDL in a structured way because this count for industry
Jacek: grounding OWL OWL-S WSMO it is interesting for W3C let's reason on the best way to tackle (incubator group?)
| task \ party | LSDIS | IBM | Ontotext | WSMX | IRS-III | Sum |
|---|---|---|---|---|---|---|
| SAWSDL API | Woden* | on top of WSMO API | 2 | |||
| single/service matching | 1 | 1 | 2 | |||
| finer-grained matching | 1 | 1 | ||||
| discovery/composition | 1 | 1 | ||||
| invocation | 1 | 1 | 1 | 3 | ||
| authoring GUI | 1 | 1 | 1 | 3 | ||
| publishing tool | 1 | 1 | ||||
| formal specs | 1 | 1 | 2 |
Table legend: task rows indicate what the implementations do, party columns say (informally) who's doing it; sum column shows how many distinct implementations we may expect.
Single-service-matching is finding a single service that matches a user goal, discovery/composition can also compose existing services in case a single service is not found. Finer-grained matching is for data, for example a tool that takes SAWSDL annotations (and other considerations) and creates an initial data mapping for two different schemas, which can then be tweaked by the user (as presented by Rama).
(*) The SAWSDL API on top of Woden will probably have contributors from LSDIS, WSMX, IRS-III, and others.
<scribe> ACTION: JacekK to summarize the implementations table into formalized CR criteria [recorded in http://www.w3.org/2002/ws/sawsdl/minutes/20061113#action07]
Rama: still need to clarify if we'll have precondition effects in example document
EricP: there's probably some conflict with other W3C group work but let's see text and evaluate
Jacek: timeline sept 06 last w draft; dec 06 CR; end of jan 2007 PR; march 2007 R
... we probably do not need further F2F meeting
... would consider putting J. Miller in bad standing as he has been mostly absent lately, I will start negotiations with him
... not useful to discuss here about future W3C group (incubator or WG) tackling spec grounding problem by means of SAWSDL, please bring up precise interests
... end of the meeting