Re: Chewing on the Abstract

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