- From: Alexandre Bertails <bertails@w3.org>
- Date: Tue, 04 Jun 2013 09:31:23 -0400
- 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 anyway. Alexandre. > > Henry > > > Social Web Architect > http://bblfish.net/ > > >
Received on Tuesday, 4 June 2013 13:31:34 UTC