Re: JSON a link poor format

... And I'd love some clear and concise guidance about what to write in
that document :-)
On Fri, 16 Oct 2015 at 18:11, Joshua Lieberman <jlieberman@tumblingwalls.com>
wrote:

> 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> 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/
>
> 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
>>>
>>>
>>>
>>
>
>