OSGeodata metadata exchange model: Unterschied zwischen den Versionen

Version vom 23. August 2006, 04:58 Uhr

We need a metadata exchange model! And let's reduce it to the max.

This is part of a discussion around a geographic metadata exchange model and an geographic metadata exchange protocol.

See also OSGeodata Discovery here and generally OSGeodata, and externally geodata metadata requirements at OSGeo Wiki.

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.

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)
• cws: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 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

This is the full list of attributes from DC together with its proposed semantic interpretation and/or enumeration list (needs probably an own XML namespace). If not indicated 'multivalued' all attributes are non-repeatable (i.e. have cardinality 1 to 1):

• Relation: reference (multivalued) - Reference to other metadata records - also useful for map service types (WxS) pointing to data service types (= file, database?)
• Type: enum (multivalued) - Either 'WPS' (= processing/filter services) or Protocol type (for data services), e.g. 'file', Well known access services: 'WxS' (WMS layer, WFS feature set), 'WSDL' (SOAP). IMPORTANT FOR SERVICE DISCOVERY
• Identifier: string - Unique id to identify an metadata record (use a URI for dc:identifier).
• Title: string - Title
• Coverage.box: - Rectangular box (mandatory) in WGS84
• Coverage.name: String - (optionally) a geographic name
• Description: string (multivalued) - Some free text
• Subject: enum - Classification from ISO 19115 as enum type (original: The topic of the resource. Typically, subject will be expressed as keywords or phrases that describe the subject or content of the resource. The use of controlled vocabularies and formal classification schemas is encouraged.)
• Language: enum - ISO Code
• Format: string - File type or name of originating source system
• Source: string - Lineage information
• Date: date - Publication date or date of last change of metadata record
• Creator: structure - Address (person or organization name, e-mail) of data owner, else of data capturer
• Publisher: structure - Distribution information (person or organization name, e-mail)
• Contributor: string - (see publisher) Leave unused?
• Rights: string - License information about the data
• Audience: string - Not used or 'GIS' as a constant

Attributes to be discussed in detail

(Most are probably enums):

• Relation (specialized): 'Relates to': Identifier of (other) data resource. Note that this may be hierarchical
• Relation (specialized for data): 'See also': URL as hint to other metadata data resource (valid XML). Note this is an important feature for crawlers if there exists not (yet) a harvesting protocol.
• Type (specialized): Protocol type: URL to WKS (WxS, WMS, WFS), WSDL, etc.
• Identifier (specialized): URL (not URN as in DC)
• Coverage (specialized): Coverage.box and Coverage.name
• Subject (specialized for data): c.f. above.
• Format (specialized for data): Not clear in unqualified DC how to point to original resource
• Creator and Publisher (specialized): structured adress including webpage and/or mail and phone
• Resource accepted (new for processing services): In case of a service: Information about the kind of data (e.g. schemas) it can process - unless there exists a GetCapabilities for every kind of service. Note that metadata about filter services are stand alone records.

Example

These are preliminary thoughts...

As a blueprint, here is a OAI-PMH Dublin Core Mapping (Version 2005-09-06) from Information Environment Service Registry (IESR).

Given the attributes described above and the two resources, data and service resource, mentioned above, here are two metadata records sketched as examples: One about POIs data of Rapperswil and one being a fictive special service/filter:

• Exerpt of a metadata record (instance) about a geographic data resource (showing only most important dc-Elements and dummy values):
  • Title := POIs of Rapperswil-Jona # a data, a set of geographic features
  • Coverage.name := Rapperswil SG
  • Language := de_ch
  • Date := 2006-08-14
  • Publisher.Address := http:// www.hsr.ch/en/
  • Creator.Name := S.F. Keller
  • Rights := LGPL for data
  • Type:= file
  • Subject := Tourism
  • Format.Path := georss http:// www.gis.hsr.ch/data/poi_data_rapperswil.georss # a file!
  • Format.Path := shapefile http:// www.gis.hsr.ch/data/poi_data_rapperswil.shp # a file!
  • Format.Path := wms http:// www.gis.hsr.ch/wms # a web service!
  • Relation.See_also := http:// www.gis.zh.ch/ # a hint for crawlers and aggregators
  • ...

• Exerpt of a metadata record (instance) about a geographic service resource, a sort of filter (showing only most important dc-Elements and dummy values):
  • Title := Geographic File Format Converter at HSR # a filter service
  • Coverage.Name := Rapperswil SG
  • Language := de_ch
  • Date := 2006-08-14
  • Publisher.Address := http:// www.hsr.ch/en/
  • Creator.Name := S.F. Keller
  • Type := Converter
  • Format.Path := converter http:// www.gis.hsr.ch/converter
  • Resource_accepted := shapefile # plus URL to shape file specification?
  • Resource_accepted := georss http:// www.georss.org/georss/xml/1.0/georss.xsd
  • ...

Encoding?

• Use GeoRSS (simple) encoding?

Weblinks

• Geodata metadata requirements at OSGeo Wiki
• FGDC with ISO 19115 summary