- From: Alexandre Bertails <bertails@w3.org>
- Date: Mon, 10 Jun 2013 11:11:28 -0400
- To: Martynas Jusevičius <martynas@graphity.org>
- CC: Henry Story <henry.story@bblfish.net>, Kingsley Idehen <kidehen@openlinksw.com>, "public-ldp@w3.org" <public-ldp@w3.org>
Hi Martynas, On 06/10/2013 10:45 AM, Martynas Jusevičius wrote: > Lets step back from the philosophical discussion a bit. By defining a > media type per problem domain, That is _not at all_ what was proposed. We would have to do it only once, in the context of LDP. You're pretty much on your own with your domain model from there. I hope you feel reassured with the approach then :-) > you would break Linked Data for > existing RDF software as it would not be able to recognise custom > types. That's a very interesting argument. Can you please say which softwares would be broken? And why? > You would also prevent generic web application design, as a > generic application cannot build on a vocabulary or type system that > is uncontrolled. That's again interesting. Can you please elaborate? For example, what do you mean by "uncontrolled"? > What it can use is a generic representation format, > such as text/turtle. Some of us has already tried to explain why text/turtle was not enough, so I won't do it again :-) Alexandre. > > Martynas > graphityhq.com > > On Tue, Jun 4, 2013 at 4:31 PM, 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... >> >> >>> >>> 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 Monday, 10 June 2013 15:11:40 UTC