- From: Martynas Jusevičius <martynas@graphity.org>
- Date: Mon, 10 Jun 2013 19:33:37 +0300
- To: Alexandre Bertails <bertails@w3.org>
- Cc: Henry Story <henry.story@bblfish.net>, Kingsley Idehen <kidehen@openlinksw.com>, "public-ldp@w3.org" <public-ldp@w3.org>
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? >> 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? 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 > >> 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. > >> 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 16:34:08 UTC