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>

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