- From: Bijan Parsia <bparsia@isr.umd.edu>
- Date: Mon, 20 Mar 2006 10:10:44 -0500
- To: Jacek Kopecky <jacek.kopecky@deri.org>
- Cc: Carine Bournez <carine@w3.org>, public-sws-ig@w3.org, "Battle, Steven" <steve.battle@hp.com>
On Mar 20, 2006, at 9:18 AM, Jacek Kopecky wrote: > Hi Bijan, see inline. 8-) > Please note that I'm writing this as my personal opinion, not as the > proposed chair of the SA-WSDL WG. Sure. > On Mon, 2006-03-20 at 08:09 -0500, Bijan Parsia wrote: >> I went back and looked and the Scope section is a bit broken (as >> evidenced by Steve's quote): >> >> """The Semantic Annotations for WSDL Working Group is chartered to >> define one or more properties of WSDL 2.0 components to point to >> additional semantics to concepts represented by those components, e.g. >> interface, operation, endpoint. Additionally, the Working Group may >> define annotations to the schema structure to point to external >> semantics."""" >> >> "point to additional semantics to concepts" just doesn't parse. >> Additional semantics *for* concepts represented? > > Yes, additional semantics of/for concepts represented. Can we have the text corrected? >> I confess to hating the term "external semantics". C'mon. > > "externally described"? Why externally? External to what? Part of the description is *in* the WSDL document (unlike in OWL-S), so I don't see the value of this term if that's *not* what it's going to indicate. In fact, I think that specifying the mechanism as opposed to the matter is not such a great idea. Why constrain the design like this? What is the *actual* scope of the group? >>> I for one see some use cases where embedding the annotations would be >>> useful, and I can see at least two ways of embedding them: put a >>> whole >>> semantic description >> >> I go back to a fight I had in SWSL. What's a *non* semantic >> description? > > Every description expresses some semantics, true, but I believe that > traditionally, when you say "semantic something", it means "semantics > that can, to some degree, be described in a machine-readable form" with > ontologies, axioms etc. That's not very illuminating or constraining. WSDL does that now. Actually, what *can't* be to *SOME* degree described in a machine-readable form? This isn't very concrete, though the charter seems to be written with something very specific in mind. This worries me. >>> document somewhere in the WSDL document (like we >>> put schemas in the <types> section) and then the annotations will >>> point >>> into the document; or put the full annotations themselves on the >>> spot, >>> instead of referring to them. >> >> How are the "semantics" to be realized? Via some sort of statement >> (e.g., axioms in some formalism). So let's say I have a set of concept >> and property names, but no further axiomization. And I want to say of >> some operation that is has at least one P relation to a C. Now since >> there *is* no other axiom, this characterized the terms entirely (thus >> far). May I inline that? It seems like I should be able to. >> Alternatively, I could require that I always coin a name for these >> intermediate expressions (but why?). > > I personally think you should be able to inline this, but WSDL-S > doesn't > do that so we'll have to start by opening an issue in the WG. 8-) er..where does what WSDL-S does or doesn't do have to do with anything. The only mention of WSDL-S is in Related Work. So I don't see that as any kind of constraint whatsoever (given by the charter). That may be the tacit understanding, but tacit understanding and a nickel still only get you 8 minutes of parking time at the meter. >> (Note that originally I interpreted the discussion as requiring *all >> parts* of the annotation to be outside the WSDL document, a la OWL-S. >> There are reasonable reasons for doing this (including supporting >> third >> party and alternative annotations seamlessly. Technically, I guess >> this >> is not ruled out by the current charter since the concrete syntax of >> the component properties could be or be required to be in a separate >> document. > > Apart from the RDF mapping, I don't expect the result to have syntax > that will be separable from the WSDL syntax Why not? > - in WSDL-S you can put > modelReference on an operation, not somewhere outside. Both OWL-S and > WSMO have semantic annotations in their own language, and I don't quite > think that we should try to externalize WSDL-S Again, I see no charter based reason to privilege WSDL-S. > above "WSDL-based > annotations". > >>> While the second option can be seen as out of scope as defined in the >>> charter, at least the first option should be available to us. 8-) >> >> I find the Out of Scope more disturbing: >> >> """discuss expression of Web services constraints and capabilities, >> including precondition and effect.""" >> >> Why? And how can this be at all narrowed? I mean, from the scope, " >> could have different meanings: calculation of tax on a product, >> calculation of income tax, etc. " Aren't these expressions of >> capabilities? (I recognize that constraints and capabilties are a term >> of art standing for "policy", but still.) > > There seems to be little agreement about the modeling of preconditions > and effects, There is little agreement about any of this ;) > in fact there may be insufficient agreement about the terms > themselves - WSMO distinguishes preconditions, postconditions, > assumptions and effects, so the WSDL-S model is restrictive for WSMO. Again with the WSDL-S. If this group is standardizing WSDL-S, it should say so in the charter. If not, these points don't have the force you are giving them. Preconditions and effects have a very standard standard meaning from the planning community, and have been imported into the SWS community. I'm loathe to give up on them, or let them be hijacked. WSMO may have more distinctions, which is fine, but if y'all have corrupted standard terms that's your look out, not a matter of "insufficient agreement". > However, at least in WSMO, one can give a name to the thing that > contains precondition and effect descriptions, and this name can go > into > modelReference on operation, so we don't need explicit precondition and > effect attributes on operations. You seem to be caught up in syntax. The hard part is specifying the semantics (which isn't all that hard, but there are issues). If the group is going to do so little, well, yay, I guess. Less work. But then, what's the payoff. > In other words, the description of preconditions and effects can be > hidden in the model reference and the SA-WSDL spec will be as useful as > WSDL-S, I believe. Er....no comment :) Ok, comment. I don't see the value of bare hooks. If we're talking bare hooks, we might as well not do anything at all. There's no interop gained with bare hooks (e.g., I have a "model reference" to a precondition and to an effect...how do I *know* which is which? By something in the p&e descriptions? Is this standardized? No? Then no interop.) Cheers, Bijan.
Received on Monday, 20 March 2006 15:10:59 UTC