ICSM ISO 19115-1 Metadata Best Practice Guide

Service Identification

When capturing information on a spatial service, it is important to identify and categorise information as pertaining to the service resource and to distinguish this information from that which applies to the metadata itself or data resources. SV_ServiceIdentification extends the abstract class MD_Identification to document a spatial service resource.

   
Element Name SV_ServiceIdentification
Parent MD_Metadata.identificationInfo
Class/Type MD_Identification
Governance ISO
Purpose Discovery, Evaluation, Use
Audience machine resource - ⭑ ⭑ ⭑
  general - ⭑ ⭑ ⭑
  resource manager - ⭑ ⭑ ⭑
  specialist - ⭑ ⭑ ⭑
Metadata type descriptive
ICSM Level of Agreement ⭑⭑

Definition -

Identification of capabilities which a service provider makes available to a service user through a set of interfaces that define a behaviour.

ISO Requirements

At least one [1..*] MD_Identification must be present in a metadata record. This must be instantiated as an SV_ServiceIdentification for metadata about service resources.

ISO Associations

MD_Identification is an abstract class that is parent to

Is a child of:

Discussion

The class, SV_ServiceIdentification, contains all metadata related to the identification of a service resource. The provision of this information strongly impacts on the ability of a user to assess the resource fitness to use. Like MD_DataIdentification, SV_ServiceIdentification instantiates the abstract class MD_Identification for use with service resources. As such it inherits all the properties of that class.

The relation of a geospatial service to the data on which it operates is varied. This relation impacts the decisions one may make regarding the capture of useful metadata for such a service. These services fall into three categories depending on how tightly coupled the data is to the service.

An example of a tightly coupled service would be a WFS service delivering a particular dataset. In the tightly coupled case, the service metadata shall describe both the service and the geographic dataset. The permitted values for the description of operations shall be constrained by the values defined by the datasets associated with the service.

An example of a loosely coupled service could be a reprojection service with user-selected input datasets. Loosely coupled services may have an association with data types through the service type definition (SV_ServiceIdentification.serviceType). Dataset metadata need not be provided in the service metadata for the loosely coupled case.

A mixed coupling might be a WMS service into which add additional data sources of your choice. In a mixed coupling situation, a single service instance may be associated with both kinds of data associated, loosely and tightly coupled.

Best Practice Recommendations

Therefore - to clearly understand what resource a metadata record is describing, there should be one and only one [1..1] MD_Identification package in a metadata record. For service metadata, this must be expressed as an SV_ServiceIdentification instance. The Service Indentifaction package contains several sub-packages and sub-elements. To ease the common use of such metadata, it is important that the use of these sub-packages and sub-elements be standardised.

In addition the recommended attributes of MD_Identification detailed below, the following SV_ServiceIdentification subpackages and sub-elements are recommended.

Note -Service Types and Standards descriptors - There are multiple methods of describing the type of service being provided. Of these ServiceType is mandatory. Also, there should be at least one entry in Keywords of type Service that also describes the service. The following others are recommended when appropriate.

The following provides additional guidance to MD_Identification inherited element recommendations.

Additional optional attributes

\pagebreak

UML diagrams

Recommended elements highlighted in yellow

SV_ServiceIdentification

\pagebreak