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

Richard Cyganiak wrote:
> 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.
> 
> 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 believe that in LDP terminology, containers and compositions are the same thing, while any resource+property combination that is allowed to have more than one value but is not a container is an aggregation.

Weak aggregation as defined is great.

Composition/Containers as defined seem to be an unneeded extra which 
burdens implementers and constrains the use of POST.

Defining both will lead to confusion.

If compositions are to be in the spec, then I sincerely hope they are 
visible so that clients know anything created via POST to them will be 
deleted when the composition is deleted.

It would be wonderful if LDP could be defined without mentioning POST. 
In my mind POST is the link to web 1.0 and web 2.0, it allows people to 
bolt on HTML forms and POST to LDP* resources, and it also allows post 
to be used for inter-resource communication and notifications.

All use cases, and all desired functionality (although less is more) can 
be done using GET/PUT/DELETE/PATCH, Why use, and moreover constrain, POST?

Best,

Nathan

Received on Tuesday, 6 November 2012 19:26:37 UTC