The OGC Definitions Server

About the OGC Definitions Server

The OGC Definitions Server is a Web accessible source of information about things ("Concepts") the OGC defines or that communities ask the OGC to host on their behalf. It applies FAIR principles to the key concepts that underpin interoperability in systems using OGC specifications.

These things can be anything that is important in the course of interoperability around spatial information where the OGC plays a role in facilitating common understanding - either through publishing specifications or assisting communities to share related concepts. OGC uses stable web addresses (URIs) to unambiguously identify concepts in its specifications. The Definitions Server makes those URIs "work" - i.e. makes them dereference to a definition that can be used.

Examples include the OGC glossary, terms from GeoSPARQL, technical terms from application schemas such as the HY_Features schema from the Hydrology Domain Working Group, and many others.

The participation of OGC in the European Union’s Horizon 2020 research and innovation programme projects DataBio (Grant Agreement No 732064), NextGEOSS (Grant Agreement No 730329), and CYBELE (Grant Agreement No 825355) has contributed to the development of The OGC Definitions Server, ensuring that these and future projects can benefit from a free and sustainable service.

What the OGC Definitions Server Offers

  1. A common way to resolve terms published by OGC to get details of definitions (instead of downloading large or complex documents in varying formats).
  2. Ability to get machine readable versions of these details (e.g. JSON to allow simple integration of details into Web and mobile applications).
  3. Per-term or as-package options for downloading details singly or in bulk.
  4. Flexible capability to cross-link between terms.
  5. Ability to use any information model to extend available details.

Terminology

Terminology here is important and carefully specified because different types of things behave differently!

  • Concept - an individual definition 
  • ConceptScheme - a set of Concepts and Collections managed as a whole - this is deemed to be a "Register" according to ISO19135 (Procedures for Registration) 
  • Collection - a way of grouping Concepts - inside or across ConceptSchemes, without requiring "broader/narrower" semantics.
  • Term - an identifiable object - i.e. any of Concept, ConceptScheme etc. 
  • Definition - the content describing a term - may consist of text or a data object or a combination of both. 
  • Resource - an information object on the Web. Typically the Definitions Server will redirect qualified term identifiers to some resource.

Concept, ConceptScheme, and Collections are defined by the Simple Knowledge Organization System (SKOS) (see below).

Current Status

The Definitions Server has a complete set of terms that have been defined by OGC since the inception of the OGC Naming Authority - which aims to keep all such URL references consistent.

Efforts are underway to improve the scope and detail of information available about each term - in particular cross references between specification documents and related Concepts.

As of Nov 2019 the access API is undergoing an upgrade to comply with the emerging W3C Recommendation for "Content Negotiation by Profile".

Making Concepts FAIR - Findable, Accessible, Interoperable, and Reusable
 

Findable

The Definitions Server is implemented using Linked Data principles - so the combination of stable URIs allowing references to be made from outside, and "follow your nose" navigation via links from one term to related terms provides enhanced findability.

Currently a limited search capability over Concept definitions is provided, however the contents are indexable by external search engines.

Accessible

The Definitions Server does not make any assumptions about the client software that may be used now or in the future to access definitions, other than the use of HTTP protocols. This enhances accessibility for different environments.

The "Web-friendly" way of using an identifier (i.e. a URL) to get more information is augmented by "content negotiation" - the Definitions Server can deliver both user-friendly Web pages and other forms of resource representations, e.g. JSON-LD or Turtle (TTL).

Figure 1 shows different views of a Concept HY_Feature. The left panel shows an HTML representation, the middle shows the same information using TTL, and the right using JSON. All three representations have the same content, but differ in its serialization/format. This allows both human users to explore the OGC Definition Server, as well as machines to process its content.

Figure 1. Various representations of the same content (fragments, HTML left, TTL middle, JSON right)
Figure 1. Various representations of the same content (fragments, HTML left, TTL middle, JSON right)

Interoperable

The interoperability of these term URI behaviours and the resources they provide access to is a key goal. There are several aspects of this handled using different mechanisms:

  1. Content model: can the client understand how the data is structured?
  2. Encoding: can the client parse the response?
  3. Interaction: how can a client ask for the form it needs?

Content Interoperability

The identifiers mentioned above, i.e. the URLs that can deliver content (in this case details of definitions) to the user, are termed Concepts and are organized into ConceptSchemes - and Collections. Concept, ConceptScheme, and Collections are defined by the Simple Knowledge Organization System (SKOS). SKOS is a W3C recommendation and widely used as a standard data model for sharing and linking knowledge organization systems via the Web.

So why SKOS? Many knowledge organization systems, such as thesauri, taxonomies, classification schemes, and subject heading systems, share similar structure, and are used in similar applications. Even though they might even share exact semantics, you need to learn that by explicitly discovering, accessing, and evaluating the content. Without a standardized interface, this endeavor is labor-intensive and can hardly be executed by machines.

SKOS captures much of this similarity and makes it explicit. It enables data and technology sharing across diverse applications by providing a lightweight, intuitive language for developing and sharing knowledge. In most cases, existing knowledge can be transformed into SKOS, because the SKOS data model provides a standard, low-cost migration path for porting existing knowledge organization systems.

Encoding Interoperability

The Definitions Server currently offers a range of encodings for all terms: 

  1. HTML 
  2. JSON (using JSON-LD augmentations to specify URLs ) 
  3. RDF (as XML,TTL or JSON-LD) 
  4. Plain text.

Use of JSON-LD is suggested for most applications because its simply JSON with extra annotations to turn relevant element names and values into unambiguous URIs. It’s an encoding of RDF, but easily parsed by browsers.

Where applicable, certain types of resources are also available in the original or additional formats. For example, Application Schemas will be made available as XML schema (XSD) and UML (XMI) forms.

Interaction (API) Interoperability

The Definitions Server maximises interoperability through its use of HTTP to access resources.

Flexibility is managed through three key mechanisms based on W3C recommendations:

  1. Separation of the concepts of "things" and "information resources representing things", as per w3.org/2001/tag/issues.html#httpRange-14
  2. Content-negotiation (asking for a specific encoding type in a HTTP GET response), as per w3.org/Protocols/rfc2616/rfc2616-sec12.html
  3. Content-negotiation-by-application-profile (CNAP) (asking for a particular view of available information), as per w3.org/TR/dx-prof-conneg/

NB: CNAP is a recommendation undergoing final steps towards Recommendation at W3C with input from OGC Definitions Server design. The full implementation of this specification is underway, including the formalisation of the different view profiles needed.

As needs are identified, new profiles can be specified and arbitrary "graphs" created by custom API endpoints to deliver different views of the available semantic resources. Interoperability is supported by publishing these profiles as definition resources for reuse.

Reusable

The OGC Naming Authority manages the Definitions Server to ensure all term URIs are stable with transparent governance. These identifiers can thus be safely used in external context. All content is freely available for reuse. Reuse is envisaged largely through the machine-readable versions.


Using the Definitions Server

URI Access

Accessing definitions by following (i.e. "dereferencing") OGC published URIs is supported.

The server will respond with an HTTP 303 URI redirect to the current service interface appropriate to the requested profile (view) and format.

http://www.opengis.net/def/docs/03-003r10

HTTP 303
Location: http://defs.opengis.net/elda-common/ogc-def/resource?uri=http://www.opengis.net/def/docs/03-003r10

(the actual final resource URL may change as we improve the interface - but the original URI will always work)

Organisation of ConceptSchemes, Collections, and Concepts

Every Concept belongs to a ConceptScheme that will usually be identified by the base part of the URI path:
http://www.opengis.net/def/docs/03-003r10 skos:inScheme http://www.opengis.net/def/docs

Each ConceptScheme will have a "top level" Collection that contains a list of members (which may be a flat list or a list of sub-Collections). By default this will have a URI based on adding a "/" to the ConceptScheme URI. This is also made explicit in the data to allow link following:
http://www.opengis.net/def/docs policy:collectionView http://www.opengis.net/def/docs/

NB: many systems conflate URL paths with and without trailing "/" to be the same thing - but this potentially leads to ambiguity and typically needs other non-standard mechanisms to access metadata about a collection.

Concepts may also be organised in a hierarchical "taxonomy" via a non-overlapping set of broader/narrower relationships, with the top of each hierarchy linked via skos:hasTopConcept from the parent ConceptScheme.

This supports the following capabilities:

  1. ConceptSchemes are the "unit of governance" where metadata and download links for sets of definitions can be accessed
  2. Collections are a flexible nested way of listing related subsets of terms - where lists may overlap - but do not state semantic relationships between terms
  3. Concepts are the basic resources with definitions
  4. Concepts may be semantically related using broader/narrower and other match (e.g. skos:exactMatch)

Search

A basic search capability over Concept definitions is provided via the underlying interface e.g.
http://defs.opengis.net/elda-common/ogc-def/concept?labelcontains=Catchment

This provides machine readable outputs if requested via the _format parameter or the HTTP Accept: header.
https://defs.opengis.net/elda-common/ogc-def/concept?labelcontains=Catchment&_format=ttl

Searches may be constrained to a specific ConceptScheme: 
https://defs.opengis.net/elda-common/ogc-def/concept?labelcontains=Profile&scheme=http://www.opengis.net/def/docs

(note URL encoding is required for parameters with URI values - browsers tend to do this automatically)

Downloading Data

Every term includes a link to an "alternates" view:

Figure 2. Alternates link
Figure 2. Alternates link

This link can be accessed by qualifying any Definitions Server hosted URIs with _view=alternates or _profile=alternates. A W3C compliant view for the specific concept (not the dataset as a whole) can be accessed with _profile=all.

This view lists available formats for both the individual term and the collection or package that defines it:

Figure 3. Available alternate representations
Figure 3. Available alternate representations

ConceptSchemes offer download options for original sources of definitions - for example an Application Schema will have a download link for the canonical UML model file.

Collections allow list of concepts to be downloaded.

Concepts allow simple packages of information about the concept itself to be accessed.


For More Information

Additional Resources

Contact

The OGC Definitions Server is managed by the OGC Naming Authority. Contact names [at] opengeospatial.org.

Feedback

Feedback is welcome on how to improve any aspect of the OGC Definitions Server.

If you intend to integrate or replicate aspects of the service please drop us a line so we can ensure future changes do not negatively impact you.

The User Interface (HTML) views are largely "out-of-the-box", and suggestions for improvement are welcome but may not be prioritised over content improvement and machine-readable options.

Additional Requirements

If the Definitions server is potentially able to solve a problem for a community, then it can be readily extended in various ways. In general, requests should be done through an existing OGC process, such as a Working Group, however technical feedback or requests to explore the feasibility of extended functionality can be made via names [at] opengeospatial.org.