- From: Henry Story <henry.story@bblfish.net>
- Date: Tue, 4 Jun 2013 15:51:28 +0200
- To: Alexandre Bertails <bertails@w3.org>
- Cc: Kingsley Idehen <kidehen@openlinksw.com>, public-ldp@w3.org
On 4 Jun 2013, at 15:31, Alexandre Bertails <bertails@w3.org> wrote: > 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... yes, and I am just as much against this as things like ldp+turtle. You don't need anything more than the well known rdf mime types, such as text/turtle. I'll point you to the archives where I argued that in detail if you want. All you need is for the spec writers to write the ontology for their spec, or for someone to do it for them. Then everythign works fine. If a client requests text/turtle, it makes sense that the client receives the errors in the same format as it requested the content in. So then if someone makes a request for json-ld they can receive json-ld error text, or if rdf/xml they can receive rdf/xml error text, etc..... The HTTP response code tells the client that this is an error code and not the representation. > >> >> 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. I would start there yes, and have the spec writers or someone who can help them put together the ontology, and publish it as linked data. If they do that then it would be a great document. > > Alexandre. > >> >> Henry >> >> >> Social Web Architect >> http://bblfish.net/ >> >> >> > Social Web Architect http://bblfish.net/
Received on Tuesday, 4 June 2013 13:52:03 UTC