W3C home > Mailing lists > Public > public-ldp-wg@w3.org > November 2012

Re: Returning HTTP codes with HTML descriptions.

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Sat, 03 Nov 2012 13:02:06 -0400
Message-ID: <50954E0E.7070205@openlinksw.com>
To: public-ldp-wg@w3.org
On 11/2/12 7:11 PM, Andrei Sambra wrote:
>>> instead of just using HTML, i suggest to have a look at
>>> http://tools.ietf.org/html/draft-nottingham-http-problem-01 and see how
>>> well it would fit. i think pretty good. the next version is supposed to
>>> add XML support (i'm working on a schema).
>> There are some interesting ideas in this spec, but in our case, the
>> client already understands RDF, so I don't see why we would return
>> anything but RDF for "problem details".
> I'm fine with returning RDF too. The reason why I suggested HTML was 
> to serve as a simple debugging message (a warning) for the developers 
> trying to use the LD platform. The way I see it in this case, RDF 
> would serve a better purpose if these messages were to change 
> frequently, though I don't really have a use case for this in my mind 
> right now.
> It would be nice to have a system like this in place for 
> interoperability tests, since I believe many of us are eager to start 
> implementing stuff. :-)
> Andrei 

Since RDF model based content can exist in different formats, why not 
describe this goal as returning an error in structured data form. HTML 
could be the default with <link/> relationships embedded to points to 
content in alternative formats. In addition, HTTP "Link:" headers could 
be used to mirror the <link/> relationships in HTML.

The pattern described above, is what we use re. DBpedia and other LOD 
cloud data spaces that we host.



Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

Received on Saturday, 3 November 2012 17:02:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:33 UTC