- From: Alexandre Bertails <bertails@w3.org>
- Date: Mon, 10 Jun 2013 13:56:48 -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>
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 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. 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/ >>>>> >>>>> >>>>> >>>> >>>> >>> >> >
Received on Monday, 10 June 2013 17:56:54 UTC