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

Re: LDP user story: sharing binary resources and metadata

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Wed, 12 Sep 2012 14:18:50 +0100
Message-ID: <50508BBA.9040507@epimorphics.com>
To: public-ldp-wg@w3.org

UC&R Editors - use as you see fit, including removal if it does not fit 
the analysis structure.

Anyone - feel free to edit and refine.  It's a wiki.


On 12/09/12 00:35, Ashok Malhotra wrote:
> Andy:
> Could you update the Wiki at
> http://www.w3.org/2012/ldp/wiki/Use_Cases_And_Requirements#Sharing_binary_resources_and_metadata
> with your observations.
> All the best, Ashok
> On 9/10/2012 10:19 AM, Andy Seaborne wrote:
>> On 10/09/12 17:39, Steve K Speicher wrote:
>>> "4.1.3 BPR servers MAY host a mixture of BPRs and non-BPRs. For example,
>>> it is common for BPR servers to need to host binary or text resources
>>> that
>>> do not have useful RDF representations."
>>> http://www.w3.org/Submission/ldbp/#bpr-general
>> This is good because Henry's UC is, to my reading, closing in on the
>> fact that the "resource" comes in two parts - here, the image and
>> information about the image (which may in the image file but better
>> external to it as it's more general).
>> A key issue for our work is whether to link these two elements or
>> treat them separately:
>> Coupled: e.g. allow a single POST/PUT with RDF and non-RDF parts, and
>> have the BPR server manage the URI naming for the non-RDF part.
>> Separate: e.g. require the image to be put somewhere with a URL, then
>> receive just the metadata as a BPR.
>> I'd like to go down the coupled direction unless there is a barrier
>> because the separate case places a co-ordination burden on the client
>> apps.  Whether the binary part is subsidiary to the RDF part, I don't
>> know what the pros an cons are.  At the moment though, I don't see it
>> as a significant extra work item and still about "protocol".
>>     Andy
Received on Wednesday, 12 September 2012 13:19:31 UTC

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