@context element

[samperd]

Hey Folks,

I don't know if element is the right word as i not an API pro or JSON master, however it is the term I can think of.

Anyhow, is there any thought of providing a context like section that may house various name spaces. This may help when extending the WET API Standard. Maybe there is a minimum context we would like to include?

eg: "@context":{ "skos":"http://www.w3.org/2004/02/skos/core", "ex": "http://example.com/vocab/", "foaf": "http://xmlns.com/foaf/0.1", "dct":"http://purl.org/dc/terms", "dcat":"http://www.w3.org/ns/dcat", "@language": "en", "name": { "@id": "dc:identifier" }, "title": { "@id": "dct:title" }, "title_fr": { "@id": "dct:title", "@language": "fr" }, "description": { "@id": "dct:description" }, "description_fr": { "@id": "dct:description", "@language": "fr" }, "type": { "@id": "dc:type" }, "broader": {"@id":"skos:broader"}

[LaurentGoderre]

Do you have an example of such feature, I have trouble understanding what purpose it would have

[samperd]

Sure,

Essentially it would be used to describe the API. So for example, if we had the API spec say we need a "metadata" element, but the solution vendor that wanted to implement an API under the GOC API spec outputed "_meta" then perhaps the GOC API spec could amintain its own namespace describing elements. The @context section would refer users to the various namespaces used in the JSON output of API. Then finaly when someone uses "_meta" and trace back the namespace they would learn that "_meta" = "metadata" and then we have interop.

The second example as you might see above is handling bilingualism with "title" and "title_fr", or "description" and "description_fr". Bilingualism is handled many different ways and is spec'ed in one way in the documents.

description:
    {
        "en":"english description",
        "fr":"Description francais"
    },

Perhaps the @context section can help communicate what is meant between the two different approaches. Again, thinking from the perspective of a vendor not needing to re-engineer their solution in order to meet the GOC API Spec.

Here is an example of this functionality in a datapackage.json file. http://donnees.ec.gc.ca/data/

By switching the interface to french the description above switches. This extends the datapackage.json specification by specifying the extension in the @context section.

here is a more complex example of a datapackage in a viewer:

[LaurentGoderre]

The goal of this standard is to standardize API so that all our API deal with the same use cases the same way. If a developer wants to mix our data with a third party, it falls on them to create the cross link. We shouldn't pollute our APIs to try an meet third party APIs

[chrismajewski]

Laurent describes this well with the hope that two things would happen.

1. Services would be consolidated to these set of standards to a single namespace. The hope would be this would align with HTML Data, schema.org encoded GC metadata as designed for the MWS' Metadata Application Profile for Canada.ca.
2. That where, for other international standardization through adopted services, we would create sets of prescriptive exemptions. Mapping services that align to OGC standards would be an example.

Since this issue was posted the MWS (TBS::CIOB::Config Team) has been calling to push applications to store data in the MWS and create APIs to this document as a means of application migration. Also, the Federal Geospatial Platform (FGP) is presently being integrated into the the Open Data Portal (open.canada.ca) calling for all other Geospatial metadata to be served through the FGP served a common platforms.

I would prefer we not take a step to encourage great variation and specialization but you do expose the possibility that we should prepare for the possibility that multiple namespaces may be required regardless.