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

Richard Cyganiak <richard@cyganiak.de> wrote on 11/06/2012 10:50:16 AM:

> From: Richard Cyganiak <richard@cyganiak.de>
> To: Arnaud Le Hors/Cupertino/IBM@IBMUS, 
> Cc: public-ldp-wg@w3.org
> Date: 11/06/2012 10:52 AM
> Subject: Re: ldp-ISSUE-30 (bugtrack): Hierarchical bugtracking 
> service [Use Cases   and Requirements]
> 
> On 6 Nov 2012, at 17:01, Arnaud Le Hors wrote:
> > > 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?
> 
> Let's say that X, Y and Z are resources, and p is a property.
> 
> I think the definition of composition, in the context of LDP, is:
> 
>   X+p is a composition of Y and Z if there exists triples "X p Y" and
>   "X p Z", and deleting X also deletes Y and Z. (Or if deleting X is
>   impossible unless Y and Z are deleted first).
> 
> I think the definition of (weak) aggregation is:
> 
>   X+p is an aggregation of Y and Z if there exists triples "X p Y" and
>   "X p Z", and X can be deleted independently from the existence of
>   Y and Z.
> 
> I think that LDP has made a decision that leads to the following axiom:
> 
>   If Y is created by POSTing to X+p, then X+p is a composition, and Y
>   becomes a member of the composition.

Hmm, isn't it rather the following?

If Y is created by POSTing to X+p, and X+p is a composition, then Y
   becomes a member of the composition.

Anyway, I don't think that really makes a difference.

> 
> Now I asked Steve whether adding and removing members of X+p via PUT
> or PATCH would be sufficient to address the bug tracker use case. 
> You seem to be saying that, if his answer is yes, then that would 
> make X an aggregation. I don't see how this follows from the 
> definitions and axiom above.

I think it depends on how you define the composition model beyond what you 
wrote above.

For instance, does composition impose additional constraints on where 
member resources live? At the meeting, we discussed how severs may not be 
able to handle resources that live on a different server from where the 
container is.

Another question is whether a resource can be in more than one container. 
If not, how do we prevent this from happening if we allow adding and 
removing members via PUT or PATCH? If yes, what happens when I delete a 
container?

And if the URI of the resource is somehow related to the container that 
created it, does it change if you move the resource from one container to 
another?


I'm getting the feeling that if we keep trying to solve this problem one 
issue at a time it's going to take us forever and we may not end up with a 
consistent model. Instead we may need to try and agree on what the general 
model is first and then discuss how this gets translated with regard to 
HTTP.

Tim was suggesting at the meeting using a filesystem as a model, where 
directories are containers and files are resources, for instance.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group