W3C home > Mailing lists > Public > public-ldp-wg@w3.org > February 2013

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]

From: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
Date: Mon, 4 Feb 2013 15:42:13 +0100
Message-ID: <CA+OuRR-UErgznGPrzPEwOpqJ3E=CWTaOEdC7Dajb=R29-V7dWw@mail.gmail.com>
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>
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

This archive was generated by hypermail 2.3.1 : Thursday, 9 May 2013 13:44:29 UTC