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

Introduction To Catalog Services Major Topics  Overview of Catalog Services  Catalog Development  Application Profiles  Issues for CIP Alignment  Impact on CIP  OCG Update  ISO 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 has Implementation Profiles for developing catalogs in CORBA, Z39.50

Catalog Services Discovery Service (mandatory) Discovery Operations (mandatory) Access Service (optional) Access Operations (optional) Management Service (optional) Management Operations (optional) Operations Classes Includes init, close functions Direct Brokered Catalog Service Catalog Service

Catalog Interface

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 Data Catalog Entry Generate Metadata link to Data Object Service Instance data served by service service referenced by data Service Catalog Entry Generate Metadata 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 Representation: ISO 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 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 Update ISO/TC 211 lists final draft of ISO as “approved” ( ISO 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