- From: Jacek Kopecky <jacek.kopecky@deri.org>
- Date: Mon, 13 Mar 2006 15:43:22 +0100
- To: David Martin <martin@AI.SRI.COM>
- Cc: public-sws-ig@w3c.org
David, I agree mostly with what Steve Battle already wrote, but anyway I think I have a few things to add. Sorry about the delay. On Mon, 2006-02-27 at 15:59 -0800, David Martin wrote: > > Here is an important question about the proposed "Semantic Annotations > for WSDL" working group, about which I'd love to see some discussion. > > The current draft charter is here: > http://www.w3.org/2005/10/sa-ws-charter.html > > Question: > Does the envisioned approach provide a foundation that will be > useful in working with, or evolving to, a more comprehensive > framework, or simply a detour that will ultimately fall out of use > (if Web service semantics become important)? Chronologically, when working with semantic web services, a tool or automatic agent needs to consider only the semantic descriptions, and only for actual invocation it may need to see a WSDL document (via what we call grounding). Annotations in WSDL are kinda backward. However, that's a top-down view. Bottom-up, we already have WSDL, so let's think what we can automate*. A CTO of a big company gave a presentation at DERI and said that they do have lots of services, and any discovery is done by humans. If we have useful annotations in WSDL, we can do this incremental step and automate discovery (or at least help the human with useful suggestions). Going this way (bottom-up), we will end up with a different, probably more complicated and spaghetti-esque result, but it seems that this is a viable way forward, as opposed to trying to do the right thing right away. If the interwoven bunch of standards becomes unwieldy in 10 years, we will know what we have achieved and we will be able to do a top-down, nice, simple and internally consistent specification to replace the spaghetti. I kinda suspect that CORBA is such a top-down replacement for the preceding RPC and object RPC systems, and in this regard CORBA is a success story. (Note that I'm not comparing WS and CORBA here, it's just an analogous standardization situation.) So I think that SA-WSDL, while possibly eventually replaced, will be a very useful next step. *I assume the goal of SWS is to automate the use of WS. > What's behind this question is the observation that, from a > WSDL-centric perspective, the semantic artifacts referenced by a WSDL > spec will be disconnected. That is, from the point of view of a WSDL > tool, they won't exist in the same declarative scope. (Indeed, in this > approach there is *no* notion of declarative scope for the semantic > artifacts, from the WSDL perspective.) > > One way to illustrate this concern is simply by observing that > preconditions and effects associated with services will frequently > have variables in common. To have a coherent representational scheme, > it is of fundamental importance to spell out the relationship between > variable X mentioned in a precondition and variable X mentioned in an > effect expression. From the perspective of a WSDL tool, there won't > be any basis for establishing or working with such a relationship. So > the concern here is that a WSDL tool ultimately won't be able to do much > with the semantic declarations that are referenced. While I agree with Steve that the variables should be correlated using their URIs, I can also see that they might be correlated using scoping in the document into which the semantic annotations point. However, note that SA-WSDL WG charter explicitly drops precondition and effect (P&E) from the scope, so the question of correlation doesn't even come up. I don't think dropping P&Es harms the usefulness of SA-WSDL, as the P&Es can be fully described in whatever the operation modelReference points to. So modelReference on an operation will tell us, in whatever underlying formalism, anything about the operation, including its process interface. > > Of course, the semantic framework underlying those declarations may > provide the basis that ties the semantic declarations together, and a > WSDL tool could build in some understanding about one or more of the > semantic frameworks that may be used in connection with WSDL. But the > point is that it's not a WSDL tool anymore - it's a WSDL tool plus a > {UML or OWL-S or WSMO or SWSF or METEOR-S or ODESWS or ...} tool. And > as far as I can tell, there won't be any meaningful connection between > the two tools. The concern is that the proposed approach does not > appear to provide any path by which such a meaningful connection might > eventually be achieved. While WSDL tools can do little with that extension, I can't quite see how you would imagine a WSDL tool to make coffee, if somebody comes up with coffee-making extension. In order to handle a particular extension, you have to extend the processor (and usually processors are extensible with plugins), and I'm not sure a coffee-making-extension plugin turns a WSDL tool into a coffee-making tool. The benefit of putting the annotations in WSDL, even if a generic WSDL tool cannot handle them, is that industry already knows how to store and find their WSDLs so we can give them SWS in small, palatable steps. Hope it helps, Jacek
Received on Monday, 13 March 2006 14:43:47 UTC