Prefer URI for LDP Server Managed Properties

All,

Given the discussion regarding server managed properties, we think it would
be useful to define them formally and give them an identifying URI for the
prefer header.  That would allow clients to send:
    return=representation;omit=http://www.w3.org/ns/ldp#preferServerManaged

 to exclude those properties in a standard way.

Rob


On Tue, Oct 14, 2014 at 9:29 AM, Robert Sanderson <azaroth42@gmail.com>
wrote:

>
> Hi John,
>
>
>
> On Tue, Oct 14, 2014 at 7:41 AM, John Arwe <johnarwe@us.ibm.com> wrote:
>
>>
>> Also note that HTTP PUT can function semantically as either create or
>> update, depending upon the prior existence of the resource identified by
>> the request URI.
>>
>
> +1.
>
> Is it worth making the distinction clearer in the spec as to how this
> affects the interpretation of the requirements for PUT?  Probably not at
> this stage, would be my assumption.
>
>
>
>> My reading of 4.2.4.1 is that "replace" covers both cases, and 4.2.4.3
>> covers modify (hence the change/modify words) but not create; although in
>> practice since it is true as you note that servers can reject requests for
>> all sorts of reasons, my "but not create" might make no practical
>> difference.
>
>
>
> > 1: write-once (by client) ... e.g. dcterms:previousVersion
>> > Doesn't this conflict with the note in .3 that says write-once
>> > properties are *not* server-managed?
>>
>> Sigh, more sub-cases.
>> Nice to have a fresh reader who still sees the words as written instead
>> of the cached copy in my wetware.
>>
> :) Sorry for the pedantics.
>
>> My best (albeit weaselly and weak) backward-looking defence is to point
>> out that the note is non-normative.
>>
> It is ... but it would not be good to have a note that conflicts with the
> normative text.
>
>
>
>> More germanely though, "write-once" != "write on create only"; "write on
>> create only" and "write once after create" are arguably distinct sub-cases
>> if we continue to rely on the CrUd distinctions, which I think will help
>> readers more than it will harm them.
>>
> Agreed.
> Rather than bogging down the spec with all of the distinctions, perhaps
> they belong in an ancillary (but linked) document, with non-normative
> clarifications pointing back into the spec for the clauses that affect them?
>
>
> > Implementers MAY WISH TO [1] apply 4a or 4b in different situations
>> > according to how they consider a particular property.
>> We appear to have consensus on this.
>> (And let anyone with a lesser-degree belt in RFC-foo be April-fooled into
>> thinking 6919 supersedes 2119, look at its publication date and status -
>> Google isn't the only org that does April Fool's jokes.)
>>
> MAY WISH TO was very carefully chosen ;)
>
> > LDP servers MAY ignore properties that have server supplied values,
>> > including their omission from the body of the request.
>>
>> I don't see a definition for "server supplied", so I cannot comment on
>> the utility of this change.
>>
>
> Sorry, that must have been part of a previous draft.
>
>
>
>>
>> > - .3 applies to containership triples, and possibly moves up to General
>> > ...
>> > And isn't there a conflict already?
>>
>> I don't think there's a conflict in today's text.  [snip]
>>
>
> Okay, I see the logic, thank you for the clarification :)
>
>
>
>> I wonder out loud if we change (really: add) the definition+name of
>> "server-managed" to be "LDP-server-managed", to be as constrained by the
>> LDP spec, and then note (perhaps alongside, or with link to, 4.2.1.6) the
>> existence of additional constraints (not LDP imposed) that the server might
>> have for rejecting any request), is this neatly wrapped up?
>>
>> The thinking being that
>> - calling them "LDP-server-managed" [wham] baby seals readers each time
>> it comes up
>> - using that term consistently in place of today's varying language
>> [wham] shaves off another set of unintended readings
>> - explicitly mentioning the (now distinct rather than overlapping) issue
>> of other non-LDP constraints causing requests to be rejected [wham]
>> untangles it from the LDP requirements
>>
> Yes. Please. :) I think this would make the spec significantly clearer,
> reducing confusion in readers (such as myself!), and thus increasing the
> interoperability of products [legitimately or not] claiming conformance.
>
> Rob
>
> --
> Rob Sanderson
> Technology Collaboration Facilitator
> Digital Library Systems and Services
> Stanford, CA 94305
>



-- 
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305