Re: Feedback on JSON-LD

Gregg Kellogg
gregg@greggkellogg.net

> On Apr 17, 2018, at 6:46 AM, akrasner@riseup.net wrote:
> 
> 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):

W3C uses GitHub for handling such repositories. Unless they’ve since changed their pricing, GitHub is free for open source software. See [1].

> 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
> @reverse?

The content-model for @reverse is the same as for @id. This should be described in [2]; I’ll add an issue and update.

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

Most of these features exist to allow other existing JSON to be interpreted as JSON-LD, or because certain access patterns are needed.

We decided in the 1.0 timeframe that improving the lives of authors is more important than for tool writers, sorry! Note, however, that most implementations are open source with liberal licenses, so finding algorithm implementations you can leverage (if not libraries you can simply add a dependency to) should help.

> 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)

Compact IRIs are somewhat controversial, but as JSON-LD is an RDF format, and Compact IRIs (or their equivalents) are common there, the spec supports them. Of course, authors have no need to make use of them, and clients can always remove them by re-compacting using another context, or just working in expanded format. For backwards compatibility, at least, I don’t see these being removed from the spec.

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

The spec does provide for a profile parameter to the content-type, which can be used to ensure you always get a specific form (see IANA Considerations [3]). There is also an open issue to allow for a context or frame to be provided in the request to have data returned in that form [4]. There’s also a provision to allow for other formats (such as CBOR), which can be quite a bit more compact on the wire.

> Thanks for the awesome work :)

Thanks for your feedback, and feel free to join in the conversation here, on GitHub, or IRC #json-ld on Freenode.

Gregg

[1] https://blog.github.com/2008-03-01-github-free-for-open-source/ <https://blog.github.com/2008-03-01-github-free-for-open-source/>[2] https://json-ld.org/spec/latest/json-ld/#context-definitions <https://json-ld.org/spec/latest/json-ld/#context-definitions>
[3] https://json-ld.org/spec/latest/json-ld/#iana-considerations <https://json-ld.org/spec/latest/json-ld/#iana-considerations>
[4[ https://github.com/json-ld/json-ld.org/issues/491