OGC Catalog Service for the Web (CS/W): experience in NASA John D. Evans, Ph.D. NASA Geosciences Interoperability Office (GIO) Earth Science Applications Division -/- Global Science & Technology, Inc. Goddard Space Flight Center, Greenbelt, MD

Introduction & overview ● OGC CS/W specification: Spring 2004 – (After many iterations) ● OGC ebRIM profile: Fall 2005 ● NASA experimenting with CS/W since Fall 2004 ● Two implementations in particular: – ECHO CS/W connector (Center for Spatial Information Science & Systems [CSISS], George Mason University) – Earth Science Gateway (NASA Geosciences Interoperability Office [GIO] & Compusult Ltd.) ● Implementation experience – Insights, opportunities, and challenges

GMU / CSISS experience with CS/W ● Bird’s eye view - From Bai, Y., et al., 2007: Towards a Geospatial Catalogue Federation Service, Photogrammetric Engineering & Remote Sensing 73 (6), pp

GMU / CSISS experience with CS/W ● Inside the Catalogue Federation Service - From Bai, Y., et al., 2007: Towards a Geospatial Catalogue Federation Service, Photogrammetric Engineering & Remote Sensing 73 (6), pp

RegistryObject Classification ClassificationSchema …… Association ServiceBindings RegistryEntry Service ExtrinsicObject CSWExtrinsicObject RepositoryItem Service Info. Model (ISO 19119) Dataset Info. Model (ISO 19115) NASA EOS Core System (ECS) Slot GMU / CSISS experience with CS/W ● ● ebRIM model extends OGC CSW for geospatial resources ● ● ebRIM + OGC Catalogue Service for CS/W + OGC Catalogue Service for ISO 19115/19119

GMU / CSISS: CS/W bridge to ECHO ● ● Connects to the full, operational ECHO ● Partial ECHO–ebRIM mapping. Emphasis: – CS/W core queryables (Dublin Core) – Granules (not Collections) ● Performance issues: – ECHO not fully optimized for granule-level search – ECHO 8 responds to most queries from CS/W connector in under 2 minutes (used to be worse) – ECHO 9 may further improve query performance ● Multiplicity of schemas poses add’l challenges – CS/W used as a “hub” for several different catalogs

NASA / GIO Earth Science Gateway (ESG)

Earth Science Gateway (ESG) Service Manager OGC WMS Servers Service Manager Service Registry Database (Oracle) Web Publishing Client OGC WFS Servers OGC WCS Servers External Applications/Clients OGC CSW Requests - GetCapabilities (1) - GetRecords (2) OGC CSW Transactions (3) - Insert - Update - Delete OGC Repository Extensions - GetRepositoryItem (4) - PutRepositoryItem (5) Capabilities XML Document (1) Transaction Status (3) Search Results (2) Repository Item (4) Repository Status (3)

OGC WMS Servers Service Manager Service Registry Database (Oracle) Web Publishing Client OGC WFS Servers OGC WCS Servers External Applications/Clients OGC CSW Requests - GetCapabilities (1) - GetRecords (2) OGC CSW Transactions (3) - Insert - Update - Delete OGC Repository Extensions - GetRepositoryItem (4) - PutRepositoryItem (5) Capabilities XML Document (1) Transaction Status (3) Search Results (2) Repository Item (4) Repository Status (3) Earth Science Gateway (ESG) Service Manager ● ESG portal uses CS/W internally for all catalog access – Search – Publish – Harvest ● Public interface available for other CS/W clients ● Simple HTML client can query other CS/W servers

ESG in OGC Web Services Testbed 3 ● Successful connections from a Refractions Research CS/W client (Nov. 2005) ● Key challenge: reconciling different ebRIM representations – E.g., WMS Layer Extrinsic Object: is its ObjectType “Layer”? “WMS_Layer”? or “Data_Set”? – A guessing game; create equivalencies to fit queries coming from different clients – Changing an ebRIM type name can be a headache ● Another challenge: maintaining performance – Query response slowed a lot at 100k-200k records. – Server-side workarounds: temp tables; caching; returning summaries rather than full records

ESG in OGC Web Services Testbed 4 UAV EO-1

Service Binding Classification ExtrinsicObject objectType = Geometry ExtrinsicObject objectType = Context Document (WMS only) HasFootprint Offers HasContext Service Binding Extents User OffersService ExtrinsicObject objectType = Dataset Description (Metadata Document) HasFootprint Describes Classification uuid = parent uuid = classified_object uuid = service ExtrinsicObject objectType = Layer / featureType / CoverageOfferingBrief Service (WMS, WFS, WCS) uuid = classified_object ExtrinsicObject objectType = Layer / featureType / CoverageOfferingBrief ESG: ebRIM model of OGC Web Service

ExtrinsicOject objectType = Legend ExtrinsicOject objectType = LayerStyle Classification ExtrinsicObject objectType = Geometry Extents HasFootprint Externally Links Styles Service (WMS, WFS, WCS) Describes HasLegend ExtrinsicOject objectType = LayerStyle ExtrinsicOject objectType = Legend ExtrinsicObject objectType = Dataset Description (Metadata Document) Offers HasFootprint ExtrinsicObject objectType = Layer, or featureType, or CoverageOfferingBrief ExternalLink Extents ExternalLink Classification g.uuid = e.parent uuid = classified_object ESG: ebRIM model of OGC Web Service objects (WMS Layer, WFS FeatureType, WCS CoverageOffering)

ESG and CS/W interoperability ● ESG as CS/W server: – – Successful CS/W connections from Intergraph testbed client – Prototype CS/W connections from European Space Agency (ESA) client [ ● ESG as CS/W client: – Successful CS/W connections to GMU/CSISS ECHO connector ● Differences in ebRIM representations continue to be the main challenge – Conforming to CS/W is necessary but NOT sufficient for catalog interoperability

CS/W opportunities & challenges ● OGC CS/W interface definition is owned by no-one (consensus-based) – Support by vendors, open source, etc. – Used across many different sectors of activity ● ebRIM is a promising “common ground” for catalogs – Very flexible meta-model – Growing momentum in e-business ● Expect tools to manage the complexity ● ebRIM: not the answer BUT a good framework for expressing the answer

CS/W opportunities & challenges ● CS/W & ebRIM complexity / generality – Impedes wider implementation – Impedes wider consensus on profiles? ● Representing earth imagery in ebRIM: – E.g., ESA’s EO products profile (slow adoption so far) ● Lots of support for product ordering ● Little support for service binding – No one ebRIM representation will fit everyone – Need an imagery counterpart to Dublin Core? ● NASA community could enhance catalog interoperability by defining one or more overlapping CS/W ebRIM representations