- From: Dan Brickley <danbri@danbri.org>
- Date: Fri, 26 Aug 2011 13:06:03 +0200
- To: Richard Cyganiak <richard@cyganiak.de>
- Cc: Thomas Steiner <tomac@google.com>, Alexandre Passant <alex@seevl.net>, RDF WG <public-rdf-wg@w3.org>
On 26 August 2011 12:35, Richard Cyganiak <richard@cyganiak.de> wrote: > On 26 Aug 2011, at 08:41, Thomas Steiner wrote: >>>> "Link headers, the mullet of the Web: business in the front, party in >>>> the back. Idea: serve #JSON, make it #jsonLD by a @context Link >>>> header." >>> >>> Are you talking about the Link: HTTP header? That doesn't make sense. Why would you use an HTTP header for something that's specific to a single representation format? What's the advantage over putting it into the representation format? >> >> I am indeed talking about the HTTP Link header. Why shouldn't it make sense to use it? > > It's really easy to include the link in the representation format. For many developers, it's harder to set an HTTP header. So it increases the risk that people just won't do it, and it increases the cost of using JSON-LD. > > You may think that setting an HTTP header isn't hard, but believe me, you're wrong. This is one of the things I've learned from the whole 303 mess. > > Also, I can see absolutely no advantage to using an HTTP header here. This is pretty clear. We've tried HTTP header -based design, and it has been pushed pretty heavily via Linked Data evangelism over the last few years. It was a hard sell. (as I write this, Thomas' mail arrives, clarifying that headers would be only as added extra) But still, from me a -1 on using headers. They are problematic for most developers and almost all publishers, and if there are also other ways of expressing the same thing, that introduces complexity when the two are simultaneously used differently. cheers, Dan
Received on Friday, 26 August 2011 11:06:31 UTC