OSGeodata: Unterschied zwischen den Versionen

Aus Geoinformation HSR
Wechseln zu: Navigation, Suche
K
(Weblinks)
 
(81 dazwischenliegende Versionen von 4 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
These pages are about our search of "a protocol for the incremental exchange of metadata about geographic resources between systems" which is open, lean and mean.
+
== Overview ==
Proposals like OGC's CSW 2.0 do not fulfill these requirements.
 
Profiled specifications like WFS or [[OAI-PMH]] (see below) are currently on our short list.
 
  
These are experimental pages originated from OSGeodata Mailing List on [https://geodata.osgeo.org/servlets/BrowseList?listName=geodata&by=date&paged=false OSGeo.org].
+
These are experimental pages ([[OSGeodata Discovery|1]],[[OSGeodata metadata exchange model|2]],[[OSGeodata metadata exchange protocol|3]],[[OAI-PMH|4]]) originated from OSGeodata Mailing List on [https://geodata.osgeo.org/servlets/BrowseList?listName=geodata&by=date&paged=false OSGeo.org].
  
== Towards a new geospatial catalog protocol... ==
+
Let's unleash geographic information through open access and dissemination of geographic data and (metadata) search appliances!
  
For protocol requirements read the OSGeodata Mailing List mentioned above, for requirements of the metadata information model (e.g. for response data) see this [http://wiki.osgeo.org/index.php/Geodata_Metadata_Requirements#Discovery OSGeo Wiki page] as well as the [[OSGeodataMetadataModel]].
+
Allow to '''[[OSGeodata Discovery| discover geodata]]'''! Let's make metadata 'sexy' again.
  
Better name sought:
+
For the '''[[OSGeodata Discovery| discovery of geodata]]''' we need a
* Geographic Metadata Harvesting Protocol (sort of [[OAI-PMH]] for Geographic Data and Services)
+
* '''[[OSGeodataMetadataModel| Geographic metadata exchange model]]''' as well as a
* Geographic Data Discovery Protocol
+
* '''[[OSGeodataMetadataProtocol| Geographic metadata exchange protocol]]''' (catalog service).  
* Geographic Metadata Dissemination Protocol
 
* ...?
 
  
== Conceptual Issue ==
+
For '''documentation''' an internal geodata management model is needed. For the '''metadata metadata exchange model''' a proposal was made called  '''[http://wiki.osgeo.org/index.php/Geodata_Metadata_Requirements#Information_model_for_metadata_exchange Dublin Core lite for Geo (DClite4G)]'''.
  
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.
+
Remarks: '''Metadata''' is just data about data. There is nothing special regarding its modeling and encoding. Metadata according to metadata exchange model should be strictly free (LGPL?).
  
:Personal remark: The dilemma get's even stronger if we think of style sheets that render the same geographic data differently. Still, I tend to the latter choice, because all are data streams originating from the single most precious source: geographic data as interpreted, digitized and stored geoinformation) -- Stefan 20:07, 6. Aug 2006 (CEST)
+
== Pleadings for metadata (models) and adequate protocols ==
 +
* ''Managing metadata well is the key to making a repository of open geographic data really useful and re-usable. Creating metadata can be a dull chore. Part of the problem is over-focus on production, rather than consumption; on standards, rather than on usage. The Geodata Committee at OSGeo has been working on a "simplest useful thing" approach to geographic metadata...''. (Citation from Jo Walsh)
 +
* [http://www.digitalearth.com.au/2006/06/23/lightweight-web-resource-catalogue/ Blog 1] - "Leight Weight Web Resource Catalogue"
 +
* [http://geotips.blogspot.com/2006/02/more-simple-web-services-catalogues.html Blog 2] - More Simple Web Services Catalogues...", and  
 +
* [http://www.kralidis.ca/blog/2006/08/04/geospatial-catalog-development-brewing/ Blog 3] - geospatial-catalog-development-brewing.
 +
* [http://home.badc.rl.ac.uk/lawrence/blog/all Bryan's Blog]: "To extend or not to extend ..." ("In practice, we can exchange any derivative of the ISO19139 profiles using OAI and store them in xml databases.").
 +
* Paper "Are Geospatial Catalogues Reaching their Goals?" from [http://www.agile2006.hu/papers/Larson_Siliceo_etal.pdf Larson et al.].
  
== Comparison between WFS and OAI-PMH ==
+
== Building blocks for metadata management ==
 
+
Building blocks are:
Relative (biased?) comparison:
+
# A geometadata '''management model''' (e.g. internal to each organisation)
* [[OAI-PMH]] is a set of simple and strictly RESTful harvesting protocols based on Dublin Core (since 1995) whereas WFS allows a RESTful or SOAP client to retrieve geospatial data encoded in GML (since 2000).
+
# '''Tools''' to manage the geometadata
* WFS though originated in GIS covers a smaller community than [[OAI-PMH]] which today has a larger user base and is supported even by Google and Yahoo!.
+
# A geometadata '''[[OSGeodata metadata exchange model| exchange model]]'''
* Both have in common that they can be made (WFS) or are ([[OAI-PMH]]) RESTful and both can be profiled to respond an 'output content model' - which has yet to be defined (see [[OSGeodataMetadataModel]]).
+
# An '''encoding''' of the geometadata exchange model (probably XML)
* WFS needs to be profiled (spec. size is ~200 p.) whereas [[OAI-PMH]] needs probably to be extended (spec. size is ~50 p.) - so WFS seems more complex and more costly to implement or adapt but much depends on the needs (make sophisticated queries vs. harvesting?) and underlying the architecture (distributed online services vs. local indexing).
+
# Geometadata '''[[OSGeodata metadata exchange protocol| exchange protocols]]''' (like [[OAI-PMH]], see [[OSGeodata_Discovery]])
 
 
=== WFS ===
 
 
 
* WFS is short for 'Web Feature Service'.  
 
* Spec. size: About 100 pages plus mandatory reference to Filter spec. of about 40 pages, plus reference to GML 2 (60 pages).
 
* Background: A de-facto standard in GIS world owned by OGC
 
* Request operations (Basic WFS, read only WFS):
 
** ''GetCapabilities'' - describe service capabilities;
 
** ''DescribeFeatureType'' - describe structure of a feature type
 
** ''GetFeature'' - retrieve feature instances
 
* Query:
 
** Standard query (c.f. Filter) includes spatial constraints (but no temporal?)
 
* Response:
 
** Must be GML 2 and may be other XML encodings.
 
* Peculiarities:
 
** Knows version negotiation (which isn't implemented yet...)
 
** Uses URN as unique identifier
 
* Availability and outreach of services, tools and (open source) software:
 
** Open source software see [http://www.freegis.org freegis.org]
 
* Expected changes to spec. (profile or extension):
 
** Profile to KVP binding
 
** Profile Filter to Boolean and Wildcard matches as well as 'within'
 
** ...
 
 
 
=== OAI-PMH ===
 
 
 
* [[OAI-PMH]] is short for 'Open Archives Initiative Protocol for Metadata Harvesting'. See [[[[OAI-PMH]]]] for a short description and architectural diagrams. Note this is not a search protocol - that could be for example enhanced or merged versions of OpenSearch/GeoRSS and SRU/SRW besides WFS.
 
* Spec. size: Version 2.0 still is < 50 pages(!)
 
* Background: Was initiated by libraries, universities, museums and galleries to 'open access' (OA) free online availability of digital content.
 
* Request operations:
 
** ''Identify'' - describe an archive (similar to WFS' GetCapabilities)
 
** ''ListMetadataFormats'' - retrieve available metadata formats from archive
 
** ''ListIdentifiers'' - abbreviated form of ListRecords, retrieving only headers
 
** ''ListRecords'' - harvest records from a repository (similar to WFS' GetFeature)
 
** ''GetRecord'' - retrieve individual metadata record from a repository (also similar to WFS' GetFeature)
 
** ''ListSets'' - retrieve set structure of a repository (optional)
 
* Query:
 
** Standard query includes temporal constraints (but no spatial yet).
 
* Response:
 
** Either an encoded error or unqualified Dublin Core XML or another format announced with ListMetadataFormats.
 
* Peculiarities:
 
** For identifiers URI must be used (similar requirement to WFS).
 
** Has no version negotiation (but see operation Identify)
 
** Knows incremental update
 
** Another spec. was released called 'OAI Static Repository and an OAI Static Repository Gateway'
 
** [[OAI-PMH]] may respond results in compressed form which is handled at the HTTP-level (how RESTful!)
 
* Availability and outreach of services, tools and (open source) software:
 
** Open source software see [http://www.openarchives.org/tools/tools.html [[OAI-PMH]] tools]
 
** Gateways available from publishing files to others 
 
** Google reads it as a Sitemaps file ([http://www.google.com/support/webmasters/bin/answer.py?answer=34655 how to submit]), Yahoo! and Internet Archive uses it among others.
 
* Expected changes to spec. (profile or extension):
 
** special treatment of ID's?
 
** Need to be extended if spatial constraints are needed here
 
** Add version negotiation?
 
** ...?
 
 
 
== Background ==
 
 
 
Let's finally unleash geographic information through open access and dissemination of geographic data and (metadata) search appliances!
 
 
 
:''Managing metadata well is the key to making a repository of open geographic data really useful and re-usable. Creating metadata can be a dull chore. Part of the problem is over-focus on production, rather than consumption; on standards, rather than on usage. The Geodata Committee at OSGeo has been working on a "simplest useful thing" approach to geographic metadata...''. (Citation from Jo Walsh)
 
 
 
Keywords: ''Open access to and dissemination of geographic data (geodata) and information; Metadata; Finding, harvesting or discovery of geodata and web map services; Interoperability; Integration; Service binding; Spatial data infrastructure; Standards''.
 
  
 
== Weblinks ==
 
== Weblinks ==
Zeile 97: Zeile 36:
 
* [http://wiki.osgeo.org/index.php/Geodata_Metadata_Requirements#Discovery Wiki at osgeo.org] for requirements
 
* [http://wiki.osgeo.org/index.php/Geodata_Metadata_Requirements#Discovery Wiki at osgeo.org] for requirements
 
* [https://geodata.osgeo.org/servlets/BrowseList?listName=geodata Geodata mailing list at osgeo.org] for discussions
 
* [https://geodata.osgeo.org/servlets/BrowseList?listName=geodata Geodata mailing list at osgeo.org] for discussions
* Pleadings... [http://www.digitalearth.com.au/2006/06/23/lightweight-web-resource-catalogue/ Blog 1] - "Leight Weight Web Resource Catalogue" and [http://geotips.blogspot.com/2006/02/more-simple-web-services-catalogues.html Blog 2] - More Simple Web Services Catalogues..."
 
  
Geographic information search services:
 
* Catalogs:
 
** [http://www.mapdex.org mapdex.org]
 
** [http://www.geographynetwork.com ESRI's geography network]
 
** National Portals: [http://www.geodata.gov US], [http://geodiscover.cgdi.ca CA], [http://eu-geoportal.jrc.it EU], [http://www.gogeo.ac.uk UK], [http://www.geocatalogue.fr FR], [http://www.geoportal.bund.de DE], [http://www.geoland.at AT], [http://www.geocat.ch CH]
 
* Search engines:
 
** General: [http://maps.google.com/ Google Maps], MSN live, Yahoo!
 
** Specialized: [http://www.geometa.info geometa.info] (still german only for linguistic processing reasons)
 
* GIS with catalog and search components:
 
** [http://udig.refractions.net uDig], ArcGIS, ...?
 
  
Specifiations:
+
<!-- Kategorien und ev. Koordinaten -->
* OGC's CSW 2.0
+
[[Kategorie: Geodaten]] [[Kategorie: Metadaten]] [[Kategorie: English]]
* OGC's WFS
 
* [[[[OAI-PMH]]]] - including home, wikipedia, documents, tutorials, tools and demos
 

Aktuelle Version vom 29. Oktober 2006, 12:15 Uhr

Overview

These are experimental pages (1,2,3,4) originated from OSGeodata Mailing List on OSGeo.org.

Let's unleash geographic information through open access and dissemination of geographic data and (metadata) search appliances!

Allow to discover geodata! Let's make metadata 'sexy' again.

For the discovery of geodata we need a

For documentation an internal geodata management model is needed. For the metadata metadata exchange model a proposal was made called Dublin Core lite for Geo (DClite4G).

Remarks: Metadata is just data about data. There is nothing special regarding its modeling and encoding. Metadata according to metadata exchange model should be strictly free (LGPL?).

Pleadings for metadata (models) and adequate protocols

  • Managing metadata well is the key to making a repository of open geographic data really useful and re-usable. Creating metadata can be a dull chore. Part of the problem is over-focus on production, rather than consumption; on standards, rather than on usage. The Geodata Committee at OSGeo has been working on a "simplest useful thing" approach to geographic metadata.... (Citation from Jo Walsh)
  • Blog 1 - "Leight Weight Web Resource Catalogue"
  • Blog 2 - More Simple Web Services Catalogues...", and
  • Blog 3 - geospatial-catalog-development-brewing.
  • Bryan's Blog: "To extend or not to extend ..." ("In practice, we can exchange any derivative of the ISO19139 profiles using OAI and store them in xml databases.").
  • Paper "Are Geospatial Catalogues Reaching their Goals?" from Larson et al..

Building blocks for metadata management

Building blocks are:

  1. A geometadata management model (e.g. internal to each organisation)
  2. Tools to manage the geometadata
  3. A geometadata exchange model
  4. An encoding of the geometadata exchange model (probably XML)
  5. Geometadata exchange protocols (like OAI-PMH, see OSGeodata_Discovery)

Weblinks

Information: