Re: Operations on containers

On Fri, Oct 19, 2012 at 10:46 AM, Ashok Malhotra
<ashok.malhotra@oracle.com>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.
>
>
Yes, I had that prior to the reintroduction of PATCH, also. Attitudes have
changed significantly, fortunately.

- James


>  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.
>
> 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
>
>   ...
>
>  2) Link that item to an existing collection
>
>    LINK /profiles/james HTTP/1.1
>   Host: 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
>   Link: <http://example.org/profiles/james>; rel="item"
>
>  - James
>
>
>
> On Fri, Oct 19, 2012 at 9:38 AM, Henry Story <henry.story@bblfish.net>wrote:
>
>>
>>  On 19 Oct 2012, at 18:32, Ashok Malhotra <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> <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/
>>
>>
>