Changes between Version 27 and Version 28 of Bolsena2010

Timestamp:

04/01/10 21:34:26 (15 years ago)

Author:

simonp

Comment:

--

Bolsena2010

@@ -60 +60 @@
  * 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.
 
- * 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. 
-GA: It is not enough to just provide Lucene field names and the mapping from metadata elements to these Lucene fields for all metadata schemas.  GN also needs to:
-"These Lucene fields must be indexed as default so that any search of these fields will return the appropriate response. This will automatically provide interoperability for the distributed searches.  Which fields are searched can be determined by the interface that is used to allow the user to enter search terms. If a particular field is not to be allowed as searchable by the interface then that field is not provided in the GUI. However, the Lucene indexes must still include that field so that other interfaces can search that field.
-GeoNetwork should use 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.
+ * 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.
 
  * 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.