OSGeodata metadata exchange model: Unterschied zwischen den Versionen

Aus Geoinformation HSR
Wechseln zu: Navigation, Suche
(Dublin Core and its interpretation in geographic metadata)
(Proposal of an information model to exchange spatial metadata: Examples)
Zeile 2: Zeile 2:
  
 
Initial version by S.F. Keller. See also [[OSGeodata]].
 
Initial version by S.F. Keller. See also [[OSGeodata]].
 
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.
 
  
 
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.
 
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.
 
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.
 +
 +
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.
  
  
Zeile 16: Zeile 16:
 
* '''Relation''': reference - Reference to other metadata records - especially useful for map service types (WxS) pointing to data service types (= file, database?)
 
* '''Relation''': reference - Reference to other metadata records - especially useful for map service types (WxS) pointing to data service types (= file, database?)
 
* '''Type''': text or enum - Protocol type, e.g. file, WMS layer, WFS feature set, etc... '''IMPORTANT FOR SERVICE DISCOVERY'''  
 
* '''Type''': text or enum - Protocol type, e.g. file, WMS layer, WFS feature set, etc... '''IMPORTANT FOR SERVICE DISCOVERY'''  
* '''Identifier''': string  - Unique id to identify an object in a certain context (use a URI for dc:identifier).
+
* '''Identifier''': string  - Unique id to identify an metadata record (use a URI for dc:identifier).
 
* '''Title''': string - Title
 
* '''Title''': string - Title
 
* '''Coverage.box''': - Rectangular box (mandatory) in WGS84
 
* '''Coverage.box''': - Rectangular box (mandatory) in WGS84
Zeile 36: Zeile 36:
 
(Most are probably enums):
 
(Most are probably enums):
  
* Subject (specialized): Only in case of a data resource? c.f. above.
+
* Relation (specialized for services): 'Relates to': Identifier of other data resource. Note that this may be hierarchical
 +
* Relation (specialized for data): 'See also': URL as hint to other data resource. Note this is an important feature for crawlers if there exists not (yet) a harvesting protocol.  
 
* Type (specialized): Protocol type, URL to WMS etc.
 
* Type (specialized): Protocol type, URL to WMS etc.
 
* Identifier (specialized): URL (not URN as in DC)
 
* Identifier (specialized): URL (not URN as in DC)
 
* Coverage (specialized): Coverage.box and Coverage.name  
 
* 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
 
* Creator and Publisher (specialized): structured adress including webpage and/or mail and phone
* Type of resource processable (new): In case of a service: Information about the kind of data (e.g. schemas) it processes. Note that metadata about filter services stand alone but link to or embed this.
+
* Resource accepted (new for services): In case of a service: Information about the kind of data (e.g. schemas) it can process. Note that metadata about filter services are stand alone records.
* Relation (specialized): Relates to
+
 
* Relation (specialized): See also in the sense of URL to geometa data
+
=== Example ===
 +
 
 +
These are preliminary thoughts...
 +
 
 +
Given these attributes and the two resources, data resource and service resource, described above, here are two metadata records about POIs data and a WMS service of Rapperswil as examples:
 +
 
 +
* Exerpt of a metadata record (instance) about a geographic ''data'' resource (showing only most important dc-Elements and dummy values):
 +
** ''Title'' := POI data of Rapperswil-Jona
 +
** ''Coverage.name'' := Rapperswil SG
 +
** ''Language'' := de_ch
 +
** ''Date'' := 2006-08-14
 +
** ''Publisher'' := http:// www.hsr.ch/en/
 +
** ''Creator'' := S.F. Keller
 +
** ''Rights'' := LGPL
 +
** ''Type'':= file
 +
** ''Subject'' := Economy
 +
** ''Format.path'' := georss http:// www.gis.hsr.ch/data/poi_data_rapperswil.georss
 +
** ''Format.path'' := wms http:// www.gis.hsr.ch/wms
 +
** ''Relation.see_also'' := http://www.gis.zh.ch/
 +
** ...
 +
 
 +
* Exerpt of a metadata record (instance) about a geographic ''service'' resource (showing only most important dc-Elements and dummy values):
 +
** ''Title'' := WMS at HSR
 +
** ''Coverage.name'' := Rapperswil SG
 +
** ''Language'' := de_ch
 +
** ''Date'' := 2006-08-14
 +
** ''Publisher'' := http:// www.hsr.ch/en/
 +
** ''Creator'' := S.F. Keller
 +
** ''Rights'' := LGPL
 +
** ''Type'' := WMS
 +
** ''Format.path'' := wms http:// www.gis.hsr.ch/wms
 +
** ''Resource_accepted'' :=  URL to shape file/Postgres schema?
 +
** ...
  
=== Example in GeoRSS (simple) encoding ===
+
=== Encoding? ===
...
+
* Use GeoRSS (simple) encoding?

Version vom 14. August 2006, 01:23 Uhr

Proposal of an information model to exchange spatial metadata

Initial version by S.F. Keller. See also OSGeodata.

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.

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.


Dublin Core and its interpretation in geographic metadata

This is the full list of (possibly repeatable) attributes from DC together with its proposed semantic interpretation and/or enumeration list (needs probably an own XML namespace):

  • Relation: reference - Reference to other metadata records - especially useful for map service types (WxS) pointing to data service types (= file, database?)
  • Type: text or enum - Protocol type, e.g. file, WMS layer, WFS feature set, etc... 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 - 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
  • Creator: string - Data owner, else: data capturer
  • Contributor: string - Leave unused?
  • Publisher: string - Distribution informatione
  • 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 for services): 'Relates to': Identifier of other data resource. Note that this may be hierarchical
  • Relation (specialized for data): 'See also': URL as hint to other data resource. Note this is an important feature for crawlers if there exists not (yet) a harvesting protocol.
  • Type (specialized): Protocol type, URL to WMS 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 services): In case of a service: Information about the kind of data (e.g. schemas) it can process. Note that metadata about filter services are stand alone records.

Example

These are preliminary thoughts...

Given these attributes and the two resources, data resource and service resource, described above, here are two metadata records about POIs data and a WMS service of Rapperswil as examples:

  • Exerpt of a metadata record (instance) about a geographic data resource (showing only most important dc-Elements and dummy values):
    • Title := POI data of Rapperswil-Jona
    • Coverage.name := Rapperswil SG
    • Language := de_ch
    • Date := 2006-08-14
    • Publisher := http:// www.hsr.ch/en/
    • Creator := S.F. Keller
    • Rights := LGPL
    • Type:= file
    • Subject := Economy
    • Format.path := georss http:// www.gis.hsr.ch/data/poi_data_rapperswil.georss
    • Format.path := wms http:// www.gis.hsr.ch/wms
    • Relation.see_also := http://www.gis.zh.ch/
    • ...
  • Exerpt of a metadata record (instance) about a geographic service resource (showing only most important dc-Elements and dummy values):
    • Title := WMS at HSR
    • Coverage.name := Rapperswil SG
    • Language := de_ch
    • Date := 2006-08-14
    • Publisher := http:// www.hsr.ch/en/
    • Creator := S.F. Keller
    • Rights := LGPL
    • Type := WMS
    • Format.path := wms http:// www.gis.hsr.ch/wms
    • Resource_accepted := URL to shape file/Postgres schema?
    • ...

Encoding?

  • Use GeoRSS (simple) encoding?