Re: LDP user story: sharing binary resources and metadata

[snip]
>>>
>>> Does that make a good user story/use case?
>>
>> It's really too bad that I cannot attend the LDP meetings because of a
>> conflict with another one...
>>
>> I'm not sure I understand how the WG came to considerer use-cases that
>> would go beyond the scope of the charter, which I thought was pretty
>> much focused on using REST to interact with RDF data in Web-documents?
>> Of course, that's only an opinion (mine) but I thought that would be
>> pretty clear as this stuff was not discussed in the IBM Submission at
>> all.
>>
>
> Well, maybe it wasn't discussed as clearly as it could.  For example, it
> is covered in statements like:
> "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
>
> I'm curious what part of the charter prohibits this?

Nothing, you're right. But let's not start with this argument, as many
things are not prohibited either...

>
>> It looks like the direction taken is much more about a complete
>> Platform instead of just the Protocol... Don't get me wrong, I think
>> this is important, but I fear that this can go into many directions,
>> while the most important thing is still to know how to talk to the
>> server in a standardized way...
>>
>> Can anybody give some context?
>
> I'm not sure what context to give other than the member submission,
> charter and the use cases we are developing.

Yes, it's really good to gather and discuss the use cases.

I was just wondering why people would not want to focus just on "doing
Linked Data with RDF+REST" and then perhaps do any addition *later*?
Is it that important to solve all the problems at once?

Alexandre.

>
> Thanks,
> Steve Speicher
> IBM Rational Software
> OSLC - Lifecycle integration inspired by the web ->
> http://open-services.net
>
>

Received on Monday, 10 September 2012 17:24:03 UTC