Re: On The Purpose of JSON and Gluon Redesign Ideas

Hi Markus,

On Mon, Jul 4, 2011 at 1:12 PM, Markus Lanthaler
<markus.lanthaler@gmx.net> wrote:
> Interesting post Niklas. I completely agree with
>
>> I doubt that any such hybrid is usable: either you know RDF
>> and should use Turtle, or you don't and you want simple JSON,
>> without the richness of inlined RDF details.

glad to hear that! It seems like the popular opinion (that JSON is for
simple, direct ("end") use within a given (and thus implicit) context,
with as little detail as possible).

> and think it is a good idea to "to remove the raw form entirely, and design
> the profile mechanism so that it is 'air tight'." But why do you think that
> these profiles should be anythink like JSON schemas?
>
>> (Note that profiles will reasonably not be anything like
>> full "JSON schemas". It's about mapping terms to URI:s and
>> as little else as possible to handle datatyping and the
>> mismatch between graphs and JSON trees
>
> Any special reason for that or just a personal preference?

Well, I kinda have a penchant for wanting to solve more than one thing
at once. I thus have thought on and off about the relative merits of
extending profiles into something schema-like (the 'define' feature of
Gluon has traces of such ideas). Or vice-versa, making profiles an
extension of JSON Schema [1]. But I believe that this will do
unwarranted double duty (mapping *and* schema). JSON Schema is a thing
in its own right, with relative merits (note that many people using
JSON just want schema-free data where attributes "speak for
themselves"). Merging those technologies would be too complex and
unsatisfactory for mapping and verification needs alike. (I can
imagine them being used in conjunction though, as complementary
technologies.)

Although e.g. coercing and multiplicity may seem like schema-like
concepts, they only serve here to disambiguate things which are too
detailed (and/or RDF-centric) to fit in the plain JSON I'm/we're
after. Most (ideally all) of that can be reduced to either lexical
value matching or e.g. attribute suffix conventions. The same goes for
the idea of "type-local term imports"; it's not about framing, only
namespace management.

(Furthermore, for schemas/validation there is RDFS/OWL (for better or
worse, barring "open world" etc.). It would be interesting to see a
(gluon) profile for representing that concisely in JSON, which could
be used for validation purposes. I may get back to this...)

Best regards,
Niklas

[1]: http://json-schema.org/

Received on Monday, 4 July 2011 13:42:40 UTC