Re: JSON a link poor format

thanks for this primer on links in JSON, Jeremy - I learnt something!
Bottom line, JSON-LD makes a lot of sense to me.
-Peter


On 2015-10-16 11:00, Jeremy Tandy 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)
>
> Here we see that the name `image` has been mapped to `http://schema.org/image`
> and that the type of that object has been set to `@id` ... meaning that
> `image` will always refer to a link.
>
> So this works for me ... but there is no general agreement how links should be
> done in 'plain-old' JSON.
>
> Looking at Simon Cox's OM-JSON presentation (from the OGC TC meeting in
> Nottingham) he proposes using names like `href`, `rel` and `title` (etc) which
> (mostly) map to the properties of XLINKs [3] ... e.g.
>
> ```
> {
>     "id": "spec1",
>     "sampledFeature": {
>         "href": "http://example.org/featureA", "title": "test feature A"
>     },
>     "complex": [
>         { "rel": "http://example.org/parent", "href":
> "http://example.org/sample2" },
>         { "rel": "http://example.org/child", "href":
> "http://example.org/sample3"  }
>     ],
>     ...
> }
> ```
>
> Looking at Link-Objects [4], GeoJSON provides a different mechanism. The spec
> says:
>
> A link object has one required member: |"href"|, and one optional
> member: |"type"|.
>
> for example:
>
> ```
> |"crs": {
>     "type": "link", 
>     "properties": {
>       "href": "http://example.com/crs/42",
>       "type": "proj4"
>       }
>     }|
> ```
>
> Part of the problem is that encodings using 'plain-old' JSON don't often
> bother explicitly identifying the resource that they are talking about.
> Looking at GeoJSON [4], for example, all that spec says about identifying this is:
>
>  *
>
>     If a feature has a commonly used identifier, that identifier should be
>     included as a member of the feature object with the name |"id"|.
>
> It doesn't provide any guidance about what that identifier should be (in
> contrast to the web-architecture and DWBP that say use HTTP URIs to identify
> things). Usually in JSON, the relationships between things are asserted by the
> nesting of objects ... which is not always convenient or possible.
>
> So ... is JSON a link-poor format? Perhaps the problem is that there are any
> number of ways to do links but none that work for everyone. The only
> formalised standard mechanism (that I know of) is provided by JSON-LD. Perhaps
> this is one of the best practices we should assert?
>
> HTH, Jeremy
>
> [1]: http://www.w3.org/TR/json-ld/#basic-concepts 
> [2]: http://www.w3.org/TR/json-ld/#the-context 
> [3]: http://www.w3.org/TR/xlink11/ 
> [4]: http://geojson.org/geojson-spec.html#link-objects 
> [5]: http://geojson.org/geojson-spec.html#feature-objects 
>
> On Fri, 16 Oct 2015 at 07:28 Linda van den Brink <l.vandenbrink@geonovum.nl
> <mailto:l.vandenbrink@geonovum.nl>> wrote:
>
>     Hi all,
>
>      
>
>     In the last telecon Jeremy commented on JSON, saying it is a ‘link poor
>     format’. I’m curious as to what he meant. Is JSON-LD not supposed to solve
>     that?
>
>      
>
>     @Jeremy could you expand on this?
>
>      
>
>     Linda
>
>      
>
>      
>

-- 
Dr. Peter Baumann
 - Professor of Computer Science, Jacobs University Bremen
   www.faculty.jacobs-university.de/pbaumann
   mail: p.baumann@jacobs-university.de
   tel: +49-421-200-3178, fax: +49-421-200-493178
 - Executive Director, rasdaman GmbH Bremen (HRB 26793)
   www.rasdaman.com, mail: baumann@rasdaman.com
   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)