- 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 saying. 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