Changes between Version 90 and Version 91 of Bolsena2010

Timestamp:

Mar 24, 2011, 10:08:49 AM (13 years ago)

Author:

simonp

Comment:

--

Bolsena2010

@@ -56 +56 @@
  || 25 || ||Validation enhancement||XSD and Schematron Validators return errors that are meaningless to most users. Ability to customise the error messages easily would be useful. Action: Code containing XSD validation messages needs to be modified to include alternative or additional messages to those already in use. Schematron diagnostics specified in rules should be made more useful to users.  setErrorHandler already in use - could me modded to support more meaningful messages? Francois has updated schematron to schematron validation and reporting language.|| heikki: 1 || Improve XSD error reporting - functions to do this have been committed to 2.7 - see ticket #441  ||
  || 26 || ||Documentation ||!GeoNetwork requires a generic capability for element help, code list choices and suggestions to be linked to metadata guidelines provided with profiles/standards. Action: !GeoNetwork to call documentation components from external sources (e.g. mouse over tool tips from profile/standard and code list documentation). || Partially done in NGR by Jose || On going ||
- || 27 || || Metadata categories||!GeoNetwork categories are not related to metadata content – should be configurable from content. Action: !GeoNetwork should  be able to configure dynamic categories from a Lucene field. Eg. An administrator could create category names as unique values of the Lucene field name purpose (which might be mapped to gmd:purpose for ISO) – records would belong to the category described by purpose cf. also discussion on dynamic categories ie. categories that are placeholders for a saved search. || heikki: 4 || Could be achieve in the index-fields mechanism ||
+ || 27 || || Metadata categories||!GeoNetwork categories are not related to metadata content – should be configurable from content. Action: !GeoNetwork should  be able to configure dynamic categories from a Lucene field. Eg. An administrator could create category names as unique values of the Lucene field name purpose (which might be mapped to gmd:purpose for ISO) – records would belong to the category described by purpose cf. also discussion on dynamic categories ie. categories that are placeholders for a saved search. || heikki: 4 || Categores are local to the GeoNetwork instance. This could be achieved within the index-fields XSLT mechanism. ||
  || 28 || ||Tag cloud || GeoNetwork currently does not manage its own tag cloud / Folksonomy. Action: !GeoNetwork could optionally manage these things internally rather than using a third party social networking site. [http://trac.osgeo.org/geonetwork/ticket/96 Ticket 96 suggests a way of doing this]|| heikki: 4 || Good idea ! ||
- || 29 || ||Harvester / Network-crawling ||Network-crawling for geo-resources. Action: GeoNetwork needs to continue to be aware of and exploit initiatives for automatic harvesting of metadata from geo-resources. Eg. Metadata extraction tools such as the Talend Spatial Data Integrator suite etc || heikki: 3 | jose: major || ||
- || 30 || ||Metadata identifier ||!GeoNetwork lacks the ability to consistently reproduce a unique identifier for the same geo resource (e.g. same dataset stored in two different locations) and/or use persistent identifier services. This is somewhere along the range from "easy enough" to "very difficult", need to spell out the precise details of the set of features you have in mind. Action: GeoNetwork needs to be able to generate, store and use metadata identifiers (eg, gmd:fileIdentifier) as well as data identifiers using the current stand alone UUID, but also (for data objects) MD5 (including what the checksum was generated from) and identifiers from external persistent identifier services (It should be possible to obtain persistent identifiers for both metadata and data from external persistent identifier services). || heikki: 4 || ||
- || 31 || ||Interoperability / resources discovery||Better inter-application interoperability. GeoNetwork needs to rethink the interoperability with the emerging FOSS such as the way that OpenLayers is designing / redeveloping its interface. e.g. use of GeoExt; e.g. GeoNetwork needs to provide simple mechanisms to allow discovered resources to be exploited and utilised in complementary open source software; e.g. drag-and-drop discovered resources into OpenLayers or GeoServer. Action: Better intra-application interoperability. GeoNetwork needs to coordinate the discovery of resources with the publication of those same resources in FOSS such as GeoServer. || heikki: 2 | jose: major || ||
- || 32 || ||Data management ||!GeoNetwork assumes resources that are tagged as data for download in gmd:protocol are local. Action: GeoNetwork needs to allow for the fact that data tagged as data for download may not be local. || heikki: 1 || Change protocol to local-download ? ||
+ || 29 || ||Harvester / Network-crawling ||Network-crawling for geo-resources. Action: GeoNetwork needs to continue to be aware of and exploit initiatives for automatic harvesting of metadata from geo-resources. Eg. Metadata extraction tools such as the Talend Spatial Data Integrator suite etc || heikki: 3 | jose: major || Documenting services that could be used by extraction tools and providing harvesters such as the OGC WFS Feature harvester are steps in this ongoing task. ||
+ || 30 || ||Metadata identifier ||!GeoNetwork lacks the ability to consistently reproduce a unique identifier for the same geo resource (e.g. same dataset stored in two different locations) and/or use persistent identifier services. This is somewhere along the range from "easy enough" to "very difficult", need to spell out the precise details of the set of features you have in mind. Action: GeoNetwork needs to be able to generate, store and use metadata identifiers (eg, gmd:fileIdentifier) as well as data identifiers using the current stand alone UUID, but also (for data objects) MD5 (including what the checksum was generated from) and identifiers from external persistent identifier services (It should be possible to obtain persistent identifiers for both metadata and data from external persistent identifier services). || heikki: 4 || Accepted but no progress yet. ||
+ || 31 || ||Interoperability / resources discovery||Better inter-application interoperability. GeoNetwork needs to rethink the interoperability with the emerging FOSS such as the way that OpenLayers is designing / redeveloping its interface. e.g. use of GeoExt; e.g. GeoNetwork needs to provide simple mechanisms to allow discovered resources to be exploited and utilised in complementary open source software; e.g. drag-and-drop discovered resources into OpenLayers or GeoServer. Action: Better intra-application interoperability. GeoNetwork needs to coordinate the discovery of resources with the publication of those same resources in FOSS such as GeoServer. || heikki: 2 | jose: major || Two issues: the user interface is most likely to be addressed through projects such as the javascript guiwidgets sandbox. Automated publishing of metadata and datasets to GeoServer has been implemented and committed to 2.7 (see ticket #159)  ||
+ || 32 || ||Data management ||!GeoNetwork assumes resources that are tagged as data for download in gmd:protocol are local. Action: GeoNetwork needs to allow for the fact that data tagged as data for download may not be local. || heikki: 1 || You can switch off GeoNetwork interpretation of gmd:protocol in 2.7 but further refinement is required. ||
  || 33 || ||Remote search||Remote search across a number of sites returns a pre-selected number of hits from all remote sites (pre-selected number is a search option) – it should return these hits from each site. Action: Presentation of pre-selected number of hits from each remote site – may require more delving into JZKit. || heikki: 3 || Is it possible to make it abstract in order to extend to other protocols ? ||
- || 34 || ||Remote search||Presentation of returned hits from remote sites may be very slow because search is limited by the speed of the slowest site. Action: Presentations of first returned hits from first responding remote site should not have to wait on the slowest site – may require more delving into JZKit. || heikki: 3 ||  ||
+ || 34 || ||Remote search||Presentation of returned hits from remote sites may be very slow because search is limited by the speed of the slowest site. Action: Presentations of first returned hits from first responding remote site should not have to wait on the slowest site – may require more delving into JZKit. || heikki: 3 || This 'feature' is not present in JZKit3 and remote search has been restored in version 2.7 (see [[wiki:RemoteSearchForm%2BTabbedSearchForms]]. ||
  || 35 || ||Configuration||There are too many configuration files in too many places eg. repositories.xml.tem and not all configuration options are supported by the existing admin interfaces. Action: Continue to consolidate configuration options in the system configuration interface. || heikki: 2 || eg. Z39.50 repositories ||
  || 36 || ||Web map client|| There is no documentation for the implementation of alternative web map clients to Intermap and this makes it appear that the process is far harder than it actually is. Given the enthusiasm for an OpenLayers-based interface, what "interface" there currently is will probably soon be rapidly-evolving - if not replaced completely. Action: Document the interface that GeoNetwork uses to call a web map client so that sites can substitute their own.|| heikki: 1 | jose: critical || ||