Re: Charter scope (Re: Semantics of WSDL vs. semantics of service)

Bijan, I'll reply to what I can below.

On Mon, 2006-03-20 at 10:10 -0500, Bijan Parsia wrote:
> >> 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.

That's why I expect some form of embedding will be added. I guess I'm
with you, and it seems that your being nit-picking here. 8-)

> 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?

Just the hooks, sorry, that's it.

> >> 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.

OK, I'm unable to formulate it clearly, so I'll defer to you. What makes
the Semantic Web semantic? When you formulate the reply, please smack it
on WSDL and there you go. 8-)

> >> 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.

As the proposed chair I fully expect WSDL-S to become the basis for our
document. Obviously this is up to the group to decide, and I won't be
pushing this, but it seems a very natural and beneficial move.

> > Apart from the RDF mapping, I don't expect the result to have syntax
> > that will be separable from the WSDL syntax
> 
> Why not?

If somebody presents good use cases for this and if it isn't too much
work, the group may consider it. However, the group should favor
schedule over new features.

> 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".

OK, our problem, not insufficient agreement. However, see below.

> > 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.

One of these threads mentioned "architecture by accretion" - I initially
also thought WSDL-S is not useful because it doesn't *do* anything,
except I realized that what it does is give us a firm platform (WSDL)
and a firm set of (general enough) hooks on which we can hang concrete
things and do things with them in a way that the industry has a chance
to understand.

The group is doing little, but I remain hopeful that this is going to be
a kick in the right direction.

> 
> > 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.
> 
> 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.)

There's mindshare interop - industry will understand what these hooks
mean, so it'll be easier for us to present them with frameworks that
make use of the hooks.

Compare the hooks with HTML <object> or <embed> - neither of these
actually says anything concrete (is it a movie? or a static thing? does
your browser support it?) yet they are useful because the browser
accepts plugins that will handle limited specific values of these
elements. HTML also could have left it to general extensibility, yet I
suspect (no hard evidence) that the existence of these elements gave
people the right ideas.

In essence, I think this is the best next step that the W3C could have
done in this situation to facilitate SWS progress.

Best regards,

Jacek

Received on Monday, 20 March 2006 17:18:38 UTC