Re: Chewing on the Abstract

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 22:43:57 UTC