[remram]

As a non-LD person, I've been very disappointed by the JSON-LD stuff when I tried to use it recently. I thought the point was to be able to "enrich" your API by adding a context and not changing your JSON responses, but in practice:

* There is no way to update your context without breaking your JSON-LD-aware consumers (one term in your JSON can't link to two IRIs, so you can have it expand to the new term or the old one, not both)

* There is no way to "expand" values to IRIs, the context only does it for keys, so if your JSON contains `{"personRole": "manager"}` you can 't expand it to `{"http://myschema.org/personRole": "http://myschema.org/manager"}`, you actually need that second IRI in your JSON

Really it's a great way to represent linked data, but there were plenty of options already. I wish it bridged the gap with JSON APIs instead of merely looking like JSON.

[aeberhart]

With your first point, you are talking about versioning (switching to a new IRI while keeping the old one for compatibility)?

I agree that there probably is no value in using JSON-LD for an application that was built without LD in mind.

Regarding your last statement about APIs. JSON API (https://jsonapi.org/) looks interesting. Have you worked with that?

[remram]

What's frustrating is that mapping to multiple terms was almost included: https://github.com/json-ld/json-ld.org/issues/142

I didn't know about JSON:API, thanks for the pointer. It seems to tighten the JSON responses a bit, but doesn't address linking or extending vocabularies though.

[aeberhart]

Thanks for the link to the discussion on Github. I don't think it is a good idea to rely on inference (owl:sameAs) for something as basic as foaf:name vs. rdfs:label vs. schema:name, ...

I have not used JSON API yet but it is cool to see the "follow your nose" approach be applied to REST APIs.