W3C home > Mailing lists > Public > public-ldp@w3.org > January 2014

Re: Multiple resource representations during LDPC POST (5.4.1)

From: John Arwe <johnarwe@us.ibm.com>
Date: Mon, 6 Jan 2014 08:02:43 -0500
To: "public-ldp@w3.org" <public-ldp@w3.org>
Message-ID: <OF3316CF65.FF10AC91-ON85257C58.0046BFB2-85257C58.0047A937@us.ibm.com>
> 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 

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario
Received on Monday, 6 January 2014 13:03:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:03:11 UTC