W3C home > Mailing lists > Public > public-ldp@w3.org > September 2013

Re: patch con-neg, was Re: multiple changes to resources

From: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
Date: Mon, 23 Sep 2013 23:25:06 +0200
Message-ID: <CA+OuRR9hNP6nGAtcjDR-dL05b8vJW9Jbp9PyaPgx5aMzL2qeLw@mail.gmail.com>
To: Erik Wilde <dret@berkeley.edu>
Cc: LDP WG <public-ldp@w3.org>, Martin P Pain <martinpain@uk.ibm.com>
Hi all,

I still think the notion of "profile" [1] could be used to convey this kind
of additional information without introducing a brand new layer to the web
architecture.

Another idea could be to consider the different kind of patches as media
types, and to consider the different "surface syntaxes" (Turtle, RDF/XML,
...) as Content-encoding [2] from the point of view of HTTP ?

  pa

[1] https://tools.ietf.org/html/rfc6906
[2] http://tools.ietf.org/html/rfc2616#page-118


On Fri, Sep 20, 2013 at 5:50 PM, Erik Wilde <dret@berkeley.edu> wrote:

> hello martin.
>
> just commenting based on the last 10 years...
>
> On 2013-09-20 02:04 , Martin P Pain wrote:
> > How about defining an HTTP header similar to "Content-Type" and
> > "Accept", but which doesn't specify the format that the body is
> > represented in, but instead specifies what that format is being used to
> > express (e.g. in RDF, the vocabulary/ies in use).
>
> this idea pops up with great regularity, just using different names. the
> last proposal before this one coined "Concept-Type" to go with
> "Content-Type", i think.
>
> web architecture is an implementation of REST, and REST is about
> representations; that's the architectural style the web has been
> engineered around. all that matters are representations, and what they
> mean is not relevant for the hypermedia fabric. i don't think there's
> any easy way to change that, and at least for the previous incarnations
> of that idea, they never went anywhere. my guess is that you run into
> fundamental mismatches in too many places. just adding one or two
> headers might look like a quick fix in the beginning, but then it
> probably starts getting more complicated once you start looking into the
> details.
>
> without trying to stir up the 20th iteration of the "web vs semweb
> perma-debate", i would just recommend to dig into a couple of archives
> and try to find the previous approaches in that direction. it may be
> useful to find out where they went, or why they stopped.
>
> cheers,
>
> dret.
>
> --
> erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
>             | UC Berkeley  -  School of Information (ISchool) |
>             | http://dret.net/netdret http://twitter.com/dret |
>
>
Received on Monday, 23 September 2013 21:25:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:03:11 UTC