W3C home > Mailing lists > Public > www-ws-desc@w3.org > July 2003

Re: Can someone recap the differences between @serviceGroup vs. definitions-targetNamespace ?

From: Bijan Parsia <bparsia@isr.umd.edu>
Date: Fri, 11 Jul 2003 23:56:02 -0400
Cc: www-ws-desc@w3.org
To: Umit Yalcinalp <umit.yalcinalp@oracle.com>
Message-Id: <C168D640-B41C-11D7-A324-0003936A0B26@isr.umd.edu>

On Friday, July 11, 2003, at 08:51 PM, Umit Yalcinalp wrote:

> Bijan Parsia wrote:
>> On Friday, July 11, 2003, at 02:35  PM, Jon Dart wrote:
>>> Jonathan Marsh wrote:
>>>> Instead of
>>>> introducing the "resource" entity, we can introduce an entity
>>>> representing the "group".  The relationship between endpoint(s) and 
>>>> the
>>>> group is that of "member of", instead of the fuzzier "manipulates".
>>> I think this is a helpful change. IMO "group" and "member of" are 
>>> actually fuzzier terms, in that there could be various kinds of and 
>>> rationales for grouping (of which "manipulate a common resource" 
>>> might be one).
>> That's exactly why they aren't fuzzy :) They just say that "this a 
>> group; these are its members", no more, no less. "Manipulate a common 
>> resource" seems to say something substantive, but we don't want it 
>> to, hence "the manipulation is undefined, and the resource can be 
>> anything, including a set of naturally disjoint things", etc.
>> I agree, of course, that this is a helpful change :)
> I am not sure that this is a helpful change. I believe the group 
> concept is fuzzy.

I have to strongly disagree. It's not fuzzy. It's not vague. It's not 
undefined. It's not oddly defined. It clearly states what the 
relationship is without ANY "hints" which *suggest* but don't *state*.

Done right, it provides a hook for out-of-wsdl band information about 
the *point* of the group, the *purpose* of the group, the *reasons* for 
grouping them so, etc. Whether WSDL *needs* to provide such a hook is 
an open question (I suspect not). But to *purport* to give a specific 
grouping (i.e., the group of "same resource manipulaters") while 
leaving the nature of the specification almost entirely open (with 
language such as "'manipulate' is undefined", or even "resource", where 
the resource in question can be either a single printer or a set of 
unrelated printers), seems, if not fuzzy, worrisomely misleading. If we 
*do* mean something specific by "manipulates", and have some idea of 
what sorts of resources are so manipulated, then we should be explicit.

In any case, there are many reasons to group interfaces besides that 
they manipulate the same resource (assuming SOME constrainsts on 
"manipulate" and "resource). Why are we privileging this one?

> With any abstraction and fuzziness introduced, there is always 
> something lost.

Abstraction != fuzziness, and there may be things gained. I would 
contend that "manipulates some resource" is no *less* abstract (given 
the actual (lack of) definitions proposed) and, due to the fact that 
the language has extra connoations, more fuzzy. Lets call a spade a 
spade unless we're actually willing to commit to pitchforks.

> There may be many different rationales for grouping.

Agreed. This is key to me. If the choice is between only 1 grouping 
permitted (with the rest of the metadata out of WSDL-band), only 1 
grouping permitted (but with very vague "permissive" semantics), there 
there's no real choice. But I would prefer nothing at all to either of 
these. If WSDL is the right place, technically and politcially and 
usabilitily, to put this information, then you should be able to define 
mulitple groups.

> However, when you introduce grouping with serviceGroup and the only
> relationship that is implied is "member of", then this begs the 
> question

(Please ignore this pickiness but I can't help it: This isn't, 
technically, "begging the question".)

> of why we introduce the grouping at all when one can not
> not define multiple groupings of a services.

If you look at my prior posting, you'll see me critiquing some of the 
concrete proposals for realizing it precisely on the grounds that 
single grouping is pointless, IMHO.

It would be pointed if there were a *clear*, *SPECIFIC*, general, and 
useful rationale for grouping that served a large community such that 
it was worth cluttering WSDL with. I really can't believe that 
"manipulating the same resource" is such a rationale. Particular when 
almost any relationship can fit that.

Note that this relationship is differen than the one suggested by WSDL 
1.1 as the useful one. Since sets of manipulations can be completely 

>  Many relationships between services are needed, why is this named 
> grouping? I would think then it would be more powerful to define them 
> then externally to the definition of the service itself, hence RDF.

Which was, in my prior post, my prefered choice.

> What we lose by dropping the targetResource is the concept of 
> "manipulation" and hence the implied concept of the state accessed via 
> multiple services.

So, the burden, as I see it, of the priviledging this grouping 
advocates is to show why *this relationship* should be priviledged. And 
this hold even if we have *mulitple* groupings. Why build in *this* 
relationship? (I can think of several other key ones off the top of my 
head. "Having the same author/mantainer" being one.)

> The whole point of putting the targetResource was to indicate just 
> that. We have discussed for several weeks now as to whether 
> targetResource is illdefined, etc. Well, I think this is worse.

I'm perplexed. You think that group membership is *more* ill/undefined 
than targetResource? I just don't see how that can be. I *can* see that 
you might think that if we're going to only have one grouping, then it 
should have a specific (useful) semantics. But then we should have an 
actual specific semantics, which has been deliberately, explicitly NOT 
given *and* we should have a good solid reason for selecting *THAT 
SEMANTICS* to be *the* first class (and only) grouping rationale.

My counterproposal (if we're not going to drop it entirely) would be to 
allow multiple groupings, with a hook for extensible metadata about the 
semantics of that grouping. I might go for a wsdl blessed "starter set" 
of rationales, if such a set could be reasonably identified.

> If we were to retain targetResource, it seems that at least one can 
> only infer a specific relationship, the manipulation of a resource 
> that is accessed by multiple services that declare it.

Except that non-manipulation is a permitted sort of manipulation and 
the type of resource is unconstrained (so could be a disjoint set of 
whatevers with no shared state).

> This would be very useful in discussing other fundemantal concepts 
> such as identity and state.

Not without nailing it down a bit further, I'd say.

> The serviceGroup thingy can not be used to express multiple 
> relationships,

Sure it can, if we let it :)

>  it is fuzzier

I really want that to be shown, rather than asserted. serviceGroup is a 
set of services with any further information about *why* they are 
grouped having to be provided by something else. It's *VERY* clear that 
that's what it is.

targetResource seems to be depending on the suggestiveness of the 
language to "imply" (in the "suggest" not in the "entail" sense) some 
stuff that, for some reason, the group (as a whole) is rather unwilling 
to explicitly state. This is clear? I think not *because* it's 
unsettled whether this language actually fixes the relationship.

>  and can not be used as a building block.

Well, it depends what you're building. It seems perfectly reasonable as 
a place to hang further information.

>  IMHO,  targetResource is better defined in comparison.

I really think you're conflating "better defined" with "more useful 
concept". Or even "more specific concept".

In any case, I think it manifestly clear that the current spec does 
*not* well define it, as it doesn't define it at all 

"""Figure 1-2 shows two services (Service1 and Service2) bound to the
same resource (Resource1), but offering different interfaces (Interface1
and Interface2). Interface1 and Interface2 may be related to each other,
but this specification is NOT defining what this relationship might be.
For example, Interface1 may be an operational interface, may Interface2
might be a management interface."""

Oh, and it gets worse 

""" targetResource attribute information item with service 

The targetResource attribute information item identifies the resource 
that the
service is a representation of."""

Am I looking at the wrong version of the WD? Or is there another 
definition somewhere, contrary to the claims of the introduction?


1) "targetResource", et al, is at best suggestive of some relationship, 
and that suggestion is not uniform across members of the WG. It 
explicitly is left undefined with the possible relationships (as 
mentioned in the text) ranging from "representing", to "operating", to 
"managing". I contend that it's not well or clearly defined in the 
spec, and it's very unclear to me, personally, what relationships are 

2) serviceGroup defines a set membership relationship only and leaves 
the rationale for that grouping for out-of-wsld-spec-band 
determination, say, by some RDF. It is not illdefined or undefined and 
it clearly communicates that if you want a group with some particular 
semantics you should check the out of band info. It also provides a 
hook by providing a uri that can be the subject of RDF assertions 
detailing the purpose of the grouping and what further information can 
be infered from that grouping

3) Having only one serviceGroup is wrongheaded. If having more than one 
is cumbersome, then that suggests we should leave grouping to things 
other than WSDL.

4) If there is a grouping/grouping purpose that is either supremely 
common, highly related to other bits of WSDL, etc. then that *may* be 
an argument for privileging it. But I would hold that a) the barrier to 
such an asymmetric treatment should be high and b) that the semantics 
of the distinguished rationale should be well defined in the spec. See 
1 for why targetResource currently fails.

Bijan Parsia.
Received on Friday, 11 July 2003 23:50:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:31 UTC