Simple Catalog Interface

This page helps document a conversation in the Geodata Committee about developing simple protocols for discovering and syndicating metadata describing where geodata is available. The conversation is visible and joinable through the osgeo geodata mailing list (archives for Aug. 2006)

• See Also: Geodata Metadata Requirements

Stefan Keller wrote an excellent overview describing some of the background to why there is a felt need for a simple metadata exchange/search interface

Requirements

• we want a simple web interface
• we want it to be as existing-standards-compliant as possible
• we want it to be very easily syndicatable and contributable as possible
• we not only want to register a static resource but also web services

Web addressable interfaces

http://www.gis.hsr.ch/wiki/OAI-PMH - Stefan Keller's comparison of OAI-PMH and WFS

Metadata models

see Geodata Metadata Requirements

See Also

• log of IRC meeting about service crawlers and metadata exchange on 2006/08/10
• Geodata Committee Eighth Meeting - summary of the above meeting
• Paul Ramsey on simple web services catalogues 2005/10
• more from Paul Ramsey 2006/02
• Andrew Hallam on Lightweight Web Resource Catalogue 2006/06 (good comments)
• Tom Kralidis' owscat
• the mapdex data catalog search API

• http://www.mapbender.org/index.php/Catalog_Services

Notes from Metadata + Catalog BOF at FOSS4G2006

stefan - ISO issues - need to describe services - being merged with ebRIM - compulsory core is 300 attributes - this is overkill for user+producer requirements

• b has a vision of how to overcome the problem

tom from owscat - hard time finding implementations of cat-2 that are available - simple requirement to discover service resources - is doing capabilities indexing and spitting out layer / index metadata - search clients are WFS clients

my spiel

schuyler - metacarta - interested in contributing solutions - + helping the geodata committee

adoyle - simple as possible, right as possible - search interfaces - human interfaces - how do text search indexes make it seem so easy - "how do we make it seem so hard?"

nedh - i'm not even sure what CSW is but i think that's what i'm interested in

Josh: CAT was its previous name - a semi-abstract spec - CSW was the description of the HTTP service. ebRIM - CSW - "the spec is big for a reason because it tries to address a lot of different communities" - corba binding, z39.50 binding.

OGC wants to contrib to simple discovery -

interested in simple profile development - work happening in geonetwork

Raj from OGC

tryign to catalogue everything - data, data services, symbols, so much process. 2 parts of simple answer -1/ do we only want to catalogue a class of thing? 2/ what comes out of the information model and letting the programmers develop

Rob Atkinson - can't build simple profiles - wants to catalogue all this kind of thing - too many implementations - little in the way of interop

"care about not the objects, but the relationships between them; this service implements this feature type" . ability to *query* relationships - this is contained in the ebRIM metamodel

rob: "protocol is not the issue"

stef: "profile is not the issue"

getting the information model right

metadata slots bound to *vocabularies* that are domain defined - this sounds much more like OWL - "guide the user through the semantic space"

Jeroen - geonetwork opensource - macmini

tom from owscat - extending WFS - putting metadata model through it. wms 1.1.1 capabilities + wfs 1.0.0 metadata - everyone's waiting for geonetwork to implement this. wfs interesting engine for query. josh suggests small proxy to offer a csw interface over it - a geoserver module.

SLD to WMS - i care about the features that it support - this is what jody is saying - query via SLD so i know what to query for.

size of model. relationship issue. stef talks about OAI-PMH approach jeroen says geonetwork will soon support an OAI-PMH interface

then we still need to define the minimal model

jeroen - in UNEP - work on defining a metadata subset - avoiding later refactoring of metadata - concern about making new versions of existing standards.

"metadata exchange protocol"

data for internal and external use

internal model - smallest common denominator

cascading query services - lightweight interface at the indexing level.

integrating search services. google talks dublin core, talks oai-pmh

rob: flexibility of the meta model - we can't predict what we're going to receive or need to express. - no guarantee of consistency -

how do we agree to agree?

stef - it's not easy to chain services - discovery first, chaining afterwards.

lightweight protocol which doesn't include filter.

OAI for propagation - is the data useful when you propagate it - our information mode