- From: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
- Date: Mon, 4 Feb 2013 15:42:13 +0100
- To: Henry Story <henry.story@bblfish.net>
- Cc: Sergio Fernández <sergio.fernandez@salzburgresearch.at>, Raúl García Castro <rgarcia@fi.upm.es>, "Linked Data Platform (LDP) Working Group" <public-ldp-wg@w3.org>
- Message-ID: <CA+OuRR-UErgznGPrzPEwOpqJ3E=CWTaOEdC7Dajb=R29-V7dWw@mail.gmail.com>
Henry, On Mon, Feb 4, 2013 at 2:44 PM, Henry Story <henry.story@bblfish.net> wrote: > > On 4 Feb 2013, at 14:31, Pierre-Antoine Champin < > pierre-antoine.champin@liris.cnrs.fr> wrote: > > Hi, > > I'm a bit uncomfortable with *ignoring* server-managed properties in what > the client submits. I would rather have the server *refusing* (with 403 > Forbidden) any client-submitted content that tries to set or change > server-managed properties. > > And I think that this extends to the problem raised by Sergio: can the > client PUT arbitrary triples to an LDPR, even triples about another > resource? My answer would be that it is up to the server. I would propose > to reformuate Section 4.4.1 [1]: > > [[ > If HTTP PUT is performed on an existing resource, LDPR servers must > replace the entire persistent state of the identified resource with the > entity representation in the body of the request. > > However, LDP servers MAY impose constraints on the state of LDPRs, > and MUST reject (with a 403 status code) a PUT request if the entity > representation in the body of the request fails to meet those constraints. > > Any LDPR servers that wish to support a more sophisticated merge of > data provided by the client with existing state stored on the server for a > resource must use HTTP PATCH, not HTTP PUT. > ]] > > We should probably provide some examples of the kind of constraints that > an LDP server can impose on the states of its LDPR: > > * an indentified set of property can only be set or changed by the server, > and should be left unchanged by PUT or PATCH requests > > * the state of an LDPR should be a Concise Bounded Description [2] of that > LDPR > > * the state of an LDPR <u> should be a union of CBDs, only about <u> and > resources whose URI is of the form <u#f> > > > Are you saying that a graph should be restricted that way? > not at all; I wrote that some servers MAY impose such constraints, and the three points above are only *examples* of the kind of constraints some servers may wish to define. > That seems too strong to me. What does > make sense, as I argued in the thread "Estabilishing conversational > context" > http://lists.w3.org/Archives/Public/public-ldp-wg/2013Feb/0032.html > there may be properties on the LDPR <> that is data that should probably > appear in the LDPC on that resource, such as dcterms:modified and > dcterms:creator > and other relations similar to the ones you would find in an atom:entry ( > ie: the metadata for the resource ). > Absolutely. LDPC are good examples where CBD will probably not be satisfactory. On the other hand, the server will probably not accept a PUT request to an LDPC that tries to change properties of its members. > If you want mechanisms to advertise restrictions on graphs for particular > purposes > then you should work on ISSUE-48 "Profile mechanism is Needed", and find > some > good use cases for it, so that we can then open it, with an idea as to > what it would > be to close it. > > http://www.w3.org/2012/ldp/track/issues/48 > I like the idea of profiles. Whether we should or not design a language to formally describe them, I'm not sure... I like Erik's idea that 'formally describe for [him] usually means "spec language is good enough"' [1]. pa [1] http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jan/0338.html > > > > Henry > > > pa > > [1] https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpr-4_4_1 > [2] http://www.w3.org/Submission/CBD/ > > > On Mon, Feb 4, 2013 at 9:35 AM, Sergio Fernández < > sergio.fernandez@salzburgresearch.at> wrote: > >> Hi, >> >> On 30/01/13 18:30, Sergio Fernández wrote: >> > On 30/01/13 09:17, Raúl García Castro wrote: >> >> .- To include in 4.4.1 the following statement: >> >> [[ >> >> However, BPR servers MAY ignore server-managed properties. >> >> ]] >> >> >> >> One example of the need for this second statement is the following: I >> >> upload a photo to flickr and later I try to update this photo saying >> >> that the owner is another person. flickr business logic won't allow me >> >> to do that. >> > >> > I see the use case. Let me think about it, and I'll come back with a >> > more detailed proposal for sec. 4.4.1. >> >> >> Based on what we discussed Raúl and me, here my proposal to replace the >> current text at Section 4.4.1 [1]: >> >> [[ >> If HTTP PUT is performed on an existing resource, LDPR servers must >> replace the entire persistent state of the identified resource with the >> entity representation in the body of the request. However, the only >> recognized exception is that LDPR servers MAY ignore server-managed >> properties under the normative ldp namespace. Any LDPR servers that wish >> to support a more sophisticated merge of data provided by the client >> with existing state stored on the server for a resource must use HTTP >> PATCH, not HTTP PUT. >> ]] >> >> Additionally, from my experience experimenting with this [2] and my >> experimental implementation in Apache Marmotta, I'd like to ask about >> the RDF payload in LDPx: do you plan to specify some constraints there? >> I mean, common REST APIs usually define flat data structures for it; but >> handle RDF is much more complex. >> >> For instance, taking this request as example: >> >> PUT /foo/bar >> Host: example.org >> Content-Length: x >> Content-Type: text/turtle; charset=UTF-8 >> >> Handle payload like this: >> >> @prefix ex: <http://example.org/ns#> . >> :subject ex:prop "value" . >> >> would be easy, because the server just needs to digest the data to get: >> >> <http://example.org/foo/bar> ex:prop "value" . >> >> But, what happens in the case where a named entity (with its URI) comes >> at the body of the requests? Moreover, how to handle when several >> entities are pushed to a single LDPR? >> >> Use request's URI as base for parsing the body could be a valid approach >> for PUT operations over LDPCs (Section 5.5 [3]), but IMO not enough for >> LDPRs. So, at the end, there is a process to identify the subject of the >> payload. And that's something that I missed in the current spec. >> >> Cheers, >> >> [1] https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpr-4_4_1 >> [2] >> >> http://code.google.com/p/djubby/wiki/ReadWriteLinkedData#RDF_payload_translation >> [2] https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#http-put-1 >> >> -- >> Sergio Fernández >> Salzburg Research >> +43 662 2288 318 >> Jakob-Haringer Strasse 5/II >> A-5020 Salzburg (Austria) >> http://www.salzburgresearch.at >> >> > > Social Web Architect > http://bblfish.net/ > >
Received on Monday, 4 February 2013 14:42:45 UTC