Re: Prefer URI for LDP Server Managed Properties

Hi Steve, John,

The idea for the URI came from observing the reaction of our client
developers trying to interact with the server.  They were initially
surprised when there was a bunch of other triples that came back after they
created a resource and retrieved it.  Then they set to work to strip them
all out, and realized some are harder to discover than others when the
server uses common ontologies.  So they asked if the server could strip
them out as it knows what it has added.

As there's already a method to omit or include containment and membership
properties, plus the move towards a stronger definition of server managed
properties, we figured the easiest way was to reuse the same prefer-omit
pattern... and hence needed a URI.

The reason they need to strip them out rather than just ignoring them is
that the client to the LDP platform is actually middleware that produces
JSON-LD with a specific context and frame, such that its client sends and
receives only the JSON structure that it expects.  That structure is this,
fwiw:
    http://www.openannotation.org/spec/core/publishing.html#Serialization

We're happy to use an internally defined URI for now and wait for the next
round of discussion to make it more formal if it's seen as useful.

Rob







On Fri, Oct 17, 2014 at 7:24 AM, John Arwe <johnarwe@us.ibm.com> wrote:

> > Given the discussion regarding server managed properties, we think
> > it would be useful to define them formally ...
>
> *Since I think this is editorial*, i.e. it would not alter the progression
> of the spec process-wise, I've been leaning in that direction too as the
> discussion probably suggests.
>
> > ... and give them an
> > identifying URI for the prefer header.
>
> Your email is the first I've heard or suspected that they need a URI for
> any reason, so this "less obvious" to me at the moment.
> As in: "why again?"  i.e. which *existing* use cases don't the existing
> specs cover, and this new URI closes that gap?
>
> > ...  That would allow clients to send:
> >     return=representation;omit=
> http://www.w3.org/ns/ldp#preferServerManaged
> >  to exclude those properties in a standard way.
>
> It's true that LDP could define that.
> I'm still flummoxed at "why again?" though.
> Adding this also raises the bar on specificity and completeness, since
> (even if supporting this hypothetical new preference is optional)
> implementations need to have a reliable sense of whether or not they're
> implementing it "correctly".
>
> If there's a new use case that you want to *add* to the current LDP 1.0
> scope, proposing a change to the UC&R document would be the first step.
> Otherwise, back to "...existing..." above.
> Given that we're one step away from the AC voting step on base LDP, my
> guess is that it would have to be a pretty glaring omission for the WG to
> add it to 1.0.
>
> Dealing with it in LDP-next would be the default starting point.
>
>
>
> FYI: I expect to be pseudo-offline for an indeterminate period (order:
> days) starting today due to having to mail my laptop out for repairs.  I'm
> going to draft some of the changes for recently converged discussions later
> today, but I may have to post news of that from my GMail ID or some other
> random place depending upon how nicely the loaner PC plays with me.
>
> Best Regards, John
>
> Voice US 845-435-9470  BluePages
> <http://w3.ibm.com/jct03019wt/bluepages/simpleSearch.wss?searchBy=Internet+address&location=All+locations&searchFor=johnarwe>
> z/VM OpenStack Enablement and zKVM
>
>


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