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

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.

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. 

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.

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.

Cheers,

--umit

-- 
Umit Yalcinalp                                  
Consulting Member of Technical Staff
ORACLE
Phone: +1 650 607 6154                          
Email: umit.yalcinalp@oracle.com

Received on Friday, 11 July 2003 20:52:03 UTC