OpenGIS Project Document 02-037

TITLE: Use of ISO 19115 Metadata to Reference Services

AUTHOR: Name: Doug Nebert

Address: 12201 Sunrise Valley Drive

MS 590

Reston, VA 20192 USA

Phone: +001 703 648 4151

FAX: +001 703 648 5755

Email: ddnebert@fgdc.gov

DATE: 23 May 2002

CATEGORY: Proposal

# Background

There exists a need to be able to document data and image resources
fully to provide for both its information content and the services
available to access the object (data) being described. ISO 19115
includes such a capability, even within the Core representation of
metadata, to reference and even qualify the online resource linkage
through the Distribution Information section of the standard. This brief
describes a proposed methodology for the systematic reference of
service/operations linkages with specific examples in support of
existing OpenGIS Consortium Web Map Service interfaces.

In metadata standards used since the early 1990's such as the FGDC
Content Standards for Digital Geospatial Metadata and the Australia-New
Zealand metadata standard promoted by ANZLIC, there was support for a
URL to the data resource. This resource URL was typically populated with
the value of an ftp or http download location or the HTML page of an
order or information page, intended to be specific to the data set or
data file being described. More than one URL could be supported but
there was little to differentiate the style or behavior of the
referenced URLs except their protocol defined by the IANA prefix (e.g.
http:// or ftp:// ). ISO 19115 remedied this problem of differentiating
the online linkage information by creating a group called
"CI_OnlineResource" that contains the linkage URL, protocol, a reference
to an application profile, the name of the resource, and a description
of the resource. Each of these "fields" may occur once, but the Online
Resource group may repeat. See Table 1, paraphrased from Table B.3.2.4
Online Resource Information, ISO 19115.CD2 (2001).

+---+------------+------+----------------+-------+-------+--------------+
| 1 | CI_OnLi    | O    | information    | Oblig | Max   | Data Types   |
| . | neResource | nlin | about on-line  | ation | occur |              |
|   |            | eRes | sources from   |       |       |              |
|   |            |      | which the      |       |       |              |
|   |            |      | dataset,       |       |       |              |
|   |            |      | specification, |       |       |              |
|   |            |      | or community   |       |       |              |
|   |            |      | profile name   |       |       |              |
|   |            |      | and extended   |       |       |              |
|   |            |      | metadata       |       |       |              |
|   |            |      | elements can   |       |       |              |
|   |            |      | be obtained    |       |       |              |
+---+------------+------+----------------+-------+-------+--------------+
| 2 | linkage    | lin  | location       | M     | 1     | URL          |
| . |            | kage | (address) for  |       |       |              |
|   |            |      | on-line access |       |       | (IETF        |
|   |            |      | using a        |       |       | RFC1738      |
|   |            |      | Uniform        |       |       |              |
|   |            |      | Resource       |       |       | IETF RFC     |
|   |            |      | Locator        |       |       | 2056)        |
|   |            |      | address or     |       |       |              |
|   |            |      | similar        |       |       |              |
|   |            |      | addressing     |       |       |              |
|   |            |      | scheme such as |       |       |              |
|   |            |      | htt            |       |       |              |
|   |            |      | p://www.statka |       |       |              |
|   |            |      | rt.no/isotc211 |       |       |              |
+---+------------+------+----------------+-------+-------+--------------+
| 3 | protocol   | prot | connection     | O     | 1     | Free text    |
| . |            | ocol | protocol to be |       |       |              |
|   |            |      | used           |       |       |              |
|   |            |      |                |       |       |              |
+---+------------+------+----------------+-------+-------+--------------+
| 4 | applicat   | ap   | name of an     | O     | 1     | Free text    |
| . | ionProfile | pPro | application    |       |       |              |
|   |            | file | profile that   |       |       |              |
|   |            |      | can be used    |       |       |              |
|   |            |      | with the       |       |       |              |
|   |            |      | online         |       |       |              |
|   |            |      | resource       |       |       |              |
+---+------------+------+----------------+-------+-------+--------------+
| 5 | name       | or   | name of the    | O     | 1     | Free text    |
| . |            | Name | online         |       |       |              |
|   |            |      | resource       |       |       |              |
|   |            |      |                |       |       |              |
+---+------------+------+----------------+-------+-------+--------------+
| 6 | d          | or   | detailed text  | O     | 1     | Free text    |
| . | escription | Desc | description of |       |       |              |
|   |            |      | what the       |       |       |              |
|   |            |      | online         |       |       |              |
|   |            |      | resource       |       |       |              |
|   |            |      | is/does        |       |       |              |
+---+------------+------+----------------+-------+-------+--------------+
| 7 | function   | orF  | code for       | O     | 1     | CI_OnLine    |
| . |            | unct | function       |       |       | FunctionCode |
|   |            |      | performed by   |       |       |              |
|   |            |      | the online     |       |       | \<\<         |
|   |            |      | resource       |       |       | CodeList\>\> |
|   |            |      |                |       |       | (B.5.3)      |
+---+------------+------+----------------+-------+-------+--------------+

Table 1. Distribution Online Resource Information

Element 1 in this table is the grouping element, whereas element 2 is
the URL for the online resource access point. Element 3 is the service
protocol to be used, defined as free-text but not restricted to a
specific set (enumeration) of valid values. Element 4 is a reference to
the application profile (a reference schema for the data to be moved,
typically expressed in DTD or XSD format for an XML encoded data object
(this should probably be a URL or URI to the application profile schema
representation online, but is not expressed as such in the standard).
Element 5 is a popular name of the online resource whereas element 6
provides for a more detailed description of what is at the end of the
resource link. Element 7 is to be populated from a code list
(enumeration) of well-known categories of information access, shown in
Table 2 taken from B.5.3 of ISO 19115.CD2 (2001). Note that this list of
codes does not include a suitable category for web mapping or feature
access services as distinct from other types of "download." One could
argue that web mapping is not well matched to any of these codes for
*function* and revisions to the ISO standard should consider generic
functions and codes to parallel broad categories of OGC interfaces.

+---+-------------+-----------+-----------------------------------------+
|   | **Name**    | **Domain  | **Definition**                          |
|   |             | code**    |                                         |
+===+=============+===========+=========================================+
| 1 | CI_OnLineF  | OnFunctCd | function performed by the resource      |
| . | unctionCode |           |                                         |
|   |             |           |                                         |
|   |             |           |                                         |
+---+-------------+-----------+-----------------------------------------+
| 2 | download    | 001       | online instructions for transferring    |
| . |             |           | data from one storage device or system  |
|   |             |           | to another                              |
|   |             |           |                                         |
+---+-------------+-----------+-----------------------------------------+
| 3 | information | 002       | online information about the resource   |
| . |             |           |                                         |
|   |             |           |                                         |
|   |             |           |                                         |
+---+-------------+-----------+-----------------------------------------+
| 4 | of          | 003       | online instructions for requesting the  |
| . | flineAccess |           | resource from the provider              |
|   |             |           |                                         |
|   |             |           |                                         |
+---+-------------+-----------+-----------------------------------------+
| 5 | order       | 004       | online order process for obtaining the  |
| . |             |           | resource                                |
|   |             |           |                                         |
|   |             |           |                                         |
+---+-------------+-----------+-----------------------------------------+
| 6 | search      | 005       | online search interface for seeking out |
| . |             |           | information about the resource          |
|   |             |           |                                         |
|   |             |           |                                         |
+---+-------------+-----------+-----------------------------------------+

Table 2. ISO 19115 Online Function Codes (Types)

# References

ISO 19115 (Metadata), ISO Technical Committee 211, Committee Draft 2,
2001

# Proposal

Existing metadata software packages typically will permit the editing
and population of information that is equivalent to an XML element, and
neither the ISO 19115 draft standard nor metadata editing tools support
XML attributes, per se. Although it might be possible to include such a
service type classification as a modifier or XML attribute to the
linkage element, this approach would not be supported by existing
metadata standards or editors.

The preferred solution would be to use the existing elements within the
Online Source compound element to hold a familiar string pattern that
could be used within the implementer community. Since the ISO metadata
standard supports multiple Online Source element groups, it is possible
to host multiple links from the perspective of the data set as to its
"data access methods" -- different facets of accessibility. The
candidate elements might include the protocol, the name, and the
description. The most closely aligned construct would appear to be the
protocol element, for which there is no clear guidance or limitations
and for which no specific code list or enumerated domain exists.
Although this information is intended to be unstructured, for practical
usage, an structured approach is proposed here that will not violate the
existing XML model (DTD) since it is text and yet extend the ability for
programmers to interpret what may methods may reside at the end of the
referenced URL.

In support of flexibility and extensibility, it is hereby suggested that
the values of the protocol element include either:

1)  a well-known protocol via the IANA prefix (e.g. ftp, http) where
    such a method is appropriate and the behavior is not specialized or,

2)  a structured value within a namespace following the XML namespace
    notation of "authority:value" with full expression of the access
    operation being used within a community of practice.

Whereas option 1 would support general data download via file transfer
over ftp or http ore similar protocols yielding a file of unknown
structure or MIME type, the use of option 2 is recommended to
disambiguate the syntax and semantics of the URL with respect to an
implementer community. The IANA prefix used in a URL may not be
sufficient to denote the computing environment, for example SOAP and
HTTP Post both exploit an http prefix handler.

In the case of the OpenGIS Consortium, a number of services with
specific interfaces (operations) are known and operate within the
implementer community. Further, multiple versions of these services may
exist at a given point in time and may offer different behaviors that
would need to be known to applications that access them through the ISO
19115 metadata entry. To accommodate these variations, the following
syntax is recommended in support of the OGC Web Mapping Service
specification, as an example:

Protocol should be constructed as a case-insensitive multi-part value
separated by dashes, square brackets denoting token boundary:

**\[namespace\]:\[service_name\]-\[version_number\]-\[interface\]-\[option\]-\[interface_name\]**

For example, the following case would infer the existence of a link that
would return the behavior (registered with the OGC) of a capabilities
request over http per the WMS 1.1.1 specification. Advanced clients
would be able to exploit this to retrieve the full capabilities.xml file
and construct a client interface:

**\<protocol\>ogc:WMS-1.1.1-http-get-capabilities\</protocol\>**

where:

> Ogc = Namespace
>
> WMS = Service Name

1.1.1 = Version number of the highest level of compatibility supported

> http = interface protocol (e.g. http, soap, corba)
>
> get = option on the protocol interaction (optional: use - - if
> missing)
>
> getCapabilities = interface/operation's well-known name

All permutations of services and interface handles could be specified
using this syntax by creating an Online Source compound element for each
instance.

For a given OGC Service and its operations, a set of minimum recommended
bindings expressed as \<protocol\> values need to be defined for
application usage. Data that are described in ISO 19115 metadata that
support online maps via the Web Map Service specification should include
the following \<protocol\> values, expressed using the full syntax above
to denote GET or POST behavior for requests of "capabilities" and "map,"
at a minimum:

For experimentation, the support of a request for WSDL or other
interface handles could be made official within the OGC community of
practice. So, in principle, an interface name of WSDL for the return of
a full service instance binding templates (as an alternative to
Capabilities) could be supported and explored. *All expression and
interpretation of characters should not be case-sensitive.*

A sample XML structure in the context of an Online Source structure:

\<onLineSrc\>

\<linkage\>http://www.xyz.org/cgi-bin/geoserver.cgi\</linkage\>

\<protocol\>**ogc:WMS-1.1.1-http-get-capabilities**\</protocol\>

\<orName\>farming_1105_IMS\</orName\>

\<orDesc\>OpenGIS compliant image Web Map Service for farms\</orDesc\>

\</onLineSrc\>

Note: In XML, the use of a bare ampersand is not allowed and will cause
XML parsers to fail. All encoding of extended request URLs with multiple
parameters will need to replace bare ampersands with &amp;

**Recommendation for Encoding in FGDC Metadata**

In FGDC metadata, there is only a single XML element \<onlink\> to store
this information, as it is not a member of a repeating group of
information. For interim usage in FGDC metadata, the following
space-delimited set shall be included within the Online Linkage
\<onlink\> element as its value, including the protocol, the URL, and a
friendly name for the data layer in this map service:

\<onlink\>ogc:WMS-1.0.7-http-get-map
[http://mapservice_url](http://mapservice_url/) \[Friendly layer
name\]\</onlink\>

where the protocol is expressed as an unbroken string (no spaces), the
URL is likewise properly formed, and the final token may be multiple
words but must be enclosed within a set of square brackets. For
programmers, the reference to the OGC namespace (ogc:) with "well-known"
operations names, the existence of a URL, and of a delimited string
would permit quick evaluation of these different elements, even if they
were entered in a different order than suggested. This information would
be sufficient, providing adequate map service parameters present to
invoke the service, for client software to be launched to view the map
data.

### Known Services and Operations

In the absence of a semantic registry for OGC Services and Operations,
the following table of approved interface specifications provides a set
of known values to be used in the composition of the protocol string.

+---------------+------+--------+--------+--------+------------------+
| Service Name  | Code | Ve     | Pr     | M      | Operations       |
|               |      | rsions | otocol | ethods |                  |
+---------------+------+--------+--------+--------+------------------+
| Web Map       | WMS  | 1.0.0  | http   | GET,   | Capabilities,    |
| Service       |      | -1.1.1 |        | POST   | map, FeatureInfo |
+---------------+------+--------+--------+--------+------------------+
| Catalog       | CS   | 1.0    | Z      | \--    | Init,            |
| Service       |      |        | 39.50, |        | SearchRequest,   |
|               |      |        | CORBA  |        | PresentRequest,  |
|               |      |        |        |        |                  |
|               |      |        |        |        | Close            |
+---------------+------+--------+--------+--------+------------------+

### Discussion

Increasingly, the OGC developer community will require a well-known set
of terms or tags with specific semantics that are held in common by the
community. Such a semantic repository of tokens, definitions, context,
domain values, and authority would be of great help in implementation as
a community dictionary. This capability supplements other community
assets such as service type catalogs, service instance catalogs, and
data catalogs, all known by various similar names with a similar intent.
With OGC Staff assistance, such a simple semantic repository should be
started for the interoperability program separate from specific
information community needs. Until that time, implementer agreement
recommendations such as this will need to be used.