Re: JSON a link poor format

Superb, Jeremy! I now have complete my first advanced course in JSON in just a few minutes. I personally like JSON-LD.

Scott

> On Oct 16, 2015, at 5:43 AM, Ed Parsons <eparsons@google.com> wrote:
> 
> Thanks Jeremy, a great intro !
> 
> ed
> 
> 
> On Fri, 16 Oct 2015 at 12:41 <allaves@fi.upm.es <mailto:allaves@fi.upm.es>> wrote:
> Indeed! Thanks for the summary, Jeremy.
> 
> +1 for JSON-LD as Best Practice.
> 
> Alejandro
> 
> 
> Peter Baumann <p.baumann@jacobs-university.de <mailto:p.baumann@jacobs-university.de>> escribió:
> 
> > 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/ <http://manu.sporny.org/>",
> >>   "image": "http://manu.sporny.org/images/manu.png <http://manu.sporny.org/images/manu.png>"
> >> }
> >> ```
> >>
> >> JSON-LD =
> >>
> >> ```
> >> {
> >>   "http://schema.org/name <http://schema.org/name>": "Manu Sporny",
> >>   "http://schema.org/url <http://schema.org/url>": { "@id": "http://manu.sporny.org/ <http://manu.sporny.org/>" },  ←
> >> The '@id' keyword means 'This value is an identifier that is an IRI'
> >>   "http://schema.org/image <http://schema.org/image>": { "@id":
> >> "http://manu.sporny.org/images/manu.png <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` <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 <http://schema.org/name>",
> >>     "image": {
> >>       "@id": "http://schema.org/image <http://schema.org/image>",
> >>       "@type": "@id"
> >>     },
> >>     "homepage": {
> >>       "@id": "http://schema.org/url <http://schema.org/url>",
> >>       "@type": "@id"
> >>     }
> >>   },
> >>   "name": "Manu Sporny",
> >>   "homepage": "http://manu.sporny.org/ <http://manu.sporny.org/>",
> >>   "image": "http://manu.sporny.org/images/manu.png <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` <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 <http://example.org/featureA>", "title": "test feature A"
> >>     },
> >>     "complex": [
> >>         { "rel": "http://example.org/parent <http://example.org/parent>", "href":
> >> "http://example.org/sample2 <http://example.org/sample2>" },
> >>         { "rel": "http://example.org/child <http://example.org/child>", "href":
> >> "http://example.org/sample3 <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 <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 <http://www.w3.org/TR/json-ld/#basic-concepts>
> >> [2]: http://www.w3.org/TR/json-ld/#the-context <http://www.w3.org/TR/json-ld/#the-context>
> >> [3]: http://www.w3.org/TR/xlink11/ <http://www.w3.org/TR/xlink11/>
> >> [4]: http://geojson.org/geojson-spec.html#link-objects <http://geojson.org/geojson-spec.html#link-objects>
> >> [5]: http://geojson.org/geojson-spec.html#feature-objects <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>
> >> <mailto: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 <http://www.faculty.jacobs-university.de/pbaumann>
> >    mail: p.baumann@jacobs-university.de <mailto: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 <http://www.rasdaman.com/>, mail: baumann@rasdaman.com <mailto: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)
> 
> 
> 
> 
> -- 
> Ed Parsons
> Geospatial Technologist, Google
> 
> Google Voice +44 (0)20 7881 4501
> www.edparsons.com <http://www.edparsons.com/> @edparsons
>