Re: ldp-ISSUE-40 (image): creating/deleting/changing non RDF resources [Use Cases and Requirements]

On 22 Nov 2012, at 18:56, "Wilde, Erik" <Erik.Wilde@emc.com> wrote:

> hello.
> 
>> ldp-ISSUE-40 (image): creating/deleting/changing non RDF resources [Use Cases and Requirements]
>> http://www.w3.org/2012/ldp/track/issues/40
>> Raised by: Henry Story
>> On product: Use Cases and Requirements
>>> From the User Story "Sharing binary resources and metadata" it should be possible to easily add non RDF resources to a containers that accept them.
>> Presumably it should be possible to 
>> - POST a picture to such a container
>> - DELETE such a resource
>> - PUT a new resource in its place
>> It should be possible to find the metadata about such a resource and edit it in the normal ways
> 
> from the ISSUE-37 perspective, we can go three ways, and maybe UCR could already give some direction or preferences? the general possibilities are:
> 
> - clients POST something in a media type accepted by the container, and that resource becomes the member in itself. the side-effect of this design is that thise resources have non-RDF media types and thus the container then presents a mix of RDF and non-RDF members.
> 
> - clients POST something in a media type accepted by the container, and the container creates a metadata entry in RDF that represents the non-RDF resource, and is linked to it. this is what AtomPub does. the model for this is that every non-RDF resource has extactly one RDF member associated with it, and the advantage is that now the container members look more uniform, because the media entry is only linked from the RDF member.
> 
> - clients POST something in a media type accepted by the container, and the container creates a metadata entry in RDF. however, clients can add more "attachments" to that one member, and they will all be represented by the same RDF entry. we have systems that behave like this and there, this concept is called "renditions", with the idea that you can have a PDF and a JPEG representing the same document (container entry). the disadvantage in this approach is that it's complex, because you now need metadata about the entry, and additional metadata about each rendition,
> 
> personally, i prefer the AtomPub model as a mix that is reasonably simple, but still allows the container to present a uniform set of entries. it would be great if the use case could be made a bit more specific to allow us to choose, or otherwise we have the freedom to pick any of these designs.

Thanks for detailing that. I myself would not yet know what to prefer. 
But being able to post cat pictures is clearly essential for the success
of this enterprise :-)

> 
> cheers,
> 
> dret.

Social Web Architect
http://bblfish.net/