Re: JSON a link poor format

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/

On Fri, 16 Oct 2015 at 15:45 Jon Blower <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/
>
> (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> wrote:
>
> Me too. For some, though, it has RDF baggage.
> On Fri, 16 Oct 2015 at 13:50, Scott Simmons <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> wrote:
>>
>> Thanks Jeremy, a great intro !
>>
>> ed
>>
>>
>> On Fri, 16 Oct 2015 at 12:41 <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> 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/",
>>> >>   "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` <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` <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)
>>>
>>>
>>>
>>>
>>> --
>>
>> *Ed Parsons*
>> Geospatial Technologist, Google
>>
>> Google Voice +44 (0)20 7881 4501
>> www.edparsons.com @edparsons
>>
>>
>>
>