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

On Wed, May 29, 2013 at 2:27 PM, Henry Story <henry.story@bblfish.net>wrote:

> 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.
>
> That would help with one of the cases I mentioned yes but agree we don't
need to discuss further.

> 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?
>
Seemed obvious based on other examples I saw sent to the list but yes.


> 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 ...
>
> Not sure why this matters but yes we can add a '/' if it helps fix
something.


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

How do you know about the URL for the LDPC of <attachments>?  This seems to
have appeared from no where.  In my example, you know this based on the
rdf:type ldp:Container, ldp:membershipSubject linking the container to
/bug/13 and ldp:membershipPredicate to bt:attachment on that subject
resource.


> 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?
>
This seems to double the number of triples I need to communicate to a
client to support my domain model?

The example for what the response would be based on the current draft of
the spec, it would be:
(BTW this is the result of doing a GET on /bugs/13/attachments/)

<..> a bt:Bug ;
       bt:attachment <attachments/3> .

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

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

What does "specify in </bug/13> mean"?  I specified within the subject of
the ldp:Container what ldp:membershipPredicate is.  Perhaps there is some
confusion on how you use ldp:membershipPredicate.

I don't understand what renaming fixes, perhaps we should be sure the
current spec model is understood.


>
> That would solve your use case just as well without mixing up
> LDPC membership and relations on your bugs.
>
I highlight a few gaps you have.  A key requirement is: a) I don't need a
large transformation layer to make my resource representations compliant b)
I don't need to go back to my application and change the business logic of
working with the model c) I can layer on the needed information to help
those clients (and servers) to handle some additional LDP semantics.

One of the key requirements of this is being able to query of my domain
model efficiently while complying with LDP as well, without having to go
through some unnatural levels of indirection.


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

I think the inverse is true, I'm not seeing what your proposal fixes
instead of one use case where some general LDP client can query and ask for
give me all membership triples for LDPC.  How to an end user does this use
case actually surface?

- Steve Speicher


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