Re: Container Questions

Thanks John!

Agreed with all of your counterpoints below :)

Just making sure that the spec was intentionally silent on all of them (and
hence we and others can do as we prefer) rather than unintentionally.

Rob


On Fri, Sep 12, 2014 at 7:39 AM, John Arwe <johnarwe@us.ibm.com> wrote:

> If the spec is silent on something, generally I think the expectation is
> to read those cases as MAY, rather than SHOULD, keeping in mind that
> 2119-SHOULD isn't a synonym for MAY as many devs seem to think.
> With that translation assumed to be applied to your email, I think all of
> your readings are allowed but not all would be what "most" will do.
>
> > 1.  It seems like an LDP system can create all of the resources
> > POSTed to a container in one operation, and should arbitrarily pick
> > one for the response.
>
> "arbitrary" server choices usually are hard for clients to cope with,
> especially clients that aspire to be general ones.
> An LDP-centric server dev might create a container for the set and return
> the container's URL.
> A "vanilla RDF store" dev might simply store the entire input graph and
> assign 1 URL, since the presence of multiple distinct subject URIs in an
> RDF graph is perfectly normal.
> Which is more logical in any particular case might depend mostly on the
> vocabulary in use and to what degree the server "understands" that
> vocabulary (uses it to affect processing).  A vanilla graph store is not
> going to react to say an OSLC Change Request resource the same way an OSLC
> Change Mgmt server would; even if the LDP-governed portions of the result
> were identical, the side effects will be very different.
>
> > 2.  It is unspecified what happens when the entity-body POSTed to an
> > IndirectContainer does not contain the insertedContentRelation
> > predicate, and thus the system can do what it thinks best
>
> Personally I think most would reject it, but I have no objective reason to
> say that.
> Not asserting anything != asserting a default, semantically.
> OTOH in certain application domains governed by a higher level interface
> contract layered over top of LDP, that semantic might be part of the
> contract.
>
> > 3.  Systems should support multiple containers with the same
> > membershipResource and the same hasMemberRelation? For example one
> > resource with both direct and indirect containers, both of which
> > contribute to populating the same pool of members in the membership
> > resource.
>
> I think it's going to very much depend on how much control you have over
> the graph.  If you're trying to use LDP as a way to get consistent
> interfaces draped over existing graphs that you can't just change
> incompatibly, then you might very well end up doing what you describe.  If
> you're doing something new from scratch, "who needs anything more than a
> Basic Container??" has been the loud oft-repeated refrain from several in
> the wg.
>
> I can see both sides; but coming from my background, I suspect that even
> the currently-new Basic-only ones will eventually become "legacy" data (if
> they're successful; and if not, "who cares") so many will end up doing what
> you describe over time.  Reality is messy, inconvenient, and annoying
> sometimes^W most times, but to paraphrase Woody Allen it's still the only
> place you can get a good steak.
>
> 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>
> Cloud and Smarter Infrastructure OSLC Lead
>



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