W3C home > Mailing lists > Public > public-ldp-wg@w3.org > December 2012

Re: "Hosting POSTed resources" user-story

From: Eric Prud'hommeaux <eric@w3.org>
Date: Mon, 3 Dec 2012 03:07:41 -0500
To: Steve Battle <steve.battle@sysemia.co.uk>
Cc: public-ldp-wg@w3.org
Message-ID: <20121203080739.GC17042@w3.org>
* Steve Battle <steve.battle@sysemia.co.uk> [2012-12-02 20:10+0000]
> 
> On 2 Dec 2012, at 16:41, Eric Prud'hommeaux <eric@w3.org> wrote:
> 
> > * steve.battle@sysemia.co.uk <steve.battle@sysemia.co.uk> [2012-12-02 15:43+0000]
> >> Eric,
> >> 
> >> I've had no takers for my request to edit the "Hosting POSTed resources", so as this is roughly in line with your current task to add narrative for ISSUE-30 I'd like to combine them. i.e. Volunteer you.
> > 
> > yeah, i figured that was coming
> 
> Thanks Eric - I knew you'd be up for it. 
> 
> > 
> >> I think "Hosting POSTed resources" can be renamed as "Hierarchical bugtracking service", and the user story can talk about the capabilities you'd like in such a service. Links to real tools (and ontologies?) offering equivalent functionality would be useful.
> > 
> > What I meant by hosted resources is what folks were trying to get to with the relative URLs discussion. Specifically, is there a pretty standard mechanism for the server to rename certain nodes in a POSTed graph (in order to serve them), and do we have a name for that?
> 
> I'd be very happy for the narrative to include something on relative URIs (basically capturing what TBL was saying at the F2F - see issue-29), this is something else missing from UC&R.
> 
> > I wasn't aware that the relative URLs discussion came to a conclusion that
> > 
> >      POST { <> :foo :bar }
> >        ⇘
> >          Location: http://example.org/resource1
> >        ⇙
> > 
> > implied that <http://example.org/resource1> had
> >  { <http://example.org/resource1> :foo :bar }
> > 
> 
> Mmm, depends what your arrows mean; the URI the that RDF is being POSTed to, or the URI created by the POST. I'll assume the latter to make the example work. The outcome of the relative URI discuss was simply that in a POST the null relative URI refers to the created resource.

Yep, that's what I intended.

> So, if your container is <http://example.org> and you POST { <> :foo :bar} to it, then a new (contained) resource is created. Assume the new resource is identified as <http://example.org/resource1>; this URI is returned in the location header of the response. It is now true that: <http://example.org/resource1> :foo :bar.
> 
> > If it does, should we call out the fact that any relative URLs posted to the server are "hosted"? OTOH, all this story does is name an aspect which is likely present in most of the user stories. I can add it to a story about portability between containers, just to give it a home, but that might make readers think that the two are linked.
> > 
> 
> It helps if the stories are scoped by discussion of a specific application. Keep it as concrete as possible and don't worry about conceptual overlap.
> In particular, the reassignment of resources (from your examples in issue-30) resulting from merging bugs reports is common practice.
> 
> I have a placeholder use-case scenario ready and waiting for this particular scenario <http://www.w3.org/2012/ldp/wiki/Use_Cases_And_Requirements#Alternative_scenario:_Moving_contained_resources_.28TBD.29>

I filled this out, but used as an example an earlier use case about Research Objects. There is already a create_a_nested_container use case, which sort of implies hierarchy.
<http://www.w3.org/2012/ldp/wiki/Use_Cases_And_Requirements#Alternative_scenario:_create_a_nested_container>
This use case also leans on the Hosting POSTed Resources user-story. I think also that eliminating this user story eliminates the last reference to one of the main features of LDP, specifically POSTing data to a container and having it create a deferencable resource.

Business relationships talks about collections as a set of links and has a forward ref to simple collections. Library Linked Data is the first use case to discuss any properties of a collection (specifically, aggregate description and discovery). I propose instead a paragraph before Maintaining Social Contact Information (which briefly references collections):

[[
  The following user stories describe ways to store and share information on the web, including a notion of "containment" within some other resource.
]]

This would permit renaming "Hosting POSTed Resources" to "Creating Dereferencable Resources", with this text:

[[
It would be convenient to use containers as an interface for creating the resources (e.g. by HTTP POST to the container).
This enables clients to defer to some container to establish dereferencable identifiers for persistent data.
The container is a natural choice for the endpoint for this interface as it will likely already have some specialized knowledge about the contained resources. A container may
  * accept from a client a requested to make a new resource.
  * tailor the data sent from the client.
  * change some of the terms in that data to match the identifier for newly created resources.
]]


> Once we have the user-story narrative, we can re-work an example for the scenario. I'm not putting examples in the stories - too much detail.

I understand there's been some pressure in that direction, though I feel that examples make it much easier for a reader to understand a user story or use case. (I recognize that this is a minority opinion.)

> > 
> >> * nested containers
> >> * moving resources between containers.
> >> 
> >> Thanks in advance, Steve.
> >> 
> >> On 29 Nov 2012, at 00:10, steve.battle@sysemia.co.uk wrote:
> >> 
> >>> I would like a volunteer to rewrite the "Hosting POSTed resources" user-story <http://www.w3.org/2012/ldp/wiki/Use_Cases_And_Requirements#Hosting_POSTed_Resources>. The story would also benefit from being renamed.
> >>> 
> >>> Currently, it is a single example that motivated discussion about identifying and naming a created resource from within a posted RDF representation (the resulting resolution of issue-20 being that the null relative URI named the created resource). Tim Berners-Lee also raised the related "relative URIs are crucial" issue (resolved by issue-29 as best-practice).
> >>> 
> >>> We think it would be good to keep these issues represented as a user-story. We need a paragraph or two covering the issues; Why are these relative URIs useful in particular applications? However, in it's present form it'll have to go. 
> >>> 
> >>> Steve.
> >>> 
> >>> Steve Battle
> >>> 
> >>> -- 
> >>> Steve Battle
> >>> Semantic Engineer
> >>> 
> >>> E-mail: steve.battle@sysemia.co.uk
> >>> Web: www.sysemia.com
> >>> 
> >>> Sysemia Limited
> >>> The Innovation Centre, Bristol&  Bath Science Park, Dirac Crescent, Emerson's Green, Bristol BS16 7FR
> >>> Registered in England and Wales. Company Number: 7555456
> >>> 
> >>> DISCLAIMER
> >>> 
> >>> Information contained in this e-mail is intended for the use of the addressee only, and is confidential and may also be privileged. If you receive this message in error, please advise us immediately. If you are not the intended recipient(s), please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. Attachments to this e-mail may contain software viruses which may damage your systems. Sysemia Ltd have taken reasonable steps to minimise this risk, but we advise that any attachments are virus checked before they are opened.
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >> 
> > 
> > -- 
> > -ericP
> 

-- 
-ericP
Received on Monday, 3 December 2012 08:15:19 UTC

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