= Collection of changes originating from [http://nationaalgeoregister.nl Nationaal Georegister] = || '''Date''' || 2009/08/24 || || '''Contact(s)''' || [http://wiki.osgeo.org/wiki/User:Heikki Heikki Doeleman] || || '''Last edited''' || [[Timestamp]] || || '''Status''' || draft || || '''Assigned to release''' || 2.5 || || '''Resources''' || The work is done in the NGR project || == Overview == This proposal combines various changes originally implemented in a !GeoNetwork fork in the project [http://nationaalgeoregister.nl Nationaal Georegister]. All changes are already implemented and visible (if applicable) in [http://nationaalgeoregister.nl Nationaal Georegister]. The changes are otherwise unrelated, but they are not very big and I think it's more efficient to bundle them in this single proposal. The proposed changes are: '''1.''' Performance improvement to search --> moved to [http://trac.osgeo.org/geonetwork/wiki/PerformanceImprovementInSearch this proposal][[BR]] '''2.''' Persistent validation results[[BR]] '''3.''' Organizations --> moved to [http://trac.osgeo.org/geonetwork/wiki/Organization this proposal][[BR]] '''4.''' Service monitoring[[BR]] '''5.''' Tabbed view of Metadata[[BR]] '''6.''' Local rating[[BR]] '''7.''' Relevance as a percentage[[BR]] '''8.''' Hyperlink display[[BR]] Another change proposal (INSPIRE support) will be separately described by [http://wiki.osgeo.org/wiki/User:Fxp Francois] and [http://wiki.osgeo.org/wiki/User:Heikki Heikki]. Yet another change proposal (replacing !InterMap by !OpenLayers) is already described [http://trac.osgeo.org/geonetwork/wiki/ReplacingIntermap here]. === Proposal Type === * '''Type''': GUI Change, Core Change, Module Change * '''App''': !GeoNetwork * '''Module''': Search engine, Data Manager, Group Manager, Rating === Links === * '''Email discussions''': on geonetwork-devel: [http://n2.nabble.com/Proposals-to-include-NGR-functionality-to-GeoNetwork-trunk-td3365623.html#a3365623 "Proposals to include NGR functionality to GeoNetwork trunk"] === Voting History === Although presented together in one proposal, all items will be put up for voting separately. * None as yet ---- == Motivations == The motivations for these changes are : '''1.''' A better performance is preferred[[BR]] '''2.''' More informative search results; motivate metadata providers to produce good quality metadata[[BR]] '''3.''' The notion of Organization is lacking in !GeoNetwork's domain model[[BR]] '''4.''' More informative search results; motivate service providers to keep them up[[BR]] '''5.''' Better usability[[BR]] '''6.''' Local user feedback[[BR]] '''7.''' Better usability[[BR]] '''8.''' Better usability[[BR]] == Proposal == '''1. Performance improvement to search'''[[BR]] Moved to [http://trac.osgeo.org/geonetwork/wiki/PerformanceImprovementInSearch this proposal] [[BR]][[BR]] '''2. Persistent validation results'''[[BR]] This proposal is to run validation (XSD+Schematron) every time a metadata is inserted or changed. The result of validation is persisted in the DB. Persistence is required to show the validation status directly (or maybe query on it later, but this is not implemented at this time). This way we can always show the current "validation status" of metadata, e.g. in the search results page.[[BR]][[BR]] Validation status is either "valid", "not valid", or "not determined". This last status is the initial validation status when validation has not yet run. Currently the statuses "valid" and "not valid" are shown in the search results. Showing "not determined" as well is a minor change.[[BR]][[BR]] A validation report is also stored in the DB. It contains any XSD or schematron validation messages, a reference to the schematron file that was used, a timestamp, and if applicable a message saying that the metadata profile could not be determined. There is basic support for multiple metadata profiles, using different Schematron rules for different profiles.[[BR]][[BR]] An icon indicating the validation status, that links to the validation report if the metadata is not valid, can be included in the search results page an/or in the show metadata page. This indicates something about the quality of the metadata to users, and may encourage metadata providers to produce more valid metadata.[[BR]][[BR]] [[Image(ngr.validationresults.searchresults.png)]] [[BR]][[BR]] '''3. Organizations'''[[BR]] Moved to [http://trac.osgeo.org/geonetwork/wiki/Organization this proposal] [[BR]][[BR]] '''4. Service monitoring'''[[BR]] In this proposal, services (WxS, current implementation is for WMS 1.1.1 and WFS 1.1.0) that are advertised in the metadata are continuously monitored to see if they're up. The current implementation in [http://nationaalgeoregister.nl NGR] just pings them. Validity of the response is checked by checking the response format, that is: for WMS an image and for WFS XML. More sophisticated checking is envisioned. The results are displayed as a percentage that represents the uptime over a certain period of time. This percentage is displayed in the search results page if the service mentioned in the metadata is monitored, see below. [[Image(ngr.validationresults.searchresults.png)]] [[BR]][[BR]] The frequency of the monitoring calls and the period over which the percentage is calculated are configurable in the Admin interface.[[BR]][[BR]] [[Image(ngr.servicemonitoring.config.png)]] [[BR]][[BR]] The uptime results for services are also calculated for all the services provided by one organization. On the Organizations page, this is displayed. [[BR]][[BR]] '''5. Tabbed view of Metadata'''[[BR]] Metadata can be very big, resulting in a display where it's not easy to find what you're looking for and that has not much structure. In [http://nationaalgeoregister.nl NGR] this is tackled by displaying sections of the metadata in separate tabs, creating a much more user-friendly display.[[BR]][[BR]] [[Image(ngr.tabs.metadata.show.png)]][[BR]] TODO compare with BlueNetMEST [[BR]][[BR]] '''6. Local rating'''[[BR]] In !GeoNetwork, users can rate metadata. The user's rating is broadcast to all !GeoNetwork nodes known to the one where the rating happens, and the results are thus shared between nodes. In [http://nationaalgeoregister.nl NGR] this does not happen and the rating is simply kept and calculated on only the user ratings on the GN node itself. This proposal wants to make this "local" rating behaviour an option to standard !GeoNetwork, configurable through the Admin interface. [[BR]][[BR]] '''7. Relevance as a percentage'''[[BR]] In standard !GeoNetwork search results can be ordered by relevance. This is based on the relevance score that the Lucene search engine gives to each item in the search results. However it is not shown to the user what the relevance score for each result *is*.[[BR]] In [http://nationaalgeoregister.nl NGR] the relevance score is displayed with each search result. Because the Lucene score is an unattractive float between 0 and 1, the relevance score is normalized such that the highest score from the search results is set to 100, and all other results' scores are calculated relative to that.[[BR]][[BR]] [[Image(ngr.relevance.percentage.png)]][[BR]] [[BR]][[BR]] '''8. Hyperlink display'''[[BR]] In [http://nationaalgeoregister.nl NGR], when metadata is displayed, any hyperlinks in the text are actually displayed as clickable links. The link types that are recognized are: http, https, ftp, and mailto. [[BR]][[BR]] [[Image(ngr.urls.links.png)]][[BR]] [[BR]][[BR]] === Backwards Compatibility Issues === '''1.''' none[[BR]] '''2.''' a database change is required. SQL script to update existing DBs will be available[[BR]] '''3.''' a database change is required. SQL script to update existing DBs will be available[[BR]] '''4.''' a database change is required. SQL script to update existing DBs will be available[[BR]] '''5.''' none[[BR]] '''6.''' none[[BR]] '''7.''' if implementations use the raw Lucene score for anything, that will be broken (not in standard !GeoNetwork)[[BR]] '''8.''' none[[BR]] == Risks == == Participants == * As above