Re: Replace hydra:Error with application/problem+json

hello dietrich.

On 2015-09-26 05:15, Dietrich Schulten wrote:
> Since Erik Wilde is also in this list, I cc'ed him.
> Erik, what do you think?

(cc'ing mark, the main author of the IETF draft)

generally, i think it is a good idea to try to reuse models, and 
application/problem+... tries to be a model that is reusable. but, as 
you notice, there always are problems when trying to translate models 
across metamodels, and the same seems to be the case here.

i came across this when trying to reuse the model for an XML-centric 
API, and as a result, now there is an appendix defining a way how to 
serialize the JSON-rooted model in XML. this is pretty straightforward 
when it comes to the predefined structures, but always gets tricky when 
it comes to dealing with questions of extensions and openness.

for the XML structure, the names reflect the JSON names, because that 
makes it easy to understand the XML structures in terms of how they 
relate/originate in the JSON model.

my feeling is that for RDF, the best way would be to do the same (plus 
whatever prefix is required to turn the names into URIs), otherwise 
translating becomes a bit too non-obvious.

i see three possible paths:

(1) hydra defines its own way to use application/problem+json and 
defines URIs for the literals used in JSON. my suggestion would be to 
not do any renaming, just to make clear that these are names that are 
reused from an existing model.

(2) a separate RDF schema is defined which has its own namespace/prefix, 
and hydra just happens to use it. i think that would be beneficial 
because then other RDF-centric approaches could reuse the vocabulary 
without having to deal with hydra as a whole. this could be done 
informally, as some IETF I-D, or as some W3C spec. i'd be happy to help 
with any of these.

(3) in the same way as the I-D currently has a section on how to 
serialize application/problem+json in XML, there could be another one 
about RDF. this would simply mean that the approach taken in (2) would 
become an integral part of the spec, instead of being standalone. 
however, my feeling is that this might slow down the progression of the 
draft, and i think that mark is in favor of keeping these things 
separate, instead of integrating them (am i reading your mind correctly, 
mark?).

regardless of the chosen approach, in think it would be great to see 
adoption of application/problem+json outside of JSON-centric approaches 
(that was my motivation to work on an XML model), but it might take a 
bit of work to figure out how to best reflect the JSON model into RDF. 
as with XML, the biggest issue is the extension/openness part, which 
tends to not map very well between different metamodel worlds.

cheers,

dret.

-- 
erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

Received on Saturday, 26 September 2015 16:25:50 UTC