== Introduction

=== Scope

This engineering report defines a new OGC service named the Web Integration 
Service.  A web integration service in a aggregation service whose purpose it
to provide, for the purpose of discovery, a list of reference to a suite of
other, perhaps related, OGC services.

This engineering report defines methods and apparatus to allow OGC web service
to externalize this internal association knowledge.  This engineering report
describes how associations between OGC and non-OGC resource can be represented
in XML.  This engineering report further defines a new operation; named
GetAssociations, that existing OGC web services can implement to allow client
applications to interrogate an OGC web service about its internal association
knowledge.

This engineering report defines an extension package for the CSW-ebRIM profile
(see OGC 07-110r4).  The profile encapsulates all the identifiers, associations
and classification schemes necessary to allow an OGC CSW-ebRIM catalogue to
register OGC web services and, by means of the GetAssociation operation,
register the resources those services offer and the associations between those
services, their offerings and other OGC and non-OGC resources.

=== Document contributor contact points

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

.Contacts
[width="80%",options="header"]
|====================
|Name |Organization
|Craig Coffin | Compusult
|Mark Lawrence | Compusult
|Panagiotis (Peter) A. Vretanos| CubeWerx Inc.
|====================

=== Change requests

* "Consider making the GetResourceById() operation mandatory for all OGC data services" 
** http://ogc.standardstracker.org/show_request.cgi?id=412

=== Future Work

* Define a JSON-LD output format for the GetAssociations operation
* Harmonize the identifiers defined herein with similar identifiers found in other OGC specifications
* Define an additional, optional, conformance class for WIS's that implement the GetResourceById() and/or GetAssocations() operations.  The WIS would need to cascade those requests down to the services that it is aggregating.
* Extended security for WIS content
** Extend the security implementation to determine the visibility of service endpoints in the WIS capabilities based on user authorization.  Propose solutions to reconcile authentication and authorization for the WIS, catalog and services.
* Approaches for filtering of WIS content
** It may be useful for a content provider to expose subsets of services through the WIS.  For example, an environmental data provider may wish to provide separate entry points for oceanographic and atmospheric data, along with an additional entry point to expose both data holdings.
** A direct solution might be to stand up a separate WIS instance for each data holding.  However, care must be taken to avoid collision between instances, while minimizing redundancy and resource usage.
** It may be preferable to extend the specification so that a single instance can support subsets of services.  A "passive" approach is for the WIS capabilities response to contain groupings or metadata attributes to categorize services. The client would be responsible for processing the response to identify the groupings.  A more active approach is to implement a parameter or operation allowing a client to specify a simple category filter in the service request.
* Software Tools
** For a service implementation that does more than simply returning a static capabilities response, software tools may aid in configuration of the service content.  It may be useful to implement an interface to manage the list of service endpoints and the metadata cache, including the ability to add/remove endpoints, restrict access to content, and configure cache settings.
** Tools to facilitate the creation of service associations may help speed the adoption of the Web Integration Service.  A software library could provide developers with an easy means of implementing the GetAssociations operation. A configuration tool for this library could be used for data providers to quickly configure association metadata for their services.

=== Foreward

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.