What is the GeoNetwork target we are aiming at?
This document focuses on future development paths, not current capabilities. NGDC is directly involved with some of these, and others we are simply aware of via the open source community.
Here are some development projects planned for Geonetwork. These are in various states of progress, anywhere from a simple proposal to active development to nearly ready for release.
- 1 Remote Sensing Metadata Support (ISO 19115-2)
- 2 Service Metadata Support (ISO 19119)
- 3 Feature Catalog Metadata Support (ISO 19110)
- 4 Spatial capabilities
- 5 XML database capabilities
- 6 Component handling
- 7 Keyword/Thesaurus/Vocabulary handling
- 8 Simplified Editing (microinterfaces)
- 9 Display of significant whitespace within metadata elements
- 10 Search improvements
- 11 Element level permissions
- 12 ebRIM Registry support
Remote Sensing Metadata Support (ISO 19115-2)
To describe imagery and gridded data, properties of the measuring equipment, numerical methods and computational procedures. A relatively simple development process to provide an XML schema to Geonetwork for this. Since the GUI is driven by the schema, no new coding is required. At NGDC, we have already added support for the comparable FGDC RSE standard, and we expect supporting ISO will be nearly as simple.
We have added support for iso-19115-2 schema in the local Geonetwork version (Jetty/McKoi). We are testing and expect to port these changes to the production version (Tomcat/Oracle) soon. The main required change are listed below.
1) Add the gmi namespace directory to the schema directory
2) Add an xsi:import to schema.xsd for the gmi namespace
3) Set the root element to MI_Metadata. This changes is required in multiple files
Service Metadata Support (ISO 19119)
It is critical that we be able to manage metadata for geographic information services. The XML Schema for 19119 is already available in the out-of-the-box version of Geonetwork as an extension of the 19139 schema.
A GeoNetwork Proposal is in place to integrate the services metadata with OGC:GetCapabilities. The requirements are very thoroughly specified, but it appears the implementation is incomplete.
The integration of OGC and ISO metadata is an important part of the general metadata translation services that we need to develop. The contents of the capabilities documents are very similar to CF metadata which is another dialect that needs to be included.
Feature Catalog Metadata Support (ISO 19110)
To specify feature types, attributes and values metadata for geographic information. This is reported as nearly ready for release on the Geonetwork developer wiki:
Spatial operations (including time ranges as well as lat/lon) are integral to the management and integration of geospatial metadata. Geonetwork supported only simple bounding box searches, which are nearly useless for many real datasets in NOAA (e.g. a US coastal dataset seems to have data in Kansas!).
Spatial databases (Oracle Spatial, PostGIS, ...) provide support for spatial objects and a variety of operators. Just last week, Geonetwork 2.4.1 was released with spatial searches using Lucene and standard shape files. We don't know yet how well this works, but it may have saved us considerable development effort ;-)
- Proposal for the polygon editor for version 2.5
Some preliminary spatial enabling tasks for Oracle spatial data types have been completed.
1) In the Regions table, fields have been added to store the region bounding box and the region feature as oracle spatial data types. These fields have been populated
2) The database schema has been expanded to provide support for multiple geographic and temporal metadata extents. This expansion was modeled after the ISO 19139 DQ_DataQuality Object. A table to store the geographic extents as oracle spatial data types was created and populated. A second table for storing the temporal extents was created and linked to the geographic extent table. A function to populate these table upon metadata insert still needs to be implemented.
XML database capabilities
The current version of Geonetwork uses a standard RDBMS for persistence, giving a lot of choice of installation options: McKoi (built-in), mySQL, Oracle, PostGres and more. The database schema stores the metadata XML in a single blob, with some additional and derived information (e.g. owner, mod time, UUID) in other tables and fields. Access to the individual metadata fields is via Java DOM or XSLT after reading the entire blob. We would like to experiments with databases with XML capabilities (Oracle, PostGres, eXist) to determine if there are performance or functionality advantages. These tables are accessed through a parent EX_Extent table. A function still needs to be implemented to populate these table upon metadata insert.
Managing metadata records as a collection of xlink'd components. The current NMMR has supported a number of "component record sets" to ease the development, searching and reuse of common sets of FGDC metadata fields: Contacts, Citations, Online Resources, Instruments, Algorithms, Processes, Platforms, Missions. Geonetwork code contains a skeleton implementation of this idea extended to any arbitrary "sub-template". But much work remains to be done to support this in the database schema, Java code and XSLT.
- Ted Habermann's overview of the concepts and challenges for doing components
- Francois Prunayre's original technical proposal
- Simon Pigot's Editor Enhancements proposal
- Component Use Cases
Currently statically configured in Geonetwork as RDF/SKOS xml files. There is out-of-box vocabulary support for region names already. Each region has bounding coordinates associated with it and alternate labels in other languages.
Can we utilize vocabulary services to be sure we offer the most up to date ontologies?
- External vocabulary services
- NCDDC Enterprise bus?
Simplified Editing (microinterfaces)
Instead of a generic editor based on the entire XML schema, allow customized forms to present a subset of the metadata elements of a standard in the order more appropriate to different authoring use cases. A GeoNetwork implementation using Orbeon XForms is available from the BlueNet MEST project.
Display of significant whitespace within metadata elements
Metadata authors often include some simple "whitespace" formatting within the text of a single metadata element, such as paragraphs, lists, and tables. General purpose metadata editors and viewers tend to ignore this whitespace, allowing a web browser to interpret it as HTML, which makes it unreadable to end users.
(Need example, eg Abstract...)
Element level permissions
Apply group permissions to metadata elements (not just records). E.g. Station metadata where lat/lon, etc. are fair game, while contact info might be limited to owner.
ebRIM Registry support
This is to implement a CSW service that provides ISO 19139 metadata as ebRIM objects. Very thoroughly specified; don't know the progress on this. It's targeted at Geonetwork 3.0.