3 ms·

JSON Schema, Schema.org, JSON-LD: What’s the Difference?

3 points by aeberhart 6y ago

remram 6y ago
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/personRole": "http://myschema.org/manager"}` 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 6y ago
  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/ https://jsonapi.org/) looks interesting. Have you worked with that?
  - remram 6y ago
    What's frustrating is that mapping to multiple terms was almost included: https://github.com/json-ld/json-ld.org/issues/142 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 6y ago
      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.

3 points by aeberhart 6y ago

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/personRole": "http://myschema.org/manager"}` 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 6y ago
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/ https://jsonapi.org/) looks interesting. Have you worked with that?
- remram 6y ago
  What's frustrating is that mapping to multiple terms was almost included: https://github.com/json-ld/json-ld.org/issues/142 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 6y ago
    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.