[GeoNetwork-users] [GeoNetwork-devel] Z39.50 remote search

Timo,

I know a little bit about the Z39.50 remote search from a users perspective.

We use the BlueNet MEST version of Geonetwork (latest version at http://anzlicmet.bluenet.utas.edu.au/wiki )
which has a Z3950 client accesssed through the 'remote search' tab.

The remote search page is very similar the advanced search page (tab) and lets users specify terms and servers to be searched using Z3950. The list of servers to be searched can be configured through the 'repositories.xml.tem
file. Note - its only necessary to change this file, to don't need to change 'repositores.xml' as it is auto-generated
from repositories.xml.tem.

On the server side the Z39.50 server is switched on and port number specified on the Admin->Sys. Config
web page.

If you are interested to try this out download a copy of the Bluenet MEST, install on your local PC
and you can do a remote search to any of the servers listed on the remote search page.

HTH,

Andrew

----- Original Message ----- From: "Timo Proescholdt" <timo@anonymised.com>
To: <geonetwork-devel@lists.sourceforge.net>
Sent: Thursday, December 17, 2009 6:10 AM
Subject: [GeoNetwork-devel] Z39.50 remote search

Hi GN developers,

as you know I have been working on the Z39.50 / SRU stuff in the last
weeks, and I'm proud to announce that I implemented a new Z39.50
interface and SRU support via the Jzkit3 library. As soon as I managed
to disentangle my eclipse workspace I will post a diff here for
discussion, for there are a lot of things that could probably only
be decided by the community or more experienced geonetworkers.

The new Z39.50 interface happens to break the Z39.50 remote search
(because it is implemented using the library) and since the new Jzkit
library has no backward-compatibility (neither for interfaces nor
for configuration files) this feature would have to be re-implemented,
too. (which is not a bad idea anyway given the shape of that part of the
code).

I looked at bit into how it is currently implemented and how it would be
done with the new library but I felt that this should maybe be discussed
before.

Does anybody have a clear set of features the Z39.50 client search
should support and how it should be configured?

Currently there is the file "repositories.xml", containing a list of
repositories that are searched when a Z39.50 remote search is triggered.
The expected behaviour is not totally clear to me. First, I dont see
where the remote search can be enabled (I see it in the code of the
portal-search, but not in the actual webinteface). Second, I'm not
100% sure if all the repositories contained therein should be searched,
when a remote search is triggered, or if the user can choose one or more
repositories.

Whatever is contained in the old repositories.xml could be automatically
transformed (even on the fly by XSLT) into the new configuration format,
and it should also be possible to reproduce the old behaviour of the
remote search (if somebody told we what it actually was). (see
attachments for demos of the old and the new config file)
But this seems like a good point in time for me to discuss a bit.

The jzkit3 library supports a search Service with caching and
persistence which is a possibility for dramatic speed improvements.
It should also be possible to expose remote Z39.50 targets as local ones
and (in theory) even to mix results from remote and local sources.
It all depends on what people want.

So if anybody has a good understanding of how the Z39.50 remote search
is currently used and what features users demand I would be grateful if
he or she could share it, so that I have a look at it while unsnarling
the patch.

best regards
Timo

<ServiceDirectory>

<!-- Simple example IR provider that randomly waits up to 10 seconds before returning records and is well behaved -->
<Repository className="org.jzkit.search.provider.SimpleExample.ExampleSearchable"
             code="Test"
             serviceName="Test Repository">
   <Preferences>
     <Preference name="randomDelay">10</Preference>
     <Preference name="behaviour">normal</Preference>
   </Preferences>
   <RecordArchetypes>
     <Archetype name="F">xml:meta:F</Archetype>
     <Archetype name="B">xml:meta:F</Archetype>
   </RecordArchetypes>

   <Collections>
   <Collection code="Test" collectionName="A test collection"/>
   </Collections>

</Repository>

<Repository className="org.jzkit.search.provider.z3950.Z3950Origin"
             code="LC/LIVE"
             servceName="Library of congress live server">
   <Preferences>
     <Preference name="defaultRecordSyntax">xml</Preference>
     <Preference name="defaultElementSetName">f</Preference>
     <Preference name="host">z3950.loc.gov</Preference>
     <Preference name="port">7090</Preference> -->
     <Preference name="smallSetElementSetName">F</Preference>
     <Preference name="charsetEncoding">UTF-8</Preference>
     <Preference name="useReferenceId">negotiate</Preference>
   </Preferences>
   <RecordArchetypes>
     <Archetype name="F">xml:meta:F</Archetype>
     <Archetype name="B">xml:meta:F</Archetype>
   </RecordArchetypes>

   <Collections>
    <Collection code="LC/BOOKS" localId="voyager" collectionName="Library of Congress, Books Collection"/>
   </Collections>

</Repository>

<CollectionPosting code="Test" name="InfoType" value="Test"/>
<CollectionPosting code="LC/BOOKS" name="InfoType" value="Bibliographic"/>

</ServiceDirectory>

<?xml version="1.0" encoding="UTF-8"?>
<RepositoryDirectory>
<!-- Collections and repositories must appear here before instance entries
The collection_dn values are the strings you can actally use in an IRQuery as
values in the collections vector. The searchable object will deal with resolving
that collection-dn into a specific instance of a collection at a repository and
make the appropriate connection using the right database name for that repository.
-->
<TypeMapping type="Z3950" class="com.k_int.z3950.IRClient.Z3950Origin" />
<TypeMapping type="HSS" class="com.k_int.srw.client.SRWSearchable" />
<!--
localhost
-->
<Collection collection_dn="localhost:2100/geonetwork" collection_name="Local GeoNetwork" />
<Collection collection_dn="193.43.36.189:2100/geonetwork" collection_name="Food and Agriculture Organization GeoNetwork (FAO-UN)" />
<!-- The type parameter is used when looking for factories to create instances of
Searchable capable of searching the identified repository -->
<!--
localhost
-->
<Repository repository_dn="localhost:2100/geonetwork" name="Local GeoNetwork" type="Z3950" can_multiplex_sessions="no">
   <RepositoryProperty name="ServiceHost" value="localhost" />
   <RepositoryProperty name="ServicePort" value="2100" />
   <RepositoryProperty name="service_short_name" value="geonetwork" />
   <RepositoryProperty name="default_record_syntax" value="xml" />
   <RepositoryProperty name="default_element_set_name" value="s" />
   <RepositoryProperty name="full_element_set_name" value="f" />
   <RepositoryProperty name="logo_src" value="http://www.k-int.com/collection_ico/sif.gif&quot; />
</Repository>
<Repository repository_dn="193.43.36.189:2100/geonetwork" name="Food and Agriculture Organization GeoNetwork (FAO-UN)" type="Z3950" can_multiplex_sessions="no">
   <RepositoryProperty name="ServiceHost" value="193.43.36.189" />
   <RepositoryProperty name="ServicePort" value="2100" />
   <RepositoryProperty name="service_short_name" value="geonetwork" />
   <RepositoryProperty name="default_record_syntax" value="xml" />
   <RepositoryProperty name="default_element_set_name" value="s" />
   <RepositoryProperty name="full_element_set_name" value="f" />
   <RepositoryProperty name="logo_src" value="http://www.fao.org/geonetwork/images/logos/fao_logo_small.gif&quot; />
</Repository>
<Repository repository_dn="62.152.116.79:2100/geonetwork" name="World Food Program VAM GeoNetwork (WFP-UN)" type="

<!-- this is the database -->
<!-- Map logical collection-dn strings on to physical instances of databases at targets (in z-speak) -->
<!--
localhost
-->
<Instance instance_dn="localhost:2100/geonetwork" collection_dn="localhost:2100/geonetwork" repository_dn="localhost:2100/geonetwork" local_name="geonetwork" />
<Instance instance_dn="193.43.36.189:2100/geonetwork" collection_dn="193.43.36.189:2100/geonetwork" repository_dn="193.43.36.189:2100/geonetwork" local_name="geonetwork" />
RepositoryDirectory>

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev

_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

Hi Timo,

I've actually implemented most of a remote search client interface in the BlueNetMEST using the new JZKit3 (xslt to cope with converting the old repositories.xml file still required) and plan to bring this into the trunk. It implements:

- choosing repositories to search from the new JZKit repositories config file
- obtaining xml (obviously) and html presentation from remote servers

Also supported:

- Z3950 harvester
- html presentation by the GeoNetwork server

Lots more to talk about here and of course any comments from others who are interested in this are welcome in any case!

Cheers,
Simon
________________________________________
From: awalsh [awalsh@anonymised.com]
Sent: Thursday, 17 December 2009 11:02 AM
To: Timo Proescholdt
Cc: geonetwork-users@lists.sourceforge.net; geonetwork-devel@anonymised.comrge.net
Subject: Re: [GeoNetwork-devel] Z39.50 remote search

Timo,

I know a little bit about the Z39.50 remote search from a users perspective.

We use the BlueNet MEST version of Geonetwork (latest version at http://anzlicmet.bluenet.utas.edu.au/wiki )
which has a Z3950 client accesssed through the 'remote search' tab.

The remote search page is very similar the advanced search page (tab) and lets users specify terms and servers to be searched using
Z3950. The list of servers to be searched can be configured through the 'repositories.xml.tem
file. Note - its only necessary to change this file, to don't need to change 'repositores.xml' as it is auto-generated
from repositories.xml.tem.

On the server side the Z39.50 server is switched on and port number specified on the Admin->Sys. Config
web page.

If you are interested to try this out download a copy of the Bluenet MEST, install on your local PC
and you can do a remote search to any of the servers listed on the remote search page.

HTH,

Andrew

----- Original Message -----
From: "Timo Proescholdt" <timo@anonymised.com>
To: <geonetwork-devel@lists.sourceforge.net>
Sent: Thursday, December 17, 2009 6:10 AM
Subject: [GeoNetwork-devel] Z39.50 remote search

Hi GN developers,

as you know I have been working on the Z39.50 / SRU stuff in the last
weeks, and I'm proud to announce that I implemented a new Z39.50
interface and SRU support via the Jzkit3 library. As soon as I managed
to disentangle my eclipse workspace I will post a diff here for
discussion, for there are a lot of things that could probably only
be decided by the community or more experienced geonetworkers.

The new Z39.50 interface happens to break the Z39.50 remote search
(because it is implemented using the library) and since the new Jzkit
library has no backward-compatibility (neither for interfaces nor
for configuration files) this feature would have to be re-implemented,
too. (which is not a bad idea anyway given the shape of that part of the
code).

I looked at bit into how it is currently implemented and how it would be
done with the new library but I felt that this should maybe be discussed
before.

Does anybody have a clear set of features the Z39.50 client search
should support and how it should be configured?

Currently there is the file "repositories.xml", containing a list of
repositories that are searched when a Z39.50 remote search is triggered.
The expected behaviour is not totally clear to me. First, I dont see
where the remote search can be enabled (I see it in the code of the
portal-search, but not in the actual webinteface). Second, I'm not
100% sure if all the repositories contained therein should be searched,
when a remote search is triggered, or if the user can choose one or more
repositories.

Whatever is contained in the old repositories.xml could be automatically
transformed (even on the fly by XSLT) into the new configuration format,
and it should also be possible to reproduce the old behaviour of the
remote search (if somebody told we what it actually was). (see
attachments for demos of the old and the new config file)
But this seems like a good point in time for me to discuss a bit.

The jzkit3 library supports a search Service with caching and
persistence which is a possibility for dramatic speed improvements.
It should also be possible to expose remote Z39.50 targets as local ones
and (in theory) even to mix results from remote and local sources.
It all depends on what people want.

So if anybody has a good understanding of how the Z39.50 remote search
is currently used and what features users demand I would be grateful if
he or she could share it, so that I have a look at it while unsnarling
the patch.

best regards
Timo

<ServiceDirectory>

<!-- Simple example IR provider that randomly waits up to 10 seconds before returning records and is well behaved -->
<Repository className="org.jzkit.search.provider.SimpleExample.ExampleSearchable"
             code="Test"
             serviceName="Test Repository">
   <Preferences>
     <Preference name="randomDelay">10</Preference>
     <Preference name="behaviour">normal</Preference>
   </Preferences>
   <RecordArchetypes>
     <Archetype name="F">xml:meta:F</Archetype>
     <Archetype name="B">xml:meta:F</Archetype>
   </RecordArchetypes>

   <Collections>
   <Collection code="Test" collectionName="A test collection"/>
   </Collections>

</Repository>

<Repository className="org.jzkit.search.provider.z3950.Z3950Origin"
             code="LC/LIVE"
             servceName="Library of congress live server">
   <Preferences>
     <Preference name="defaultRecordSyntax">xml</Preference>
     <Preference name="defaultElementSetName">f</Preference>
     <Preference name="host">z3950.loc.gov</Preference>
     <Preference name="port">7090</Preference> -->
     <Preference name="smallSetElementSetName">F</Preference>
     <Preference name="charsetEncoding">UTF-8</Preference>
     <Preference name="useReferenceId">negotiate</Preference>
   </Preferences>
   <RecordArchetypes>
     <Archetype name="F">xml:meta:F</Archetype>
     <Archetype name="B">xml:meta:F</Archetype>
   </RecordArchetypes>

   <Collections>
    <Collection code="LC/BOOKS" localId="voyager" collectionName="Library of Congress, Books Collection"/>
   </Collections>

</Repository>

<CollectionPosting code="Test" name="InfoType" value="Test"/>
<CollectionPosting code="LC/BOOKS" name="InfoType" value="Bibliographic"/>

</ServiceDirectory>

<?xml version="1.0" encoding="UTF-8"?>
<RepositoryDirectory>
<!-- Collections and repositories must appear here before instance entries
The collection_dn values are the strings you can actally use in an IRQuery as
values in the collections vector. The searchable object will deal with resolving
that collection-dn into a specific instance of a collection at a repository and
make the appropriate connection using the right database name for that repository.
-->
<TypeMapping type="Z3950" class="com.k_int.z3950.IRClient.Z3950Origin" />
<TypeMapping type="HSS" class="com.k_int.srw.client.SRWSearchable" />
<!--
localhost
-->
<Collection collection_dn="localhost:2100/geonetwork" collection_name="Local GeoNetwork" />
<Collection collection_dn="193.43.36.189:2100/geonetwork" collection_name="Food and Agriculture Organization GeoNetwork (FAO-UN)"
/>
<!-- The type parameter is used when looking for factories to create instances of
Searchable capable of searching the identified repository -->
<!--
localhost
-->
<Repository repository_dn="localhost:2100/geonetwork" name="Local GeoNetwork" type="Z3950" can_multiplex_sessions="no">
   <RepositoryProperty name="ServiceHost" value="localhost" />
   <RepositoryProperty name="ServicePort" value="2100" />
   <RepositoryProperty name="service_short_name" value="geonetwork" />
   <RepositoryProperty name="default_record_syntax" value="xml" />
   <RepositoryProperty name="default_element_set_name" value="s" />
   <RepositoryProperty name="full_element_set_name" value="f" />
   <RepositoryProperty name="logo_src" value="http://www.k-int.com/collection_ico/sif.gif&quot; />
</Repository>
<Repository repository_dn="193.43.36.189:2100/geonetwork" name="Food and Agriculture Organization GeoNetwork (FAO-UN)"
type="Z3950" can_multiplex_sessions="no">
   <RepositoryProperty name="ServiceHost" value="193.43.36.189" />
   <RepositoryProperty name="ServicePort" value="2100" />
   <RepositoryProperty name="service_short_name" value="geonetwork" />
   <RepositoryProperty name="default_record_syntax" value="xml" />
   <RepositoryProperty name="default_element_set_name" value="s" />
   <RepositoryProperty name="full_element_set_name" value="f" />
   <RepositoryProperty name="logo_src" value="FAO Map Catalog; />
</Repository>
<Repository repository_dn="62.152.116.79:2100/geonetwork" name="World Food Program VAM GeoNetwork (WFP-UN)" type="

<!-- this is the database -->
<!-- Map logical collection-dn strings on to physical instances of databases at targets (in z-speak) -->
<!--
localhost
-->
<Instance instance_dn="localhost:2100/geonetwork" collection_dn="localhost:2100/geonetwork"
repository_dn="localhost:2100/geonetwork" local_name="geonetwork" />
<Instance instance_dn="193.43.36.189:2100/geonetwork" collection_dn="193.43.36.189:2100/geonetwork"
repository_dn="193.43.36.189:2100/geonetwork" local_name="geonetwork" />
RepositoryDirectory>

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
Best Open Source Mac Front-Ends 2024

_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
geonetwork-devel List Signup and Options
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers

_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net

GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork