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

Hi Steve,

On 05/28/2013 03:53 PM, Steve Speicher 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.
> 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.

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.

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

Received on Wednesday, 29 May 2013 14:36:24 UTC