Re: JSON a link poor format

On 16 October 2015 at 05:00, Jeremy Tandy <jeremy.tandy@gmail.com> wrote:
> Hi
>
> Indeed, JSON-LD does resolve the problem of links ...
>
> However, there is some concern that formalism of JSON-LD places an
> additional burden over an above the use of 'plain-old-JSON' (as I call it)
> ... so there are still folks out there not wanting to adopt JSON-LD.
>
> Taking a look at some basic concepts in JSON-LD (from [1]):
>
> plain-old JSON =
>
> ```
>
> {
>   "name": "Manu Sporny",
>   "homepage": "http://manu.sporny.org/",
>   "image": "http://manu.sporny.org/images/manu.png"
> }
>
> ```
>
> JSON-LD =
>
> ```
>
> {
>   "http://schema.org/name": "Manu Sporny",
>   "http://schema.org/url": { "@id": "http://manu.sporny.org/" },  ← The
> '@id' keyword means 'This value is an identifier that is an IRI'
>   "http://schema.org/image": { "@id":
> "http://manu.sporny.org/images/manu.png" }
> }
>
> ```
>
> Looking at the final name-value pair (relating the profile object for 'Manu
> Sporny' to his chosen picture), there's quite a lot going on here ...
>
> 1) in the plain-old JSON, the link is provided as a simple URL that
> applications can _infer_ means that if they follow it they can find
> something useful
> 2) there are no semantics provided for the `image` name ... applications
> need to know somehow what it means; perhaps because the developer has read
> the documentation!
> 3) in the JSON-LD version we see that the target is an object with a
> name-value pair that has name of `@id`; this mechanism is used to say
> "here's an identified something" ... it's an explicit link
> 4) the `image` name is replaced by a fully qualified URL
> `http://schema.org/image` that, when resolved, provides you with the
> information about the semantics of that name.
>
> If desired, you can also express the Type of the thing being linked to by
> including a name-value pair with name of `@type` in the object ...
>
> One can also use JSON-LDs `@context` (see [2]) to make the resulting JSON
> look more 'normal':
>
> ```
>
> {
>   "@context":
>   {
>     "name": "http://schema.org/name",
>     "image": {
>       "@id": "http://schema.org/image",
>       "@type": "@id"
>     },
>     "homepage": {
>       "@id": "http://schema.org/url",
>       "@type": "@id"
>     }
>   },
>   "name": "Manu Sporny",
>   "homepage": "http://manu.sporny.org/",
>   "image": "http://manu.sporny.org/images/manu.png"
> }
>
> ```
>
> (the `@context` object can be referenced via HTTP header so the JSON
> document itself doesn't even need to include it)

Yup, so for schema.org we did wire up the server to content negotiate
at http://schema.org/ allowing this use.

With a couple of tweaks (adding a type, and s/homepage/url/) this can
be written (for HTML embedding) as

<script type="application/ld+json">
{
  "@context": "http://schema.org",
  "@type": "Person",
  "name": "Manu Sporny",
  "url": "http://manu.sporny.org/",
  "image": "http://manu.sporny.org/images/manu.png"
}
</script>

... which is pretty readable and compact as JSON while still having a
triples/graph RDF reading.

If you have CURL you can test the content negotiation e.g. using:

 curl -H "Accept: application/ld+json" http://schema.org/

For easy reference the context file for schema.org is also available
without messing about with content negotiation at this URL:
http://schema.org/docs/jsonldcontext.json ... note for now it is
pretty minimalistic; we don't include full RDF schema information
there (but could if it was considered useful).

cheers,

Dan

Received on Tuesday, 27 October 2015 00:48:18 UTC