Archie Warnock, A/WWW Enterprises OCG Catalog Specification v2.0 Overview and Discussion Archie Warnock, Doug Nebert Yonsook Enloe, Jolyon Martin May 14,

Archie Warnock, A/WWW Enterprises

OCG Catalog Specification v2.0Overview and Discussion

Archie Warnock, Doug Nebert

Yonsook Enloe, Jolyon Martin

May 14, 2003

Introduction To Catalog Services

• Major TopicsOverview of Catalog ServicesCatalog Development Application ProfilesIssues for CIP AlignmentImpact on CIPOCG UpdateISO Update

Catalog Services

Problem: The ability to search for spatial information using the same set of fields and get similarly structured results from different servers

Solution: OGC Catalog Services

Evidence: Z39.50 implementations - FGDC, GILS, INFEO, NASA/CIP, others

OGC Catalog Services

• Support the search and retrieval of descriptive information (metadata) on an information resource (dataset, service, schema, etc.)

• Version 1.1.1 has Implementation Profiles for developing catalogs in CORBA, Z39.50

Catalog Services

DiscoveryService

(mandatory)

DiscoveryOperations

(mandatory)

AccessService

(optional)

AccessOperations(optional)

ManagementService

(optional)

ManagementOperations(optional)

OperationsClasses

Includes init, closefunctions

DirectDirect BrokeredBrokered

CatalogService

CatalogService

Catalog Development

• Catalog Revision Working Group (RWG) convened in December 2002 to address revisions

• Functional requirements requested early 2003• RWG developing a revised general model to

accommodate stateless and transactional interfaces• RWG evaluating the types of API to be defined

for HTTP access (SOAP, HTTP GET/POST) and possible parity with other APIs (UDDI, ebRIM)

The Ideal Catalog Service

DataCatalogEntry

GenerateMetadata

link to

DataObject

ServiceInstance

data served by service

service referenced by data

ServiceCatalogEntry

GenerateMetadata

link to

Catalog Service

Internet

association

New Catalog Work• Catalog Version 2.0 consolidates the

stateless catalog/WRS/Registry activities into the Catalog Service Specification as an “HTTP Protocol Binding” section

• HTTP binding is increasingly desirable as a result of security lockdowns at many sites in which only the web server port 80 is left open to the outside world

• Will define how to create Application Profiles to specify community behavior

Implementer Agreement = Profile

• Within a specific community of desired interoperability, a specific subset of behaviors that incorporate specific services, operations, interaction patterns, and information packages should be declared

• This “implementers agreement” can be realized through an Application Profile of the OGC Spec:– Application: specific performance context– Profile: specific subset of function and content

• Interoperability is problematic without one

Content of an Application Profile

• Domain/intent of the application/community

• Required service and operations

• Query language expectations

• Information Model, Content, Semantics

• Message syntax and schemas

• Conformance Testing Guidance

Community of application

• Describing the specific intent and scope of the interaction within an application community helps bound the problem– What subject domain is being addressed?

– Who is the implementer community?

– What type of resources are being described and accessed?

– What specific semantic and syntactic resources are used?

– Provide example scenarios (use cases, sequence diagrams) of typical interaction

Scoped service and operations

• The selected Distributed Computing Environment (Protocol Binding Option)

• Variations on the protocol (GET vs POST)• Required groups/enumerations of

operations (Discovery, Management, etc)• Exception handling options defined• Identify dependency or relation to other

supporting service operations

Query language expectations

• Presence of “abstract” query against well-known query entry points (e.g. OGC Core)

• Identify resources that are queryable vs. opaque but deliverable

• Nuances of the query language– Supported data types– Expected operation types in query (inequality, proximity,

partial string, spatial, temporal)?– Expected results content (e.g. brief/full, individual

elements)

Information Model and Content

• Identify information resource types that can be requested

• Reference “well-known” schemas that can be used to validate responses

• Any semantic resources including data content model, dictionary, feature type catalog, code lists, authorities, taxonomies, etc.

Message syntax and schemas

• Identify restrictions or conformance to request messages

• Identify valid schema(s) with respect to a given format (syntax) for response message validation in association with a specific function

• Identify expected exception handling behavior

Conformance Testing Guidance• Identify a test for each required operation to include

a typical request that exercises required terms and operators

• Test mandatory and optional operations • Include test data to be loaded to a service for

specific request/response validation• Specify a series of requests that exercise:

– Correct number of results

– Correct format of results

– Validated result by schema

Examples

• Web Feature Services can operate on any number of specialized schemas (every WFS could be content-unique)

• Gazetteer can be considered a Profile of WFS• Catalog Services interoperate best with well-

known metadata schemas Certain services may support optional transactional interfaces

Example values from Catalog

• Interfaces: Discovery Interfaces

• Protocol: Z39.50 “GEO”

• Information Model: ISO 19115

• Representation: ISO 19139

• Validation: XML Schema

• …

Possible HTTP Interfaces• General operations:

– getCapabilities: fetch service characteristics– describeCollection: like Explain– describeType: fetches schema(s) of resources– query: performs query and returns results– registerResource

• Transaction/session operations:– initSession - terminateSession– transaction - status– lockRecord - cancelRequest

Issues for CIP alignment

• Definition of a single Application Profile for GEO/CIP over HTTP is desired

• Translation/selection of appropriate query language

• Issues of managing Session or State over HTTP• Support of suitable schemas for ISO metadata

expressed as XML (ISO 19139)• Address need for transactional operations• Catalog RWG meets weekly and seeks active

contributors and implementers

Interoperability Lessons learned from OGC Catalog 1.1.1

• Original specification does not direct selection of metadata models or schemas

• Lack of implementation profile conformance test suite is a liability

• Need for a core set of well-known field/use attribute equivalents across all implementations is helpful in discovery

Impact on CIP: Protocols

• OGC Catalog will allow access to existing metadata resources

Interoperability is an issue if FGDC or, more broadly, OGC-based efforts, moves away from Z39.50 to OGC Stateless Catalog implementation

• 3 Implementation Profiles (Protocol Bindings) – CORBA Coarse, Z39.50, and Web Service

CIP uses only Z39.50 now, and has participated in testbed developments of Web Services in the past

Impact on CIP: Schema/Information Models

• Will need to support catalog uses where all metadata is searchable – discoverable objects in the Catalog, such as data metadata, services metadata, schemas, codelists, symbol or style templates, vocabularies

• Need persistent identifiers for information resources

OGC Update• Recent Catalog RWG meeting in Orleans, France.

Topics included:Will include “Protocol Binding” sections, in

place of the old "Implementation Profiles“: CORBA, Z39.50, and HTTP

Opportunity to review and revise Z39.50 Protocol Binding Section

Develop Application Profiles as linked documents

Transactional capabilities to allow programmatic insert, update, delete functions, 'registration' of searchable resource types

ISO 19115 Update

• ISO/TC 211 lists final draft of ISO 19115 as “approved” (http://www.isotc211.org/publications.htm)

• ISO 19139 is a Technical Specification that will include a conformant XML Schema Document and supporting UML model for metadata expressed as XML– This will form basis of US Metadata Standard