Testbed-12 OWS Context / Capabilities Engineering Report

Publication Date: 2017-05-22

Approval Date: 2017-03-23

Posted Date: 2016-11-13

Reference number of this document: OGC 16-052

Reference URL for this document: http://www.opengis.net/doc/PER/t12-A073

Category: Public Engineering Report

Editor: Joan Masó

Title: Testbed-12 OWS Context / Capabilities Engineering Report

OGC Engineering Report

COPYRIGHT

WARNING

This document is an OGC Public Engineering Report created as a deliverable of an initiative from the OGC Innovation Program (formerly OGC Interoperability Program). It is not an OGC standard and not an official position of the OGC membership.It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, any OGC Engineering Report should not be referenced as required or mandatory technology in procurements. However, the discussions in this document could very well lead to the definition of an OGC Standard.

LICENSE AGREEMENT

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications.

This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.

Table of Contents

1. Introduction
2. References
3. Terms and definitions
4. Conventions
- 4.1. Abbreviated terms
- 4.2. Data dictionary tables
5. Overview
6. OWS Context to describe the Contents of the service
- 6.1. Introduction
- 6.2. The WMS case.
7. A context document as a GetCapabilities response
8. Associations as links to context documents.
- 8.1. Links to OWS context for each individual content (each resource)
  - 8.1.1. CR to OWS Common to allow linking resources to OWS Context documents.
- 8.2. Links to OWS context for the whole service
  - 8.2.1. CR to OWS Common to allow linking services to OWS Context documents.
9. OpenSearch in combination with ServiceMetadata
Appendix A: Revision History
Appendix B: Bibliography

Abstract

The OGC service metadata document (sometimes also called "capabilities" document) is a key part in the service discovery. It describes the service and also the resources that the service expose. Resources are listed in the service metadata document inside a section named as Contents by OWS Common. There are two main limitations to the current Contents section approach:

OWS Common offers flexibility for describing resources and it only proposes a very minimum set of metadata in figure 7 of OGC 06-121r9 called DatasetSummary that need to be sub-classed (i.e. extended) by any specific application. As a result, each standard proposes its own alternative for it. Integrated client developers need to implement them separately.
If the number of resources is very large or the service is highly dynamic, the Contents section can be too long or useless and neither the service nor the client can handle it efficiently.

This Engineering Report proposes a double solution to the Contents section of the service metadata documents: It proposes ways to encode the Contents section using the OWS Context encoding data types and it introduces the use OpenSearch as a way to request a subset of the resources that the service can provide access to. In that sense, the use of the OGC 10-032r8 OpenSearchGeo can provide the long time needed geospatial and temporal filter capabilities.

Business Value

This ER has the objective of providing a new encoding for OWS Common Service Metadata for resources that can have a minimum transversal structure based on OWS context making integration of different services easier. Based on this minimum set of resource properties, it suggests a new way to interrogate GetCapabilities based on OpenSearch that could be valid alternative for services with very large number of resources or the service is highly dynamic content that currently are not well supported by the traditional monolithic GetCapabilities approach.

What does this ER mean for the Working Group and OGC in general

This ER is important for the WMS SWG, and the OGC in general, because it provides a minimum set of properties to describe resources in the GetCapabilities and a way to query a capabilities document and get a subset of the actual content.

How does this ER relate to the work of the Working Group

This ER relates to the work of the WMS SWG because the use of OpenSearchGeo in requests allow to cover the user requeriment of services with a too long list of geospatial resources that can not be enumerated. This characteristic could be included in the next version of the WMS standard.

Keywords

ogcdocs, testbed-12, Quality, Capabilities

Proposed OGC Working Group for Review and Approval

WMS.SWG

1. Introduction

1.1. Scope

This OGC® document proposes an alternative encoding for the resources part of OWS Common GetCapabilities

This OGC® document describes way to use OpenSearch Geo in GetCapabilities queries.

This OGC® document is applicable to OWS Common standard that expose data as a list of resources and to any web services that addopts OWS Common.

1.2. Document contributor contact points

All questions regarding this document should be directed to the editor or the contributors:

Table 1. Contacts
Name	Organization
Joan Masó	UAB-CREAF

1.3. Future Work

Conduct a practical experiment using OpenSearch Geo in requesting OWS Common service metadata to make the Contents section shorter and validate the efficiency of the solution in different use cases including a highly dynamic service and a service with a very long list of resources. There is a need to experiment with services responding OWS Context documents as an alternative to the current GetCapabilies response and validate the theoretical advantages. Consider a CR to OWS Common that is described in the "A context document as a GetCapabilities response" Section.

1.4. Foreword

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

2. References

The following documents are referenced in this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.

OGC 06-121r9, OGC® Web Services Common Standard

NOTE: This OWS Common Standard contains a list of normative references that are also applicable to this Implementation Standard.

3. Terms and definitions

For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard [OGC 06-121r9] and in Clause 4 of the OpenSearch Geo and Time Extensions [OGC 10-032r8] and in Clause 4 of the OWS Context Conceptual Model [12-080r2, ] shall apply.

4. Conventions

4.1. Abbreviated terms

Some more frequently used abbreviated terms:

OWS OpenGeospatial Web Services
WMS Web Map service
KVP Key and Value Pair

4.2. Data dictionary tables

Table 2. Contents of data dictionary tables
Column title	Column contents
Names (left column)	Two names for each included parameter or association (or data structure). The first name is the UML model attribute or association role name. The second name uses the XML encoding capitalization specified in Subclause 11.6.2 of [OGC 06-121r3]. The name capitalization rules used are specified in Subclause 11.6.2 of [OGC 06-121r3]. Some names in the tables may appear to contain spaces, but no names contain spaces.
Definition (second column)	Specifies the definition of this parameter (omitting un-necessary words such as “a”, “the”, and “is”). If the parameter value is the identifier of something, not a description or definition, the definition of this parameter should read something like “Identifier of TBD”.
Data type and value (third column) or Data type (if are no second items are included in rows of table)	Normally contains two items: The mandatory first item is often the data type used for this parameter, using data types appropriate in a UML model, in which this parameter is a named attribute of a UML class. Alternately, the first item can identify the data structure (or class) referenced by this association, and references a separate table used to specify the contents of that class (or data structure). The optional second item in the third column of each table should indicate the source of values for this parameter, the alternative values, or other value information, unless the values are quite clear from other listed information.
Multiplicity and use (right or fourth column) or Multiplicity (if are no second items are included in rows of table)	Normally contains two items: The mandatory first item specifies the multiplicity and optionality of this parameter in this data structure, either “One (mandatory)”, “One or more (mandatory)”, “Zero or one (optional)”, or “Zero or more (optional)”. The second item in the right column of each table should specify how any multiplicity other than “One (mandatory)” shall be used. If that parameter is optional, under what condition(s) shall that parameter be included or not included? If that parameter can be repeated, for what is that parameter repeated?

When the data type used for this parameter, in the third column of such a table, is an enumeration or code list, all the values specified shall be listed, together with the meaning of each value. When this information is extensive, these values and meanings should be specified in a separate table that is referenced in the third column of this table row.

The data type of many parameters, in the third table column, is specified as “Character String type, not empty”. In the XML Schema Documents specified herein, these parameters are encoded with the xsd:string type, which does NOT require that these strings not be empty.

(These conditions may seem obvious to you, but they are rarely obvious to most readers.)

The contents of these data dictionary tables are normative, including any table footnotes.

(This means that these table footnotes should use the normative verbs "shall", "should", "may", and "can", as defined in Subclause 5.3 "Document terms and definitions" of OWS Common [OGC 06-121r9].)

5. Overview

5.1. The OWS Common ServiceMetadata document.

Service metadata document is the key part of the service discovery. It describes the service and also the resources that the service exposes. It follows the structure proposed in OWS Common. It is composed by 5 independent sections identifying the service identification, the service provider, the service operations and the contents (in addition other metadata can be provided following other formats). Subclause 7.4 in the OWS Common standard defines the service metadata document.

$includes\images\ServiceMetadataMainClass$

Figure 1. Service metadata main class UML diagram (from OWS common)

The service metadata document is the result of a GetCapabilities operation and for this reason it is also commonly know as the "capabilities document".

The first three sections (service identification, service provider, and service operations) are fully described in the OWS Common standard. For the XML representation, schemas.opengis.net provides XML schemas for validating these sections.

The list of resources offered by a service is listed in a section that OWS Common names as “Contents section”. There are two main limitations to the current Contents section approach:

OWS Common offers flexibility for describing resources and it only proposes a very minimum set of metadata in figure 7 of OGC 06-121r9 called DatasetSummary that need to be sub-classed (i.e. extended) by any specific application. As a result, each standard proposes its own alternative for it. Integrated client developers need to implement them separately.
If the number of resources is very large or the service is highly dynamic, the Contents section can be too long or useless and neither the service nor the client can handle it efficiently.

5.2. OWS Context

The OGC Web Services Context Document (OWS Context) was created to allow a set of configured information resources to be passed between applications. The goal is to support use cases such as the distribution of search results, the exchange of a set of resources such as OGC Web Feature Service (WFS), Web Map Service (WMS), Web Map Tile Service (WMTS), Web Coverage Service (WCS), and others in a common operating picture.

In practice it provides a list of resources that belong together for a reason. Each resource has a minimum set of instructions for its retrieval from the containing service (i.e. referenced as a sample URL).

OWS Context document can be created in XML Atom and in GeoJSON encodings. In this Testbed a HTML5 format has also been suggested in the Testbed 12 OWS Context JSON, JSON-LD and HTML5 ER (OGC 16-053).

One drawback of the OWS Context standard is that it does NOT describe a service mechanism to produce it (e.g. in the same way that WFS is the service that was designed to communicate GML content). Context documents are supposed to be produced by advanced clients and stored in the local hard drive of the user and for later retrieval or to exchange them by email or other means to other users. For example, a OWS Context document can be linked and exposed by web pages to be shared over the web (in the same way that other RSS or Atom feeds are exposed). In addition, there is a possible use case where a CSW server can deliver the results list of a catalogue query in OWS Context format. The specification of this kind of CSW service has not been produced yet. For completeness, a WPS service has been proposed as a mechanism to deal with the creation of OWS Context documents.

5.3. Combining Service Metadata and OWS context

OWS context and the service metadata partially share a common goal: describe a list of resources provided by services. This ER explores the potential behind this common goal and describes different ways of taking advantage of the combination of ServiceMetadata and OWS Context documents. This combination can serve different purposes:

A GetCapabilities operations can respond a OWS Context document as a alternative format replacing the normal service metadata document. In this case, the document response can be in either XML Atom, the GeoJSON encoding or the HTML5 format suggested by the Testbed 12 OWS Context JSON, JSON-LD and HTML5 ER (OGC 16-053).
The Contents section can be written using the OWS Context encoding data model. This will present a common ground for the Content section that all services can share. An OWS Context resource could be extended, if needed, to accommodate the specific needs of each service. Since the OWS Common proposes a way to retrieve a single section of the capabilities document, a service implementing this approach receiving a request for “SECTIONS=contents” will be able to provide a stand-alone perfectly valid OWS Context document describing all its resources.
Each content element in the ServiceMetadata document will include one or more links to OWS context documents that provide an additional lists of possible resources that can be combined with the current content to create a more complete common operation picture. This approach could also be used to provide a list of resources that reside in different services that, in fact are alternative representations of the same dataset. This approach is an another implementation of the concept of service associations that has also been studied in the OGC 16-043 Testbed 12 - Web Integration Service Engineering Report.
The service metadata document provides a list of links to OWS context documents in a new section that allows for publicize resources lists (combining both local and remote resources) that together are suggestions for different common operational pictures that can be used to have different views of the content of this service.

5.4. Better queries for Service Metadata

If the number of resources listed in the service metadata document is very large or the service is highly dynamic, the Contents section can be too long or useless and neither the service nor the client can handle it efficiently. This ER also proposes another approach for the Service Metadata retrieval to solve this issue: the use of OpenSearch as a way to request a subset of the resources that the service can provide access to. This can help to make individual responses shorter and at the same time moves the GetCapabilities operation closer to a simple catalogue capabilities. In that sense, the use of OpenSearch provides kywork filter capabilities and the OpenSearchGeo extension (OGC 10-032r8) can provide geospatial and temporal filter capabilities exemplified in following request:
http://www.bob.com/wms?service=WMS
&request=GetCapabilities&sections=contents&
q=temperature&bbox=120,10,134,14&
start=2003-01-17&end=2004-01-17

A service that receives this request will return an OWS Context document (instead of a capabilities document) with all the resources that are related to temperature that also fit in the specified bounding box and are included in the specified temporal extent. If necessary, other specific extensions for the specific characteristics of the resources served by each type of services could be introduced.

This ER explores the possibility to apply OpenSearchGeo in the resource retrieval phase too as an alternative to request resource identifiers. This is only applicable to data resources (e.g. WMS, WMTS, WCS, WFS) but cannot be applied to WPS. For example, a WMS server could accept and OpenSearch syntax to request a map of a specific region and time about temperature without knowing the layer IDs for temperature.
http://www.bob.com/wms?service=WMS
&request=GetMap&q=temperature&
bbox=120,10,134,14&time=2003-01-17&
width=256&height=256

6. OWS Context to describe the Contents of the service

This section introduces how OWS Context can be used as a description of the contents of data service in the ServiceMetadata document

6.1. Introduction

The Contents section of the service metadata document is the less precisely described in OWS Common because it depends deeply on the nature of the service. OWS Common only specifies that a list of resource descriptions will be includes (it calls each one “datasetSummary”). OWS Common establishes that a dataset summary can have an ID, a title, an abstract, some keywords, a Bounding Box in WGS84, some Bounding Boxes in other CRS’s and some link to external metadata. All this elements are also present in OWS Context resource description. This ER is proposing to use a OWS Context encoding for this section. One of the advantages of OWS Context is that it presents some full examples of the URLs for the resources present in the services.

6.2. The WMS case.

Even is WMS 1.3 does not confrom OWS Common, it follows osme of its pattenrs. In particular, the contents section is easily identifiable by the existence of a root layer that acts as the root for the layer list.

In this example we are using the NASA NEO WMS service as an example. The real server is available at:
http://neowms.sci.gsfc.nasa.gov/wms/wms?
version=1.3.0&service=WMS&request=GetCapabilities

ServiceMetadata document simplified fragment for a NASA WMS service

<WMS_Capabilities version="1.3.0"
  xsi:schemaLocation="http://www.opengis.net/wms http://schemas.opengis.net/wms/1.3.0/capabilities_1_3_0.xsd"
  xmlns="http://www.opengis.net/wms"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink">
  <Service>
    <Name>WMS</Name>
  </Service>
  <Capability>
    <Request>
      <GetCapabilities/>
    </Request>
    <Exception>
      <Format>text/xml</Format>
    </Exception>
    <Layer>
        <Abstract></Abstract>
        <Layer>
          <Name>MODAL2_M_SKY_WV</Name>
        </Layer>
    </Layer>
  </Capability>
</WMS_Capabilities>

WMS 1.4 ServiceMetadata draft is adopting OWS Common a as a base line. Next figure shows the UML model of the Contents part of it.

$includes\images\WMS14contents$

Figure 2. OWS Contents adapted for WMS 1.4 UML class diagram

6.2.1. Mapping between WMS capabilities and OWS Context concepts

To see the convenience to replacing the OWS Common Contents with the OWS Context document, we need to map the concepts of one model into the other first. This subsection contains the mapping between the Contents section of WMS 1.4 service metadata (the version that WMS.SWG is working on to adopt OWS Common) and the OWS Context. In the mapping provided below in the from of a table, the four first columns comes from the OWS Context and the last four columns refers to WMS 1.4 layers section.

Table 3. Mapping between OWS Context and the WMS ServiceMetadata.
Name	Definition	Data type and Value	Multiplicity and Use	Name	Definition	Data type and Value	Multiplicity and Use
id	Unique Identifier assigned to the owc Resource. Used to reference a resource from other resources	CharacterString	One (mandatory)	identifier Identifier	An unambiguous reference to this layer, normally used by software	ows:CodeType, as adaptation of MD_Identifier class ISO 19115	Zero or one (optional)
title	A Human Readable Title for the owc Resource.	CharacterString	One (mandatory)	title Title	Title of this layer, normally used for display to a human	LanguageString data structure, see Table 15 on OCG 06-121r9	Zero or more (optional) Include when available and useful Include one for each language represented
abstract	Description of the Context Document Purpose/Content	CharacterString	Zero or one (optional)	abstract Abstract	Brief narrative description of this layer, normally available for display to a human	LanguageString data structure, see Table 15 on OCG 06-121r9	Zero or more (optional) Include when available and useful Include one for each language represented
updateDate	Date when the resource definition was updated	CharacterString	Zero or one (optional)
author	Identifier for the author of the resource definition	CharacterString	Zero or one (optional)	attribution Attribution	The provider of the source data for the Layer	AttributionDescription data structure, see Table 12	Zero or one (optional)
publisher	Identifier for the publisher of the resource definition	CharacterString	Zero or one (optional)
rights	Rights which apply to the resource definitiona	CharacterString	Zero or one (optional)
geospatialExtent	The geographic extent of the resourceb	GM_Envelope	Zero or one (optional)	wgs84BoundingBox WGS84BoundingBox	Minimum bounding rectangle surrounding dataset, using WGS 84 CRS with decimal degrees and longitude before latitude c	WGS84Bounding Box data structure see Subclause 10.2 of OGC 06-121r9	Zero or one (optional)
				boundingBox BoundingBox	Minimum bounding rectangle surrounding the layer, in the supported CRS	BoundingBox data structure, see Subclause 10.2 of OGC 06-121r9	Zero or one (optional)
temporalExtent	The temporal extent of the content of the resource	TM_GeometricPrimitive	Zero or one (optional)
contentDescription	A reference to a description of the Context resource in alternative format.	Any	Zero or one (optional)
preview	A URI identifying a preview of the resource	URI	Zero or more (optional)
contentByRef	A URI identifying a service which will return an immediately exploitable result by simply requesting based on the URI. The expectation is that the return type of this call will be a well-known format	URI	Zero or more (optional)	catalogueIdentifier CatalogueIdentifier	Unique identifier in other codespaces or catalogues.	ows:CodeType, as adaptation of MD_Identifier class ISO 19115	Zero or more (optional)
				dataURL DataURL	Offers a link to the underlying data represented by a particular layer.	ows:ReferenceType data structure on OCG 06-121r9	Zero or more (optional)
				featureListURL FeatureListURL	Points to a list of the features represented in a Layer	FormattedOnlineResource data structure, see Table 14	Zero or more (optional)
offering	Service or inline content offering for the resource targeted at OGC compliant clients	owc:OfferingType	Zero or more (optional)
active	This flag indicates the state of the resource within the context document. It can be interpreted by the caller as required (this may be defined in a profile or in the specific service extensions)	Boolean Default=TRUE	Zero or one (optional)	N/A
keyword	Keyword related to this resource definition. Shall support an optional codelist parameter.	CharacterString	Zero or more (optional)	keywords Keywords	Unordered list of one or more commonly used or formalised word(s) or phrase(s) used to describe this dataset	MD_Keywords class in ISO 19115	Zero or more (optional) One for each keyword authority used
minScaleDenominator	Minimum scale for the display of the layer.	double	Zero or one (optional)	minScaleDenominador MinScaleDenominador	Minimum scale denominator (inclusive) for which it is appropriate to generate a map of a Layer	Double type	Zero or one (optional) Include when relevant and available
maxScaleDenominator	Maximum scale for the display of the layer.	double	Zero or one (optional)	maxScaleDenominador MaxScaleDenominator	Maximum scale denominator (exclusive) for which it is appropriate to generate a map of a Layer	Double type	Zero or one (optional) Include when relevant and available
resourceMetadata	Metadata about the resource itself	Association	Zero or more (optional)	metadata Metadata	Additional metadata about this dataset	ows:Metadata	Zero or more (optional) One for each useful metadata object
folder	Definition of the folder structure in which the resource is placed.	CharacterString	Zero or one (optional)	layer/layer
extension	Any encoding should allow the user to extend the resource content to include custom items	n/a	Zero or more (optional)	supportedCRS SupportedCRS	Reference to a supported CRS	URI type	One or more (mandatory)
				catalogueIdentifier CatalogueIdentifier	Unique identifier in other codespaces or catalogues.	ows:CodeType, as adaptation of MD_Identifier class ISO 19115	Zero or more (optional)
				spatialResolution SpatialResolution	Spatial resolution of the data comprising the layer	SpatialResolution data structure, see Table 10 replace
				recomendedFormat RecomendedFormat	Recommended output formats for a map request	RecomendedFormat data structure	Zero or more (optional) Include when relevant and available
				cascaded	Indicates how main times the layer has been retransmitted by another Web Map Server (cascading).	Integer	Zero or one (optional) Default value is 0
				opaque	Indicates whether the map data represents vector features that probably do not completely fill space or the map data are mostly or completely opaque.	Boolean	Zero or one (optional) Default value is false
				noSubsets	Indicates whether the server can produce a map that is a subset of the full bounding box.	Boolean	Zero or one (optional) Default value is false
				fixedWidth	Indicates that the server can only produce map of a fixed width instead of an arbitrary width	Positive integer type	Zero or one (optional)
				fixedHeight	Indicates that the server can only produce map of a fixed height instead of an arbitrary height	Positive integer type	Zero or one (optional)

One interesting aspect that emerges is that OWS Common does not provide a way to define the temporal extent and spatial extent can only be provided in long/lat WGS84. Other fields related with authorship and publisher are better defined in OWS Context. On the other hand to apply OWS Context to the Contents section of the WMS, an extension of OWS Context is needed.

6.2.2. Example of a layer description in WMS

In this section we are demonstrating how a layer description looks like.

We will start with a layer representation copied directly from the NEO Web Mapping Service. More information about this service here: http://neo.sci.gsfc.nasa.gov/about/wms.php. The XML fragment has been extracted from the response to this request:
http://neowms.sci.gsfc.nasa.gov/wms/wms?
version=1.3.0&service=WMS&request=GetCapabilities

Layer description named MOD14A1_M_FIRE from the NEO Web Mapping Service

<Layer>
  <Name>MOD14A1_M_FIRE</Name>
  <Title>Active Fires (1 month - Terra/MODIS)</Title>
  <Dimension units="ISO8601" name="time" default="2016-04-01">2000-03-01/2016-04-01/P1M</Dimension>
  <MetadataURL type="FGDC">
    <Format>text/xml</Format>
    <OnlineResource xlink:href="http://neo.sci.gsfc.nasa.gov/servlet/FGDCMetadata?datasetId=MOD14A1_M_FIRE"/>
  </MetadataURL>
  <DataURL>
    <Format>text/html</Format>
    <OnlineResource xlink:type="simple" xlink:href="http://neo.sci.gsfc.nasa.gov/view.php?datasetId=MOD14A1_M_FIRE"/>
  </DataURL>
  <Style>
    <Name>rgb</Name>
    <Title>RGB Style</Title>
    <Abstract><![CDATA[A colored representation of the data.]]></Abstract>
    <LegendURL width="200" height="35">
      <Format>image/png</Format>
      <OnlineResource xlink:type="simple" xlink:href="http://neo.sci.gsfc.nasa.gov/palettes/modis_fire_l3.png"/>
    </LegendURL>
  </Style>
  <Style>
    <Name>gs</Name>
    <Title>Grayscale Style</Title>
    <Abstract><![CDATA[A grayscale representation of the data.]]></Abstract>
  </Style>
</Layer>

The following XML fragment shows how the previous layer description can be transposed into OWS Context.

OWS Context document describing only the layer MOD14A1_M_FIRE

<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:georss="http://www.georss.org/georss" xmlns:gml="http://www.opengis.net/gml" xmlns:owc="http://www.opengis.net/owc/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://purl.org/dc/elements/1.1/ ../encodings/xml/csw/2.0.2/rec-dcmes.xsd http://www.georss.org/georss ../encodings/xml/owc/1.0/georss.xsd http://www.opengis.net/gml ../encodings/xml/owc/1.0/gmlgeorss311.xsd http://www.opengis.net/owc/1.0 ../encodings/xml/owc/1.0/owc.xsd" xml:lang="ca-ES">
	<link rel="profile"
		href="http://www.opengis.net/spec/owc-atom/1.0/req/core"
		title="This file is compliant with version 1.0 of OGC Context"/>
	<id>http://neowms.sci.gsfc.nasa.gov/wms/wms</id>
	<title>NASA Earth Observations (NEO) WMS</title>
	<subtitle type="html">
              Remote sensing imagery from NASA Earth Observations (NEO).
      </subtitle>
	<entry>
		<id>http://neowms.sci.gsfc.nasa.gov/wms/wms/MOD14A1_M_FIRE</id>
		<title>Active Fires (1 month - Terra/MODIS)</title>
		<author>
			<name>Kevin Ward</name>
			<email>kevin.a.ward@nasa.gov</email>
		</author>
		<updated>2016-04-01T00:00:00Z</updated>
		<dc:publisher>NASA</dc:publisher>
		<georss:where>
			<gml:Envelope srsName="CRS:84" srsDimension="2">
				<gml:lowerCorner>-180.0 -90</gml:lowerCorner>
				<gml:upperCorner>180 90</gml:upperCorner>
			</gml:Envelope>
		</georss:where>
		<dc:date>2000-03-01T00:00:00Z/2016-04-01T00:00:00Z/P1M</dc:date>
		<link rel="via" type="application/xml" href="http://neo.sci.gsfc.nasa.gov/servlet/FGDCMetadata?datasetId=MOD14A1_M_FIRE" title="FGDC metadata"/>
            <link rel="enclosure" type="text/html"
   href="http://neo.sci.gsfc.nasa.gov/view.php?datasetId=MOD14A1_M_FIRE"
   title="HTML representatino of the data"/>
		<content type="text">Fire is a recurring part of nature. Wildfires can be caused by lightning striking a forest canopy or, in a few isolated cases, by lava or hot rocks ejected from erupting volcanoes. Most fires worldwide are started by humans, sometimes accidentally and sometimes on purpose. Not all fires are bad. Fire clears away dead and dying underbrush, which can help restore forest ecosystems to good health. Humans use fire as a tool in slash-and-burn agriculture to speed up the process of breaking down unwanted vegetation into the soil. Humans also use fire to clear away old-growth forests to make room for living spaces, roads, and fields for raising crops and cattle. But not all fires are good. Wildfires can destroy natural resources and human structures. Globally, fire plays a major role in Earth's carbon cycle by releasing carbon into the air, and by consuming trees that would otherwise absorb carbon from the air during photosynthesis. These maps show the locations of actively burning fires around the world, detected by instruments aboard NASA satellites.</content>
		<owc:offering code="http://www.opengis.net/spec/owc-atom/1.0/req/wms">
			<owc:operation code="GetCapabilities" method="GET" type="application/xml" href="http://neowms.sci.gsfc.nasa.gov/wms/wms?version=1.3.0&amp;service=WMS&amp;request=GetCapabilities"/>
			<owc:operation code="GetMap" method="GET" type="image/jpeg" href="http://neowms.sci.gsfc.nasa.gov/wms/wms?version=1.3.0&amp;service=WMS&amp;request=GetMap&amp;CRS=CRS:84&amp;BBOX=-180,-90,180,90&amp;WIDTH=720&amp;HEIGHT=360&amp;LAYERS=MOD14A1_M_FIRE&amp;FORMAT=image/jpeg&amp;STYLES="/>
			<owc:styleSet default="true">
				<owc:name>rgb</owc:name>
				<owc:title>RGB Style</owc:title>
				<owc:legendURL href="http://neo.sci.gsfc.nasa.gov/palettes/modis_fire_l3.png"/>
			</owc:styleSet>
			<owc:styleSet default="false">
				<owc:name>gs</owc:name>
				<owc:title>Grayscale Style</owc:title>
			</owc:styleSet>
		</owc:offering>
	</entry>
</feed>

This example illustrates that there is no information lost in the transformation.

6.2.3. Recommendation to replace the Contents with OWS Context

Both the mapping and the example suggest that replace the Contents section by OWS Context is possible. This way we can achieve a better degree of interoperability by reducing the number of encodings for describing metadata about the offerings/resources of a service.

If the service is asked to respond only the Contents section, a full OWS Context document can be returned as a response (like the one in the previous example but with all the resources of the service). This replacement is particularly relevant if the OpenSearchGeo request format is also adopted. OpenSearchGeo responses are expected to be provided in XML Atom encoding.

In case a complete Service Metadata document is requested, a OWS Context Service Metadata document can be generated but the Contents section will be replaced by the XML Atom encoding of the OWS Context.

Example of the Service Metadata document with XML Atom Contents

<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSpy v2008 sp1 (http://www.altova.com) by Joan Masó (UAB-CREAF-MiraMon). Based on previous documents of Keith Pomakis. -->
<Capabilities xmlns="http://www.opengis.net/wms/2.0"
xmlns:ows="http://www.opengis.net/ows/2.0"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/wms/2.0 ../wmsGetCapabilities_response.xsd" version="2.0.0">
	<ows:ServiceIdentification>
		<ows:Title>My Web Map Service</ows:Title>
        ...
    </ows:ServiceIdentification>
	<ows:ServiceProvider>
		<ows:ProviderName>MiraMon</ows:ProviderName>
        ...
    </ows:ServiceProvider>
	<ows:OperationsMetadata>
		<ows:Operation name="GetCapabilities">
		...
	</ows:OperationsMetadata>
	<ows:Languages>
		<ows:Language>en-us</ows:Language>
	</ows:Languages>
    <feed xmlns="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:georss="http://www.georss.org/georss" xmlns:gml="http://www.opengis.net/gml" xmlns:owc="http://www.opengis.net/owc/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://purl.org/dc/elements/1.1/ ../encodings/xml/csw/2.0.2/rec-dcmes.xsd http://www.georss.org/georss ../encodings/xml/owc/1.0/georss.xsd http://www.opengis.net/gml ../encodings/xml/owc/1.0/gmlgeorss311.xsd http://www.opengis.net/owc/1.0 ../encodings/xml/owc/1.0/owc.xsd" xml:lang="ca-ES">
    	<link rel="profile"
    		href="http://www.opengis.net/spec/owc-atom/1.0/req/core"
    		title="This file is compliant with version 1.0 of OGC Context"/>
    	<id>http://neowms.sci.gsfc.nasa.gov/wms/wms</id>
    	<title>NASA Earth Observations (NEO) WMS</title>
    	...
    	<entry>
    		<id>http://neowms.sci.gsfc.nasa.gov/wms/wms/MOD14A1_M_FIRE</id>
    		<title>Active Fires (1 month - Terra/MODIS)</title>
            ...
    		<owc:offering code="http://www.opengis.net/spec/owc-atom/1.0/req/wms">
                ...
    			<owc:operation code="GetMap" method="GET" type="image/jpeg" href="http://neowms.sci.gsfc.nasa.gov/wms/wms?version=1.3.0&amp;service=WMS&amp;request=GetMap&amp;CRS=CRS:84&amp;BBOX=-180,-90,180,90&amp;WIDTH=720&amp;HEIGHT=360&amp;LAYERS=MOD14A1_M_FIRE&amp;FORMAT=image/jpeg&amp;STYLES="/>
    			<owc:styleSet default="true">
    				<owc:name>rgb</owc:name>
                    ...
                </owc:styleSet>
    		</owc:offering>
    	</entry>
    </feed>

This subsection can be considered a CR to OWS Common

6.2.4. Recommended extensions for OWS Context

As a consequence of the previous mapping, some extensions to OWS Context could be useful to make a better mapping.

Current ATOM encoding describes the temporal extend as:

"This element is optional and expresses a date or range of dates relevant to the Context resource inside a dc:date element. The content of this element SHALL conform to the "date-time" production of ISO-8601. An uppercase "T" character SHALL be used to separate date and time, and an uppercase "Z" character SHALL be present in the absence of a numeric time zone offset. To specify a range of dates the "/" character SHALL be used."

OWS time interval fragment

   <feed xmlns="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:gml="http://www.opengis.net/gml" xml:lang="en">
       ...
       <entry>
           ...
         <dc:date>2009-01-23T09:08:56.000Z/2009-01-23T09:14:08.000Z</dc:date>
          ...
       </entry>
      ...
   </feed>

For better representation of time intervals it could be good to allow for a 3rd member of the time interval specifying the time resolutions:

OWS time interval fragment using time resolution extension

   <entry>
       ...
     <dc:date>2000-03-01T00:00:00Z/2016-04-01T00:00:00Z/P1M</dc:date>
      ...
   </entry>

In fact, we could be able to convey even more complicated time intervals as WMS is doing:

OWS time interval fragment using time resolution extension

   <entry>
       ...
     <dc:date>2000-03-14/2000-12-27/P8D,2001-01-01/2001-06-10/P8D,2001-06-26/2001-12-27/P8D,2002-01-01/2002-12-27/P8D</dc:date>
      ...
   </entry>

In addition to this, we would like to recommend that bounding boxes can be also provided in any CRS in OWS Context.

This subsection can be considered a CR to OWS Context

7. A context document as a GetCapabilities response

In this section we examine the possibility that a service receiving a GetCapabilities request responds a OWS Context that completely replaces (or becomes an alternative to) the classic XML format for the whole service metadata document. In this scenario, the document response could be in either XML Atom, GeoJSON encoding or even in the HTML5 format suggested in the OGC 16-053 Testbed 12 OWS Context JSON JSON-LD and HTML5 ER. This section describes how this request needs to be done and how the result will look like using the OWS Context Atom encoding as an example.

7.1. GetCapabilities request of a OWS Context Atom encoding

To request a ServiceMetadata document in the OWS Context Atom encoding format, the FORMAT parameter with the value application/atom+xml should be include in the request:
http://www.bob.com/wms?service=WMS
&request=GetCapabilities&format=application/xml+atom

7.2. GetCapabilities response in OWS Context Atom encoding.

All data services could potentially respond OWS Context Atom encoding to describe de service and its resources if requested. As it will be discussed below, services types will require an extension of OWS Context to convey the specifics of the service but even in that case, they will share the common core defined in the OWS Context standard.

7.2.1. GetCapabilities response: The WMS Case

Even if WMS 1.3 is not following OWS Common structure, the conceptual structure is almost the same so we considered it as a valid example. In addition, the WMS.SWG is working on a WMS 1.4 that incorporates OWS Common 2.0. The correspondence of the layer section (equivalent to the contents section in OWS Common) has been already described and exemplified in the previous section.

In this section we continue using the NASA NEO WMS service as a WMS example available at:
http://neowms.sci.gsfc.nasa.gov/wms/wms?
version=1.3.0&service=WMS&request=GetCapabilities

7.2.2. Mapping between OWS common capabilities and OWS Context concepts

To assess the convenience to replace the Service Metadata document with the OWS Context document, or consider it as an alternative, we need to map the concepts of one model into the other. This subsection contains the mapping between OWS Common first sections and the OWS Context. In the mapping provided in the from of the table below, the four first columns comes from the OWS Context and the last five columns refers to OWS Common attributes as described in their respective standard documents. The Contents section was considered in the previous section and it is not repeated here.

Table 4. Mapping between OWS Context and the WMS 1.4 ServiceMetadata Content.
Name	Definition	Data type and Value	Multiplicity and Use	Section	Name	Definition	Data type and Value	Multiplicity and Use
specReference	Specification Reference identifying that this is an owc Context document	URI	One (mandatory)		N/A
language	Language used in the owc Context document	CharacterString	One (mandatory)	Languages	Languages	List of languages supported by the server.	Language data structure	Zero or One (optional)
id	Unique Identifier assigned to the OWS Context Document	CharacterString	One (mandatory)		N/A
title	Human Readable Title for the OWS Context Document	CharacterString	One (mandatory)	ServiceIdentification	title	Title of this server, normally used for display to a human	LanguageString data structure	One or more (mandatory)
abstract	Description of the Context Document Purpose/Content	CharacterString	Zero or one (optional)	ServiceIdentification	abstract	Brief narrative description of this server, normally available for display to a human	LanguageString data structure	Zero or (optional) Include when server chooses, recommended and usually included
updateDate	Date when the Context Document was updated	CharacterString	Zero or one (optional)	root	updateSequence^c	Service metadata document version, value is “increased” whenever any change is made in complete service metadata document	Character String type, not empty. Values are selected by each server, and are always opaque to clients	Zero or one (optional). Omitted when parameter not supported by server
author	Identifier for the author of the document	CharacterString	Zero or more (optional)		N/A
publisher	Identifier for the publisher of the document	CharacterString	Zero or one (optional)		N/A
creator	The tool/application used to create the context document and its properties	Creator	Zero or one (optional)	ServiceProvider	providerName/providerSite/serviceContact	Information for contacting service provider	See CI_ResponsibleParty and subsidiary classes in ISO 19115
rights	Rights which apply to the context document	CharacterString	Zero or one (optional)	ServiceIdentification	accessConstraints	Access constraints that should be observed to assure the protection of privacy or intellectual property, and any other restrictions on retrieving or using data from or otherwise using this server	Character string type, not empty Reserved value NONE (case insensitive) shall be used to mean no constraints are imposed	Zero or more (optional) Include when server chooses, recommended and usually included
areaOfInterest	Geographic area of interest of the users of the context document	GM_Envelope	Zero or one (optional)		N/A
timeIntervalOfInterest	A date/time interval relevant to the context document	TM_GeometricPrimitive	Zero or one (optional)		N/A
keyword category in Atom ^b	Keyword related to this context document. Shall support an optional codelist parameter.	CharacterString	Zero or more (optional)	ServiceIdentification	keywords	Unordered list of one or more commonly used or formalised word(s) or phrase(s) used to describe this server	See MD_Keywords class in ISO 19115	Zero or more (optional) One for each keyword authority used
resource	The description of a resource and its access parameters and configuration	owc:Resource	Zero or more (optional)	Contents	DatasetSummary
contextMetadata	Additional metadata describing the context document itself. The format recommendation is ISO19115 complaint metadata. The metadata standard used should be specified	Association	Zero or more (optional)
extension	Any encoding should allow the user to extend the context content to include custom items	n/a	Zero or more (optional)
				OperationsMetadata	<all>^a
				ServiceIdentification	serviceType	A service type URN from a registry of services, normally used for machine-to-machine communication	URN	One (mandatory)
				ServiceIdentification	serviceTypeVersion	Versions of this service type implemented by this server	Character string type, not empty	One or more (mandatory) One for each version implemented by server, unordered
				ServiceIdentification	profile	Identifier of OGC Web Service (OWS) Application Profile	Character string type, not empty. Value specified by each Application Profile	Zero or more (optional) Include for each specified Application Profile implemented by server
				ServiceIdentification	fees	Fees and terms for using this server, including the monetary units as specified in ISO 4217	Character string type, not empty Reserved value NONE (case insensitive) shall be used to mean no fees or terms	Zero or one (optional) Include when server chooses, recommended and usually included
^a Some attributes are provided for each layer in the OWS Common Offerings. ^b Keywords or categories can be used to include other properties in the OWS Common (or in the specifics of the service types) that cannot be mapped in other OWS Context entries. ^c The correspondence is partial and only relevant if the date is explored to know if there are updates.

One immediate result is that some properties that are documented in OWS Common sections are not present in OWS Context and viceversa. This means that completely replacing OWS Common with a OWS Context document will require some extensions in OWS Context.

Instead, it seems more convenient to propose OWS Context as an alternative response for OWS Common services that provides the minimum set of information that OWS Context allows. If the client needs more information, it always can request the "classical" format.

Another relevant aspect that emerges from this mapping is that OWS Common does not provide a way to define neither the spatial extent nor temporal extent as a service level (only as a contents level). It also lacks the capability to provide an identifier for the specific service.

7.2.3. Example of a service description of a WMS

In this section, we are demonstrating how an example of service metadata will look like in OWS Context format.

This is the first part of the capabilities document copied directly from the NEO Web Mapping Service. More information about thi service here: http://neo.sci.gsfc.nasa.gov/about/wms.php

This XML fragment has been extracted from the response to this request: http://neowms.sci.gsfc.nasa.gov/wms/wms?
version=1.3.0&service=WMS&request=GetCapabilities

Service metadata for the NEO Web Mapping Service. (fragment: layers part have been removed)

<?xml version="1.0" encoding="UTF-8"?>
<WMS_Capabilities version="1.3.0"
  xsi:schemaLocation="http://www.opengis.net/wms http://schemas.opengis.net/wms/1.3.0/capabilities_1_3_0.xsd"
  xmlns="http://www.opengis.net/wms"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink">
  <Service>
    <Name>WMS</Name>
    <Title>NASA Earth Observations (NEO) WMS</Title>
    <Abstract><![CDATA[Remote sensing imagery from NASA Earth Observations (NEO).]]></Abstract>
    <KeywordList>
      <Keyword>nasa</Keyword>
      <Keyword>earth science</Keyword>
      <Keyword>picture</Keyword>
    </KeywordList>
    <OnlineResource xlink:type="simple" xlink:href="http://neo.sci.gsfc.nasa.gov/"/>
    <ContactInformation>
      <ContactPersonPrimary>
        <ContactPerson>Kevin Ward</ContactPerson>
        <ContactOrganization>Science Systems and Applications, Inc./NASA</ContactOrganization>
      </ContactPersonPrimary>
      <ContactPosition>NEO Architect and Developer</ContactPosition>
      <ContactAddress>
        <AddressType>postal</AddressType>
        <Address>NASA GSFC, Code 613</Address>
        <City>Greenbelt</City>
        <StateOrProvince>Maryland</StateOrProvince>
        <PostCode>20771</PostCode>
        <Country>United States</Country>
      </ContactAddress>
      <ContactVoiceTelephone>+01-503-246-1608</ContactVoiceTelephone>
      <ContactElectronicMailAddress>kevin.a.ward@nasa.gov</ContactElectronicMailAddress>
    </ContactInformation>
    <Fees>none</Fees>
    <AccessConstraints>none</AccessConstraints>
    <LayerLimit>1</LayerLimit>
  </Service>
  <Capability>
    <Request>
      <GetCapabilities>
        <Format>text/xml</Format>
        <DCPType>
          <HTTP>
            <Get>
              <OnlineResource xlink:type="simple" xlink:href="http://neowms.sci.gsfc.nasa.gov/wms/wms"/>
            </Get>
          </HTTP>
        </DCPType>
      </GetCapabilities>
      <GetMap>
        <Format>image/png</Format>
        <Format>image/jpeg</Format>
        <DCPType>
          <HTTP>
            <Get>
              <OnlineResource xlink:type="simple" xlink:href="http://neowms.sci.gsfc.nasa.gov/wms/wms"/>
            </Get>
          </HTTP>
        </DCPType>
      </GetMap>
    </Request>
    <Exception>
      <Format>text/xml</Format>
    </Exception>
    <Layer>
    ...
    </Layer>
  </Capability>
</WMS_Capabilities>

The same service could return an OWS Context Atom version by including a format parameter: http://neowms.sci.gsfc.nasa.gov/wms/wms?
version=1.3.0&service=WMS&request=GetCapabilities& + format=application/atom+xml

(please, do not try this url, since the capability described is a suggestion of this ER and, naturally, is NOT currently implemented in the NASA service)

OWS Context document describing the services (fragment; "entry" section has been removed)

<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:georss="http://www.georss.org/georss" xmlns:gml="http://www.opengis.net/gml" xmlns:owc="http://www.opengis.net/owc/1.0">
    <link rel="profile"
		href="http://www.opengis.net/spec/owc-atom/1.0/req/core"
		title="This file is compliant with version 1.0 of OGC Context"/>
	<id>http://neowms.sci.gsfc.nasa.gov/wms/wms</id>
	<title>NASA Earth Observations (NEO) WMS</title>
	<subtitle type="html">
              Remote sensing imagery from NASA Earth Observations (NEO).
	</subtitle>
	<category term="nasa"/>
	<category term="earth science"/>
	<category term="picture"/>
	<author>
		<name>Kevin Ward</name>
		<name>kevin.a.ward@nasa.gov</name>
		<uri>http://neo.sci.gsfc.nasa.gov</uri>
	</author>
	<rights>none access contraints or fees</rights>
	<category term="1" scheme="http://www.opengis.net/spec/owc-atom/1.0/req/wms/LayerLimit"/>
	<category term="image/png" scheme="http://www.opengis.net/spec/owc-atom/1.0/req/wms/GetMapFormat"/>
	<category term="image/jpeg" scheme="http://www.opengis.net/spec/owc-atom/1.0/req/wms/GetMapFormat"/>
	<category term="text/xml" scheme="http://www.opengis.net/spec/owc-atom/1.0/req/wms/ExceptionFormat"/>
	<entry>
    ...
	</entry>
</feed>

7.3. Evaluation

As can be seen from the WMS example, it is clear that the service is capable to advertize most of its basic information and layer description (see previous sections) in a OWS Context document. With the suggested modification, services will be able to distribute their description in a format that is transversal in the web, increasing the possibility than servers are better discovered in the web. In addition, users can subscribe the server capabilities and be alerted of new additions or modifications in the service with their favorite RSS Feed tool.

Neverdeless, OWS Context cannot completely replace the current version of the service metadata without important extensions on the OWS Context. Thsi are some examples.

OWS Common is designed to convey detailed information about the service provider such as, full address, telephone, etc but OWS Context only provide a limited information. In favor of OWS Context we have the capability to diferenciate between author, publisher and creator.
OWS Context does not offer the possibility to describe the operation available at the service level. Even if this can be found at the resource level, the level of description of the operation at he resource level is not as detailed as the one that OWS Common can offer (for instance by specifying parameters and constraints for specific operations).

7.3.1. CR to OWS Common.

Even if OWS Context seem more limited that OWS Common Service Metadata document, OWS context include interesting ideas that are not present in the current Service Metadata section that we believe that normal OWS Common XML output should consider in future versions:

There is no way to include a globally unique identifier (UUID) for the service. This is important to detect duplications of services descriptions in different catalogues (in the same or on other formats). In addition, ISO19119 includes the need for a service identifier. We could consider that the url of the service can be the id, but this property might not be stored in the Service Metadata documents stored in catalogues or file systems. The proposal is to include an "identifier" of Code type as part of the ServiceIdentification. You could argue that the xml id property could be used for that function but we rather prefer that this is included in the UML model itself and be trasversal in future encodings.
There is no spatial extent for the service. Many services are not global and describe only region of the world with different resource. Clients are normally focused on an area of the world (e.g. in Testbed 12, services and clients for Arctic data where developed). To be able to know the geographic area covered by the service, currently the client needs to examine the Bounding Box of all resources to find out the common area of the resources. This is easy in WMS (where the bounding boxes of the layers are in the same ServiceMetadata), but it is more complex in other services, where getting this information will require to request details for each and every resource.
There is no temporal extent for the service. Typically the data provided by a service describe features of the Earth there were measured in a period of time (a concept called content period in the FGDC and temporal extent in ISO 19115). Services that contain static information should inform their temporal extent, for example, to allow clients to look for complementary services that reflect temporal evolution easily. Please not that this temporal extent has nothing to do with tha date in which the service or the resources were published. By the way, the date of publication and update of the service description is also not provided in the OWS Common and should also be interesting to have.

8. Associations as links to context documents.

In this section we describe two possible ways of providing associations from a service or a resource to other resources and other services by introducing in the service metadata links to OWS context documents.

8.1. Links to OWS context for each individual content (each resource)

Each content element (a resource) in the ServiceMetadata document can include one or more links to OWS context documents that provide an additional lists of possible resources in this of in other services that clients can combine with the actual used content e.g. to create a more complete common operation picture. The same mechanism can also be used to provide a list of resources that reside in different services that, in fact are alternative representations of the same dataset. This approach is an another implementation of the concept of service and resource associations that has been also analyzed from other angles in the OGC 16-043 Testbed 12 Web Integration Service Engineering Report.

8.1.1. CR to OWS Common to allow linking resources to OWS Context documents.

As said in a previous sections, the resources available in a OWS Common document are described in an abstract class called DatasetSummary described in the UML model in the figure 7 and the Table 21 of OGC 06-121r9.

To be able to link a resource to a context document, we need a new element in DatasetSummary that allows to express associations to OWS Context.

Table 5. Proposed extension attribute of the description of DatasetSummary in OWS Context.
Name	Definition	Data type and Value	Multiplicity and Use
associatedContext	Link to a context document that is associated to the offered resource	Reference type (see next table)	zero or more, optional

Table 6. Proposed extension of the description of ReferenceType in OWS Context.
Name	Definition	Data type and Value	Multiplicity and Use
URL	Link to the context document that is associated to the offered dataset	URL	one, mandatory
rel	The link relation type	Possible values described in the atom standard RFC4287 section 4.2.7.2 ^a	zero or one, optional
^a This registry is maintained by IANA and initially contains five values: "alternate", "related", "self", "enclosure", and "via". New assignments are subject to IESG Approval, as outlined in [RFC2434].

Other values of "rel" could be needed such us "commonOperationPicture" or "alternativeServicesOrFormats" that should be registered in the OGC Namespace by the OGC Naming Authority if this extension in included.

This is how the AssociatedContext looks like in an example.

Layer with AssociatedContext example

<Layer>
  <Name>MOD14A1_M_FIRE</Name>
  ...
  <AssociatedContext>
    <atom:link href="http://www.bob.com/mid14a1_m_fire.owc" rel="alternativeServicesOrFormats"/>
  </AssociatedContext>
</Layer>

8.2. Links to OWS context for the whole service

Link OWS context documents, in the service description of a service, can be used to publicize recommended resource lists (combining both local and remote resources) that together can present different common operational pictures that are different views of the content of this service in combination with other services. It could also be used to link to alternative services or services combinations that can be used in case the current service is down or it is planned to be deactivated or moved in the near future.

8.2.1. CR to OWS Common to allow linking services to OWS Context documents.

Generic properties of the services are described in the OWS Common document that are described by the abstract class called OWSCommonServiceMetadata described in the UML model in the figure 3 and the Table 9 of the OGC 06-121r9.

To be able to link a service to a context document, we need a new element in OWSCommonServiceMetadata that allows to express associations to OWS Context.

Table 7. Proposed extension of the description of OWSCommonServiceMetadata in OWS Context.
Name	Definition	Data type and Value	Multiplicity and Use
associatedContexts	A list of associated to the service	AssociatedContext type (see following table)	zero or more, optional

Table 8. Proposed extension attribute of the description of DatasetSummary in OWS Context.
Name	Definition	Data type and Value	Multiplicity and Use
associatedContext	Link to a context document that is associated to the offered resource	Reference type (see previous table)	one or more, mandatory

This is how the associatedContexts looks like in an example. .Layer with AssociatedContext example

<GetCapabilities ...>
    ...
    <associatedContexts>
      <associatedContext>
        <atom:link href="http://www.bob.com/new_service.owc" rel="futureAlternative"/>
      </associatedContext>
    </associatedContexts>
    ...
</GetCapabilities>

===Proposed rel extensions

The following table contains the values of "rel" that should be registered in the OGC Namespace by the OGC Naming Authority if this extension in included in OWS Common.

Table 9. Proposed extension of the description list of "rel" values.
Name	Definition	Applicable for
commonOperationPicture	context with resources to create a more complete common operation picture	resource or service
alternativeServicesOrFormats	context with resources that provides alternative representations of the same dataset in other formats. E.g. a WMS can provide a context with the same resource in different representations such as a WMTS service layer or a WFS providing the GML encoding of the same features represented in the WMS layer	Resource
backUpAlternative	context with resources that provide a backup or secondary alternative if the service is off-line	Service
futureAlternative	context with resources that provide a future alternative when this service is switched-off	Service

9. OpenSearch in combination with ServiceMetadata

If the number of resources listed in the service metadata document is very large or the service is highly dynamic, the Contents section can be too long or useless. In this circumstances, neither the service nor the client can handle it efficiently. From now on we call this the large service metadata problem. The OWS common standard suggests to use an OtherSources link to overcome this problem: "The OtherSource parameters may reference one or more catalogue servers from which dataset metadata is available. This ability is expected to be used by servers with thousands or millions of datasets, for which searching a catalogue is more feasible than retrieving and then searching a very large Capabilities XML document. When no DatasetSummaries are included, and one or more catalogue servers are referenced, this set of catalogues shall contain current metadata summaries for all the datasets currently available from this OWS server, with the metadata for each such dataset referencing this OWS server."

OWS Common assumes that in this large situations, the GetCapabilities operation will not be able to function correctly and clients will have to follow the "link" to OtherSources to access a true catalogue.

Indeed, CSW catalogues are not easy to implement and there are not so many implementations of them. Essentially it implies to develop the CSW operations but also deal with the metadata format used in the catalogue that differs from the one used in data services (WMS, WFS, WCS etc).

Fortunately, there is another approach, not directly discussed by the OWS Common standard, that can result in data services that can autonomously deal with large ServiceMetadata documents: The use of OpenSearchGeo.

9.1. Current filter mechanims in OWS Common.

Currently, there is already a mechamism to filter the information in the ServiceMetadata: OWS Common proposes the use of the sections parameter in the GetCapabilities request (section 7.3.2 in OGC 06-121r9). Unfortunatelly this parameter only allows to request the contents section as a whole and does not help with the large service metadata.

9.2. OpenSearchGeo filter

OpenSearch can be a way to request a subset of the resources that the service can provide access to, and that are part of the Contents section. The syntax of OpenSearchGeo is simple and general enough to be used in any data service. It can be added as extra parameters to the current GetCapabilities syntax with no interference with the current ones.

Mainly, OpenSearch provides the possibility to do thematic searches by adding the q parameter to filter by keywords. OGC 10-032r8 OpenSearchGeo adds a geospatial extent (the bbox parameter), and a temporal extent (the start and end parameters). The combination of these parameters with the current GetCapabilities operation could results in KVP requests like this:

http://www.bob.com/wms?service=WMS
& request=GetCapabilities&sections=contents&
q=temperature&geo:bbox=120,10,134,14&
time:start=2003-01-17&time:end=2004-01-17& + format=application/atom+xml

If the right request is formulated, this can help to make individual responses shorter and, at the same time, moves the GetCapabilities operation closer to the catalogue capabilities.

OpenSearch specify the return of an Atom feed document as one of the possible results. In a previous section we have described how to use a OWS Context document in the capabilities (that is already an Atom encoding). In this case, the response of the previous request will be a OWS Context document with all the resources that are related to temperature, fitting in the specified bounding box and included in the specified temporal extent. Nevertheless, in our opinion, a service that responses the common ServiceMetadata xml encoding will be equally useful, and the OWS Context encoding should be only and option to make the OGC services fully compatible to OpenSearch (meaning that pure OpenSearch clients (like some web browsers) will be able to deal with OGC services capabilities with no modification.

9.2.1. CR to OWS Common to add a OpenSearchGeo filter method to GetCapabilities.

This CR to OWS Common proposes the addition of the following parameters to Table 3 (OGC 06-121r9) of the GetCapabilities operation:

Table 10. Additional parameters in GetCapabilities operation request based on OpenSearch.
Name	Definition	Data type and Value	Multiplicity and Use
q	keyword or keywords desired by the search	string	one (required)
count	Number of search results per page	non-negative integer	zero or one (optional)
startIndex	Index of the first search result	integer	zero or one (optional)
startPage	Page number of the set of search results	integer	zero or one (optional)
geo:bbox	Geographic bounding box	The box is defined by "west, south, east, north" coordinates of longitude, latitude, in a CRS:84 decimal degrees	zero or one (optional)
geo:relation	Spatial relation to result set	Character String; One of “intersects”, “contains”, “disjoint” One (optional) default is “intersects”	zero or one (optional)
time:start	A string describing the start of the temporal interval to search (bigger or equal to)	Character String; must match the RFC-3339	zero or one (optional)
time:end	A string describing the end of the temporal interval to search (smaller or equal to)	Character String; must match the RFC-3339	zero or one (optional)
time:relation	A temporal relation to the result set	Character String: One the “intersects”, “contains”, “during”, “disjoint”, “equals”	zero or one (optional). Default is “intersects”

9.3. OpenSearchGeo beyond GetCapabilites

This section explores the possibility to apply OpenSearch in the resource retrieval phase too, as an alternative to request resource identifiers. This is only applicable to data resources (e.g. WMS, WCS, WFS but cannot be applied to WPS).

For example, a WMS server could accept and OpenSearch syntax that replaces the "layers" and "styles" parameter to request a map of a specific region and time about temperature without knowing or caring about the layer ids for temperature. This is how the sintax will look like:

http://www.bob.com/wms?service=WMS
&request=GetMap&q=temperature& + bbox=120,10,134,14&time=2003-01-17&
width=256&height=256&format=image/jpeg

The result of this request will be a map overlaying all datasets that respond to the temperature keyword in the requested extend. This could not be appropriate in a server with many layers related to temperature, because only one layer may be seen in the map and no information about which one is delivered with the map format. In a WFS this problem is not present because features are delivered independently.

The main advantage of this syntax is that can be applied blindly to any service without any need to read the GetCapabilities previously.

9.3.1. CR to WMS to add a OpenSearchGeo filter method to GetMap and GetFeatureInfo.

This CR to OWS Common proposes the addition of the following parameters to the GetMap and GetFeatureInfo operation:

Table 11. Additional parameters in GetMap and GetFeatureInfo operation request based on OpenSearch.
Name	Definition	Data type and Value	Multiplicity and Use
q	keyword or keywords desired by the search	string	one (required)
startIndex	Index of the first layer search result	integer	zero or one (optional)^a
startPage	Page number of the set of layer search results	integer	zero or one (optional)^a
count	Number of layer search results per page	non-negative integer	zero or one (optional)^a
geo:bbox	Geographic bounding box	The box is defined by "west, south, east, north" coordinates of longitude, latitude, in a CRS:84 decimal degrees	zero or one (optional)
geo:relation	Spatial relation to result set	Character String; One of “intersects”, “contains”, “disjoint” One (optional) default is “intersects”	zero or one (optional)
time:start	A string describing the start of the temporal interval to search (bigger or equal to)	Character String; must match the RFC-3339	zero or one (optional)
time:end	A string describing the end of the temporal interval to search (smaller or equal to)	Character String; must match the RFC-3339	zero or one (optional)
time:relation	A temporal relation to the result set	Character String: One the “intersects”, “contains”, “during”, “disjoint”, “equals”	zero or one (optional). Default is “intersects”
^a Paging is useful in GetFeatureInfo to limit the number o results provided. In GetMap, paging is useful in GetMap to limit the number of layers contributing features to the map.

Please note that the LAYER and INFO_LAYER parameters should be defined optional (or conditional to the non use of OpenSearch parameters).

Appendix A: Revision History

Table 12. Revision History
Date	Release	Editor	Primary clauses modified	Descriptions
September 30, 2016	.8	Joan Maso	all	consolidated draft
November 11, 2016	.9	Joan Maso	all	OGC Staff corrections incorporated