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

On 8 Nov 2012, at 02:28, Arnaud Le Hors <lehors@us.ibm.com> wrote:

> 
> 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.

I think that is a very good place to start. The intuitions are well honed for those systems.
http://data.fm/ for example follows that path.

$ cwm https://bblfish.data.fm/
     @prefix : <http://www.w3.org/ns/posix/stat#> .

    </.meta>     a <http://www.w3.org/2000/01/rdf-schema#Resource>;
         :mtime 1304601365;
         :size 7168 .
    
    </webid.test.earl>     a <http://www.w3.org/2000/01/rdf-schema#Resource>;
         :mtime 1304602417;
         :size 7418 .

The above does not specify that the resource is a collection - which it is - and the 
datatypes are a bit inflexible there and using unix time perhaps a bit limiting.
Once one has those intutions one can then relax them ( say: the resulting resources
need not be forced to be in a simple hierarchical data space )

So for posting new data that is all very good.

The next question I have is: are there Containers that have deeper side effects. For
example a container that would not just create a resource, but also buy me an airline
ticket if I posted the correct ticket info:

I suppose we can develop those by having a new classes such as
air:AirlineTicketContainer. I am not sure if one would define such a class
like 

  ldp:Container  rdfs:subClassOf air:AirlineTicketContainer .

or like this:

  air:AirlineTicketContainer rdfs:subClassOf  ldp:Container  .


I think the second. One would know that when one posts to such a thing one is also going
to end up with an ldp resource, but there are additional things that could happen too. Or
perhaps we need to have an upper bound and a lower bound class: on the lower bound container
we expect only file system like things to happen ( ldp:FileContainer ) on the upper bound we have those but other things can happen too: such as buying a ticket. Then a robot that knows it is dealing with an ldp:FileContainer does not need to worry too much if he posts something, but he should make sure he understands the vocal of a a more general container.

Does that make sense?


> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
> 

Social Web Architect
http://bblfish.net/