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

Thus quoth Umit Yalcinalp (~ 11-Jul-03 5:51 PM ~)...
> 
> 
> 
> 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. With any abstraction and fuzziness introduced, there is always 
> something lost.
+1
> 
> There may be many different rationales for grouping. However, when you 
> introduce grouping with serviceGroup and the only
> relationship that is implied is "member of", then this begs the question 
> of why we introduce the grouping at all when one can not
> not define multiple groupings of a services. 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.
+1
> What we lose by dropping the targetResource is the concept of 
> "manipulation" and hence the implied concept of the state accessed via 
> multiple services. 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.
+1

I agree completely.  While the serviceGroup is "more general," it misses 
completely in providing the ability to express that some collection of 
endpoints "manipulates" (works with, shares state with, etc.) some 
underlying thing.  Having the ability to find an interface but be unable 
to figure out which one to use seems to me to considerably lessen the 
power of the standard.

Amongst the points of Web services is to create interoperable systems 
which can be assembled regardless of implementation technology.  Such 
assembly requires the ability to determine interfaces, points of access, 
*and* an ability to determine which of the alternatives with which to 
work.  The ability to indicate this as part of a service's definition 
seems critical.

The general notion, separately, of serviceGroups is also powerful.  *If* 
there were a means (perhaps an extensible collection of @purpose 
attributes, at least one of which is something like /underlying 
entity/), then that mechansim would work as well.  But losing the means 
to link endpoints (or collections thereof) to some named underlying 
thing seems like a loss to me.


> 
> 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. This would be very useful 
> in discussing other fundemantal concepts such as identity and state. The 
> serviceGroup thingy can not be used to express multiple relationships, 
> it is fuzzier and can not be used as a building block. IMHO,  
> targetResource is better defined in comparison.
+1
> 
> Cheers,
> 
> --umit
> 


-- 
Fred Carter / AmberPoint, Inc.

mailto:fred.carter@amberpoint.com
tel:+1.510.433.6525 fax:+1.510.663.6301

Received on Thursday, 24 July 2003 19:34:53 UTC