- From: Tomasz Pluskiewicz <tomasz@t-code.pl>
- Date: Mon, 28 Sep 2015 12:45:40 +0000
- To: "Asbjørn Ulsberg" <asbjornu@gmail.com>, "John Walker" <john.walker@semaku.com>
- Cc: "Karol Szczepański" <karol.szczepanski@gmail.com>, "Dietrich Schulten" <ds@escalon.de>, public-hydra@w3.org
Here's how I've always viewed similar concerns. For any RDF serialization, the media type signifies the syntax used. It can be application/rdf+json, application/ld+json or text/turtle. The problem is that this is incompatible with common use of media types, where they define not only the syntax but also the semantics of a given resource contents. With RDF the semantics are described on a different level, by types and predicates. This is why you don't have a multitude of media types and can mix and match unrelated data. It is always "just" RDF. Does that make sense? Regards, Tom September 28 2015 1:47 PM, "Asbjørn Ulsberg" <asbjornu@gmail.com> wrote: > Yes, that’s fine. I just don’t see the need to explain to anyone that application/problem+json is > based on JSON-LD if the spec is rewritten to be based on JSON-LD. In that case, it will be a given > just due to its content type (and the RFC explaining the fact). So, yes, we can always bridge the > gap between the current spec and JSON-LD, but is that necessary? Is anything lost if > application/problem+json is rewritten so it is JSON-LD compatible out of the box? >
Received on Monday, 28 September 2015 12:46:28 UTC