CSW: Unterschied zwischen den Versionen

Aus Geoinformation HSR
Wechseln zu: Navigation, Suche
(Core catalogue schema)
(Remarks)
Zeile 51: Zeile 51:
 
   </csw:Record>
 
   </csw:Record>
  
The example in 10.2.5.3.2 "Full record" shows element ows:WGS84BoundingBox and the text in 10.2.5.3.3 "Summary Response Record" mentions "dct:spatial" for the encoding!??
+
=== How to encode WGS84 Bounding Box? ===
 +
The example in 10.2.5.3.2 "Full record" shows element ows:WGS84BoundingBox (instead of ows:BoundingBox) and the text in 10.2.5.3.3 "Summary Response Record" mentions "dct:spatial" for the encoding. Then, "OGC's Cataloguing of ISO Metadata (CIM) using the ebRIM profile of CS-W (0.1.7)" mentions again dct:spatial !???
  
 +
Proposal: ows:BoundingBox or dct:spatial (both with CRS=WGS84 as mandatory/default)
  
 
=== How to encode record sets? ===
 
=== How to encode record sets? ===
 
csw:Record is a single instance. How to encode record sets??  
 
csw:Record is a single instance. How to encode record sets??  
  
 +
Proposal: ?
  
 
=== How to encode services? ===
 
=== How to encode services? ===
Zeile 63: Zeile 66:
 
In order to not confuse people too much who believe, WMS is a service on its own, and to simplify harvesing of WMS I propose the following:
 
In order to not confuse people too much who believe, WMS is a service on its own, and to simplify harvesing of WMS I propose the following:
  
  dataset record: A record of dc:type=dataset and  
+
  Dataset record: A record of dc:type=dataset and  
 
  Service record: Another record of dc:type=service with dct:references=<identifier-of-dataset>.  
 
  Service record: Another record of dc:type=service with dct:references=<identifier-of-dataset>.  
  
 
dct:references is part of the dc:relation subgroup. Here, for example, a WMS URL would be encoded in dc:identifier of the service record.
 
dct:references is part of the dc:relation subgroup. Here, for example, a WMS URL would be encoded in dc:identifier of the service record.

Version vom 4. Oktober 2007, 13:04 Uhr

'Catalog Services for the Web' from OGC.

See also OAI-PMH and especially HowTo OAI-PMH for harvesting geo-metadata.

Specifications and software:

  • OGC-CSW 2.0.1, OGC Catalogue Services Specification, version 2.0.1 OGC 04-021r3.
  • GeoNetwork opensource v2.1 (GN) the Reference Implementation of CSW.

The following OGC specifications are also relevant for CSW (!):

  • OpenGIS Web Services Common Specification, version 1.0.0 OGC 05-008c1
  • Filter Encoding Implementation Specification, version 1.1.0 OGC 04-095
  • Geographic information -- Geography Markup Language OGC 03-105r1

Remarks

CSW is not the only catalog specification from OGC. There is a competing specification called 'ebRIM Profile' (!!!) :-O.

Harvesting is not yet implemented in GeoNetwork (GN) - the reference implementation (!!!). Question from the GeoNetwork-devel mailing list: "Why the CSW harvesting compliant with the OGC spec. is not implemented in GN 2.1". Answer (26.09.2007 14:07): " The CSW harvesting operation has a not well defined sematics and is not flexible enough to allow a good harvesting. The specs are continually changing making its usage useless. I'm finishing to implement the OAI-PMH harvesting protocol and, IMHO, it outperforms CSW harvesting on all aspects.".

The following is from OCG's "Catalogue Service Implementation Specification", 2.0.2 (OGC 07-006r1, chap. 6.3.3) and from http://schemas.opengis.net/csw/2.0.2/examples/:

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <csw:Record
    xmlns:csw="http://www.opengis.net/cat/csw/2.0.2" 
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:dct="http://purl.org/dc/terms/"
    xmlns:ows="http://www.opengis.net/ows"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.opengis.net/cat/csw/2.0.2 ../../../csw/2.0.2/record.xsd">
   <dc:creator>U.S. Geological Survey</dc:creator>
   <dc:contributor>State of Texas</dc:contributor>
   <dc:publisher>U.S. Geological Survey</dc:publisher>
   <dc:subject>Elevation, Hypsography, and Contours</dc:subject>
   <dc:subject>elevation</dc:subject>
   <dct:abstract>Elevation data collected for the National Elevation Dataset (NED) based on 30m horizontal and 15m vertical accuracy.</dct:abstract>
   <dc:identifier>ac522ef2-89a6-11db-91b1-7eea55d89593</dc:identifier>
   <dc:relation>OfferedBy</dc:relation>
   <dc:source>dd1b2ce7-0722-4642-8cd4-6f885f132777</dc:source>
   <dc:rights>Copyright © 2004, State of Texas</dc:rights>
   <dc:type>Service</dc:type>
   <dc:title>National Elevation Mapping Service for Texas</dc:title>
   <dct:modified>2004-03-01</dct:modified>
   <dc:language>en</dc:language>
   <ows:BoundingBox>
     <ows:LowerCorner>-108.44 28.229</ows:LowerCorner>
     <ows:UpperCorner>-96.223 34.353</ows:UpperCorner>
   </ows:BoundingBox>
 </csw:Record>

How to encode WGS84 Bounding Box?

The example in 10.2.5.3.2 "Full record" shows element ows:WGS84BoundingBox (instead of ows:BoundingBox) and the text in 10.2.5.3.3 "Summary Response Record" mentions "dct:spatial" for the encoding. Then, "OGC's Cataloguing of ISO Metadata (CIM) using the ebRIM profile of CS-W (0.1.7)" mentions again dct:spatial !???

Proposal: ows:BoundingBox or dct:spatial (both with CRS=WGS84 as mandatory/default)

How to encode record sets?

csw:Record is a single instance. How to encode record sets??

Proposal: ?

How to encode services?

Services can be divided into WxS being "Data Access Points" to datasets and to services on their own being Processing Services (WPS), like Coordinate Transform, which don't have any specifically related dataset.

In order to not confuse people too much who believe, WMS is a service on its own, and to simplify harvesing of WMS I propose the following:

Dataset record: A record of dc:type=dataset and 
Service record: Another record of dc:type=service with dct:references=<identifier-of-dataset>. 

dct:references is part of the dc:relation subgroup. Here, for example, a WMS URL would be encoded in dc:identifier of the service record.