W3C home > Mailing lists > Public > public-ldp-wg@w3.org > November 2012

Re: ldp-ISSUE-30 (bugtrack): Hierarchical bugtracking service [Use Cases and Requirements]

From: Steve K Speicher <sspeiche@us.ibm.com>
Date: Tue, 6 Nov 2012 12:34:17 -0500
To: public-ldp-wg@w3.org
Message-ID: <OFA3F2750D.7F6D2224-ON85257AAE.005F7644-85257AAE.0060869E@us.ibm.com>
Arnaud Le Hors/Cupertino/IBM@IBMUS wrote on 11/06/2012 12:01:28 PM:
> Richard Cyganiak <richard@cyganiak.de> wrote on 11/05/2012 12:06:07 PM:
> 
> > Steve, can't this already be done using the vanilla PATCH/PUT 
> > machinery? It seems all we need is a statement that members MAY be 
> > added and removed to/from containers by means other than POST-to-
> > container and DELETE-member (and DELETE-container).
> 
> Hi Richard, 
> doesn't that make the container a weak aggregator again though?

To me, it all depends on how we define the semantics of PUT/PATCH on a 
container based on the resolution of ISSUE-25.  I think the starting point 
is that with strong composition would be that a client can only POST to a 
container to create a resource and it gets added to the container.  DELETE 
of the resource, "removes" the resource from the server and removes the 
membership triple <container> rdfs:member <resource>.  These use cases 
(ISSUE-30 thread)are to see if this is an aggregation motivator or a 
motivator to unlink a resource from one container and then link a to a new 
container, which I believe is Richard's PUT/PATCH machinery suggestion.

Thanks,
Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web -> 
http://open-services.net
Received on Tuesday, 6 November 2012 17:35:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:42 UTC