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

Re: Proposal to close ISSUE-19: Adressing more error cases, as is

From: Alexandre Bertails <bertails@w3.org>
Date: Tue, 04 Jun 2013 09:31:23 -0400
Message-ID: <51ADEC2B.1090003@w3.org>
To: Henry Story <henry.story@bblfish.net>
CC: Kingsley Idehen <kidehen@openlinksw.com>, public-ldp@w3.org
On 06/04/2013 01:21 AM, Henry Story wrote:
> On 3 Jun 2013, at 22:30, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>> On 6/3/13 3:31 PM, Erik Wilde wrote:
>>> which would get to the touchy issue of media types. application/api-problem+json and application/api-problem+xml are the current media types, would an RDF model follow what pattern and expose application/api-problem+turtle?
>> No, since API problems ultimately boil down to entity relationships. The format is ultimately irrelevant.
> Agree with Kingsely. This issue is not touchy: it is settled.
> In RDF you don't need to create a media type for your responses, text/turtle will
> do.  The reason you have to do this with JSON is because, lacking namespaces you have no idea without the
> media type wha the content is.

I fail to understand where Erik's idea would be bad. The goal of the
spec is clear:

This document defines a "problem detail" as an extensible way to carry
machine-readable details of errors in a HTTP response, to avoid the
need to invent new response formats for HTTP APIs.

application/api-problem already conveys the informations we'd want,
right? We would just have to register +turtle as a new Structured
Syntax Suffix and map the existing model to the RDF meta-model.

That's the same discussion than with application/ldp+turtle...

> More useful would be to find which ontologies express the relevant information the user would need.

What's already defined in application/api-problem is not enough? I
don't know, I haven't looked carefully, but I would start there


> Henry
> Social Web Architect
> http://bblfish.net/
Received on Tuesday, 4 June 2013 13:31:34 UTC

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