Re: "Hosting POSTed resources" user-story

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.
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>
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.


> 
>> * 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

Received on Sunday, 2 December 2012 20:11:02 UTC