Re: JSON a link poor format

Another consideration from the XLink experience in GML (for those who do not know: in the GML standard, OGC is using the W3C XLink standard to represent links between resources): 

One reason for using XLink over any other mechanism for representing links was that it was a W3C XML standard and there was hope that it would see good adoption with time - and with that software support. But while XML Schema, XPath, XSLT, XQuery, etc have seen good software support over the years that never happened with XLink. I would say in GML it would not have been a big difference, if we would have ignored Xlink and used our own mechanism. Using XLink did not help much to make using links easier to anyone.

No doubt JSON-LD looks very promising, and it probably is the best bet for using links in JSON, but we should make sure that we not only evaluate a formalism from looking at the JSON, but also consider who could "understand" the links right away or how easy developers can make use of the links in their software.

Clemens


> On 16 Oct 2015, at 11: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/ <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>> 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
> 
>  
> 
>  
>