Re: Model questions

On 29 Jan 2013, at 02:21, Ashok Malhotra <ashok.malhotra@oracle.com> wrote:

> A few weeks ago I had asked some questions about the LDP model on the Wiki page:
> http://www.w3.org/2012/ldp/wiki/ISSUE-37
> This is an attempt to assess where we are with these questions today and what we should
> do to answer them.
> 
> 1. We need to be able to create and delete collections.
> 
> Steve S indicates that there is agreement that the client should be able
> to create collections.  This is good,
> but we have not agreed on a mechanism to create collections although
> there has been a good deal of mail on the subject.  Perhaps we need to
> open an issue:  How are Collections Created?

By sending a create-collection message  (eg MKCOL ) to a collection that 
allows collection  creation. If you follow the parents of such collection 
up you inevitably end up with a root collection:  you can never do without 
a root collection. 

Think of it: how do you create  the root in the file system? Well you format 
the hard drive of a new  computer. How do you start the root of a web server:
you start the web server.... The process that you follow to put up a root
collection is completely different from that of creating a collection and
so I think is really out of scope.

If you reject the idea of a root collection then you end up 
with an infinite regress here. Because of whatever R you come up with as the
thing that will create the root collection, you will be able to ask
with equal justification of R how do you produce it.

> 
> 2. When a collection is deleted are its members deleted also?
> This is the composition vs. aggregation question.  We closed issue
> http://www.w3.org/2012/ldp/track/issues/25 but I don't think
> the matter is settled.
> 
> We agree that both composition and aggregation are needed but we
> don't have agreement on mechanisms.  http://www.w3.org/2012/ldp/track/issues/34
> covers a part of it.
> 
> There seem to be three proposals:
> A.  Use an attribute on the collection to indicate composition or aggregation
> B.  Use two separate classes for composition and aggregation
> C.  Delete all members when a collection is deleted.  Use links to cover the
> aggregation case.

I think you mean when a Container is deleted. 

> 
> Perhaps we need an issue to decide on the mechanism.

D: seperate relations one for aggregation and one for composition
  eg: ldp:contains and ldp:link where ldp:contains members are deleted
  when the container is deleted.
  ldp:link would be a bit like symbolic links on the file system. 
  But this means have to work out how to distinguish the creation of the
  ldp:link from the creation of the ldp:contains relation. 
  My guess is that the PATCH method on a collection could be used for
  that: one could PATCH a collection to add ldp:links. 

  PATCH /container HTTP/1.1
  ...
  ADD { <> ldp:link </otherContainer/bug22> }

  One could also use a PATCH to delete intelligently a number of links, 
  without having to go to each to delete them, by sending something like

  PATCH /container HTTP/1.1
  ...
  DELETE { <> ldp:contains ?c .
            ?c dc:created ?spammer . }
            
  => So my suggestion is we should work a good PATCH first. Then this
    problem is easy to resolve.



> 
> 3. Can collections contain collections?
> There seems to be agreement that, yes, collections can contain collections.
> There also seems to be agreement that collections are LDPRs and should
> be added to collections like any other LDPR.  I think this is settled but, personally,
> I would like to see a line in the spec saying collections can be added to collections
> just like any other LDPR rather than leaving this as an exercise for the reader.

The mechanism is not quite settled on how to do this in my view yet, and 
of course it would need to go into the spec.

> 
> 4. Does each LDP model have/need a service document?
> The question is whether we need a starting point to start navigation and
> create collections etc.  There has been some mail on this.  I'm not sure where
> the WG stands on this but I don't think this is a crucial question for the model.
> I'm happy to withdraw it.

ok. I think that will fall out logically from the rest of the work anyway. If you
can describe collections then other documents can just point to them.


> 
> This is my assessment of the situation.  I know I don't have to say this to this
> group, but don't be shy and send mail if you disagree
> --
> All the best, Ashok
> 

Social Web Architect
http://bblfish.net/

Received on Tuesday, 29 January 2013 09:04:17 UTC