- From: Jeremy Tandy <jeremy.tandy@gmail.com>
- Date: Mon, 19 Oct 2015 08:47:22 +0000
- To: Simon.Cox@csiro.au, l.vandenbrink@geonovum.nl, public-sdw-wg@w3.org
- Message-ID: <CADtUq_3afZKQUxr7SOQQQVdmX5LMiDvuzhaB894Jwr4UaKbfAw@mail.gmail.com>
Oops- Simon's unbalancing must be contagious - I forgot to define `title`
properly in my last example. Should have referred to `
http://www.w3.org/2000/01/rdf-schema#label`, see below:
{
"@context": {
"sampledFeature": {
"@id": "
http://def.seegrid.csiro.au/isotc211/iso19156/2011/sampling#sampledFeature",
"@type": "@id"
},
"title": {
"@id": "http://www.w3.org/2000/01/rdf-schema#label"
}
},
"@graph": [
{ "sampledFeature": "http://example.org/featureA" },
…
{
"@id": "http://example.org/featureA",
"title: "test feature A"
}
]
...
}
On Mon, 19 Oct 2015 at 09:42 Jeremy Tandy <jeremy.tandy@gmail.com> wrote:
> Hi Simon.
>
> That looks about right.
>
> In JSON-LD, the @id name-value pair exists within a nested object. You can
> add other name-value pairs within that nested object ... I think of these
> as extra RDF triples that are included in the graph.
>
> So the snippet from your example:
>
> {
>
> "sampledFeature": {
>
> "@id": "http://example.org/featureA",
>
> "title": "test feature A"
>
> },
> ...
> }
>
> includes the RDF triple
>
> *subject*: <http://example.org/featureA>
> *predicate*: :title
> *object*: "test feature A"
>
> (presumably title is aliased to `dct:title` ... other options include
> `rdfs:label`. Your choice, what ever you want to specify in the @context.
>
> Note that when you include additional name-value pairs like we have done
> above, you can't coerce [1] the property `sampledFeature` to always refer
> to an identifier (@id) because you need a nested object. Of course, you
> could include the target object at the top-level in the graph; e.g.
>
> {
>
> "@context": {
>
> "sampledFeature": {
>
> "@id": "
> http://def.seegrid.csiro.au/isotc211/iso19156/2011/sampling#sampledFeature
> ",
>
> "@type": "@id"
>
> },
>
> "title": {
>
> "@id": "http://www.w3.org/2000/01/rdf-schema#"
>
> }
>
> },
>
> "@graph": [
>
> { "sampledFeature": "http://example.org/featureA" },
>
> {
>
> "@id": "http://example.org/featureA",
>
> "title: "test feature A"
>
> }
>
> ]
> ...
> }
>
>
> HTH, Jeremy
>
>
> [1]: http://www.w3.org/TR/json-ld/#type-coercion
>
> On Mon, 19 Oct 2015 at 01:02, <Simon.Cox@csiro.au> wrote:
>
>> Whoops – unbalanced braces. Fixed below.
>>
>>
>>
>> *From:* Simon.Cox@csiro.au [mailto:Simon.Cox@csiro.au]
>> *Sent:* Monday, 19 October 2015 10:10 AM
>> *To:* jeremy.tandy@gmail.com; l.vandenbrink@geonovum.nl;
>> public-sdw-wg@w3.org
>> *Subject:* [ExternalEmail] RE: JSON a link poor format
>>
>>
>>
>> Thanks Jeremy –
>>
>>
>>
>> Indeed – the approach to linking in OM-JSON is probably more a statement
>> of requirements than a fully resolved solution.
>>
>> JSON-LD’s “@id” approach might be preferable, particularly (as you point
>> out) it is the only linking mechanism for JSON which is fully and formally
>> defined.
>>
>>
>>
>> How to mix in the other useful link properties?
>>
>> In JSON-LD the rel|xlink:arcrole function is satisfied by the property
>> itself.
>>
>> So we just need to handle ‘title’.
>>
>> Re-writing the example from the OM-JSON presentation in a more
>> JSON-LD-friendly manner, how does this look?
>>
>>
>>
>> ```
>>
>> {
>>
>> "name": "spec1",
>>
>> "sampledFeature": {
>>
>> "@id": "http://example.org/featureA", "title": "test feature A"
>>
>> },
>>
>> "complex": [
>>
>> { "http://example.org/parent": { "@id": "
>> http://example.org/sample2", "title": "parent sample" } },
>>
>> { "http://example.org/child": { "@id": "
>> http://example.org/sample3", "title": "child sample" } }
>>
>> ],
>>
>> ...
>>
>> }
>>
>> ```
>>
>>
>>
>> Simon
>>
>>
>>
>>
>>
>> *From:* Jeremy Tandy [mailto:jeremy.tandy@gmail.com
>> <jeremy.tandy@gmail.com>]
>> *Sent:* Friday, 16 October 2015 8:01 PM
>> *To:* Linda van den Brink <l.vandenbrink@geonovum.nl>; SDW WG (
>> public-sdw-wg@w3.org) <public-sdw-wg@w3.org>
>> *Subject:* Re: JSON a link poor format
>>
>>
>>
>> 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 <http://schema.org/name>*": "Manu Sporny",
>>
>> "*http://schema.org/url <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 <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` 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/",
>>
>> "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` 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> 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
>>
>>
>>
>>
>>
>>
Received on Monday, 19 October 2015 08:48:09 UTC