Re: Multiple resource representations during LDPC POST (5.4.1)

John, following the discussion, I have a question about 5.4.1 again:

"LDPC clients should create member resources by submitting a
representation as the entity body of the HTTP POST to a known LDPC"

How can the client submit the complete representation in a single RDF
graph (which here is the entity body), if a resource representation is
potentially constructed from multiple graphs, as my DESCRIBE example
shows? Or is it somehow partial representation that is meant here? Or
does the LDP prohibit multi-graph representations?

In my view, what is submitted as the entity body is an RDF *graph*
which is then stored as named graph - just like in the GSP.
Subsequently, representations of resources described in the graphs can
be retrieved, possibly spanning multiple named graphs.

Martynas

On Mon, Jan 6, 2014 at 2:02 PM, John Arwe <johnarwe@us.ibm.com> wrote:
>> What I want to point out is that resource representations and graphs
>> are different dimensions of Linked Data.
>
> Violently agree ;-)
> I'd go further: they're so far apart conceptually that using a single word
> to encompass both (dimensions) could be seen as the same problem.  The old
> apples vs oranges meme.
>
>> An LDP scenario that I think
>> makes most sense would be:
>> - GET resource representations generated by SPARQL DESCRIBE (possibly
>> from multiple graphs)
>> - POST/PUT/DELETE graphs as the GSP does
>>
>> That would make the LDP read-write life-cycle somewhat asymmetrical,
>> but I don't see why that's a problem.
>
> I agree, no problem there.
>
>> In my opinion, the current LDP spec fails to differentiate between
>> resource representations and graphs, or conflates the terms to
>> (over)simplify the design.
>
> The more you can point out specific cases, and propose specific changes if
> you feel so inclined, the better your odds of getting what you're after are.
> The editors on LDP have been so close to it for so long that they(we)'re
> vulnerable to the "I know what it's trying to say" effect.  Some of the
> issues recently closed and in the queue are going to have widespread effects
> in the spec (i.e. result in a lot of editor work), and they're clearly
> normative text hits, so those will get prioritized.  If you help them see
> specific conflation points, they're more likely to get addressed sooner.
> Those points will be much easier for you to see, simply based on it being
> easier for you to read what it actually says without being polluted by
> knowing what you already think (coming in) that it's saying.
>
> Best Regards, John
>
> Voice US 845-435-9470  BluePages
> Tivoli OSLC Lead - Show me the Scenario
>

Received on Monday, 6 January 2014 16:23:17 UTC