Re: ldp-ISSUE-41 (Member Attachments): Standard way to manage members with attachments

HI all,

This is an interesting use case.

Perhaps a PUT using multipart/alternative would work.  The RDF portion may need a way to associate URLs to the remainder of the attachments, though, and that would be the tricky part.

Regards,
Dave
--
http://about.me/david_wood



On Nov 28, 2012, at 08:52, "Linked Data Platform (LDP) Working Group Issue Tracker" <sysbot+tracker@w3.org> wrote:

> ldp-ISSUE-41 (Member Attachments): Standard way to manage members with attachments
> 
> http://www.w3.org/2012/ldp/track/issues/41
> 
> Raised by: John Arwe
> On product: 
> 
> A user is trying to create a work order along with an attached image showing a faulty machine part. To the user and to the work order system, these two artifacts are managed as a set (a single creation request creates the work order, the attachment, and the relationship between them, atomically).
> 
> When the user retrieves the work order later, they expect a single request by default to retrieve the work order plus all attachments.
> 
> When the user updates the work order, e.g. to mark it completed, they only want to update the work order proper, not its attachments.
> 
> Users may add/remove/replace attachments to the work order during its lifetime.
> 
> In other cases (e.g. an email system) the implementation may want to perform deduplication on the attachments, so a single file attached to 'n' emails/work orders could be stored only once.  It would be desirable if the spec allowed this as well.
> 
> 
> This likely overlaps at least in part with http://www.w3.org/2012/ldp/wiki/Use_Cases_And_Requirements#Sharing_binary_resources_and_metadata , however the product dev who read that existing user story had sufficient trouble interpreting it that he could not be sure if it covers this one already or not.  Based on that feedback, raising this as a separate user story; if it happens to drive the same technical requirements, fine.
> 
> 
>