Re: Missing use case for supporting ldp:membershipPredicate/Subject

Thanks for putting this together Steve.

On 28 May 2013, at 21:53, Steve Speicher <sspeiche@gmail.com> wrote:

> 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. 

Ok so the problem here seems to be that you are missing a way of expressing 
what types of relations your container can contain. Is this not something 
that the rdf-validation group  is meant to work on?

   https://www.w3.org/2012/12/rdf-val/Overview.php

Whaever, I don't want to argue that one has to wait for them to do that.

> 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 <>. 

( my guess work before reading the rest was:
So a client doing a GET on <http://example.org/bugs/13> would receive the above?
And so he would know that by POSTing something to <attachements/> he would create 

 1. a new resource in 
    http://example.org/bugs/attachments
    lets call it <attach1> .
 2. a new relation expressed in http://example.org/bugs/13 from
    bug 13 to the new attachment. This relation
    <> bt:attachment <attacments/attach1> .

So that seems useful indeed....
)
    

> 
> 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.

Minor nit: your attachment url is <http://examples.org/bugs/attachments> as expressed above because your
bug url did not end in a '/' . Your statement should have been

   <13/attachments> a ldp:Container ...

even better would be

   <13/attachments/> a ldp:Container ...


> 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 <>.

Ok. I was guessing correctly above :-)

So ISSUE-73 "LDPCs to list all their rdf:member" is just arguing that it should
be required that the ldp:Container <attachments> also list all of 
its members with the rdf:member relation when a GET request is made on it.

ie a GET on <attachments> should return

~~~~~~~ GET /bugs/13/attachments/ HTTP/1.1 ~~~~~~~~~~
<> a ldp:Container;
   rdf:member <1>, <2>, <3> .
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Does this seem unreasonable? 
It would greatly help clients to know what the content of the LDPC
is for many many reasons. 

So what it seems to me is that ldp:membershipProperty is just a way 
to specify in </bugs/13> ( and not in <13/attachments> ! ) that
if you want to create an attachment on the bug you should POST over
in that container. This is why I opened ISSUE-76  "rename the 
ldp:membershipXXX properties". 

That would solve your use case just as well without mixing up
LDPC membership and relations on your bugs.

So I hope that makes the case that one can solve your use case
while also accepting 

  ISSUE-71 ( membershipX )  No membershipSubject or membershipPredicate
  ISSUE-73 ( rdf:member )   LDPCs to list all their rdf:member
  ISSUE-75 ( monotonicity ) rdf:membershipProperty makes LDP PATCHing non-monotonic
  ISSUE-76 ( rename membershipXXX ) rename the ldp:membershipXXX properties

I hope that helps.

> 
> 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:
> 
> <> 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

Social Web Architect
http://bblfish.net/

Received on Wednesday, 29 May 2013 18:27:50 UTC