Hey Stephan, If you want to implement a MAB parser, numerous people would be quite pleased! My excuse for not trying is that I can't read the documentation :). MAP is deprecated, but given the speed at which libraries make changes, I'd guess the MARC transition won't happen overnight.
For testing and debugging z39.50 stuff, I'd recommend using the z3950 test program that we have. You'll need subversion installed, and you can check it out with svn co https://bibdesk.svn.sourceforge.net/svnroot/bibdesk/trunk/bibdesk_vendorsrc/indexdata/yaz or just open the vendorsrc folder if you have a BibDesk source checkout (which you'd need anyway for hacking a parser). Inside the yaz/objc folder is the Obj-C wrapper we use, and there's a GUI test program called (creatively) z3950Test that you can play with (after compiling it with Xcode). You might want to add your server in the z3950Test/Controller.m file to avoid typing it in every time. It looks like you also need to compile the yaz.xcodeproj first, since I never set it up as a dependency. Make sure Xcode is set to use a customized location for Build Products in its preferences. -- adam On Friday, December 14, 2007, at 09:56AM, "Stephan Kurz" <[EMAIL PROTECTED]> wrote: >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 > > ------------------------------------------------------------------------- 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
