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]

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

I really agree with where this might go to. 

PUT is really a bit of a loose cannon, and PATCH seems to require a new language. I can see that PUT is fine for some scenarios, but, in other cases, I would like to see hypermedia-driven update mechanism which offers more control and discoverability. It seems that this might be in LDP++ scope now -- but, we need keep this in mind all the same. Maybe you are interested in my proposal [1] (unfortunately still not quite finished) this covers these aspects. The base assumption of is that *every* link of a resource is a manageable. Something I am missing from Johns proposal - but, I might be wrong.

I think the point you make about CBD is worth exploring - it works for many of the scenarios that we are looking at. But, I can see (and understand too) that there might be complaints.

Roger

[1] http://www.w3.org/2012/ldp/wiki/Bug-tracker_LDP_service

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