Dear Geonetwork developers, please find a patch for SRU support in GN attached to the SRU proposal on the trac (http://trac.osgeo.org/geonetwork/wiki/z3950_sru) In order to activate it, apply the (eclipse) patch to the trunk and add the libraries listed in (libs.txt) to WEB-INF/lib. In case you dont want to compile yourself, you find a zip file containing these libraries on the WMO webpages (hope this is sufficient so as to ascertain the trustworthy origin) http://www.wmo.int/pages/prog/www/WIS/libs.zip I can also provide access to a pre-compiled version should there by interest. A few comments on the implementation. I have put most changes into the package org.wmo.geonet, although some changes were necessary in the rest of the package structure. The new package is mostly for clarity of the patch and can be changed upon integration. The SRU gateway is implemented as jeeves service and can be reached at http://example.com/geonetwork/srv/en/portal.sru?<SRUQUERYstring> . Only publicly accessible metadata is searchable, as was already the case with the classical Z39.50 interface. SRU is only active if the Z39.50 interface is enabled (could be changed easily when a new config option is added). There is no possibility to select the catalogue which is to be searched via the URL (portal.sru/mycatalogue?<SRUQUERY>), since this would require an additional "/" after the portal.sru in the URL, and there seems to be no way to implement this in jeeves. The possibility to select the catalogue is not required though and a default (GN local) can safely be assumed according to the standard. The SRU implementation requires an update to jzkit3 (from version 1 before), mostly because of the caching and improved configuration. I used the improved configuration features to configure the usage of a "geo" attribute set, vastly improving the ISO23950 capabilities of GN. The list of attributes was elaborated with the help of the ISO23950 community, and is mapped to corresponding lucene indices. Strict adherence to this profile can be configured via the jzkit configuration files which I put into WEB-INF/classes (have to be in the classpath). (I will document how to use them). We would like to encourage discussion of the supported attributes and their mappings to lucene indices. Please find a document listing the mappings attached to this mail and the trac. (SRUattributes_1x.pdf) There were some concerns about breaking the remote Z39.50 implementation of proprietary GN extensions, like BLUENetMEST. I downloaded them and made sure that the new implementation is easy to integrate. Currently there are two "interfaces" to the remote search. Triggering a search, and getting a list of (remote) searchable repositories. With the new implementation launching a remote search works as it used to work before. In order to get the list of searchable repositories, I provided a helper class which returns names and connection strings (used to indicate which remote repositories to search in a request). This replaces the old mechanism of including the repositories.xml, which has been moved to a new format. For testing I included two operations (testListRemoteRepositories, testRemoteSearch) into the SRU gateway (SRUSearch.java) which simulate how the "interfaces" are accessed and can serve as an example on how to use the remote search. (the SRU does not (but could) do a remote search) The implementation is currently being tested by the German,Korean and Chinese weather-services, as we plan to use geonetwork as part of a global distributed meta-data catalogue (WIS). The (XML) format in which SRU requests are returned can be changed in xsl/portal-srusearch.xsl. There might be some discussion whether the metadata files should be returned as XML or CDATA and which namespaces should be used for the reply, and we would welcome suggestions of the community. The patch being a medium to major change, I would hope that it can still be considered as a feature for 2.5, since we would like to make (and continue making) a contribution to the GN community which has provided us with an essential tool for WMOs WIS initiative. Please dont hesitate to criticise this, I'm sure there are many shortcomings, this work is meant to be understood as a proposal and I'm happy to address concerns of the community. Thanks also go to Ian Ibbotson the developer of JZkit for help and accepting patches, who received a separate copy of this email. wow, this was a long one.. directly correlated to the amount of pain in the patch I guess (-; best regards Timo -- Timo Pröscholdt Program Officer, WMO Information System (WIS) Observing and Information Systems Department World Meteorological Organization Tel: +41 22 730 81 76 Cell: +41 77 40 63 554 e-mail: tproescholdt@...
Sign up for the SourceForge newsletter:No, thanks