W3C home > Mailing lists > Public > public-linked-json@w3.org > April 2018

Feedback on JSON-LD

From: <akrasner@riseup.net>
Date: Tue, 17 Apr 2018 06:46:07 -0700
To: public-linked-json@w3.org
Message-ID: <efc5efaee127855a5d939e05b104c245@riseup.net>
Hello everyone!

I'd like to express thoughts about JSON-LD. I've been writing some code
to support JSON-LD in my app and I noticed some things (sorry I'm not
just opening issues, I would if you picked GitLab CE or something else
free instead of github for collaboration):

1. Neither 1.0 nor 1.1 draft says what's allowed as the value of
@reverse when used inside a context. There is one example in which it's
an absolute IRI, but otherwise no information. What's allowed in
2. I feel like JSON-LD has tons of convenience features and shortcuts.
I'm sure they all exist because someone needs them, but it's a pain to
everyone who doesn't. My code is written in languages that aren't JS and
have nothing to do with JS, so to me JSON and JSON-LD are just data
serialization formats. I never need to write them manually so I never
need any shortcut. Compact IRIs can be nice to avoid repetition of some
long URL many times in the document (save some network bandwidth?) but
otherwise the rest just complicates my JSON-LD implementation a lot. It
would be nice to have some simplified form that has what's needed for
treating JSON-LD as an opaque serialization format (I define some
application specific values in my Haskell code, and a function that
converts the values to JSON-LD by mapping fields to RDF properties -
that's all I need)

Obviously since I don't have nearly as much experience as many people
here and generally in the web dev community, I may be missing something.
It would be nice for example if transmission of JSON-LD on the web
required some normalized form that doesn't involve any features that
exist just for convenience (say, allow ones that make the file smaller
etc. something that is really relevant to communication).

Thanks for the awesome work :)
Received on Tuesday, 17 April 2018 14:18:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:51 UTC