Re: Returning HTTP codes with HTML descriptions.

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.



-- 

Regards,

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