Issue-89

This builds on top of the new Container proposal but replaces ldp:member with ldp:contains to align the containment triples and the membership triples in the case of the SimpleContainer.

This also assumes that the proposals from ISSUE-90 were accepted first.

1 PROPOSAL 3: define the containment relationship

We call containment the relationship binding an LDPC and its (contained) LDPRs.

Note: the containment relationship proposed here does not build upon membership, and the opposite is still true as well. Also, the current specification already defines membership, except for the bits related to ISSUE-90.

The containment relationship is expressed through the ldp:contains predicate (I was using ldp:xyz in ISSUE-89).

The containment triples for a Container are defined as follow:

• the containment subject is the LDPC itself
• the containment predicate is ldp:contains
• the containment object is the contained LDPR

ISSUE-90 related: the containment triples belong to the representation of the LDPC.

A successful POST on the LDPC results in a new containment triple, the containment object being the URL returned in the Location header. Note: this is true for any LDPR, including an LDPB.

Note: following that rule, a successful POST of a Binary resource results in one new contained LDPB. The LDPC might create an associated LDPR to contain data about the LDPG but this one is not contained. It is just linked through the meta rel-Link, as specified in 5.4.12.

Same for successful PUT, but the containment object will be the URL being used for the PUT.

A successful DELETE on a contained LDPR results in the deletion of the corresponding containment triple from the Container.

To create a Container (POST/PUT), one MUST use a rel="type" Link header of value <http://www.w3.org/ns/ldp#Container>, along with a valid representation for an ldp:Container: that includes the expected member properties (as defined in the new Container proposal) and the capacity for the server to satisfy them eg. the server can/cannot write to the hashless-ContainerResource.

2 PROPOSAL 4: get rid of ldp:created

Remove ldp:created altogether as it's completely subsumed by ldp:contains.

3 PROPOSAL 5: filtering server-managed triples

An LDPC representation has potentially the following triples:

• member-properties triples
• containment triples
• membership triples
• application data

When 1. a DirectContainer (respectively IndirectContainer) is also the hashless-ContainerResource and 2. its membership predicate is not ldp:contains, then its representation has both the containment triples and the membership triples ie. the number of triples is doubled.

I propose to change 5.9.1 Non-member resource to filter out the containment triples. I would also make the Link header returned wht GET/HEAD (it's currently under OPTIONS).

proposed 5.9.1 starts here

LDP servers SHOULD define a corresponding no containment triples resource to support requests for information about an LDPC without retrieving a full representation including all of its contained LDPRs.

The server SHOULD provide an HTTP Link header whose target URI is the no containment triples resource and whose link relation type is http://www.w3.org/ns/ldp#noContainmentTriplesResource [RFC5988]. This is the mechanism by which clients discover the URL of the properties-only resource.

If no such Link header is present, then conservative clients will assume that the LDPC does not have a corresponding property-only resource.

For example, if there is a LDPC with URL <containerURL> whose corresponding no containment triples resource URL is <containerURL?noContainmentTriples>, then the corresponding Link header would be

Link: <?noContainmentTriples>;rel='http://www.w3.org/ns/ldp#propertiesOnlyResource'

proposed 5.9.1 ends here

Remark: using 5.9.1 as defined in the current spec, one is supposed to be able to filter out the membership triples. I don't think that the way it's currently done works in practice. Example 5 suggests that the membership triples are under the hashless ContainerResource <http://example.org/netWorth/nw1/> (and this is also how it's handle in my proposal for ISSUE-90 Named Graphs). But per 5.9.1, the non-member resource would be linked from the LDPC eg. <http://example.org/netWorth/nw1/assetContainer/>, but not from the hashless ContainerResource. So if I'm not mistaken, the membership triples can't be filtered out that way when the ContainerResource is not the LDPC itself.