Changes between Version 56 and Version 57 of Bolsena2010


Ignore:
Timestamp:
05/18/10 15:20:47 (15 years ago)
Author:
mcoudert
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Bolsena2010

    v56 v57  
    4343 || 21 || || Metadata versioning  || !GeoNetwork needs some form of version control to track changes made to a metadata record over time. Action/Justification: This can be done inside the database without needing to externalise the metadata records. That way you can index and search on the old versions as well, if desired. Alternatively it could be done externally using perhaps a Java interface to subversion or through an interface to existing enterprise document management systems or perhaps using a different database approach for the documents eg. CouchDB. See also [http://geoserver.org/display/GEOS/Versioning+WFS this] approach to versioning WFS content?|| ||
    4444 || 22 || || Community || Some aspects of project planning for !GeoNetwork are not visible to those outside the project steering committee. Action: Continue to adopt and implement OSGeo best practise (e.g. GeoServer).|| ||
    45  || 23 || || || || ||
    46  || 24 || || || || ||
    47  || 25 || || || || ||
    48  || 26 || || || || ||
     45 || 23 || ||Documentation / Community ||Documentation for ‘Implementing !GeoNetwork into your organisation’ should be provided. Rather than changing the perspective of the current documentation from "how to" from "it does", perhaps you can have different documentation for different audiences. The “how to” section of the Trac is very useful. Action: As the “how to” section of the OSGeo !GeoNetwork trac site expands, it could be linked into the documentation. || ||
     46 || 24 || ||Index enhancement ||!GeoNetwork’s current Lucene field / index names and the mapping of metadata fields to these Lucene field names are ad hoc. This has the potential to prevent search interoperability between catalogues. Action: !GeoNetwork should use an established mapping such as the geo profile of Z3950 (including attributes, data and relations) to define Lucene field names and the mapping from metadata elements to Lucene fields for all metadata schemas. || ||
     47 || 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.|| ||
     48 || 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). || ||
     49 || 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. || ||
     50 || 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]|| ||
     51 || 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 || ||
     52 || 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). || ||
     53 || 31 || || || || ||
     54 || 32 || || || || ||
     55 || 33 || || || || ||
     56 || 34 || || || || ||
     57
     58
    4959
    5060 * While at it can we change the code so that you can save settings from the GUI even if not all expected settings are present in your database?
    … …  
    5666 * From 16 to XX : Topics extracted from Australia/New Zealand Community GeoNetwork Feedback
    5767
     68
     69
    5870 *
    5971
    … …  
    6173
    6274 *
    63 
    64 
    65 
    66  *
    67 
    68  * Documentation for ‘Implementing !GeoNetwork into your organisation’ should be provided. Rather than changing the perspective of the current documentation from "how to" from "it does", perhaps you can have different documentation for different audiences. The “how to” section of the Trac is very useful. Action: As the “how to” section of the OSGeo !GeoNetwork trac site expands, it could be linked into the documentation.
    69 
    70  * !GeoNetwork’s current Lucene field / index names and the mapping of metadata fields to these Lucene field names are ad hoc. This has the potential to prevent search interoperability between catalogues. Action: !GeoNetwork should use an established mapping such as the geo profile of Z3950 (including attributes, data and relations) to define Lucene field names and the mapping from metadata elements to Lucene fields for all metadata schemas.
    71 
    72  * 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.
    73 
    74 setErrorHandler already in use - could me modded to support more meaningful messages? Francois has updated schematron to schematron validation and reporting language.
    75 
    76  * !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).
    77 
    78  * !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.
    79 
    80  * 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.
    81 
    82 [http://trac.osgeo.org/geonetwork/ticket/96 Ticket 96 suggests a way of doing this]
    83 
    84  * 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
    85 
    86  * !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).
    8775
    8876 * 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.