This post describes a series of Python scripts to convert FGDC XML metadata for WMS and WFS services to ISO 19139 service metadata via GeoNetwork's OGC harvest service. Here are the steps:

1. Extract WMS and WFS GetCapabilities URLs from FGDC XML metadata and write them to a file.
2. Create a GeoNetwork Harvest Node from extracted GetCapabilities URLs and let GeoNetwork's OGC WMS/WFS harvester create ISO 19139 metadata from GetCapabilities response. Note: the resulting ISO 19139 metadata is only as good as the one in the GetCapabilities response. In addition, GetCapabilities responses do not include all fields necessary for minimum ISO 19139 metadata.
3. Copy some FGDC metadata entries (Title, Abstract, etc.) to newly created ISO 19139 metadata.

Our goal is to have working WMS and WFS metadata records in our CSW catalog that can be used to add the described services to analytical software such as ESRI's C-SW Client for ArcGIS Desktop. Following are the reasons why I am currently choosing this convoluted process instead of a direct FGDC to ISO 19139 metadata conversion:

Files: 

MultipartPostHandler.py_.txt

This group will focus upon GeoNetwork setup, configuration, and development. Any questions or comments are welcome!

Following are some resources that can help you learn about GeoNetwork:

We presented the following posters at the 2009 GSA Annual Meeting in Portland, Oregon. Note, the PDF files are large.

• USGIN: Interoperable Geoscience Data Services on the Web - How do we get there? (45MB PDF) by Stephen Richard, Lee Allison, Ryan Clark and Wolfgang Grunberg, Arizona Geological Survey
• Catalog Service for the Web, Implementing Interoperable Services for Discovering Geoscience Resources (46MB PDF) by Wolfgang Grunberg, Stephen Richard and Ryan Clark, Arizona Geological Survey.

 This is an example Python script that showcases GeoNetwork authentication, session handling, and CSW transactions. 

Files: 

gn_csw_transaction_example.py_.txt

Now that we know what kind of CSW services we can pull off, we need to pay more attention to creating and maintaining metadata. Right now, I just do a bunch of ETLs from our in-house data repositories (ArcSDE, Access, Excel, etc.) to CSW Insert Transaction XML files. That method is not user friendly and editing individual metadata records are a pain.

So, here are some CSW metadata editors I am looking at:

Tested with deegree-csw 2.3pre
Read the XSLT file for more information.

Attached is an example XSLT1 script to transform a WMS GetCapabilities 1.1.1 response to a CSW Insert transaction. The script is based on deegree's wms2iso19119.xsl (http://www.deegree.org/).
Note that currently it only supports WMS version 1.1.1 (<WMT_MS_Capabilities>) responses because it chokes on 1.3.0 (<WMS_Capabilities>) responses.

Files: 

etl_wms2csw_v3.py_.txt

Files: 

wms2iso19119_insert_XSLT1_07.xsl

Files: 

wms_getcapabilities_url.txt

... kind of sounds like overkill, but there's reason behind the confusion!

Imagine that you're trying to find some data. In the USGIN scheme, in order to find data you search through CSW services, which are catalogues full of ISO1939 metadata documents. Each of these documents points you to a dataset or service that is somewhere, hopefully online, for you to take a look at. These CSW services are like the card catalogues of the digital era.

Following is a list of some metadata implementation recommendations and profiles I am looking at.

This is a list of our configuration changes too deegree-csw - specifically version 2.3-pre (missing link) with an PostgreSQL backend.

Follow instructions in deegree's documentation

See deegree_csw_2.0.2_documentation_en.pdf. Make sure the document is in a version corresponding to your version of deegree-csw (in this case "deegree Web Catalogue Service v.2.2").

Well .. I couldn't find any difference between CSW, CS-W, and CS/W.