Following is how we modified the Views Bonus Pack module for Drupal 6 to generate ISO 19139 XML metadata files for the USGIN Document Repository. This hack can be be used to relatively easily generate other XML metadata (FGDC, CSW records) or most complex XML. Ideally, this hack will evolve into a separate module. If you are interested or have questions, please participate in the Generate ISO 19139 metadata record XML files Views Bonus Pack issue thread.

Overview

The goal is to generate minimum ISO 19139 dataset metadata XML files (that conform to the USGIN profile) from the core and CCK fields used in the repository's Collection (ct_collection) and Document-like Information Object (DLIO, ct_dlio) content types.

Files: 

Patch for Views Bonus Pack 6.x-dev (CVS trunk)

Following is a break-down of the Drupal 6 modules used in the USGIN Document Repository site (you may want to familiarize yourself with general Drupal concepts):

We just finished putting together a Drupal based Document Repository site (http://repository.usgin.org) as a testbed and as an alternative for other Repository systems such as DSpace. The goal was to fulfilled the following requirements in a ca. 2 week development period (200+ man hours):

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

GeoNetwork offers a harvest service that, among other, follows a OGC WMS or WFS GetCapabilities URL and transforms the response into an ISO 19139 metadata record. Bear in mind that the resulting ISO metadata record is only as good as the GetCapabilities response and that the metadata can never be entirely ISO 19139 conformant without dummy values due to limitations of the OGC GetCapabilities schema.

GeoNetwork offers a handy user interface to add those "GeoNetwork Harvesting Nodes" and also exposes their functionality through a even handier XML service. See chapter 19.3 on "Harvesting Services" of the GeoNetwork opensource V 2.4 The Complete Manual. Following are my notes on creating an OGC harvesting node through GeoNetwork's harvesting service.

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:

It appears that the GeoNetwork WMS harvest selects an incorrect codeListValue for a service metadata record's srv:DCPList (Distributed Computing Platform). Currently, it enters HTTP-GET and HTTP-POST. However, there is a bit of confusion within GeoNetwork and among standards and profiles. Specifically, one could interpret a conflict between DCP in a service's GetCapabilities (OGC) and a service's metadata record (ISO):

In order to create metadata for both static datasets and dynamic, online services and for use with CSW, the OGC created an xml schema that merges the schema for ISO19115 (dataset metadata) and ISO19119 (service metadata) (see secion D.1.5, page 105 in OGC 07-045). The way that was accomplished was by creating a schema located at http://schemas.opengis.net/csw/2.0.2/profiles/apiso/1.0.0/apiso.xsd. The contents of that schema are quite simple -- it looks like this:

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:

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