Ahm sorry, forgot to ask one question: How is the query sent over to the server in the yaz framework of BD? I tried the following using yaz-client:
> Z> open aleph.univie.ac.at:9992/UBW01 > Connecting...OK. > Sent initrequest. > Connection accepted by v3 target. > ID : 81 > Name : GFS/YAZ / Aleph Server > Version: YAZ 1.9.1 / ALEPH 16 > Options: search present delSet scan sort extendedServices > namedResultSets > Elapsed: 0.010944 > Z> format USMARC > Z> find @attr 1=h001 AC00028031 > Sent searchRequest. > Received SearchResponse. > Search was a success. > Number of hits: 1, setno 2 > records returned: 0 > Elapsed: 0.029441 > Z> show 1 > Sent presentRequest (1+1). > Records: 1 > [UBW01]Record type: USmarc … and it crashed after some time… > yaz-client(38304) malloc: *** mmap(size=2396000256) failed (error > code=12) > *** error: can't allocate region > *** set a breakpoint in malloc_error_break to debug > 18:43:35-14/12 [fatal] Out of memory, realloc (-1898971135 bytes) > [Cannot allocate memory] So I wonder, how BD can still retrieve the MAB data (btw, querying with "Z> format MAB" works and gives the result I see in BD, too) or what I am doing wrong. Any suggestions? Best, Stephan Am 14.12.2007 um 18:31 schrieb Stephan Kurz: > Christiaan, > > thanks for your reply, though it means bad luck at least for now, I > guess. > Is the data in the Annote field exactly the same that is transmitted > by the server? Is there some way to imitate BD’s negotiation with the > server? > I tried to run /Applications/BibDesk.app/Contents/Frameworks/ > yaz.framework/Versions/A/yaz from Terminal but got an error: cannot > execute binary file, now trying with the yaz client from macports – > without success. > > It seems that they currently only handle MAB2 data (some kind machine > readable bibliographic data syntax used in some German speaking > libraries), altough one of the system librarians told me this > afternoon that their server supports USMARC as well… > > Thanks for your good idea to contact the libraries; I’ll do so > (again). > > If that won’t work, I probably try to write some MAB parser (but I’m > not sure if this is very useful since most of the union catalogues > will be switching to MARC in the next few years (since the last few > years, so it might just take some time, see > http://artcataloging.net/ala/mw06/germanmarc.html) > … > > Too bad. > Is anyone else on this list in need of z39.50 access to a library > catalogue using MAB format? > > Best, > Stephan > > > Am 14.12.2007 um 16:18 schrieb Christiaan Hofman: > >> The MARC they send is not valid. The first 24 characters of MARC are >> determined to some extent by the syntax and we use them to recognize >> it as MARC. You could perhaps petition the libraries to send valid >> MARC (though that probbaly won't work). >> >> Christiaan >> >> On 14 Dec 2007, at 2:04 PM, Stephan Kurz wrote: >> >>> Dear list, >>> >>> using BD 1.3.12 on Mac OS X 10.5.1 (yeah, at least on my office >>> mac, I >>> have finally left 10.3.9 panther world!), I have experienced a >>> problem >>> adding a search group for my local university library: >>> aleph.univie.ac.at:9992, database UBW01, USMARC, utf-8 encoding >>> >>> I have been looking in the list archive and only found Simon’s >>> requests for support of Basel and Zürich ULib catalogues which did >>> not >>> seem really useful for this case. >>> >>> Search seems to work so far, but the catalogue data seems to be >>> parsed >>> in a non-human-readable way. >>> >>> A search for AC05915622 (this is some kind of unique identifier for >>> one title in the Austrian union catalogue database), actually >>> first I >>> searched for "au=darwin and ti=origin" brings up exactly 1 match – >>> and >>> all available data are imported to the Annote field as follows: >>> >>> 00757nM2.01000325 45 >>> h001001400000005001700014026001800031030001600049036000700065037000800 >>> 0720500017000800510010000970700008001070760007001151000031001223310030 >>> 0015335900520018340300150023541000180025041200160026842500090028443300 >>> 1500293451003100308453001500339454002300354455001000377456000800387540 >>> 001800395540001800413 >>> $$aAC0591562220070416090200.0 aOBVAC05915622 z|1dcr|||||17a aGBb >>> aeng a|a||||||||||| s|||||| aUBWs a27 aDarwin, Charles9118523813 >>> a<<The>> origin of species aCharles Darwin. Introd. by L. Harrison >>> Matthews aLast repr. aLondon [u.a.] aDent [u.a.]a a1972 aXX, 488 >>> S. aEveryman's library ; [811]r aAC00131892c aEveryman's library >>> a[811] a811a a0-460-00811-0a a0-460-01811-6 >>> >>> Then, I tried the same search in the Austrian Union catalogue (which >>> is meteor.bibvb.ac.at:9991, database ACC01EN, using USMARC and >>> iso-8859-1 encoding, which lead to a similar result, namely >>> >>> 00809nM2.01000337---45- >>> h001001400000005001700014026001800031030001600049036000700065037000800 >>> 0720500017000800510010000970700008001070760007001151000031001223310030 >>> 0015335900520018340300150023541000180025041200160026842500090028443300 >>> 1500293451003100308453001500339454002300354455001000377456000800387540 >>> 001800395540001800413088004000431 >>> $$aAC0591562220070416090100.0 aOBVAC05915622 z|1dcr|||||17a aGBb >>> aeng a|a||||||||||| s|||||| aUBWs a27 aDarwin, Charles9118523813 >>> a<<The>> origin of species aCharles Darwin. Introd. by L. Harrison >>> Matthews aLast repr. aLondon [u.a.] aDent [u.a.]a a1972 aXX, 488 >>> S. aEveryman's library ; [811]r aAC00131892c aEveryman's library >>> a[811] a811a a0-460-00811-0a a0-460-01811-6 aA074bMcZ- >>> II=Everyman's >>> L./811e28 >>> >>> I’m a bit lost with this… Z39.50 access was one of the major causes >>> for me to go from panther to leopard, and now it’s not working >>> properly (mumblemumble) – >>> >>> Any comments on how to improve this? Both catalogues are quite >>> important for me, but to enlarge the focus it would rather be better >>> to start with the union catalogue I guess… >>> What are my next steps? File a feature request? Find out something >>> about the actual syntax that ACC01EN uses (How?)? >>> >>> It might not seem very unusual in such a case, but then I have once >>> again to say that BD is one of the most useful apps and I am >>> thankful >>> that it exists already, thanks for a wonderful app. >>> >>> Best, >>> Stephan >>> >>> >>> p.s.: Endnote connection files (both not working with EN11 which I >>> happen to have a campus license for but still don’t want to use) for >>> both catalogues are available here: >>> http://www.univie.ac.at/bibliothekssystem/opac-pdfs/UBW.enz >>> http://opac.obvsg.at/opac_help/OBV.enz >>> >> ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Bibdesk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-users
