- From: Henry Story <henry.story@bblfish.net>
- Date: Thu, 30 May 2013 09:32:58 +0200
- To: Steve Speicher <sspeiche@gmail.com>
- Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-Id: <77C1ABA6-A0DE-4B15-9EEF-FF73E8234542@bblfish.net>
On 29 May 2013, at 21:57, Steve Speicher <sspeiche@gmail.com> wrote:
> 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.
It's just that your Turtle did not express what you wanted it to.
It does not matter to the thrust of your argument, I suppose.
But it is an indication I hope that I am reading your
example very carefully.
>
>
> > 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.
?????
You have written it in the bug report above. It says
<attachments> a ldp:Container ;
ldp:membershipPredicate bt:attachment ;
ldp:membershipSubject <>.
??????
We furthermore used the URL to POST your attachment above !
I don't see how you can say that the URL for <attachments>
"appeared from nowhere" .
>
> 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?
In your example below you have the same number of triples. But you
express those triples by relating things that are not the container
to the created resources, and the client is meant to deduce from the
ldp:membershipPredicate that the membership relations from the
container to the content exist.
So for one the ldp:membershipXXX relations are making requirements
of reasoning. Which is why you are getting the compression of information.
If this reasoning is not expressible either in RDFs or OWL, then one may
wonder if it is carefully thought through.
Also: your modelling below is a bit weird because
why would a client end up looking in the </bugs/13/attachments/> LDPC in
order to find out that there is a relation from the </bugs/13> to
</bugs/13/attachments/3> ? Why not go an look at the bug to find that out?
>
> 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 <>.
( I suppose you meant to write
<> ldp:membershipSubject <..> . )
One way to look at ISSUE-73 is that it is saying:
- keep the bt:Bug information in the resource </bugs/13> where it belongs
( after all that resource is where the official information for that bug lives.
Ie: the final arbitrer of the bug 13 is the resource </bugs/13> . In security
scenarios I have been working on as with WebID you MUST go to the
defining URL to find the information . That is true here too)
- keep the ldp:member information in the LDPC where it belongs.
>
> 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.
Your example brought something new to the table which I had not seen clearly
before. You put the information about the ldp:membershipXXX relations in the
<bug/13> resource - a resource which is not an LDPC! I had seen those relations
only in the LDPCs themselves until now.
You described clearly a use case where someone GETs this non-LDPC, finds out
from it that he can POST an attachment to the <attachments> LDPC, and
does exactly that.
> I don't understand what renaming fixes, perhaps we should be sure the current spec model is understood.
Yes, it is a problem of understanding that we have. Naming may help fix that.
ldp:membershipXXX suggests that these relations imply membership of the
LDPC - at least for the very good reason that the domain of those relations is
an LDPC.
What we seem to have is the rule
{ ?ldpc a ldp:Container;
ldp:membershipPredicate ?p;
ldp:membershipSubject ?s .
?s ?p ?o . } => { ?ldpc rdf:member ?o }
So if we have this rule then perhaps the name makes sense.
But then whenever I mention something like a rule, I am told
that this is wrong. But if it is wrong then we should rename
these relations.
>
>
> 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.
But your domain model are the bugs and the attachments in the examples above.
I don't see why you need the LDPC which is its own domain model, to also be the
domain model of your domain of bugs and attachments.
What is it that I can't do with the examples I gave? The only thing you have is that you
are not being explicit about the inference rule.
>
>
> 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?
He finds a bug and it links to the attachment. It works just as well. I think I can rework your
examples without loss.
But here we are defining the domain model of an LDPC, not of everything
else, and you are mixing these models up, which is making things
very confusing. Have LDPCs be LDPCs and bugs be bugs.
>
> - 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/
>
>
Social Web Architect
http://bblfish.net/
Received on Thursday, 30 May 2013 07:33:34 UTC