W3C home > Mailing lists > Public > public-ldp-wg@w3.org > February 2013

Re: Issue-34 Back_to_Basics proposal

From: Henry Story <henry.story@bblfish.net>
Date: Sun, 3 Feb 2013 11:50:56 +0100
Cc: public-ldp-wg@w3.org
Message-Id: <0FADF5CA-F572-4C98-9450-6E8DF0977E1E@bblfish.net>
To: Arnaud Le Hors <lehors@us.ibm.com>

On 1 Feb 2013, at 21:45, Arnaud Le Hors <lehors@us.ibm.com> wrote:

> Hi Henry, 
> 
> I think John's off today so I'll offer my understanding of his proposal. 
> 
> In John's proposal, Container is a subclass of Aggregation so if a resource is a Container it is by definition also an Aggregation. 

Thanks, that helps a lot. Indeed it should be right at the top of the page, as it explains very
tersely what the difference ontologically is that this makes.

   :Container rdfs:subClassOf :Aggregation .

> 
> Whether a member resource gets deleted when a collection is deleted merely hinges on whether it is a Container (i.e., and an Aggregation) or only an Aggregation (i.e., and not a Container). 
> 
> In either case when a member resources is deleted it is removed from the collection.

Ok. So the difference should be minimal then from 
http://www.w3.org/2012/ldp/wiki/Issue-34_-_Aggregation:_simple_proposal

In fact there should be no visible difference at present.
Because if an LDPC is a subclass of an LDPA, then there is 
no need to mention it

<> a Container, Aggregation .

can just become

<> a Container .

Onotologically I suppose it just removes the need for ldp:Collection which 
we had before.

Perhaps the thing to watch out for would be when trying to PATCH
an aggregation with a { <> a :Container }. If the rdfs:members of
the existing Aggregation were things that the container could not
guarantee to control, then the addition of { <> a :Container } would
be impossible. If this were a use case that were to turn up, then
it would argue for distinguishing the ldp:contains relation .



> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
> 
> 
> Henry Story <henry.story@bblfish.net> wrote on 02/01/2013 12:18:26 PM:
> 
> > From: Henry Story <henry.story@bblfish.net> 
> > To: John Arwe/Poughkeepsie/IBM@IBMUS, 
> > Cc: public-ldp-wg@w3.org 
> > Date: 02/01/2013 12:19 PM 
> > Subject: Re: Issue-34 Back_to_Basics proposal 
> > 
> > Hi John, 
> > 
> > Reading your "Interaction Model" section, you point out that I added
> > an additional constraint 
> > on HTTP DELETE, namely that deleting the resource removes it from 
> > the containers 
> > listing.  As you seem to think it is a good idea, I wonder if one 
> > should add that 
> > as a new issue on its own. 
> > 
> > In the section "Creating a member resource" 
> > http://www.w3.org/2012/ldp/wiki/
> > Issue-34:_Back_to_Basics#Creating_a_member_resource 
> > 
> > you have a resource that ends up being an Aggregation and a 
> > Container. I don't understand how one would know how to distinguish 
> > the meaning of rdfs:member in such a collection. Does the thing it 
> > points to when deleted get remove from the container always? In 
> > which case is there a point still to call it an Aggregation? 
> > 
> > Henry 
> > 
> > On 31 Jan 2013, at 22:01, John Arwe <johnarwe@us.ibm.com> wrote: 
> > 
> > Not having seen any replies to [1], wondering if it got lost in the 
> > shuffle.  This is the same proposal [2] mentioned on this week's 
> > call for how to resolve the issue and define an interaction model 
> > covering both aggregation and composition. 
> > 
> > [1] http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jan/0330.html 
> > [2] http://www.w3.org/2012/ldp/wiki/Issue-34:_Back_to_Basics 
> > 
> > Best Regards, John
> > 
> > Voice US 845-435-9470  BluePages 
> > Tivoli OSLC Lead - Show me the Scenario 
> > 
> > Social Web Architect 
> > http://bblfish.net/

Social Web Architect
http://bblfish.net/




Received on Sunday, 3 February 2013 10:51:28 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 9 May 2013 13:44:29 UTC