- From: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
- Date: Wed, 19 Dec 2012 21:09:01 +0100
- To: Henry Story <henry.story@bblfish.net>
- Cc: public-ldp@w3.org
- Message-ID: <CA+OuRR_o1S0oAsSRV6DKPc-+DCdgUNLuVkm7=wvFfhGUkX39wA@mail.gmail.com>
(moving to public-ldp, as I'm not allowed to post on public-ldp-wg)
On Wed, Dec 19, 2012 at 1:37 PM, Henry Story <henry.story@bblfish.net>wrote:
>
> On 19 Dec 2012, at 12:52, Pierre-Antoine Champin <
> pierre-antoine.champin@liris.cnrs.fr> wrote:
>
> Henry,
>
>
> On Mon, Dec 17, 2012 at 3:58 PM, Henry Story <henry.story@bblfish.net>wrote:
>
>> I wonder if this does not raise the issue that one should at some point
>> in the spec distinguish what the server says and what the content says. I
>> think HTTP headers is what the server is saying about the content.
>
>
> I'm affraid the distinction may not always be that crisp. As long as your
> resource is not just static content PUT there by a user, but something
> dynamically computed (e.g. with PHP), then what you GET in the body is
> produced both by the author of the resource *and* by the server performing
> the computation.
>
>
> I am saying: headers are statements made by the server.
> You reply: content in the body may also be a statement the server
> contributed to.
>
> Your reply does not invalidate that point.
>
Indeed it does not. I was just pointing out that statements made by the
server did not belong *only* to headers. Sorry if I misinterpreted your
message.
> Clearly sometimes the content is a statement made by the
> server such as with the bodies to responses that have error response
> codes.
>
Agreed, but my point is that even in the case of a "200 Ok" response code,
a part of the returned content can *sometimes* be attributed to the server.
> Secondly the fact that PHP or server CPU is involved in generating content
> does not mean it is the server that is making a claim. My brain is
> involved in
> processing statements you make in this mail, but I don't jump to the
> conclusion
> that I am making those statements.
>
Of course! I was not implying that any PHP content can be attributed to the
server. But PHP allows the resource's author to let the server generate
information on which (s)he (the author) has no direct control.
> In the case of LDP, some resources may have server-computed properties,
> some of which may be application-dependant, hence not belong to the HTTP
> headers. A collection might for example compute aggregate value on the
> items they contain (total cost of my shopping cart, for example).
>
>
> If you look at the body of the content, then an LDP collection is clearly
> the type of thing you'd expect
> to be a statement made by the server. It is in the namespace of the server
> and it is pointing to other
> things that it is in control of.
>
> If you think of the server and the shop as one entity then you can mix the
> information that both are making.
> If on the other hand the server is just hosting files about sales that
> other people are making, then it needs
> to be able to distinguish those statements from statements it is making.
>
Indeed; in my system (where the content is RDF), I use different
namespaces. There are "reserved" namespace; properties in this namespace
can obly be set/changed/removed by the server.
It seems to me that you reach a similar solution in your example below,
distinguishing the server generated metadata (controlledBy) from the
user-stated one (dc:creator).
pa
>
> So sometimes many different people share beliefs, sometimes a group of
> people get together to make
> a statement, but you often need to know who is making a statement to be
> able to assess your relation to it,
> or even if it has any value at all. Only priests can marry, only chairs
> can close sessions.... ( simplifying of course)
>
>
> So I think the case of server-computed properties should be considered.
> Obviously, I agree with Raúl that the WG should not limit that list to a
> predefined set.
>
> pa
>
>
>> I think it is clear that the HTTP headers is the space for the server to
>> make statements, such as last modified and who made the edit - as the
>> server can factually know this. The content on the other hand is something
>> said by the content creator. Now the question is then is in true that the
>> following equivalence is true in n3
>>
>> { { <> dc:author ?a } = ?doc } <=> { ?doc dc:author ?a } }
>>
>
> or stated more carefully
>
> // for log see http://www.w3.org/2000/10/swap/doc/CwmBuiltins
> @prefix log: <http://www.w3.org/2000/10/swap/log#> .
>
> { ?doc log:includes { <> dc:author ?a } } <=> { ?doc dc:author ?a } }
>
> So if you accept the above then the server must maintain control over
> dc:author
>
> If you model the server as host content said by someone else, then you
> could have
> the following:
>
> <doc1> dc:author <jack> ;
> dc:updated "2012-12-12"
> log:includes { <> a document;
> dc:author <
> http://dbpedia.org/resource/Jean_Jacques_Rousseau>;
> dc:updated "1777-07-08" .
> }
>
>
> now this is contradictory only if one can have one author. But it does
> show that the server
> should perhaps have a more limited notion of authorship, more something
> like - controllership of
> a resource. in which case it would make sense to have a document that was
> authored by
> someone, yet controlled by someone else. Perhaps this is better:
>
> <doc1> controlledBy <jack> ;
> dc:updated "2012-12-12"
> log:includes { <> a document;
> dc:author <
> http://dbpedia.org/resource/Jean_Jacques_Rousseau>;
> dc:updated "1777-07-08" .
> }
>
> Henry
>
>
>>
>> On 2 Oct 2012, at 16:14, Linked Data Platform (LDP) Working Group Issue
>> Tracker <sysbot+tracker@w3.org> wrote:
>>
>> > 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]
>> >
>> > http://www.w3.org/2012/ldp/track/issues/11
>> >
>> > Raised by: Raúl García Castro
>> > On product: Linked Data Platform core
>> >
>> > "4.4.1 If HTTP PUT is performed on an existing resource, BPR servers
>> must replace the entire persistent state of the identified resource with
>> the entity representation in the body of the request. The only recognized
>> exception are the properties dcterms:modified and dcterms:creator that are
>> never under client control - BPR servers must ignore any values of these
>> properties that are provided by the client."
>> >
>> > I think that saying that dcterms:modified and dcterms:creator cannot be
>> modified by clients is an application-specific restriction.
>> >
>> > I would not include it, but if you think that it is relevant, I would
>> rewrite it in the style of 5.5.2:
>> > "BPR servers MAY ignore server managed properties such as
>> dcterms:modified and dcterms:creator".
>> >
>> >
>> >
>> >
>>
>> A short message from my sponsors: Vive la France!
>> Social Web Architect
>> http://bblfish.net/
>>
>>
>
>
> On Mon, Dec 17, 2012 at 3:58 PM, Henry Story <henry.story@bblfish.net>wrote:
>
>> I wonder if this does not raise the issue that one should at some point
>> in the spec distinguish what the server says and what the content says. I
>> think HTTP headers is what the server is saying about the content. I think
>> it is clear that the HTTP headers is the space for the server to make
>> statements, such as last modified and who made the edit - as the server can
>> factually know this. The content on the other hand is something said by the
>> content creator. Now the question is then is in true that the following
>> equivalence is true in n3
>>
>> { { <> dc:author ?a } = ?doc } <=> { ?doc dc:author ?a } }
>>
>>
>> On 2 Oct 2012, at 16:14, Linked Data Platform (LDP) Working Group Issue
>> Tracker <sysbot+tracker@w3.org> wrote:
>>
>> > 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]
>> >
>> > http://www.w3.org/2012/ldp/track/issues/11
>> >
>> > Raised by: Raúl García Castro
>> > On product: Linked Data Platform core
>> >
>> > "4.4.1 If HTTP PUT is performed on an existing resource, BPR servers
>> must replace the entire persistent state of the identified resource with
>> the entity representation in the body of the request. The only recognized
>> exception are the properties dcterms:modified and dcterms:creator that are
>> never under client control - BPR servers must ignore any values of these
>> properties that are provided by the client."
>> >
>> > I think that saying that dcterms:modified and dcterms:creator cannot be
>> modified by clients is an application-specific restriction.
>> >
>> > I would not include it, but if you think that it is relevant, I would
>> rewrite it in the style of 5.5.2:
>> > "BPR servers MAY ignore server managed properties such as
>> dcterms:modified and dcterms:creator".
>> >
>> >
>> >
>> >
>>
>> A short message from my sponsors: Vive la France!
>> Social Web Architect
>> http://bblfish.net/
>>
>>
>
> A short message from my sponsors: Vive la France!
> Social Web Architect
> http://bblfish.net/
>
>
Received on Wednesday, 19 December 2012 20:09:30 UTC