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

Re: Operations on containers

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Sat, 20 Oct 2012 11:33:03 +0100
Message-ID: <50827DDF.5040606@epimorphics.com>
To: public-ldp-wg@w3.org


On 19/10/12 18:46, Ashok Malhotra wrote:
> James:
> At another time, in another context I suggested a new HTTP verb (MGET to get
> the metadata for a resource) and was told that there was no way that
> adding a new HTTP
> verb would be accepted.
>
> The LDP position is to use POST/PATCH/DELETE on the container to do what
> you want to do
> with LINK/UNLINK.
>
> I think it's worth listing requirements and asking how they translate to
> POST/PATCH/DELETE
> on the container.  For example:
>
> 1. Create a resource and add it to a container
> 2. Add an existing resource to a container
> 3. Remove a resource from a container
> 4. Remove a resource from a container and delete it
>
> Henry has provided some answers but it would be good to have them
> written down,
> perhaps as a table.

+1 - good plan

	Andy

>
> All the best, Ashok
>
> On 10/19/2012 9:46 AM, James M Snell wrote:
>> FWIW... this is precisely the kind of use case that has led me to
>> explore the re-introduction of the LINK and UNLINK http methods.
>>
>> http://tools.ietf.org/html/draft-snell-link-method-01
>>
>> Consider...
>>
>> 1) Create the item
>>
>>   PUT /profiles/james HTTP/1.1
>>   Host: example.org <http://example.org>
>>   ...
>>
>> 2) Link that item to an existing collection
>>
>>   LINK /profiles/james HTTP/1.1
>>   Host: example.org <http://example.org>
>>   Link: <http://example.com/my/friends>; rel="collection"
>>
>> 3) Link the collection to the item
>>
>>   LINK /my/friends HTTP/1.1
>>   Host: example.com <http://example.com>
>>   Link: <http://example.org/profiles/james>; rel="item"
>>
>> - James
>>
>>
>>
>> On Fri, Oct 19, 2012 at 9:38 AM, Henry Story <henry.story@bblfish.net
>> <mailto:henry.story@bblfish.net>> wrote:
>>
>>
>>     On 19 Oct 2012, at 18:32, Ashok Malhotra
>>     <ashok.malhotra@oracle.com <mailto:ashok.malhotra@oracle.com>> wrote:
>>
>>>     If I have another usecase.  I have an, already created, resource
>>>     R which has a URI and I
>>>     want to put it in a container C.  Is that possible
>>
>>     it should be.
>>
>>     you put
>>
>>     <http://mydomain.com/foaf#me> a foaf:Person .
>>
>>     to
>>
>>     <http://data.fm/friends>
>>
>>     then you would have
>>
>>     <http://mydomain.com/foaf#me> a foaf:Person .
>>
>>     in
>>
>>     <http://data.fm/friends>
>>
>>     if you PUT
>>
>>     <#me> a foaf:Person
>>
>>     to
>>
>>     <http://data.fm/friends>
>>
>>     Then you'll have that resources  contain
>>
>>     <http://data.fm/friends#me> a foaf:Person .
>>
>>
>>>     or would the conflation of
>>>     the container URI and resource URI prevent that?
>>
>>     The new resource you PUT to, would now contain a metnion of the
>>     resource R.
>>
>>
>>>     Or would the URI of the resource in
>>>     the container just point to R which could have a different URI?
>>
>>     The above should be the case. If it is not then one should open an
>>     issue.
>>
>>     Henry
>>
>>
>>>     All the best, Ashok
>>>
>>>     On 10/19/2012 9:22 AM, Arnaud Le Hors wrote:
>>>>     "Steve Battle" <steve.battle@sysemia.co.uk>
>>>>     <mailto:steve.battle@sysemia.co.uk> wrote on 10/19/2012 08:44:36 AM:
>>>>
>>>>     > It's my understanding that The Opacity Axiom
>>>>     > <http://www.w3.org/DesignIssues/Axioms.html#opaque> applies
>>>>     only to clients
>>>>     > attempting to pick apart a URI, rather than to the server.
>>>>     >
>>>>
>>>>     Indeed, but I'm not sure clients could live without knowing the
>>>>     magic involved in this scenario and even more so in the case of
>>>>     creating a resource using PUT.
>>>>     --
>>>>     Arnaud  Le Hors - Software Standards Architect - IBM Software Group
>>
>>     Social Web Architect
>>     http://bblfish.net/
>>
>>
Received on Saturday, 20 October 2012 10:33:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:32 UTC