Missing use case for supporting ldp:membershipPredicate/Subject

I've drafted some motivation around how the ldp:membershipPredicate/Subject
came into being and what motivated it.  Perhaps this is missing from the
UC&R [1] and I can gladly work to get that resolved.  Seems that ISSUE-71
is around this topic as well.

Let's take one of the most simple examples of what one might find based on
the recent primer examples, let's say a bug that has a few properties but
no associated attachments or child bugs.

Representation of bug http://example.org/bugs/13:

<> a bt:Bug ;
      dcterms:title "Product A crashes when shutting down.";
      dcterms:creator <http://example.org/users/johndoe>;
      dcterms:created "2013-05-05T10:00"^^xsd:dateTime;

Now we'll explore how add a couple screen shots to the bug. Using this
information I have with this resource, I'm not sure how I do that (assuming
I am a Linked Data client). I could just attempt to PUT replace the
contents and add a bt:attachment statement referring to the screenshot.
Depending on the server, it may reject it for a couple of reasons, such as:
it doesn't known anything about bt:attachment, or it has restrictions on
the object (where the attachment is physically stored), or simple PUT
updates not allowed for bt:attachment.
To help with this problem, we can associate an ldp:Container with this bug
resource to assist with this. So we expand our example, with out modifying
any of the original model, just adding a few more statements.

<> a bt:Bug ;
      dcterms:title "Product A crashes when shutting down.";
      dcterms:creator <http://example.org/users/johndoe>;
      dcterms:created "2013-05-05T10:00"^^xsd:dateTime.

# New stuff below this line, doesn't affect the "bug" resource model
<attachments> a ldp:Container ;
   ldp:membershipPredicate bt:attachment ;
   ldp:membershipSubject <>.

This tells my client now that we have an ldp:Container associated with the
bug, since the ldp:membershipSubject connects this container to the bug. I
can inspect also ldp:membershipPredicate to know for which same-subject and
same-predicate pairing I can use this container to assist with managing and
navigating them.
Now I have a URL http://examples.org/bugs/13/attachments where I can POST a
screenshot to create an attachment and associate it with bug 13. Let's look
at what the POST looks like:

Request:

POST http://example.com/bugs/13/attachments
Slug: screenshot1.png
Content-Type: image/png
Content-Length: 18124

[binary content]


Response:

HTTP/1.1 201 CREATED
Location: http://example.com/bugs/13/attachments/3
Content-Length: 0

Now that the attachment has been created, we can fetch bug 13 again to see
what we have.

<> a bt:Bug ;
      dcterms:title "Product A crashes when shutting down.";
      dcterms:creator <http://example.org/users/johndoe>;
      dcterms:created "2013-05-05T10:00"^^xsd:dateTime;
      bt:attachment <attachments/3> .

<attachments> a ldp:Container ;
   ldp:membershipPredicate bt:attachment ;
   ldp:membershipSubject <>.

We now see that there is a bt:attachment statement associated with bug 13.
This statement was added by the server when it processed the POST request
to create a new resource (attachment) and then added it as a member of the
attachments associated with the bug.

We can also see that this list can grow to be quite large. Experience has
shown, that end users of bug trackers need to attach a number of documents,
images, logs, etc. with bugs. This need also comes from a number of other
capabilities such as having nested bugs or tasks. To illustrate, let's
assume our bug tracking server has been upgrade or now exposes child
resources within bug resources (or has had children added by other means).
Let's take a look at bug 13 again:

<> a bt:Bug ;
      dcterms:title "Product A crashes when shutting down.";
      dcterms:creator <http://example.org/users/johndoe>;
      dcterms:created "2013-05-05T10:00"^^xsd:dateTime;
      bt:attachment <attachments/3>, <attachments/14> ;
      bt:child <../47>, <../2> .

# If you want to monkey with attachments using ldp:Container semantics,
look here:
<attachments> a ldp:Container ;
   ldp:membershipPredicate bt:attachment ;
   ldp:membershipSubject <>.

# If you want to fiddle with child bugs using ldp:Container semantics, look
here:
<children> a ldp:Container ;
   dcterms:title "Children for bug 13" ;
   ldp:membershipPredicate bt:child ;
   ldp:membershipSubject <>.

As you can see, the bug model stays very simple with statements about bug
13 being made directly about it using simple RDF concepts where the
statements are of the form [bug13, predicate, object|literal]. We can
repeat this pattern and use it in many other forms, such as a container of
all the bugs the serve knows about, which I plan to illustrate in other
posts.  This allows the queries that I need to construct about bt:child or
bt:attachment to be very simple, which is the typical case.  If needed,
though I don't know of the use case, I could query to separate the
membership statements based on the information provided in
ldp:membershipPredicate.

I may also want to model my set of known or reported bugs, I can do this
with the default/vanilla ldp:Container such as:

Representation of bug http://example.org/bugs <http://example.org/bugs/13>:

<> a ldp:Container ;
      dcterms:title "List of bugs, regardless of state";
      rdfs:member <13>, <2>, <47>.

For this type of container, just listing stuff, providing
ldp:membershipPredicate for rdfs:member would just be re-telling the client
what the default is.  Of course, POST could be supported on this container
to all new bug records to be created.

Agreement that this should be added to the UC&R doc?

[1] - https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-ucr.html

- Steve Speicher