Composed Metadata Records

Date	2009/09/01
Contact(s)	Simon Pigot
Last edited	Timestamp
Status	draft, being discussed, in progress, early stage complete
Assigned to release	2.5
Resources	Available for first stage

Overview

For GeoNetwork to become part of an institutional metadata and data management fabric, it must be able to compose metadata from content held in databases external to GeoNetwork. This proposal would add two new components to the kernel and harvester modules of GeoNetwork:

• WFS fragment harvester - a harvester that can import metadata fragments (also known as subtemplates) from an external database with a WFS interface
• XLink resolver and cache - metadata records can then be composed from a skeleton with links to fragments of metadata

Proposal Type

• Type: Core Change
• App: GeoNetwork
• Module: Harvester, Kernel, Data Manager, Jeeves

Links

• Subtemplates: Metadata fragments are equivalent to subtemplates (which were only partially implemented in GeoNetwork). Subtemplates appear to have been an extension of the template concept in GeoNetwork. Templates are complete metadata records with some elements filled in. A user can clone such a record for use in the editor as a template. At this stage all connection between the template and the cloned record is broken ie. changes to the template are not visible in the cloned record and vice versa. Subtemplates (as they were partially implemented in GeoNetwork) took the template concept down to the level of individual elements in the metadata record. So for example, contact information would be implemented This proposal intends to implement subtemplates as fragments of metadata harvested from an external database.
• Composed, Componentized and Relational Metadata: The idea of composed or componentized metadata and the term itself, appears to be common to many discussions on the net eg. (albeit obliquely) ​http://eww.jot.fm/issues/issue_2007_11/column6.pdf. Another term with similar concepts is "relational" metadata (!LISASoft metadata report). Although there has been discussion in and around these topics and even some implementation of fragments in GeoNetwork as subtemplates, this proposal appears to be the first to suggest the mechanisms for implementing these concepts in GeoNetwork using fragments harvested from a database with a WFS interface.
• Email discussions:
• Other wiki discussions:

Voting History

• Not voted on as yet.

---

Motivations

The motivation for this proposal comes from the need to fit GeoNetwork into organisations that already manage metadata in a number of different databases external to GeoNetwork.

Proposal

WFS fragment harvester - this is a harvester that accepts (along with the usual harvester parameters) the

Future work would add:

• Transaction support - sometimes it makes sense for a fragment to be edited and saved back into the external database. WFS-T support would be used to provide this facility.
• Support for metadata fragments through GeoServer community schemas, including how to configure the GeoServer WFS embedded with GeoNetwork to provide the WFS interface.
• URN resolver to provide a level of indirection that can be used to cope with changing URLs and ensure referential integrity. Metadata fragments are linked into records using XLinks. XLinks can use URLs or URNs in the link attribute (xlink:href). URNs are intended to provide a permanent A service that provides the ability to register a urn and associated URL, and lookup a URL given a URN, would allow the implementation to use URNs in place of URLs, thus providing a measure of control over broken links/missing content which can occur if we were to use URLs.

Backwards Compatibility Issues

Metadata records as traditionally handled by GeoNetwork should not be affected by the addition of this feature.

Effects on harvesting: Composed metadata records can have their XLinks resolved before they are harvested as a harvester usually updates the set of records harvested from a remote site on a regular basis. If there was a requirement for composed metadata records to be harvested with unresolved XLinks then an option could be added to the harvester to prevent XLink resolution before harvesting.

Effects on export (eg. MEF): Composed metadata records exported as MEF files would normally have their XLinks resolved before export. If there was a requirement for composed metadata records to be exported with unresolved XLinks then an option could be added to the MEF export service to prevent XLink resolution before export.

XLinks and metadata records composed from xlink'd fragments can be made optional through the use of a system configuration option.

Risks

Participants

• Simon Pigot, IMOS/eMii
• Geocat.ch implementors - have similar requirements including transaction support for metadata fragments
• Other XLink implementors: Jesse, Francois, Patrick
• URN resolver and GeoServer community schema support: AuScope/Spatial Information Services Stack (SISS) team
• "Relational" metadata - !LISASoft developers?
• Others?