GeoNetwork target

From NGDCWiki

(Difference between revisions)
Jump to: navigation, search
Current revision (15:06, 30 April 2013) (view source)
m (Replacing page with 'out of date content - see history tab')
 
Line 1: Line 1:
-
[[Category:Metadata]]
+
out of date content - see history tab
-
[[Category:Geonetwork]]
+
-
 
+
-
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.
+
-
 
+
-
== 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<br/>
+
-
2) Add an xsi:import to schema.xsd for the gmi namespace<br/>
+
-
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 [http://trac.osgeo.org/geonetwork/wiki/ISO19119impl 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:
+
-
* [http://trac.osgeo.org/geonetwork/wiki/Iso19110Support ISO19110 support]
+
-
 
+
-
== Spatial capabilities ==
+
-
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 [http://trac.osgeo.org/geonetwork/wiki/GeoEditorViewer polygon editor for version 2.5]<br/>
+
-
 
+
-
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<br/>
+
-
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.
+
-
 
+
-
== Component handling ==
+
-
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.
+
-
* [http://trac.osgeo.org/geonetwork/wiki/ComponentsAndComposites Ted Habermann's overview of the concepts and challenges for doing components]
+
-
* [http://trac.osgeo.org/geonetwork/wiki/XLinkedFragments Francois Prunayre's original technical proposal]
+
-
* [http://trac.osgeo.org/geonetwork/wiki/EditorEnhancements Simon Pigot's Editor Enhancements proposal]
+
-
* [https://intranet.ngdc.noaa.gov/wiki/index.php?title=Geonetwork_Components Component Use Cases]
+
-
 
+
-
== Keyword/Thesaurus/Vocabulary handling ==
+
-
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?
+
-
 
+
-
* [http://trac.osgeo.org/geonetwork/wiki/thesaurus Thesaurus and keyword management proposal]
+
-
; External vocabulary services
+
-
* [http://gcmd.nasa.gov/Resources/valids/archives/keyword_list.html NASA/GCMD]
+
-
* [http://cf-pcmdi.llnl.gov/documents/cf-standard-names CF Standard Names]
+
-
* [http://ncicb.nci.nih.gov/NCICB//infrastructure/cacore_overview/vocabulary NCI EVS]
+
-
* [http://www.bodc.ac.uk/products/web_services/vocab/ NERC DataGrid vocabulary server]
+
-
 
+
-
* 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 [http://www.bluenet.org.au/MEST_intro.html BlueNet MEST project].
+
-
* [http://trac.osgeo.org/geonetwork/wiki/UserCentricGUI User Centric GUI proposal]
+
-
 
+
-
== 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...)
+
-
 
+
-
== Search improvements ==
+
-
* [http://trac.osgeo.org/geonetwork/wiki/NarrowYourSearchWidget Search narrowing and tag clouds proposal]
+
-
* [http://trac.osgeo.org/geonetwork/wiki/Statistics Search logging and analysis proposal]
+
-
 
+
-
== 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.
+
-
 
+
-
* [http://trac.osgeo.org/geonetwork/wiki/HiddenElements Hidden Elements proposal]
+
-
 
+
-
== 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.
+
-
 
+
-
* [http://trac.osgeo.org/geonetwork/wiki/ebxml Geonetwork ebXML interface proposal]
+
-
* Some background on [http://docs.oasis-open.org/regrep/v3.0/specs/regrep-rim-3.0-os.pdf ebRIM] from OASIS
+

Current revision

out of date content - see history tab

Personal tools