I have been modifying the repository again. If you want to download the
bib1_to_dces.cfg file, you'll need to use this link:
I have today changed the name and location of the file (to
Katherine Don wrote:
> 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
> 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 :-( )
> 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
> greenstone-users mailing list