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

On Mar 20, 2006, at 12:18 PM, Jacek Kopecky wrote:

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

Having been bashed with charter language that I took as loose but was 
subsequently interpreted as strict (strict to a tendentious reading), I 
think I have reason to be cautious.

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

Eh. That's not quite what I was after.

And there are hooks and there are hooks. I can have a hook 
"precondition", but that will have some impact beyond mere hookatude. 
If it's just raw extensibilty points then there's no need for the group 
at all.

>>>> 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 would that help? I'm saying that the specific aspect of the 
enhanced description should be targeted. For example, if we are 
interested in service categories, let's talk about how to describe 
them. If we are interested in behavior, let's talk about *that*. If we 
are interested in non-functional properites, let's talk about *them*. 
If we're not talking about anything of the sort, then what advantage do 
we have over normal WSDL extensibility.

In other words, I think we should be more like the WS-* groups...let's 
define *specific* and usable functionality.

[snip]
>> 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.

So all your WSDL-S derived constraints are conditional (i.e., "if 
wsdl-s is the basis..."). I don't mind pointing out how WSDL-S does it, 
but I think initial discussion should be more free ranging.

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

"New" features? What's new? What are the non-new features?

[snip]
>> 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.

I still fail to see the advantage over normal WSDL extensibility. A 
concrete example will help.

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

It seems premature. Who is using WSDL-S? What's the experience? How 
does it help with WSMO or OWL-S? Where is the interop and 
standardization advantages?

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

Perhaps. Then the hooks can't be *too* general.

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

Except there is a clear semantics there, roughly, 'display what a 
plugin gives you inline'.  That is there is a builtin model for how to 
compose the extension and the rest of the document. Annotations on 
operations can have more far reaching effects.

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

The history of HTML is littered with specific extensions as well. What 
makes you think that object or embed are the right model? (Consider CSS 
as being more like what useful annotations on operatiosn or services 
are like.)

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

Well, obviously, I disagree :)

I mean, it's easy enough. I'm not convinced that the politics benefit 
are worth the expense of a working group.

Cheers,
Bijan.

Received on Monday, 20 March 2006 17:37:15 UTC