OSGeodata metadata exchange model
We need a geographic metadata exchange model! And let's reduce it to the max.
This is part of a discussion around a geographic metadata exchange model and a geographic metadata exchange protocol.
See also OSGeodata Discovery here and generally OSGeodata, and externally discovery requirements at OSGeo Wiki.
Inhaltsverzeichnis
Overview
A metadata model is nothing else than a usual information model. Information models are the basis for capturing data, database management as well as for data exchange protocols. This metadata information model should be lightweight and should describe geographic resources being primary data but also filter services.
The currently proposed ISO 19115 spec. has mainly two weaknesses: It is too complex (even the core) and it does not cover service description. Extending an already heavyweight spec. probably does'nt make it more lightweight.
A metadata exchange model would be the building block for a metadata exchange protocol. OAI-PMH would be such a protocol which is already in widespread use (including Google).
Status of geographic metadata models
Geographic catalog is rather data provider centric name for a system and a model, so we prefer a user centric 'metadata (information) model'.
- ISO 19115/19 The model behind many current GIS initiatives (even core too complex and lacking service descriptions)
- csw:record behind OGC's CSW (CSW was also labeled 'painfull', yet another encoding)
- unqualified default Dublin Core - too simple, no own proper encoding
- IESR's Extension to OAI-PMH Dublin Core (see also Introduction to the IESR: A Registry of Collections and Services, by Hill and Ann Apps, MIMAS, Univ. of Manchester, 2006).
Thus, the proposal of an information model to exchange spatial metadata like below and at OSGeo Wiki.
Service as own resource or as attribute value to data resource
There is a dilemma about what constitutes a 'resource' the metadata points to: Is a geographic service, like WMS, a resource on its own? In this case a harvester must subsequently try to request it for more information based on the indicated protocol hopefully indicated by a type value. If the geographic data remains the single source of resource, every file format (like GeoRSS, GML, DXF, Shapefile) as well a service type, like a 'WMS layer' or a 'WFS feature set' needs to be mentioned in the metadata record.
Idea: Take the smallest possible information model for geographic metadata which describes data and filter services. Dublin Core (DC) is the most well known model. This must be extended using the known DC specs.
Proposal of an information model to exchange spatial metadata
There is strong evidence that the architecture should be centered around data resources. Therefore metadata describes primary data resources. As a consequence, a probably specialized type attribute/XML element 'dc:type' contains data access services values like File API, JDBC, HTTP GET, WMS, WFS, etc. These are all services which provide a programming interface to access data.
But there is also a need to describe services on its own, also called filter - finally as own metadata records: Normally you feed some data in and get data out. For these kinds of services it’s interesting to know what kind of data you can feed in and get back. Examples are format conversion or coordinate transformation services.
Dublin Core and its interpretation in geographic metadata
There sis now a proposal out called Dublin Core lite for Geo (DClite4G).
This is the list of attributes of DClite4G which defines the minimal information model for metadata exchange, harvesting and discovery ( *) Manual input required from somewhere):
- dc:identifier, dc:title*, dc:description*, dc:type*, dc:format*, dct:spatial, dct:modified, dc:subject*, cld:isAccessedVia, dcterms:hasPart, dc:source*,
- Remaining (optional) DC elements: dc:publisher*, dc:language, dc:rights*, dc:relation*,
Other links:
- As a blueprint, here is a OAI-PMH Dublin Core Mapping (Version 2005-09-06) from Information Environment Service Registry (IESR).
Example
See proposal here at OSGeo.
Toughts about encoding and links
Encodings:
- Use RDF or qualified DC or?
Notes:
- Links are for three things, (1) discovery (what pages exists), (2) reputation (how important is this page) and (3) annotation (what is this page about).
