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

Hi

Your approach would put non-RDF clients to problem as you suggest to respond with application/ld+json instead of application/problem+json. Even for RDF aware client JSON-LD media type may not tell it to much as it still may not interprete the Hydra vocabulary used. Mayby media type profile pointing to Hydra may improve but still it leaves other clients unresolved.

Please lets try not to forget about the outside world thats still lives in middle ages and doesn't speak RDF :)

Regards
Karol Szczepański

<div>-------- Oryginalna wiadomość --------</div><div>Od: Dietrich Schulten <ds@escalon.de> </div><div>Data:27.09.2015  10:36  (GMT+01:00) </div><div>Do: public-hydra@w3.org </div><div>Temat: Re: Replace hydra:Error with application/problem+json </div><div>
</div>Hi,

Am 26.09.2015 um 18:25 schrieb Erik Wilde:
> 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)
> 

> as with XML, the biggest issue is the extension/openness part, which
> tends to not map very well between different metamodel worlds.

Do you mean the openness for custom attributes like 'balance' and
'accounts'? The group has not even discussed the opportunity to have an
http-problem vocabulary. But due to the openness of RDF Schema, such a
vocabulary would not prevent anyone from defining and adding their own
properties to a problem detail response.

There are various options, but if we

had a http-problem vocabulary: http://tinyurl.com/nwobfxx
and a json-ld context: http://tinyurl.com/qxj5n4s

and the context would be dereferenceable, e.g. at
http://tools.ietf.org/html/rfcXXXX/context
(or at http://www.w3.org/ns/hydra/problem or wherever it might end up)

then it could be used like this:

Request:
POST /transfers HTTP/1.1
Accept: application/ld+json
...

Response:

HTTP/1.1 403 Forbidden
Content-Type: application/ld+json

{
  "@context": "http://tools.ietf.org/html/rfcXXXX/context",
  "type": "https://example.com/probs/out-of-credit",
  "title": "You do not have enough credit.",
  "detail": "Your current balance is 30, but that costs 50.",
  "instance": "/account/12345/msgs/abc"
}

reads like below after json-ld compaction:
{
  "@id": "../account/12345/msgs/abc",
  "urn:ietf:rfc:XXXX:detail":
    "Your current balance is 30, but that costs 50.",
  "urn:ietf:rfc:XXXX:title":
    "You do not have enough credit.",
  "urn:ietf:rfc:XXXX:type": {
    "@id": "https://example.com/probs/out-of-credit"
  }
}

Or, with custom attributes:

Request:
POST /transfers HTTP/1.1
Accept: application/ld+json
...


Response:
HTTP/1.1 403 Forbidden
Content-Type: application/ld+json

{
  "@context": [
    "http://tools.ietf.org/html/rfcXXXX/context",
    {
      "balance" : "http://api.example.com/vocab#balance",
      "accounts" : "http://api.example.com/vocab#accounts"
    }
  ],
  "type": "https://example.com/probs/out-of-credit",
  "title": "You do not have enough credit.",
  "detail": "Your current balance is 30, but that costs 50.",
  "instance": "/account/12345/msgs/abc",
  "balance": 30,
  "accounts": ["http://example.net/account/12345",
    "http://example.net/account/67890"]
}

*If* http-problem would use a URL namespace instead of a URN, I would
consider it a bit cooler, but I guess the URN is in the wild, so we have
to live with it ;-)

> (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.

Having worked on this a bit, I do not think it would slow down the RFC
much. But let us see what Mister Nottingham says.

Best,
Dietrich