Publishing Interoperability Resources as Definitions

Introduction

The OGC maintains a Definitions Server under the auspices of the OGC Naming Authority and policies governing use of "names" - a.k.a. identifiers.

For convenience, "names" are Web addresses, so the name can be dereferenced (i.e. followed as links) to get the definition. The Definition Server implements this using best practices for Linked Data, so that definitions can be delivered in multiple different forms.

For example, a web application can access defintions using JSON format, to incorporate into a user interface, or you can browse via the HTML views. For incorporation into external systems, then RDF provides a rich data transfer model.

Most definitions are simple terms, however the Definitions Server supports richer types of definition, such as Application Schema and Interoperability Profiles, which allow communities of practice to share interoperability resources.

For the CSIE, Profiles are especially important, as the Defintions Server allows us to publish very simple "profiles of profiles" so that, for example an EU Air Quality Observation Profile can be further profiled for Citizen Science Air Quaity Observations, and then further profiled for specific projects, such as HackAir.

This document provides guidance on the available support and methodology for publishing different types of resource in this initial experimental phase.

Common governance concerns

For any resource, it is necessary to define its governance arrangements, both so OGC can manage the content, and to allow users to decide if it's suitable for reuse.

Using the terminology from ISO19135, OGC is the Registry Manager - i.e. we maintain the infrastructure

OGC-NA is the Register Managerfor the top level domain http://www.opengis.net/def/

Temporary registers can be delegated under

http://www.opengis.net/def/experimental/<register>;

and for each new register we need to know:

1) the Register Owner (what organisation has responsibility for the content - what is the source of the data - e.g. the HackAir project)

2) the Control Body (who makes decisions as to the policy for updating the register)

3) the Register Manager (typically this will be delegated by the Control Body to OGC staff (Rob Atkinson) to perform this on your behalf - but we are very happy to provide access to self-manage content

4) Submitting Organisations - who is allowed to submit proposed updates (if any expected)

In the case of externally defined definitions of more general use (i.e. not really experimental - but to be proxy hosted by OGC to make definitions accessible in an interoperable fashion - then consult with OGC-NA (via Rob Atkinson) to explore best solutions

In all cases, source materials should be checked into the CSIE git ub and an issue raised to review and import it, assigned to Rob Atkinson and stating who has the roles identified about. We will then negotiate about maintenance and change.

Controlled vocabularies

(note, observable properties are not simple vocabularies - they need units of measure etc we will support a richer register for these, the design of which will emerge in the IE)

Option 1: SKOS

The SKOS standard (in RDF) is the main way vocabularies are managed - it is a rich standard that allows for multi-lingual alternative labels, heirarchies, crosswalks etc. All vocabularies are available in this format - but it is not expected that participants need to provide this.

Option 2: CSV

Simple lists of definitions can be provided by spreadsheet or CSV

term,preferredlabel,definition

(A spreadsheet importer to the Definitions Server is in development)

Option 3: GML dictionary (XML)

GML dictionaries can be directly imported into the Definitions Server

Option 4: Whatever you have

If there is a form that is native to your system and you can easily dump (and ingest) let us know - check in an example and README with links ot documention if possible.

Profiles

Profiles will be the main way of publishing a statement about what data means and how it is structured. For now, identify the baseline standard(s) and any constraints - e.g. using the SOSA vocabulary with sensor types from list X and Rob Atkinson will start the process of publishing a formal description.

(we only expect a handful in the IE so its not worth trying to kae this self-managing, and we will need to work to get all related baseline definitions into the Definitions Server anyway

Observable Properties

Treat these as per any other resource for now - check in the source data into github - and this will be used to design a specialised register.

-- RobAtkinson - 09 Oct 2018