Re: What does "being a member" mean?

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.

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 again SteveS 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> wrote:

> Henry Story <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*<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/>
> >     <*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
>