Re: 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?
> 
> You just want to be able to conflate LDPC membership with your own
> domain model. I still think this is not a good idea. Several people
> made the case that mixing the LDP vocabulary and the domain one is
> bad.
> 
> Let's say I have a Linked Data client, which is just allowed to follow
> links and dereference URLs. Now, I have to search for
> ldp:membershipPredicate -- if it exists... -- before I know how to
> find the members. That's some extra logic, I would prefer not having
> to do that. That would simplify everything.

hi Alexandre, 

If you have a generic LD client, which is following links and dereferencing URLs, I really don't see why you need to worry about GETing an LDPC. I think that a generic LD client (which is conversant with LDP), navigates LDPRs, and uses LDPC's support the non-read interaction.  I'm just re-iterating what I said yesterday here on that, really, but, I recognise that there are differing opinions on that :) !! 

Regarding your comment about  SPARQL. I agree that a SPARQL endpoint is really useful (but optional). In my opinion (or for my usecases at least), I would expect that the default graph behind a SPARQL endpoint would cover a *group* of related LDPR resources (it might be useful to have a link from each LDPR to that useful SPARQL endpoint). 

What I am really taking from your comment here is how it exposes the differences in how people are viewing LDP. It seems clear to me that you want to use LDP to do "Documents about Things into Boxes". Would you agree ? You might argue next that that the only thing that we should be doing with LDP :) !! Actually, I think that is the fundamental reason why we are having this blast of intensity in the discussions right now. 

regards, 
Roger


> 
> Also, what happens if there is both rdfs:member and
> ldp:membershipPredicate? The problem is that we cannot make a choice
> easily. We have to be ready to change the state of the client
> depending on some property, which may happens at any moment (the
> content could be streamed). This is an extra constraint on the client
> that seems not necessary.
> 
> Here is another argument. Let's say you want to extend an LDPC with
> some SPARQL capabilities (that's very natural), where the LDPC is the
> default graph and its members are named graphs. Now try to think about
> the query that would give you these members and you'll see that there
> is something wrong, as you need to handle two cases: with and without
> ldp:membershipPredicate. For me this is really fishy.

> I hope this is enough for discouraging people from making this a new
> entry in UC&R.
> 
> Alexandre.
>