Re: Proposal for containers

El 30/01/13 20:18, Steve Battle escribió:
> Ashok,
>
> LDP resources (including containers) are defined as "web resources
> that describe their state using RDF". What are your thoughts on how
> the relationship between the container and the contained is
> represented in RDF? This being part of it's state.
>
> My concern, as always, is that if predicates like rdfs:member are
> allowed for composition then this makes it difficult to distinguish
> between a resource POSTed to the container (as in B.), and a resource
> _linked_ to the container using rdfs:member (as in F.). I advocate
> use of a distinct composition property (eg. ldp:contains, or
> ldp:owns, or ldp:manages) to avoid this confusion between composition
> and aggregation.
>
> This is an extension of your proposal below, NOT an alternative
> proposal.

Hi,

I agree with Steve, we need to distinguish between protocol properties 
and non-protocol ones, which entails not using rdfs:member as a default 
membership property.

The current specification already covers this (changing the property 
name) and is consistent with Ashok's summary:

.- Use ldp:contains (or any other name in the ldp namespace) as the 
default property to represent the members of a container.
.- Use ldp:membershipPredicate if you want to change the default 
membership property.

What I'm not really sure is about the need for the following:
.- Use ldp:membershipSubject if you want to change the membership 
subject to another resource that is not the container.

I suppose that the following restrictions apply:
a) The membership property must be used only with a single RDF resource 
in a container representation (i.e., only one resource with members).
b) An RDF resource with members must be a container.

Taking these restrictions in mind, there is no need to explicitly state 
which is the membership subject.

Seeing it in another way, if we continue defining the LDP ontology, we 
can say something like:
"A Container is something that contains Resources",
which explicitly states these restrictions.

Kind regards,

> On 30 Jan 2013, at 15:23, Ashok Malhotra <ashok.malhotra@oracle.com>
> wrote:
>
>> OK.  Here goes
>>
>> Container Model
>>
>> A. Containers can contain containers Containers are LDPRs and
>> should be added to contianers like any other LDPR.
>>
>> B. To add a container to a container, POST a (child) container
>> representation to a (parent) container.
>>
>> C. Thus, a contianer can contain a mix of members and comtainers.
>> (Some of the members may be links to LDPRs.)
>>
>> D. If you GET all members of a container that has nested
>> components, you get all the contents, members and containers at the
>> top level.  That is, you do not get nested components.
>>
>> Composition and Aggregation
>>
>> E. If you delete a container you delete everything it contains. For
>> nested containers this leads to a cascaded delete.
>>
>> F. If you do not want a member to be deleted when the container is
>> deleted, do not include the member in the containers but rather
>> include a link to the member in the container.
>>
>> E and F follow the AtomPub model.  There are other proposals --
>> distinct containers and aggregators, an attribute to distinguish
>> between containers and aggregators.  We can debate these
>> separately from A, B, C, D
>>
>>
>> All the best, Ashok
>
>
>


-- 

Dr. Raúl García Castro
http://delicias.dia.fi.upm.es/~rgarcia/

Ontology Engineering Group
Departamento de Inteligencia Artificial
Universidad Politécnica de Madrid
Campus de Montegancedo, s/n - Boadilla del Monte - 28660 Madrid
Phone: +34 91 336 36 70 - Fax: +34 91 352 48 19

Received on Thursday, 31 January 2013 08:42:11 UTC