Re: JSON a link poor format

JSON allows almost anything for links, so there is no clear practice that provides consistency; present link semantics are just as ambiguous as in RDF. And @context is practically a schema language, but there is no established practice yet for using it this way. These are some of the issues that Joan Maso addressed in the TB-11 ER on JSON and GeoJSON. JSON-LD has great potential, but desperately needs some guidance on best ways to do many of things that it has the potential for. Fortunately there is a Best Practices document in preparation…

Josh

> On Oct 16, 2015, at 11:35 AM, Jon Blower <j.d.blower@reading.ac.uk> wrote:
> 
>> That said, the evidence of JSON-normality is in the examples I provided above; with proper use of the @context, JSON-LD looks _exactly_ like JSON. 
> 
> Yep, that’s the killer feature. Some corner cases are hard to do cleanly but 99% of the time this seems to be true.
> 
> (One decision is whether to use JSON-schema. Validating against both JSON-schema and JSON-LD is pretty hard in the general case. In MELODIES we’ve given up trying to use schema and are sticking with JSON-LD, as far as we can.)
> 
> Cheers,
> Jon
> 
> 
>> On 16 Oct 2015, at 16:06, Jeremy Tandy <jeremy.tandy@gmail.com <mailto:jeremy.tandy@gmail.com>> wrote:
>> 
>> Thanks Jon ...
>> 
>> > The point is that the RDF “baggage” should not be a worry, if anyone’s concerned about it. You can use JSON-LD without knowing or caring about RDF
>> 
>> I completely agree, but there is a perception that may arise. It's worth being aware of it :-) ... 
>> 
>> That said, the evidence of JSON-normality is in the examples I provided above; with proper use of the @context, JSON-LD looks _exactly_ like JSON. 
>> 
>> There are some additional complexities encountered when using JSON-LD relating to how the keywords are processed (@base, @context, @vocab etc.) ... these can be seen as challenging by people who just want "normal JSON". However, IMHO, you can given them normal JSON & they can ignore the @context, whilst those who want/need to be more specific can be.
>> 
>> Jeremy
>> 
>> [1]: http://www.w3.org/TR/tabular-metadata/ <http://www.w3.org/TR/tabular-metadata/> 
>> 
>> On Fri, 16 Oct 2015 at 15:45 Jon Blower <j.d.blower@reading.ac.uk <mailto:j.d.blower@reading.ac.uk>> wrote:
>> I’d like to add my appreciation to everyone else’s for Jeremy’s very helpful summary!
>> 
>> Regarding the RDF baggage, it’s interesting to note that Many Sporny, the driving force behind JSON-LD, hates RDF and the Semantic Web:
>> 
>> http://manu.sporny.org/2014/json-ld-origins-2/ <http://manu.sporny.org/2014/json-ld-origins-2/>
>> 
>> (note: some strong opinions and strong language in here!)
>> 
>> The point is that the RDF “baggage” should not be a worry, if anyone’s concerned about it. You can use JSON-LD without knowing or caring about RDF. (It’s JSON-LD not JSON-RDF for a reason…)
>> 
>> Cheers,
>> Jon
>> 
>>> On 16 Oct 2015, at 13:51, Jeremy Tandy <jeremy.tandy@gmail.com <mailto:jeremy.tandy@gmail.com>> wrote:
>>> 
>>> Me too. For some, though, it has RDF baggage. 
>>> On Fri, 16 Oct 2015 at 13:50, Scott Simmons <ssimmons@opengeospatial.org <mailto:ssimmons@opengeospatial.org>> wrote:
>>> 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 <mailto: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
>>>> 
>>> 
>> 
>