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 then be 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 state using 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 Monday, 8 December 2014 23:50:07 UTC