- From: Steve Speicher <sspeiche@gmail.com>
- Date: Thu, 11 Dec 2014 08:34:14 -0500
- To: Arnaud Le Hors <lehors@us.ibm.com>
- Cc: "ashok.malhotra@oracle.com" <ashok.malhotra@oracle.com>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
Thanks for the feedback to all. I'm not hearing too much interest for folks and those that I have, it doesn't appear to be converging on a new approach. So I'm just going to tweak what we have and call it "done". "Linked Data Platform (LDP) defines a set of rules for HTTP operations on web resources, some based on RDF, to provide an architecture for read-write Linked Data on the web." https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#abstract - Steve On Tue, Dec 9, 2014 at 11:32 AM, Arnaud Le Hors <lehors@us.ibm.com> wrote: > I agree the abstract should give the reader enough to decide whether this > spec might be of interest to them but I think what Cody is proposing is a > bit too much text. We shouldn't turn this into an introduction either. It'd > be nice to find a middle ground. > -- > Arnaud Le Hors - Senior Technical Staff Member, Open Web Standards - IBM > Software Group > > > ashok malhotra <ashok.malhotra@oracle.com> wrote on 12/08/2014 03:49:35 PM: > >> From: ashok malhotra <ashok.malhotra@oracle.com> >> To: public-ldp-wg@w3.org >> Date: 12/08/2014 03:50 PM >> Subject: Re: Chewing on the Abstract >> >> Sorry, Steve, but I agree with Cody! >> >> TimBL once said that the abstract should tell you what the document is >> about and tell you enough about it to decide whether you want to read >> further. So, I think a couple of paras is better than a single sentence. >> >> Cody, I like your words. We can fine tune but generally OK. >> >> Regards, Ashok >> >> On 12/8/2014 5:43 PM, Steve Speicher wrote: >> > Cody, >> > >> > Thanks for helping with this. First, I will say that I believe the >> > abstract should be very short: 1 or 2 sentences. People (like myself) >> > have a very short attention span. They'll just need enough to know if >> > they should the intro. I believe the introduction should elaborate a >> > bit more such as the abstract you provide. >> > >> > I personally like a variant such as this: >> > >> > [[ >> > LDP merges the HTTP interaction model with the >> > RDF data model to create a new, but familiar system for working with >> > Linked Data resources. LDP defines the LDP Container to which a client >> > may POST content and the server will create a new member resource. >> > ]] >> > >> > I think it would go without saying that "LDP does more" than they >> > abstract but this hits on the key parts, perhaps? >> > >> > Regards, >> > Steve Speicher >> > http://stevespeicher.me > >> > >> > >> > On Mon, Dec 8, 2014 at 10:32 AM, Cody Burleson >> <cody.burleson@base22.com> wrote: >> >> Team, >> >> >> >> Recently, we've been discussing some concerns about the current >> >> abstract on >> >> the specification. Some of us believe that with a little more "chewing" >> >> on >> >> it together, we might be able to elicit something more informative and >> >> perhaps also a little more compelling. >> >> >> >> Here's what I have so far as a rough idea of what I think is an >> improvement. >> >> You'll see at the end that I just have kind of fallen off with >> >> dot-dot-dot. >> >> That is because I haven't yet found the right closing statement; >> I was still >> >> in-process. >> >> >> >>> This specification defines a client-server platform and a standard >> >>> approach for managing and exchanging Linked Data resources over HTTP. >> >>> It >> >>> introduces the notion of a URI addressable "container" through which a >> >>> client may POST an RDF graph. Once POSTed, an RDF graph can thenbe >> >>> managed > >> >>> through its parent container as a single web resource. Resources can >> >>> be >> >>> members of one or more containers and the containers themselves can be >> >>> arranged in hierarchies. This enables the development of rich >> >>> information >> >>> architectures, which can be managed using the classic and well-known >> >>> HTTP >> >>> interaction model and familiar techniques such as the exchange >> of data using >> >>> REST and JSON. Yet because the resources being managed are expressed >> >>> primarily in RDF, the platform additionally affords all the benefits >> >>> ... >> >> >> >> I had also started experimenting with this as a possible alternative >> >> near >> >> the end... >> >> >> >>> which can be managed using the classic and well-known HTTP interaction >> >>> model, yet with the additional benefits of the RDF data model. >> Abstracted as >> >>> URI addressable resources, RDF data can be exchanged using familiar >> >>> approaches such as the exchange of data through REST using a JSON >> >>> format. >> >>> Linked Data Platform (LDP) ... >> >> >> >> If you have opinions for or against, please share. >> >> >> >> For your convenience, here is what is currently written on the spec as >> >> of >> >> now: >> >> >> >>> Linked Data Platform (LDP) merges the classic and well-known HTTP >> >>> interaction model with the RDF data model to provide a new, but >> >>> familiar >> >>> system for working with Linked Data and related media. >> >> >> >> >> >> Here are some other statements that were made amongst the group. I have >> >> already tried to capture some of the ideas expressed by these: >> >> >> >> "Linked Data Platform (LDP) defines rules around HTTP access to web >> >> resources, some based on RDF, to provide an architecture for read-write >> >> Linked Data on the web." >> >> I think Philippe said that he didn't know what a "read-write Linked >> >> Data >> >> architecture" was or how web resources might describe their stateusing >> >> the >> >> RDF data model. I guess he (and the public) would be better informed by >> >> something like: >> >> >> >> LDP is a language and protocol for using RDF to exchange state between >> >> HTTP >> >> servers and clients. LDP provides a notional "container" to which a >> >> client >> >> may POST an RDF graph and the server will create a new web resources. >> >> >> >> This document defines the behavior of an LDP (web) server with respect >> >> to >> >> client requests. >> >> >> >> >> >> >> >> -- >> >> Cody >> >> >> >> >> >>
Received on Thursday, 11 December 2014 13:34:42 UTC