Re: What does "being a member" mean?

Hi Nandana,

On 11/13/2013 03:47 AM, Nandana Mihindukulasooriya wrote:
> Hi,
>
> I also agree with Alexandre that it is useful to always have a way to
> traverse from an LDPC to it's members.
>
> We have two relationships now linking LDPC to its members.
>
> (1) ldp:created -  the relation with LDPC HTTP resource (in the def.
> "which is uniquely identified by a URI that responds to client requests
> for creation, modification, and enumeration of its members") to member
> HTTP resource.  This is something ldp specific / domain independent and
> described using LDP vocabulary. This is allows to traverse from LDPC to
> a LDPR and to know which HTTP resource are managed by this LDPC. I think
> even in the case of converting some existing data to LDP as the use case
> SteveS mentioned several times, it should be possible to add this
> relation to the HTTP resources that tracks / manages ( so the name
> ldp:created may not be the best name -> ldp:tracks, ldp:manages).
>
> (2) ldp:membershipX - the relationships between the entities in the
> domain and additional consequences of posting something to a LDPC.  This
> (most of the time) is domain specific and described by a domain
> vocabulary. This allows to describe richer relationships in data and
> automatically create those relationships upon creating a new resource.
>
> Right now (1) is optional and (2) is mandatory. I think it would be nice
> for us to consider both of them mandatory or (1) is mandatory and (2) is
> optional.

Looks like the group is not opposed to make (1) mandatory.

I would personally prefer (2) to be optional. And if (2) is mandatory,
then I'd like to be able to align its interpretation to the semantics
of ldp:created to nullify its effect, but I'm not sure if it's
possible:

[[
:_1234
    ldp:containerResource <>;
    ldp:containsRelation ldp:created;
    ldp:insertedContentRelation ??????.
]]

Alexandre.

> If (1) is mandatory and (2) is optional, we can have very simple
> containers like (if you don't want richer relationships represented in
> your LDPC). In this case, as a client I know that ldp:created relation
> will always be created and I can find the other relations that will be
> created by getting ldpc-url?non-member-properties. If there are no
> ldp:membershipX, that means there won't be any other relations created.
>
> </shopping/cart/> a ldp:Container;
>         ldp:created </shopping/cart/order1>;
> ldp:created </shopping/cart/order2>.
>
> If both (1) and (2) are mandatory, the container won't be this simple
> but you will always have a way to traverse from LDPC its members
> (specially when ldp:membershipObject/ldp:insertedContentRelation is
> not ldp:MemberSubject).
>
> The main downside of this is, as againSteveS mentioned several times,
> this lead to redundant triples in one common scenario.
>
> </shopping/cart/> a ldp:Container;
>     ldp:membershipSubject <#>;
>     ldp:membershipPredicate o:oder;
>     ldp:membershipObject ldp:MemberSubject.
>
>         ldp:created </shopping/cart/order1>;
> ldp:order </shopping/cart/order1>;
>         ldp:created </shopping/cart/order2>;
> ldp:order </shopping/cart/order2>.
>
> However, I think having (1) as mandatory will be quite helpful.
>
> Best Regards,
> Nandana
>
>
>
> On Wed, Nov 13, 2013 at 12:32 AM, Arnaud Le Hors <lehors@us.ibm.com
> <mailto:lehors@us.ibm.com>> wrote:
>
>     Henry Story <henry.story@bblfish.net
>     <mailto:henry.story@bblfish.net>> wrote:
>
>      > My definition contains
>      > an "or":
>      >  - either an LDPR is created through a POST
>      >  - or if an LDPR is DELETEd the LDPC needs to remove the
>     membership triples
>      >
>      > (see _http://www.w3.org/2012/ldp/wiki/Member_)
>
>     I think there is a problem with this proposal in that it limits
>     members to being LDPRs. This doesn't match what we have in the spec
>     today and what we've been talking about all along.
>
>     The spec clearly defines that an LDPR is an "HTTP resource whose
>     state is represented in RDF" and although this definition now needs
>     updating to match the more complex membership mechanism we've
>     developed I think the intent of what the members of a container
>     appear in the definition of an LDPC: "An LDPR representing a
>     collection of same-subject, same-predicate triples which is uniquely
>     identified by a URI that responds to client requests for creation,
>     modification, and enumeration of its members." See
>     http://www.w3.org/TR/2013/WD-ldp-20130730/#terminology
>
>     So, as the spec stands, the members of a container are the resources
>     listed as members. These are the resources listed using the
>     membershipXXX stuff. Some of these may have been created by POSTing
>     to the container some may not. Some may be LDPRs, some may not
>     (binaries for example).
>
>     In the case where one uses ldp:insertedContentRelation the member is
>     the resource found using the object of that property in the POSTed
>     resource. This actually was the whole point of adding this feature
>     to the spec. Roger wanted to make zaza the cat the member of his
>     container as opposed to the information resource that talks about zaza,
>
>     Going back to Alexandre's orginal question, in his example below
>     this means <urn:isbn:0470396792> is the member:
>      >     $ GET _http://example.com/shopping/__cart/_
>      >     <_http://example.com/shopping/cart/_>
>      >
>      >     [[
>      >     </shopping/cart/> a ldp:Container;
>      >         ldp:containerResource <#>;
>      >         ldp:containsRelation order:contains;
>      >         ldp:insertedContentRelation foaf:primaryTopic.
>      >
>      >     <#> order:contains <urn:isbn:0470396792>
>      >     ]]
>
>     Similarly, we agreed that when POSTing a binary to a container, it
>     is the binary that is listed as a member, and metadata associated to
>     it is to be found from the binary. See section 5.9.2:
>     http://www.w3.org/TR/2013/WD-ldp-20130730/#ldpc-5_9_2(side note: I
>     wonder why this is under OPTIONS rather than POST, looks like a bug
>     to me).
>
>     Given that, I don't see a problem with what figuring out what the
>     members of a container are.
>     Now, I understand Alexandre and others also want to be able to find
>     the resources that are created as a result of a POST, including in
>     the above example. I think that's a fair request but I don't think
>     that requires revisiting what being a member means.
>     --
>     Arnaud  Le Hors - Software Standards Architect - IBM Software Group
>
>

Received on Thursday, 14 November 2013 05:38:29 UTC