Interoperable catalog motivation

Use of a standardized protocol for searching and retrieving metadata would save resources currently spend developing multiple client and server applications that are functionally very similar, and make life easier for users because they could learn to use a single search client application that could then be used to search multiple catalogs.

Catalog client --  Many applications to search a metadata catalog currently exist (see Links to Operational Catalogs). Most (all?) of these applications are 'tightly coupled' -- i.e. the web page only searches one metadata registry database, typically using a protocol specific to that particular application. In an interoperable catalog scenario, the metadata databases would all implement a standard catalog service (along with the existing custom interfaces). A single client application could be connected to any of these databases to search the metadata. A single, open source client framework could be reused by anyone wishing to implement a structured metadata search capability. Such frameworks are under development, see exCat, CatalogConnector, GeoNetwork. Wide usage of a catalog search framework would provide users with a familiar interface that would then require less training.

Catalog server -- Tightly coupled client-server search applications require that an agency wishing to expose metadata for thier resources implement a search application specific to their metadata registry database. In an interoperable catalog scenario, in which existing clients can be used to search any metadata registry database that is 'published' using a standard catalog service, the agency would only have to implement the catalog service and make the interface public to enable search by existing clients.

Metadata propagation -- Currently a user may have to search multiple metadata registries using different user interfaces to be confident that they have looked everywhere. In a system of interoperable catalogs, metadata records from any registry might be harvested and cached by any other catalog in the system. Thus a resource registered in one metadata registry would eventually propagate through the system. Alternatively, single search clients might be programmed to search many catalogs and aggregate the results. Both of these scenarios would act to ensure that searches from a single search interface would reliably discover a high proportion (ideally all!) of relavent resources of interest.

Structured metadata -- Most internet users are now accustomed to single text-box free text searches (e.g. Google, Yahoo...) that return hundreds of results ranked by 'relavence'. These search engines use algorthms to determine relavence based on word associations in text, http linkages between resources, and statistics on user navigation between resources. Such searches work remarkably well for many everyday situations. The down side is the large number of irrelevant hits, the lack of information to asses the utility of the located resources for specific technical applications, the absence of information required to access the resource automatically except through http urls, and the inability to index resources that are not text-based and web accessible. Structured metadata enables scenarios in which very focused results can be obtained, the information returned by a search can provide good guidance on fitness for purpose, and the results can include sufficient information to allow automated linkage to non-http services.

Related Community Groups
CSW Debug Blog | 17 Posts | Join
A group blog to discuss metadata Catalog Service for the Web (CSW) implementation experiences
Building a GeoSciML WFS Server | 11 Posts | Join
Development, testing and implementation of a WFS service that returns GeoSciML documents
ETL Debug Blog | 12 Posts | Join
A group blog on implementing and debugging Extract-Transform-Load (ETL) efforts.
Presentations and Posters | 12 Posts | Join
Post your posters and presentations related to USGIN topics.
Metadata interest group | 13 Posts | Join
group for general posting on metadata content, standards, tools
USGIN Amazon Virtual Server Development | 18 Posts | Invite only
Documenting the process of development of a Web Server in the Amazon EC2 environment. Software installations tailored to the requirements for USGIN
GeoNetwork configuration and development | 7 Posts | Join
Discussion on GeoNetwork setup, configuration, and development.
Student Projects | 0 Posts | Join
Discussion of student projects related to USGIN
Drupal Development | 6 Posts | Join
All about bending Drupal to your needs
Geoportal on an Amazon Virtual Machine | 3 Posts | Closed
Installation, configuration, etc.
Using Django for USGIN | 7 Posts | Request membership
Thought and ideas about using Django to accomplish USGIN-related... things.
ArcGIS Server and OGC Services | 3 Posts | Join
Tips on using ArcGIS Server to provide OGC web services
Content model discussion | 0 Posts | Request membership
Community site for comments on development of content models and encoding for information intechange
Making Web Maps | 2 Posts | Request membership
For information about the myriad of mechanisms for showing service data on a web page.
Troubleshooting Web Service Deployment - Blog | 5 Posts | Join
This blog is for documenting our group's experiences with web service deployment.
Best Practices for USGIN Web Service Hosting | 10 Posts | Join
Tips, techniques, and frequently asked questions for hosting AASG Geothermal Data Web Map Services and Web Feature Services
Hub Disaster Recovery | 0 Posts | Request membership
Discussions around how to harden a distributed federated system against disaster; setting up a system to mirror hub VMs at other hubs.