- From: Henry Story <henry.story@bblfish.net>
- Date: Mon, 10 Jun 2013 20:07:24 +0200
- To: Alexandre Bertails <bertails@w3.org>
- Cc: Martynas Jusevičius <martynas@graphity.org>, Kingsley Idehen <kidehen@openlinksw.com>, "public-ldp@w3.org" <public-ldp@w3.org>
On 10 Jun 2013, at 19:56, Alexandre Bertails <bertails@w3.org> wrote: > On 06/10/2013 12:33 PM, Martynas Jusevičius wrote: >> Hey again, >> >>> 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 :-) >> >> I haven't read 100% of the thread, but wasn't the proliferation of >> (RDF) media types one of the main issues? > > No, this is not happening. > >> >>>> 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? >>> >> >> Any software that uses a mapping between media types and RDF syntaxes. >> Which syntax is it supposed to use to read >> application/api-problem+turtle or application/ldp+turtle >> representations? Or should it make that decision based on the >> "+turtle" token? > > Right, +turtle would itself point to what's defined for turtle/text, > leaving the interactions and semantics to application/ldp (and > possibly application/api-problem). > >> >> Here are examples from Jena's Fuseki and my Graphity code -- both use >> such mappings for content negotiation: >> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.jena/jena-fuseki/0.2.4/org/apache/jena/fuseki/FusekiLib.java#FusekiLib.langFromContentType%28java.lang.String%29 >> https://github.com/Graphity/graphity-browser/blob/master/src/main/java/org/graphity/client/util/DataManager.java > > Would be extremely easy to adapt in the present case. You left out your question to which Martynas was answering which was: "Can you please say which softwares would be broken? And why?" His answer is that client software which would before have correctly parsed the turtle or been able to content negotiate on it, now won't be able to do so correctly. What was working correctly now is not working. That is what "broken" means. You now have to fix, what did not need fixing before hand. This would be very expensive. Since you can furthermore achieve the same aim without breaking clients, it is not clear why you want to introduce this. >>> >>>> 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"? >>> >> >> With uncontrolled I mean that a mapping using uncontrolled types >> cannot be included in generic software, as it is not standardized and >> its full extent is unknown. There is a dozen RDF syntaxes, each with >> its own media type -- any software can easily have a mapping for that. >> If every service or API begins to offer its own media type, generic >> software can no longer maintain such mapping. > > Ah, ok, so just know that there wouldn't be any new syntax. Which is exactly why having a new mime type is silly. > > Alexandre. > >> >>> >>>> 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/ >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > Social Web Architect http://bblfish.net/
Received on Monday, 10 June 2013 18:07:55 UTC