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

I believe that issue-41 does have significant overlap with issue-40. The UC&R now has a UC to cover both <http://www.w3.org/2012/ldp/wiki/Use_Cases_And_Requirements#UC8:_Managing_non-RDF_Resources>. I've used the text of issue-41 as a the beginnings of a scenario - it would be good to put together some RDF for this along the lines of the other UCs.

As per the discussion, there may be two different scenarios here. One with a single asset posted along with the RDF, and another with multiple assets.
Assuming each asset has its own URI, it would be possible to distinguish them by their media type, if this were explicitly added when they were added.

Steve.

On 28 Nov 2012, at 13: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.
> 
> 
>

Received on Sunday, 2 December 2012 21:15:06 UTC