An analysis about standard conformance of some commercial GIS platforms

Chapter 1
OpenGIS Catalogue Service
Implementation Specification
1.1 Introduction
Metadata for geographic data typically describes the content, quality, type, collection
date, and spatial location of the actual data. Looking at metadata can help you
determine whether a particular dataset is appropriate for your use. In fact, it’s often
easier to judge the suitability of the data from its metadata than by examining the
actual data itself. This is because metadata is generally much smaller and easier to
share than the actual data [2].
This implementation specification defines the interfaces, bindings, and a frame-
work for defining application profiles required to publish and access digital catalogues
of metadata for geospatial data, services, and related resources; this is accomplished
through the use of catalogue services. With catalogue services, client applications
are capable of searching for georesources in a standardized way (i.e. through stan-
dardized interfaces and operations) and, ideally, they are based on a well-known in-
formation model, which includes spatial references and further descriptive (thematic)
1
2information that enables client applications to search for georesources in very efficient
ways [5].
An application profile specifies the use of an application-layer protocol in order to
provide for the structured transfer of information between systems. An application
profile is derived from one or more base specifications in order to address particular
needs or requirements. Clause 10 in the ISO 19119 standard distinguishes platform-
neutral from platform-specific specifications and assumes that one of the former will
constitute the basis for one or more of the latter. That is, a single platform-neutral
specification will give rise to multiple platform-specific specifications, each of which
is bound to a particular distributed computing protocol. The OGC catalogue frame-
work upholds this basic distinction: the general interface model is a platform-neutral
description of catalogue operations; each application profile is platform-specific, it
makes use of one of the protocol bindings defined in the catalogue specification. The
platform-neutral specification is one of the base specifications with which the appli-
cation profile complies. A given catalogue implementation in turn conforms to one
or more application profiles.
Figure 1.1: Relationship of general model, protocol binding, and application profile
3Figure 1.2: Relationships between base specs, profiles, and implementations
1.2 Catalogue Abstract Information Model
The abstract information model specifies a BNF grammar for a minimal query lan-
guage, a set of core queryable attributes (names, definitions, conceptual datatypes),
and a common record format that defines the minimal set of elements that should be
returned in the brief and summary element sets.
The query capabilities of the OGC General Catalogue Model provide a minimum
set of data types and query operations that can be assumed of OGC Compliant
Catalogue implementations. The query operation contains the parameters needed to
select the query result presentation style and to provide a query expression which
includes the actual query with an identification of the query language used. The
interoperability goal is supported by the specification of a minimal abstract query
(predicate) language, which must be supported by all compliant OpenGIS Catalogue
Services. An implementation of a query language transformable to the OGC Common
Catalogue Query Language is the OGC Filter Specification.
The Common Catalogue Query Language is based on the SQL WHERE clause
in the SQL SELECT statement and supports nested Boolean queries, text matching
operations, temporal data types, and geospatial operators; it can be extended by
4adding new predicates, operations, and datatypes. Application Profiles should be
explicit about the selected query languages and any features peculiar to a scope of
application.
1.3 Core Catalogue Schema
Metadata structures, relationships, and definitions (known as conceptual schemas)
exist for multiple information comunities. A metadata schema should be defined so
that provides a common vocabulary which supports search, retrieval, display, and
association between the description and the object being described. Although this
specification does not require the use of a specific schema, the adoption of a given
schema within an information-sharing community ensures the ability to communicate
and discover information.
Defining core queryable properties it is possible to enable simple cross-profile dis-
covery, where the same queries can be executed against any catalogue service without
modification and without detailed knowledge of the catalogue’s information model.
This requires a set of general metadata properties that can be used to characterise
any resource. A set of core properties returned from a metadata search is encour-
aged to permit the minimal implementation of a catalogue service independent of a
companion application profile and to permit the use of metadata returned from dif-
ferent systems and protocol bindings. Protocol Bindings interpret the general model
in the referenced implementation environment; each one includes a mapping from the
general interfaces, operations, and parameters to the constructs available in a chosen
protocol.
51.4 General Catalogue Interface Model
The General Catalogue Interface Model provides a set of abstract service interfaces
that support the discovery, access, maintenance and organization of catalogues of
geospatial information and related resources. The interfaces specified are intended
to allow users or application software to find information that exists in multiple
distributed computing environments, including the World Wide Web (WWW) en-
vironment. Each protocol binding includes a mapping from the general interfaces,
operations, and parameters specified in this clause to the constructs available in a
chosen protocol. An Application Profile is predicated on the existence of one protocol
binding in the base specification. In the case of the Catalogue Services Specification,
a profile could reference CORBA, Z39.50, or HTTP protocol bindings.
The Application Client shown in Figure 1.3 interfaces with the Catalogue Service
using the OGC Catalogue Interface. The Catalogue Service may draw on one of
three sources to respond to the Catalogue Service request: a Metadata Repository
local to the Catalogue Service, a Resource service, or another Catalogue Service. The
interface to the local Metadata Repository is internal to the Catalogue Service. The
interface to the Resource service can be a private or OGC Interface. The interface
between Catalogue Services is the OGC Catalogue Interface. In this case, a Catalogue
Service is acting as both a client and server. Data returned from an OGC Catalogue
Service query is processed by the requesting Catalogue Service to return the data
appropriate to the original Catalogue request.
Figure 1.4 is a general UML model of OGC catalogue service interfaces, in the
form of a class diagram. This model shows the Catalogue Service class plus five other
6Figure 1.3: Reference model architecture
classes with which that class are associated.
OGC Service class provides the getCapabilities operation that retrieves catalogue
service metadata. This class is always realised by the Catalogue Service class. Dis-
covery class provides four operations for client discovery of resources registered in a
catalogue. This class is always implemented by a Catalogue Service implementation.
Session class provides four operations for interactive sessions between a server and a
client. Manager class provides two operations for inserting, updating, and deleting
the metadata by which resources are registered in a catalogue. Brokered Access class
provides the order operation for ordering an identified resource that is registered in
a catalogue but is not directly accessible to the client. This five classes that can be
associated with the Catalogue Service class allow different OGC catalogue services to
provide significantly different abilities. A particular protocol binding is used by each
Application Profile and a particular set of these catalogue service classes is specified
by each Application Profile. Furthermore, specific protocol bindings or application
profiles can define additional parameters.
7Figure 1.4: General OGC catalogue UML static model
The Catalogue Interface defines a stateful session; this specification defines the
states of the session and the allowed transitions between the states. All other state
transitions are disallowed and are consider errors if exhibited by a server. In the state
model below, a transition is typically triggered by a request. Generally, a transaction
in this model is bounded by a request-response pair. Note that a transaction can
be statused or cancelled while it is active (before a response is issued). The server
shall not change state in response to a StatusRequest (or CancelRequest) when the
transaction is complete.
8The top-level state diagram for the Catalogue Interface is shown in Figure 1.5.
After a successful initialization, the session will be in the Main state. The Main
state is a concurrent, composite state, consisting of four substates: Discovery, Access,
Management, and Explain. While in the Main state, Requests (other than Termi-
nateRequest) may cause transitions internal to the substates. If a server does not
support interfaces associated with a substate, the substate is not present for sessions
with that server. When a TerminateRequest is received, the session will transition
from the Main state to the end state, ending all processing associated with the sub-
states of Main.
Figure 1.5: Catalogue session state diagram
91.5 Z39.50 Protocol Binding
The Z39.50 Protocol binding uses a message-based client server architecture im-
plemented using the ANSI/NISO Z39.50 Application Service Definition and Pro-
tocol Specification [ISO 23950]. This protocol binding maps each of the general
model operations to a corresponding service specified in the ANSI/NISO/ISO stan-
dard [http://lcweb.loc.gov/z3950/agency/document.html]. For compliance, clients
and servers must support Z39.50 Version 3.
At a minimum, Catalogue Services implemented using the Z39.50 protocol binding
must support the Discovery and Session operation groupings.
The Z39.50 Protocol binding offers the choice of the following transport mecha-
nisms:
1. Directly over TCP where services are encoded using the Basic Encoding Rules
(BER) [ISO 8825].
2. Z39.50 Next Generation Search/Retrieve Web Service (SRW) or its URL Ac-
cess Mechanism (SRU) Version 1.0 [http://lcweb.loc.gov/z3950/agency/zing/
srw/index.html].
BER over TCP/IP is the historical implementation of Z39.50 transport, whereas
SRW/SRU provides a transition strategy from legacy Z39.50/BER to a Web Services
interface. Z39.50 using Basic Encoding Rules over TCP is implemented using regis-
tered profiles listed by the maintenance agency
[http://lcweb.loc.gov/z3950/agency/profiles/profiles.html]. These profiles indicate
10
required operations, sets of registered Use Attributes (search fields), Relations (oper-
ators), Z39.50 datatypes, Element Sets (named sets of returned fields/elements), Pre-
ferred Syntaxes (encoding format), and information sets (metadata standards and/or
schemas returned). SRW implements a simplified, stateless approach to catalogue
services that preserves core functions of the Information retrieval protocol but offers
them over HTTP. SRW provides Simple Object Access Protocol (SOAP) access to
post and receive messages as formatted XML; SRU is a URL-based access method
that employs keywordvalue pairs (KVP) using GET interfaces.
The Z39.50 Services used in this protocol binding include the Init, Search, Present,
Resource Control, Trigger Resource Control, Sort, Extended Services and Close.
1.6 CORBA/IIOP Protocol Binding
The core of the CORBA protocol binding consists of only one interface: CatalogSer-
vices. The separate services of the General Model (Discovery, BrokeredAccess, Man-
ager and Session) are defined in separate interfaces to reflect the General Model. They
are all inherited by the central interface CatalogServices. At a minimum, Catalogue
Services implemented using the CORBA protocol binding must support the Discov-
ery and Session interfaces. The operations of CatalogServices, without exception,
take a request message as an input parameter and return a response parameter. All
messages are filled with standard or compound CORBA structures.
The CORBA protocol binding supports the following query languages:
1. CQL (Common Query Language) (mandatory).
2. OGC Filter Encoding (optional).