[greenstone-users] Getting z3950 to work

From Katherine Don
DateMon May 25 15:50:43 2009
Subject [greenstone-users] Getting z3950 to work
In-Reply-To (4A12CE4E-3050401-senylrc-org)
Hi Zachary

I have just tried this with the latest release. Here is what I found
out. I don't know if this will apply to you as your Greenstone is quite
old. But the code hasn't been worked on very much I think, so it might
be helpful. If not, you'll need to upgrade to 2.82.
I have fixed a couple of bugs after the 2.82rc release, so if you want
to try the latest version, please download a nightly snapshot (26 May or
later). http://greenstone.org/snapshots. You'll need to download the
binary release, then get the source code component and configure with
--enable-z3950.

* Lucene doesn't work very well. The server was written for use with
mgpp. Query syntax is mgpp style. If a mapping is found between the
field specified in z3950 request, then a fielded query is done, and this
will be invalid syntax for lucene.
If no field can be determined, then the query is sent as is - like in
your case. The second problem is that in lucene, the default searching
is done on the text index and that may not have all the data. It depends
how the index was created as to what ends up in the text field. Check
the doc.xml files in the archives directory - they should show you what
is in the text field.

Anyway, try changing your collection to using mgpp, and you should get
some search results.
If you want fielded searching to be done, then you need a
bib1_to_dces.cfg file. I don't know whether this was in the 2.75 release
- look in the gsdl/etc directory. If its not there, you can download the
one I have just added today, from
http://trac.greenstone.org/browser/gsdl/trunk/etc/bib1_to_dces.cfg?format=raw

The provides a mapping between bib1 attributes used in a z3950 request
(the field) and dublin core. Then the dublin core names are matched
against the indexfieldmap in the collection's build.cfg to see what
index field (TT, TI, TX etc) to use.
You need to make sure that the dublin core metadata names in the
bib1_to_dces.cfg file match those in your indexfieldmap.
If they don't, you can add a bib1_to_dces.cfg file to your collection's
etc directory, and change the values.
For instance, if your titles index is dc.Title,Title, then you may want
to have
4 dc.Title,Title
in the bib1 mapping file.

* The second problem is that namespaced metadata will not be displayed
in a record result. We use d2m to provide a mapping between dublin core
and marc. It doesn't use namespaces. So any namespaced metadata will not
show up.
If your metadata has no namepsaces, then it should be ok. If it does,
then it won't show up. you'll need to get the next nightly release.

I hope this is useful.
If you have time (and the inclination) it would be really useful if you
can try out the nightly release for z3950. If you do try it and find any
problems, I may be able to fix them for the 2.82 release proper (due
next week, so not much time :-( )

Regards,
Katherine
Zachary Spalding wrote:
> I was hopeing someone might have some experience with Greenstone and
> z39.50. I got the z39.50 daemon to work and accept searches but it
> always returns with no results. On the Greenstone server this is what
> is logged when a search is performed. There is a message that it
> failed to find index, but my index is stored in
> /greenstone/gsdl2.75/collect/newshrvh/index/ as shown in the log. Any
> ideas????
>
>
> Entering ztest_search
> querytype = 1
> attributeSetId = 128401000331-1
> [newshrvh]: failed to find index
> GSQuery = `esopus'
> Searching basename = newshrvh
> calling filter...
> Lucene command: "/greenstone/gsdl2.75/bin/script/lucene_query.pl"
> "/greenstone/gsdl2.75/collect/newshrvh/index/didx" "esopus" -dco AND
> -startresults 1 -endresults 10000
> Cached: false
> returned from filter.
> search complete.
> 11:14:33-19/05 z3950server(1) [request] Search OK 0 3 1+0 RPN:
> @attrset Bib-1 @attr 1=1016 @attr 2=3 @attr 4=1 esopus
>