Re: ldp-ISSUE-11 (Server-managed properties): Do we need to define server-managed properties or do we leave them to applications? [Linked Data Platform core]

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

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



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/