BibDesk

On 27.12.2006, at 05:48, Adam R. Maxwell wrote:

> I just checked in the beginnings of z39.50 support.  Providing I
> haven't broken the xcode project or hard-coded some dependencies, it
> should be working in the next nightly build.
>
> If you want other servers on the list, someone can start a master bug
> report for those; I've only tested with the Library of Congress server
> at this point.  It seems fairly slow, and I'm not sure if this is a
> network issue, a software issue, or a server issue.  I never use
> z39.50 servers, so I've no idea if this is typical.  The query syntax
> I'm using is CCL, which seems the most readable of them all.
>
> The main point here is: this is buggy, use at your own risk!
>

Cool, looking can't wait to test this!

Thanks a lot

simon

--
Simon Spiegel
Steinhaldenstr. 50
8002 Z=FCrich

Telephon: ++41 44 451 5334
Mobophon: ++41 76 459 60 39

http://www.simifilm.ch

"I'm not that easy to impress. =96 O, a blue car." Homer Simpson

Hi everybody,

I will try to provide some feedback on the newly added z39.50 support. 
As I am not a programmer and have only just started to involve myself 
into library catalogue stuff, I am not sure what I can contribute. At 
first and right now, I would like to express that not only BD is a 
wonderful program already, but z39.50 support will make it even better. 
Great idea!

For accessing z39.50 servers I guess there are multiple sources to 
retrieve server data from:
http://targettest.indexdata.com/u.php
http://staff.library.mun.ca/staff/toolbox/z3950hosts.htm
…
Another possibility (which I am not sure if BD should use) would be to 
import Endnote connection files (.enz), which basically do not provide 
any more information than these lists but are often provided by 
libraries on their websites for use with that expensive yet buggy thing.

So much for now,
looking forward to testing the next nightly build,
Stephan


Adam R. Maxwell wrote:

> I just checked in the beginnings of z39.50 support.  Providing I  
> haven't broken the xcode project or hard-coded some dependencies, it  
> should be working in the next nightly build.
> 
> If you want other servers on the list, someone can start a master bug  
> report for those; I've only tested with the Library of Congress server  
> at this point.  It seems fairly slow, and I'm not sure if this is a  
> network issue, a software issue, or a server issue.  I never use  
> z39.50 servers, so I've no idea if this is typical.  The query syntax  
> I'm using is CCL, which seems the most readable of them all.
> 
> The main point here is: this is buggy, use at your own risk!
> 
> -- arm

I just compiled and uploaded the lastest 'nightly', so have fun guys.

Mike

On Dec 27, 2006, at 12:48 AM, Adam R. Maxwell wrote:

> I just checked in the beginnings of z39.50 support.  Providing I
> haven't broken the xcode project or hard-coded some dependencies, it
> should be working in the next nightly build.
>
> If you want other servers on the list, someone can start a master bug
> report for those; I've only tested with the Library of Congress server
> at this point.  It seems fairly slow, and I'm not sure if this is a
> network issue, a software issue, or a server issue.  I never use
> z39.50 servers, so I've no idea if this is typical.  The query syntax
> I'm using is CCL, which seems the most readable of them all.
>
> The main point here is: this is buggy, use at your own risk!
>
> -- arm
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Bibdesk-users mailing list
> Bibdesk-users@...
> https://lists.sourceforge.net/lists/listinfo/bibdesk-users

On Dec 27, 2006, at 02:54, Stephan Kurz wrote:

>
[...]
> =85
> Another possibility (which I am not sure if BD should use) would be to
> import Endnote connection files (.enz), which basically do not provide
> any more information than these lists but are often provided by
> libraries on their websites for use with that expensive yet buggy =20
> thing.

I just glanced at these files from my Endnote X install, and they =20
appear to be binary, so there's no chance of us reading them (unless =20
ISI published the spec somewhere).

> So much for now,
> looking forward to testing the next nightly build,

Thanks.  Testers do need to keep in mind that these are basically =20
alpha releases as far as the new features go :).

Adam=

Yep, they're binary, although they're all editable within Endnote, so =20=

anyone with an Endnote license can copy the connection info from =20
individual .enz files.

-A

On Dec 27, 2006, at 8:05 AM, Adam R. Maxwell wrote:

>
> On Dec 27, 2006, at 02:54, Stephan Kurz wrote:
>
>>
> [...]
>> =85
>> Another possibility (which I am not sure if BD should use) would =20
>> be to
>> import Endnote connection files (.enz), which basically do not =20
>> provide
>> any more information than these lists but are often provided by
>> libraries on their websites for use with that expensive yet buggy
>> thing.
>
> I just glanced at these files from my Endnote X install, and they
> appear to be binary, so there's no chance of us reading them (unless
> ISI published the spec somewhere).
>
>> So much for now,
>> looking forward to testing the next nightly build,
>
> Thanks.  Testers do need to keep in mind that these are basically
> alpha releases as far as the new features go :).
>
> Adam
> ----------------------------------------------------------------------=20=

> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to =20
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?=20
> page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV
> _______________________________________________
> Bibdesk-users mailing list
> Bibdesk-users@...
> https://lists.sourceforge.net/lists/listinfo/bibdesk-users

Wow, this new z39.50 search feature is fantastic.  Now I know why  
people have been so excited about PubMed searching.  Any chance that  
the next improvement to this feature be to allow users to input their  
favorite z39.50 server?  I notice that my local library has such a  
server... :-)

Mike

On Dec 27, 2006, at 10:23 AM, Michael Hohensee wrote:

> I just compiled and uploaded the lastest 'nightly', so have fun guys.
>
> Mike
>
> On Dec 27, 2006, at 12:48 AM, Adam R. Maxwell wrote:
>
>> I just checked in the beginnings of z39.50 support.  Providing I
>> haven't broken the xcode project or hard-coded some dependencies, it
>> should be working in the next nightly build.
>>
>> If you want other servers on the list, someone can start a master bug
>> report for those; I've only tested with the Library of Congress  
>> server
>> at this point.  It seems fairly slow, and I'm not sure if this is a
>> network issue, a software issue, or a server issue.  I never use
>> z39.50 servers, so I've no idea if this is typical.  The query syntax
>> I'm using is CCL, which seems the most readable of them all.
>>
>> The main point here is: this is buggy, use at your own risk!
>>
>> -- arm
>>
>> --------------------------------------------------------------------- 
>> -
>> ---
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to
>> share your
>> opinions on IT & business topics through brief surveys - and earn  
>> cash
>> http://www.techsay.com/default.php?
>> page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Bibdesk-users mailing list
>> Bibdesk-users@...
>> https://lists.sourceforge.net/lists/listinfo/bibdesk-users
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Bibdesk-users mailing list
> Bibdesk-users@...
> https://lists.sourceforge.net/lists/listinfo/bibdesk-users

Michael Hohensee
hohensee@...

On Dec 27, 2006, at 09:19, Alexander H. Montgomery wrote:

> Yep, they're binary, although they're all editable within Endnote, so
> anyone with an Endnote license can copy the connection info from
> individual .enz files.

My guess is that we'll do something similar to facilitate sharing  
between users, probably with an OS X property list (ASCII or XML).   
You'd be able to drop them on the desktop or into an e-mail message.

-- arm

On Dec 27, 2006, at 09:43, Michael Hohensee wrote:

> Wow, this new z39.50 search feature is fantastic.  Now I know why  
> people have been so excited about PubMed searching.  Any chance that  
> the next improvement to this feature be to allow users to input  
> their favorite z39.50 server?  I notice that my local library has  
> such a server... :-)

Choose Other from the popup and you may be able to type it in  
(Christiaan has discovered some issues with it).

For now, if you just type in the address as as  
"myhostname.library.edu:nnnn/database" it should work (set the port  
text field to 0 and enter it in the hostname (nnnn) instead, and  
substitute "database" with the database name).  The LoC server, for  
example, is "z3950.loc.gov:7090/Voyager".

Adam

I've found that the address field doesn't become editable when I  
select 'Other' from the popup menu (I assume we do this via File- 
 >'New Z39.50 Search Group' route).  Is there a trick to avoid this  
problem?

On Dec 27, 2006, at 12:52 PM, Adam R. Maxwell wrote:

>
> On Dec 27, 2006, at 09:43, Michael Hohensee wrote:
>
>> Wow, this new z39.50 search feature is fantastic.  Now I know why
>> people have been so excited about PubMed searching.  Any chance that
>> the next improvement to this feature be to allow users to input
>> their favorite z39.50 server?  I notice that my local library has
>> such a server... :-)
>
> Choose Other from the popup and you may be able to type it in
> (Christiaan has discovered some issues with it).
>
> For now, if you just type in the address as as
> "myhostname.library.edu:nnnn/database" it should work (set the port
> text field to 0 and enter it in the hostname (nnnn) instead, and
> substitute "database" with the database name).  The LoC server, for
> example, is "z3950.loc.gov:7090/Voyager".
>
> Adam
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Bibdesk-users mailing list
> Bibdesk-users@...
> https://lists.sourceforge.net/lists/listinfo/bibdesk-users

Michael Hohensee
hohensee@...

No, I did not enable them yet (I just did in svn though). It was too
unreliable: in my test cases it either led to a crash or a freeze.

Christiaan

On 12/27/06, Michael Hohensee <hohensee@...> wrote:
>
> I've found that the address field doesn't become editable when I select
> 'Other' from the popup menu (I assume we do this via File->'New Z39.50Search Group' route).  Is there a trick to avoid this problem?
>
> On Dec 27, 2006, at 12:52 PM, Adam R. Maxwell wrote:
>
>
> On Dec 27, 2006, at 09:43, Michael Hohensee wrote:
>
> Wow, this new z39.50 search feature is fantastic.  Now I know why
> people have been so excited about PubMed searching.  Any chance that
> the next improvement to this feature be to allow users to input
> their favorite z39.50 server?  I notice that my local library has
> such a server... :-)
>
>
> Choose Other from the popup and you may be able to type it in
> (Christiaan has discovered some issues with it).
>
> For now, if you just type in the address as as
> "myhostname.library.edu:nnnn/database" it should work (set the port
> text field to 0 and enter it in the hostname (nnnn) instead, and
> substitute "database" with the database name).  The LoC server, for
> example, is "z3950.loc.gov:7090/Voyager".
>
> Adam
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Bibdesk-users mailing list
> Bibdesk-users@...
> https://lists.sourceforge.net/lists/listinfo/bibdesk-users
>
>
> Michael Hohensee
> hohensee@...
>
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> Bibdesk-users mailing list
> Bibdesk-users@...
> https://lists.sourceforge.net/lists/listinfo/bibdesk-users
>
>
>

On 27-Dec-06, at 9:43 AM, Michael Hohensee wrote:

> Wow, this new z39.50 search feature is fantastic.  Now I know why  
> people have been so excited about PubMed searching.

Could someone briefly explain the greatness of z39.50 searching?  I  
gather it's a protocol used for querying certain kinds of  
databases...?  What kinds of resources does it make accessible in  
BibDesk?

Paul






> On Dec 27, 2006, at 10:23 AM, Michael Hohensee wrote:
>
>> I just compiled and uploaded the lastest 'nightly', so have fun guys.
>>
>> Mike
>>
>> On Dec 27, 2006, at 12:48 AM, Adam R. Maxwell wrote:
>>
>>> I just checked in the beginnings of z39.50 support.  Providing I
>>> haven't broken the xcode project or hard-coded some dependencies, it
>>> should be working in the next nightly build.
>>>
>>> If you want other servers on the list, someone can start a master  
>>> bug
>>> report for those; I've only tested with the Library of Congress  
>>> server
>>> at this point.  It seems fairly slow, and I'm not sure if this is a
>>> network issue, a software issue, or a server issue.  I never use
>>> z39.50 servers, so I've no idea if this is typical.  The query  
>>> syntax
>>> I'm using is CCL, which seems the most readable of them all.
>>>
>>> The main point here is: this is buggy, use at your own risk!
>>>
>>> -- arm
>>>
>>> -------------------------------------------------------------------- 
>>> --
>>> ---
>>> Take Surveys. Earn Cash. Influence the Future of IT
>>> Join SourceForge.net's Techsay panel and you'll get the chance to
>>> share your
>>> opinions on IT & business topics through brief surveys - and earn  
>>> cash
>>> http://www.techsay.com/default.php?
>>> page=join.php&p=sourceforge&CID=DEVDEV
>>> _______________________________________________
>>> Bibdesk-users mailing list
>>> Bibdesk-users@...
>>> https://lists.sourceforge.net/lists/listinfo/bibdesk-users
>>
>>
>> --------------------------------------------------------------------- 
>> ----
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to  
>> share your
>> opinions on IT & business topics through brief surveys - and earn  
>> cash
>> http://www.techsay.com/default.php? 
>> page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Bibdesk-users mailing list
>> Bibdesk-users@...
>> https://lists.sourceforge.net/lists/listinfo/bibdesk-users
>
> Michael Hohensee
> hohensee@...
>
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV________________________________ 
> _______________
> Bibdesk-users mailing list
> Bibdesk-users@...
> https://lists.sourceforge.net/lists/listinfo/bibdesk-users

On 27.12.2006, at 05:48, Adam R. Maxwell wrote:

> I just checked in the beginnings of z39.50 support.  Providing I
> haven't broken the xcode project or hard-coded some dependencies, it
> should be working in the next nightly build.
>
> If you want other servers on the list, someone can start a master bug
> report for those; I've only tested with the Library of Congress server
> at this point.  It seems fairly slow, and I'm not sure if this is a
> network issue, a software issue, or a server issue.  I never use
> z39.50 servers, so I've no idea if this is typical.  The query syntax
> I'm using is CCL, which seems the most readable of them all.
>
> The main point here is: this is buggy, use at your own risk!

Ok, some first feedback. Just let me say again that I'm really, =20
really grateful about this.

As you said yourself, this is still rather buggy ATM. I had several =20
freezes at different times. Since only LoC search is possible for =20
now, I can't really comment on speed and such things, since I never =20
use LoC. As has been said, we definitely need some UI here to chose =20
between different servers and, if possible, an easy way to exchange =20
them. This could be done easily with simple text files.

I tried to acquaintance myself with CCL, but most of the time BibDesk =20=

would just crash if I tried examples I found on the web. Just a =20
simple search for one string would work, but as soon as I define a =20
field, things get messy. For example, something like  "au=3Dneal =20
stephenson" always crashed the app. Anyway, no app I know let's you =20
do CCL searches, and an UI which allows to search specific fields and =20=

also does boolean search is needed.

So much for now. Once again, thank you very much. Can't wait for the =20
next nightly.

simon



--
Simon Spiegel
EDV-Koordinator

Seminar f=FCr Filmwissenschaft
Plattenstrasse 54
CH-8032 Z=FCrich
+41 33 634 35 37
 http://www.film.unizh.ch

B=FCro: Wilfriedstrasse 6, Raum 006, +41 44 634 35 06

On Dec 27, 2006, at 12:43, Simon Spiegel wrote:

>
> On 27.12.2006, at 05:48, Adam R. Maxwell wrote:
>
>> I just checked in the beginnings of z39.50 support.  Providing I
>> haven't broken the xcode project or hard-coded some dependencies, it
>> should be working in the next nightly build.
>>
>> If you want other servers on the list, someone can start a master bug
>> report for those; I've only tested with the Library of Congress  
>> server
>> at this point.  It seems fairly slow, and I'm not sure if this is a
>> network issue, a software issue, or a server issue.  I never use
>> z39.50 servers, so I've no idea if this is typical.  The query syntax
>> I'm using is CCL, which seems the most readable of them all.
>>
>> The main point here is: this is buggy, use at your own risk!
>
> Ok, some first feedback. Just let me say again that I'm really,
> really grateful about this.
>
> As you said yourself, this is still rather buggy ATM. I had several
> freezes at different times. Since only LoC search is possible for
> now, I can't really comment on speed and such things, since I never
> use LoC. As has been said, we definitely need some UI here to chose
> between different servers and, if possible, an easy way to exchange
> them. This could be done easily with simple text files.

These are minor things (with the exception of freezes), and mostly  
fixed for the next build.

> I tried to acquaintance myself with CCL, but most of the time BibDesk
> would just crash if I tried examples I found on the web. Just a
> simple search for one string would work, but as soon as I define a
> field, things get messy. For example, something like  "au=neal
> stephenson" always crashed the app.

In my test app, zoom doesn't recognize that as a CCL query.  Don't ask  
me why; all query syntaxes for z39.50 are very weird, and I haven't  
dug into it enough to understand the details.

I've fixed the crash you're seeing, though, and will try to provide  
some error feedback.

> Anyway, no app I know let's you
> do CCL searches, and an UI which allows to search specific fields and
> also does boolean search is needed.

If you can figure out how to translate UI elements into a CCL query  
(or PQF/CQL query), that would really help.  This is another feature I  
have no use for, and I'm not really interested in creating a UI that  
generates query strings.  Possibly someone else has already done this,  
so if you can find something out, that would be useful.

-- arm

On Dec 27, 2006, at 3:07 PM, Paul Ingraham, RMT wrote:

[snip]

>
> Could someone briefly explain the greatness of z39.50 searching?  I
> gather it's a protocol used for querying certain kinds of
> databases...?  What kinds of resources does it make accessible in
> BibDesk?
>

It makes available the library catalogs of virtually every research  
library in the world.
--
Dr. Adam M. Goldstein
adam <dot> goldstein <at> jhu.edu
http://shiftingbalance.wordpress.com

On 27-Dec-06, at 1:14 PM, Adam M. Goldstein wrote:

> On Dec 27, 2006, at 3:07 PM, Paul Ingraham, RMT wrote:
>
> [snip]
>
>>
>> Could someone briefly explain the greatness of z39.50 searching?  I
>> gather it's a protocol used for querying certain kinds of
>> databases...?  What kinds of resources does it make accessible in
>> BibDesk?
>>
>
> It makes available the library catalogs of virtually every research
> library in the world.

Wow!  That DOES sound great!  :-)  Thanks for the synopsis, Adam.

Paul

On Dec 27, 2006, at 13:08, Adam R. Maxwell wrote:

>> I tried to acquaintance myself with CCL, but most of the time BibDesk
>> would just crash if I tried examples I found on the web. Just a
>> simple search for one string would work, but as soon as I define a
>> field, things get messy. For example, something like  "au=neal
>> stephenson" always crashed the app.
>
> In my test app, zoom doesn't recognize that as a CCL query.  Don't ask
> me why; all query syntaxes for z39.50 are very weird, and I haven't
> dug into it enough to understand the details.

In the next build, try au="stephenson, neal" as a query, and it should  
work fine, at least with servers that support bib-1 mapping.  If you  
want to experiment, there will be a file in the yaz.framework inside  
BibDesk's bundle called default.bib that you can modify with a text  
editor (this is not a BibTeX file).

Adam

On 27.12.2006, at 21:08, Adam R. Maxwell wrote:

>
> I've fixed the crash you're seeing, though, and will try to provide
> some error feedback

Ok, I tested the new nightly and have a lot of praise. But first, a =20
rather serious bug: ATM groups are not saved by BibDesk. Opening =20
a .bib file with groups (smart or static) and saving them will result =20=

in the loss of these groups.

I tested it with the following  Swiss libraries

opac.nebis.ch Port: 9909 Database: NEBIS
aleph.unibas.ch Port: 9909 Database: IDS_ANSEL
biblio.unizh.ch Port: 9909 Database: uzh01 Login: z39 Password: z39 =20
This does work, although I can't edit the login/password fields in =20
BibDesk.

In general, connection and retrieval was quick and without any =20
serious problems. Search like au=3Dmaxwell, adam or ti=3Dtex work now. =
So =20
do booelan searches (see later) I didn't encounter any crashes. There =20=

definitely are problems with special characters though. Searching =20
terms with umlauts seem to be completely ignored and in the the =20
retrieved information, results are mixed. With nebis and unibas.ch, =20
umlauts aren't properly rendered, with unizh.ch they are displayed =20
just fine. I guess this depends on the encoding of the results, maybe =20=

this should also be definable by the user.

A general note: When you drag and drop an entry from a search group =20
to your library, the entry opens (as it always does) but it is not =20
editable at that moment. This should be changed IMO. It's my =20
experience that you almost always want to change something about an =20
entry you add to your library, and it's not very handy if a have to =20
drag'n'drop first, then change to the library and edit it then.

A more general question: What information is actually available via =20
z39.50? Does it/can it change from library to library, which one does =20=

BibDesk download, can you control how much is downloaded? If I =20
understand you correctly, the content of default.bib only relates to =20
searching but not retrieval (I must admit that I don't really =20
understand what default.bib does, though).

>> Anyway, no app I know let's you
>> do CCL searches, and an UI which allows to search specific fields and
>> also does boolean search is needed.
>
> If you can figure out how to translate UI elements into a CCL query
> (or PQF/CQL query), that would really help.  This is another feature I
> have no use for, and I'm not really interested in creating a UI that
> generates query strings.  Possibly someone else has already done this,
> so if you can find something out, that would be useful.

I don't really understand what you mean here. If you mean whether I =20
can actually build this, the answer is no. If you mean whether I can =20
think of a useufl UI, the answer is yes. Basically, this would just =20
work like BibDesk's smart group. Boolean searches like
(au=3Dtodorov or wuensch) and (ti=3Dliteratur) and date=3D2002 seem to =20=

work. What doesn't seem to work are operators like <  and >

So much for the moment.

simon





--
Simon Spiegel
Steinhaldenstr. 50
8002 Z=FCrich

Telephon: ++41 44 451 5334
Mobophon: ++41 76 459 60 39

http://www.simifilm.ch

"In a world getting more and more democratic, film directing is the last
resort for dictators." Francis Ford Coppola

The addition of Z39.50 support is excellent news and makes BibDesk an =20=

even better research tool.

I've been able to use the LoC server, but have failed to access the =20
Z39.50 server at the National Library of Wales. Its server details =20
are as follows:

Internet address of z39.50 server at NLW:
geacprif.llgc.org.uk

Port number:
210

Database name:
advance

Supported searches

?MARC21

Can anyone suggest why I'm not able to search the NLW server?

Many thanks.

Owen Thomas

--------------
Owen Thomas
Department of Welsh
University of Wales, Lampeter
Ceredigion
SA48 7ED
owen.thomas@...


On 27 Rhag 2006, at 20:43, Simon Spiegel wrote:

>
> On 27.12.2006, at 05:48, Adam R. Maxwell wrote:
>
>> I just checked in the beginnings of z39.50 support.  Providing I
>> haven't broken the xcode project or hard-coded some dependencies, it
>> should be working in the next nightly build.
>>
>> If you want other servers on the list, someone can start a master bug
>> report for those; I've only tested with the Library of Congress =20
>> server
>> at this point.  It seems fairly slow, and I'm not sure if this is a
>> network issue, a software issue, or a server issue.  I never use
>> z39.50 servers, so I've no idea if this is typical.  The query syntax
>> I'm using is CCL, which seems the most readable of them all.
>>
>> The main point here is: this is buggy, use at your own risk!
>
> Ok, some first feedback. Just let me say again that I'm really,
> really grateful about this.
>
> As you said yourself, this is still rather buggy ATM. I had several
> freezes at different times. Since only LoC search is possible for
> now, I can't really comment on speed and such things, since I never
> use LoC. As has been said, we definitely need some UI here to chose
> between different servers and, if possible, an easy way to exchange
> them. This could be done easily with simple text files.
>
> I tried to acquaintance myself with CCL, but most of the time BibDesk
> would just crash if I tried examples I found on the web. Just a
> simple search for one string would work, but as soon as I define a
> field, things get messy. For example, something like  "au=3Dneal
> stephenson" always crashed the app. Anyway, no app I know let's you
> do CCL searches, and an UI which allows to search specific fields and
> also does boolean search is needed.
>
> So much for now. Once again, thank you very much. Can't wait for the
> next nightly.
>
> simon
>
>
>
> --
> Simon Spiegel
> EDV-Koordinator
>
> Seminar f=FCr Filmwissenschaft
> Plattenstrasse 54
> CH-8032 Z=FCrich
> +41 33 634 35 37
> http://www.film.unizh.ch
>
> B=FCro: Wilfriedstrasse 6, Raum 006, +41 44 634 35 06
>
>
>
> ----------------------------------------------------------------------=20=

> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to =20
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?=20
> page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV
> _______________________________________________
> Bibdesk-users mailing list
> Bibdesk-users@...
> https://lists.sourceforge.net/lists/listinfo/bibdesk-users

I am still on 10.3.9, and neither of the nightlies [BibDesk-20061227.dmg  
  or BibDesk-20061228.dmg] do start up here.

dyld: /Volumes/BibDesk/BibDesk.app/Contents/MacOS/BibDesk can't open
library: /System/Library/Frameworks/Quartz.framework/Versions/A/Quartz 
(No such file or directory, errno = 2)

One more reason to change to Tiger…

When I have upgraded my system (it still hurts to change a winning team…),
I will test BD and z39.50 support immediately.

Cheers and keep up the good work,
Stephan

On 28 Dec 2006, at 7:55 PM, Simon Spiegel wrote:

>
> On 27.12.2006, at 21:08, Adam R. Maxwell wrote:
>
>>
>> I've fixed the crash you're seeing, though, and will try to provide
>> some error feedback
>
> Ok, I tested the new nightly and have a lot of praise. But first, a
> rather serious bug: ATM groups are not saved by BibDesk. Opening
> a .bib file with groups (smart or static) and saving them will result
> in the loss of these groups.
>

sorry, that's a bug xcode should have warned me about but failed  
again. Fixed now.

> I tested it with the following  Swiss libraries
>
> opac.nebis.ch Port: 9909 Database: NEBIS
> aleph.unibas.ch Port: 9909 Database: IDS_ANSEL
> biblio.unizh.ch Port: 9909 Database: uzh01 Login: z39 Password: z39
> This does work, although I can't edit the login/password fields in
> BibDesk.
>
> In general, connection and retrieval was quick and without any
> serious problems. Search like au=maxwell, adam or ti=tex work now. So
> do booelan searches (see later) I didn't encounter any crashes. There
> definitely are problems with special characters though. Searching
> terms with umlauts seem to be completely ignored and in the the
> retrieved information, results are mixed. With nebis and unibas.ch,
> umlauts aren't properly rendered, with unizh.ch they are displayed
> just fine. I guess this depends on the encoding of the results, maybe
> this should also be definable by the user.
>

I can't say anything about that.

> A general note: When you drag and drop an entry from a search group
> to your library, the entry opens (as it always does) but it is not
> editable at that moment. This should be changed IMO. It's my
> experience that you almost always want to change something about an
> entry you add to your library, and it's not very handy if a have to
> drag'n'drop first, then change to the library and edit it then.
>

That's a bug, a side effect of the change where we don't switch  
groups anymore for drag/drop. Also checked in a fix for that.

Christiaan

Folks,

This is *wonderful*. I'm compiling a course bibliography and this one  
feature will cut the work time by 50%. Thank you, thank you.

Now for the problem - I tried accessing COPAC, the catalogus  
catalogorum for UK libraries, and it caused a crash. This may be  
because COPAC does not support Marc format records (sutrs and grs-1  
only); Sente has always choked on Copac as well, but it is one of the  
most important bibliographic resources in Europe.

Access details: z3950.copac.ac.uk port 210 dbname copac. For further  
info see http://copac.ac.uk/interfaces/z39.50/zed-support/

Thanks again

-WBTD.


- - -- --- ----- ------- ------------ -------------------
Dr. Will Tuladhar Douglas                w.t.douglas@...
Indic Religions and Himalayan Studies
University of Aberdeen    +44 (0)12 24 27 22 74
Scotland

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hello!.
How would a MD use z39.50?
does is it have the same capabilities of pubned?

Daniele Pontillo
Chief, Echo Lab, Cardiology, Belcolle Hospital
Strada Sanmartinese, Viterbo, Italy 01100
Work: +39 0761 339424
Cell: +39 3383734157
Home: +39 0761 834051
http://www.danpont.it



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFFlPNLxfmSf9JGn5oRAs0qAJ9zXt3FUuu3w+gmB08MtkUf44gMnwCgrFWk
01XhobR4RoMzJkKLJyLiOpo=
=36MG
-----END PGP SIGNATURE-----

Support for  z39.50 servers is an excellent idea.

I'm having problems, however, with searching the National Library of
Wales server.

geacprif.llgc.org.uk:210/advance

Apparently, it's compatible with MARC21 searches.

I would appreciate a solution to this.

Many thanks again for this great application.

Owen Thomas

------
Owen Thomas
Department of Welsh
University of Wales, Lampeter
Ceredigion
SA48 7ED



On 29/12/06, Will Tuladhar-Douglas <w.t.douglas@...> wrote:
> Folks,
>
> This is *wonderful*. I'm compiling a course bibliography and this one
> feature will cut the work time by 50%. Thank you, thank you.
>
> Now for the problem - I tried accessing COPAC, the catalogus
> catalogorum for UK libraries, and it caused a crash. This may be
> because COPAC does not support Marc format records (sutrs and grs-1
> only); Sente has always choked on Copac as well, but it is one of the
> most important bibliographic resources in Europe.
>
> Access details: z3950.copac.ac.uk port 210 dbname copac. For further
> info see http://copac.ac.uk/interfaces/z39.50/zed-support/
>
> Thanks again
>
> -WBTD.
>
>
> - - -- --- ----- ------- ------------ -------------------
> Dr. Will Tuladhar Douglas                w.t.douglas@...
> Indic Religions and Himalayan Studies
> University of Aberdeen    +44 (0)12 24 27 22 74
> Scotland
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Bibdesk-users mailing list
> Bibdesk-users@...
> https://lists.sourceforge.net/lists/listinfo/bibdesk-users
>


-- 
Owen Thomas
Adran y Gymraeg
Prifysgol Cymru
Llanbedr Pont Steffan
Ceredigion
SA48 7ED
01570 424864

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 29.12.2006, at 10:51, Daniele Pontillo wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> hello!.
> How would a MD use z39.50?

This does depend on the library you use.
> does is it have the same capabilities of pubned?

Z39.50 is a protocol to retrieve information from a specific  =20
library. Most university libraries support it. So if you need =20
bibliographic data from your university library, there's a big chance =20=

that you might benefit from z39.50 support. Where it doesn't help you =20=

though is with bibliographic data for specific journals and articles =20
(which is, AFAIK, Pubmed's domain).

simon

- --
Simon Spiegel
Steinhaldenstr. 50
8002 Z=FCrich

Telephon: ++41 44 451 5334
Mobophon: ++41 76 459 60 39


http://www.simifilm.ch

"I have never been certain that the moral of the Icarus myth is, as =20
is generally accepted, 'don't fly too high', or whether it might also =20=

be thought of as: 'forget about the wax and feathers, and do a better =20=

job on the wings." Stanley Kubrick


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFFlQoSI+bknClY7b8RAmzaAJ0b1sINa3b0FwndX/IkPnVMy+oZtwCbByaO
kwEzyaWUp/XUaPk47FvoQLk=3D
=3Dmd26
-----END PGP SIGNATURE-----

On Dec 29, 2006, at 02:37, Will Tuladhar-Douglas wrote:

> Folks,
>
> This is *wonderful*. I'm compiling a course bibliography and this one
> feature will cut the work time by 50%. Thank you, thank you.
>
> Now for the problem - I tried accessing COPAC, the catalogus
> catalogorum for UK libraries, and it caused a crash. This may be
> because COPAC does not support Marc format records (sutrs and grs-1
> only); Sente has always choked on Copac as well, but it is one of the
> most important bibliographic resources in Europe.

MARC (USMARC/MARC21) is a requirement at present.  If you can find a  
specification for SUTRS or GRS-1 syntax, we can look into it.

-- arm

On Dec 29, 2006, at 04:29, Simon Spiegel wrote:
>
> On 29.12.2006, at 10:51, Daniele Pontillo wrote:
>>
>> hello!.
>> How would a MD use z39.50?
>
> This does depend on the library you use.
>> does is it have the same capabilities of pubned?
>
> Z39.50 is a protocol to retrieve information from a specific
> library. Most university libraries support it. So if you need
> bibliographic data from your university library, there's a big chance
> that you might benefit from z39.50 support. Where it doesn't help you
> though is with bibliographic data for specific journals and articles
> (which is, AFAIK, Pubmed's domain).

Dan, have you tried the PubMed searching we added?  Isn't that  
sufficient?

-- arm

>
>> I tested it with the following  Swiss libraries
>>
>> opac.nebis.ch Port: 9909 Database: NEBIS
>> aleph.unibas.ch Port: 9909 Database: IDS_ANSEL
>> biblio.unizh.ch Port: 9909 Database: uzh01 Login: z39 Password: z39
>> This does work, although I can't edit the login/password fields in
>> BibDesk.
>>
>> In general, connection and retrieval was quick and without any
>> serious problems. Search like au=3Dmaxwell, adam or ti=3Dtex work =
now. So
>> do booelan searches (see later) I didn't encounter any crashes. There
>> definitely are problems with special characters though. Searching
>> terms with umlauts seem to be completely ignored and in the the
>> retrieved information, results are mixed. With nebis and unibas.ch,
>> umlauts aren't properly rendered, with unizh.ch they are displayed
>> just fine. I guess this depends on the encoding of the results, maybe
>> this should also be definable by the user.
>>
>
> I can't say anything about that.

Any comments on this from Adam? Shall I post bugs for this?

On a more general note: Is z39.50 in state now that we should file =20
bugs and feature requests, or is still too much subject to change ?

simon

--
Simon Spiegel
Steinhaldenstr. 50
8002 Z=FCrich

Telephon: ++41 44 451 5334
Mobophon: ++41 76 459 60 39

http://www.simifilm.ch

"In a world getting more and more democratic, film directing is the last
resort for dictators." Francis Ford Coppola

On Dec 29, 2006, at 13:03, Simon Spiegel wrote:

>>> I tested it with the following  Swiss libraries
>>>
>>> opac.nebis.ch Port: 9909 Database: NEBIS
>>> aleph.unibas.ch Port: 9909 Database: IDS_ANSEL
>>> biblio.unizh.ch Port: 9909 Database: uzh01 Login: z39 Password: z39
>>> This does work, although I can't edit the login/password fields in
>>> BibDesk.
>>>
>>> In general, connection and retrieval was quick and without any
>>> serious problems. Search like au=maxwell, adam or ti=tex work now.  
>>> So
>>> do booelan searches (see later) I didn't encounter any crashes.

Good.  Any crashes should definitely be reported.

>>> There
>>> definitely are problems with special characters though. Searching
>>> terms with umlauts seem to be completely ignored and in the the
>>> retrieved information, results are mixed. With nebis and unibas.ch,
>>> umlauts aren't properly rendered, with unizh.ch they are displayed
>>> just fine. I guess this depends on the encoding of the results,  
>>> maybe
>>> this should also be definable by the user.

I'm not sure yet how encodings are handled; this seems to be dependent  
on the server, so it may need to be customized.  From my reading of  
the code, it should work as-is, but I haven't found explicit  
documentation on z39.50 and encodings.  If you can dig something up  
(specifically for the yaz code), that would be helpful.

>>> I can't say anything about that.
>
> Any comments on this from Adam? Shall I post bugs for this?
>
> On a more general note: Is z39.50 in state now that we should file
> bugs and feature requests, or is still too much subject to change ?

You can file away, I think.  Aim low and you won't be disappointed ;).

-- arm

On 29.12.2006, at 22:28, Adam R. Maxwell wrote:

>
> On Dec 29, 2006, at 13:03, Simon Spiegel wrote:
>
>>>> I tested it with the following  Swiss libraries
>>>>
>>>> opac.nebis.ch Port: 9909 Database: NEBIS
>>>> aleph.unibas.ch Port: 9909 Database: IDS_ANSEL
>>>> biblio.unizh.ch Port: 9909 Database: uzh01 Login: z39 Password: z39
>>>> This does work, although I can't edit the login/password fields in
>>>> BibDesk.
>>>>
>>>> In general, connection and retrieval was quick and without any
>>>> serious problems. Search like au=3Dmaxwell, adam or ti=3Dtex work =
now.
>>>> So
>>>> do booelan searches (see later) I didn't encounter any crashes.
>
> Good.  Any crashes should definitely be reported.
>
>>>> There
>>>> definitely are problems with special characters though. Searching
>>>> terms with umlauts seem to be completely ignored and in the the
>>>> retrieved information, results are mixed. With nebis and unibas.ch,
>>>> umlauts aren't properly rendered, with unizh.ch they are displayed
>>>> just fine. I guess this depends on the encoding of the results,
>>>> maybe
>>>> this should also be definable by the user.
>
> I'm not sure yet how encodings are handled; this seems to be dependent
> on the server, so it may need to be customized.  =46rom my reading of
> the code, it should work as-is, but I haven't found explicit
> documentation on z39.50 and encodings.  If you can dig something up
> (specifically for the yaz code), that would be helpful.

I don't really know what I'm looking for what information you already =20=

have, but here are some sites I found which looked interesting.

It's the complete specification of the z.39.50 protocoll, a 270 pages =20=

PDF.

Then there's the YAZ User's Guide and Reference http://=20
 http://www.indexdata.dk/yaz/doc/ which links to this: http://www.loc.gov/=20
z3950/agency/defns/charneg-3.html

And then there's the yaz-client manpage http://manpage.willempen.org/=20
1/yaz-client


>
>>>> I can't say anything about that.
>>
>> Any comments on this from Adam? Shall I post bugs for this?
>>
>> On a more general note: Is z39.50 in state now that we should file
>> bugs and feature requests, or is still too much subject to change ?
>
> You can file away, I think.  Aim low and you won't be disappointed ;).

Ok, I'll file some stuff.

simon

--
Simon Spiegel
Steinhaldenstr. 50
8002 Z=FCrich

Telephon: ++41 44 451 5334
Mobophon: ++41 76 459 60 39


http://www.simifilm.ch

"I have never been certain that the moral of the Icarus myth is, as =20
is generally accepted, 'don't fly too high', or whether it might also =20=

be thought of as: 'forget about the wax and feathers, and do a better =20=

job on the wings." Stanley Kubrick

On Dec 29, 2006, at 03:52, Owen Thomas wrote:

> Support for  z39.50 servers is an excellent idea.
>
> I'm having problems, however, with searching the National Library of
> Wales server.
>
> geacprif.llgc.org.uk:210/advance
>
> Apparently, it's compatible with MARC21 searches.
>
> I would appreciate a solution to this.

No idea why this doesn't work.  The searches don't return any error  
message, so I suspect it's a configuration issue, since it connects to  
advance or MAIN*BIBMAST.  Searching also works via http://targettest.indexdata.com/n.php 
.

-- arm

On Dec 29, 2006, at 15:41, Adam R. Maxwell wrote:

> On Dec 29, 2006, at 03:52, Owen Thomas wrote:
>
>> Support for  z39.50 servers is an excellent idea.
>>
>> I'm having problems, however, with searching the National Library of
>> Wales server.
>>
>> geacprif.llgc.org.uk:210/advance
>>
>> Apparently, it's compatible with MARC21 searches.
>>
>> I would appreciate a solution to this.
>
> No idea why this doesn't work.  The searches don't return any error
> message, so I suspect it's a configuration issue, since it connects to
> advance or MAIN*BIBMAST.  Searching also works via http://targettest.indexdata.com/n.php

Okay, I poked at this a bit more.  It looks like searching with  
au="thomas" will work, but searching with just "thomas" will not.  A  
z39.50 connection to my alma mater's library has similar quirks, so  
this will likely be a common problem.  Anyone with a clue of how to  
fix it should let us know.

In the meantime, you can use ti="something" for title searches and  
au="someone" for author searches (look up CCL4 query syntax for more  
info).

-- arm

On Dec 29, 2006, at 03:52, Owen Thomas wrote:

> Support for  z39.50 servers is an excellent idea.
>
> I'm having problems, however, with searching the National Library of
> Wales server.
>
> geacprif.llgc.org.uk:210/advance
>
> Apparently, it's compatible with MARC21 searches.

I just fixed this so that the National Library of Wales and the  
Washington State University library servers (and presumably others)  
will search based on "any" field when you don't enter an explicit  
title/author/issn/etc. attribute.  What I said previously about ti and  
au still works, but is no longer required to get results.  I hope.

-- arm

On 30.12.2006, at 07:27, Adam R. Maxwell wrote:

>
> On Dec 29, 2006, at 03:52, Owen Thomas wrote:
>
>> Support for  z39.50 servers is an excellent idea.
>>
>> I'm having problems, however, with searching the National Library of
>> Wales server.
>>
>> geacprif.llgc.org.uk:210/advance
>>
>> Apparently, it's compatible with MARC21 searches.
>
> I just fixed this so that the National Library of Wales and the
> Washington State University library servers (and presumably others)
> will search based on "any" field when you don't enter an explicit
> title/author/issn/etc. attribute.  What I said previously about ti and
> au still works, but is no longer required to get results.  I hope.

A suggestion on z39.50: Has anyone tried to either contact the =20
developers of Sente or Bookend? Maybe some simple exchange format for =20=

server settings which can be used across all three apps could be =20
established? I know that the developers of both apps are very =20
responding to user's feature requests, and maybe they're willing to =20
help us out here. (forget Endnote, nobody will answer there) I get =20
the impression that you and Christian must, due to lack of =20
documentation, re-invent the wheel and maybe you could save a lot of =20
time here.

simon

--
Simon Spiegel
Steinhaldenstr. 50
8002 Z=FCrich

Telephon: ++41 44 451 5334
Mobophon: ++41 76 459 60 39

http://www.simifilm.ch

"In a world getting more and more democratic, film directing is the last
resort for dictators." Francis Ford Coppola

Simon Spiegel wrote:

> A suggestion on z39.50: Has anyone tried to either contact the
> developers of Sente or Bookend? Maybe some simple exchange format for
> server settings which can be used across all three apps could be
> established? I know that the developers of both apps are very
> responding to user's feature requests, and maybe they're willing to
> help us out here. (forget Endnote, nobody will answer there) I get
> the impression that you and Christian must, due to lack of
> documentation, re-invent the wheel and maybe you could save a lot of
> time here.
>
> simon

Books [http://sourceforge.net/projects/books-macosx/] also has z39.50
support to some extent. They seem to have similar problems with encoding
and so on as they seem to currently support only Library Catalogues using
MARC8.
I cannot test their plugins [see
http://books.aetherial.net/wordpress/?p=405] as they are unavailable in
v2.2.3b (3.0b won't run on 10.3), so I can't say anything about their
efforts.
This piece of software is published under the MIT license (other than
Sente and Bookends which Simon mentioned).

I just downloaded Bookends. They use plain text pseudo-XML "import filter"
files for z39.50 access data and the specific MARC fields that each
library is using (just guessing, I have to admit).

This looks like

##################
900+100a,100b,104,104a,104b,108a,112a,116a,200a	331a,335a591a451a,
461a,590a596a433a405a,425a,595a	260b,412a	410a,594a655e	341a,345a

Oops, the rest of my e-mail dissappeared after this strange file snippet.
Now the complete message again and without it. Sorry for 1,5 times
posting…

Cheers,
Stephan

On Sa, 30.12.2006, 12:21, Stephan Kurz wrote:

Simon Spiegel wrote:

> A suggestion on z39.50: Has anyone tried to either contact the
> developers of Sente or Bookend? Maybe some simple exchange format for
> server settings which can be used across all three apps could be
> established? I know that the developers of both apps are very
> responding to user's feature requests, and maybe they're willing to
> help us out here. (forget Endnote, nobody will answer there) I get
> the impression that you and Christian must, due to lack of
> documentation, re-invent the wheel and maybe you could save a lot of
> time here.
>
> simon

Books [http://sourceforge.net/projects/books-macosx/] also has z39.50
support to some extent. They seem to have similar problems with encoding
and so on as they seem to currently support only Library Catalogues using
MARC8.
I cannot test their plugins [see
http://books.aetherial.net/wordpress/?p=405] as they are unavailable in
v2.2.3b (3.0b won't run on 10.3), so I can't say anything about their
efforts.
This piece of software is published under the MIT license (other than
Sente and Bookends which Simon mentioned).

I just downloaded Bookends. They use plain text pseudo-XML "import filter"
files for z39.50 access data and the specific MARC fields that each
library is using (just guessing, I have to admit).

[sample file removed from e-mail as it produces an error with sending the
complete message]

But they seem also only to use MARC formats, which is a growing standard
(others like Vienna University Library are currently preparing migration
from MAB2 to MARC).

I think though, that it would not be that big an issue for BD to submit
(in yaz syntax) "format MAB" or "format GRS.1" or whatever before the
actual query.


So much for now (still not on Tiger...)
Stephan

On Dec 30, 2006, at 03:27, Stephan Kurz wrote:
>
> On Sa, 30.12.2006, 12:21, Stephan Kurz wrote:
>
> Simon Spiegel wrote:
>
>> A suggestion on z39.50: Has anyone tried to either contact the
>> developers of Sente or Bookend? Maybe some simple exchange format for
>> server settings which can be used across all three apps could be
>> established? I know that the developers of both apps are very
>> responding to user's feature requests, and maybe they're willing to
>> help us out here. (forget Endnote, nobody will answer there)

Feel free to contact Sente about this if you're using it or have some  
sort of relationship with them.  What options do they provide for  
z39.50 connections?

>> I get
>> the impression that you and Christian must, due to lack of
>> documentation, re-invent the wheel and maybe you could save a lot of
>> time here.

That impression is accurate :).  However, a reference manager is  
everyone's favorite app to reinvent, so we're not alone.

>>
>> simon
>
> Books [http://sourceforge.net/projects/books-macosx/] also has z39.50
> support to some extent. They seem to have similar problems with  
> encoding
> and so on as they seem to currently support only Library Catalogues  
> using
> MARC8.
> I cannot test their plugins [see
> http://books.aetherial.net/wordpress/?p=405] as they are unavailable  
> in
> v2.2.3b (3.0b won't run on 10.3), so I can't say anything about their
> efforts.
> This piece of software is published under the MIT license (other than
> Sente and Bookends which Simon mentioned).

I just pulled the source for Books, out of curiosity.  He's using  
Python scripts to parse MARC and convert it to XML, it looks like, and  
the server info is hardcoded into each script (which is then bundled  
into a separate application that is launched from Books).  That can be  
a good approach, but it's not very compatible with the direction we're  
taking.

> I just downloaded Bookends. They use plain text pseudo-XML "import  
> filter"
> files for z39.50 access data and the specific MARC fields that each
> library is using (just guessing, I have to admit).

Based on that sample you posted, we're not going to imitate Bookends  
in this regard :).  Thanks for checking, though.

> [sample file removed from e-mail as it produces an error with  
> sending the
> complete message]
>
> But they seem also only to use MARC formats, which is a growing  
> standard
> (others like Vienna University Library are currently preparing  
> migration
> from MAB2 to MARC).
>
> I think though, that it would not be that big an issue for BD to  
> submit
> (in yaz syntax) "format MAB" or "format GRS.1" or whatever before the
> actual query.

It's trivial for us to retrieve records in other formats.  The problem  
is that we don't have parsers for MAB/SUTRS/GRS-1 at present, and  
can't even find documentation for SUTRS.  Good thing Christiaan wrote  
a MARC parser a few weeks ago!

-- arm

On Dec 29, 2006, at 02:37, Will Tuladhar-Douglas wrote:

> Now for the problem - I tried accessing COPAC, the catalogus
> catalogorum for UK libraries, and it caused a crash. This may be
> because COPAC does not support Marc format records (sutrs and grs-1
> only); Sente has always choked on Copac as well, but it is one of the
> most important bibliographic resources in Europe.
>
> Access details: z3950.copac.ac.uk port 210 dbname copac. For further
> info see http://copac.ac.uk/interfaces/z39.50/zed-support/

Try the next nightly build.  Unless I broke something else, COPAC  
should work at a minimal level; they support Dublin Core XML, which is  
pretty easy to parse, but doesn't translate perfectly to BibTeX.

-- arm

On Dec 29, 2006, at 6:31 PM, Adam R. Maxwell wrote:

> MARC (USMARC/MARC21) is a requirement at present.  If you can find a
> specification for SUTRS or GRS-1 syntax, we can look into it.
>
After a bit of digging:

SUTRS = Simple Unstructured Text Record Syntax.

Exhaustive description under Z39.50 standards defintions at LoC, see  
http://www.loc.gov/z3950/agency/asn1.html#RecordSyntax-SUTRS

 From http://epub.mimas.ac.uk/papers/macappslwow4_full.html

"The SUTRS format is similar to that displayed as the result of a  
search using the Web interface, but as plain text without the HTML  
tags. The simple tagged format returns fields of the record preceded  
by a token, e.g. TI: precedes a title, again in plain text. This  
format may be used for importing citations into a personal  
bibliographic database."

An example is given there. Given the existing parsing code within  
Bibdesk this looks like an easy victory and a major one.

GRS-1 looks somewhat less trivial; see http://www.loc.gov/z3950/ 
agency/defns/tag-gm.html

Hope that helps.

-WBTD.

_ _ __ ___ _____ ________
Will Tuladhar-Douglas
w.t.douglas@...

On 30.12.2006, at 18:20, Adam R. Maxwell wrote:

>
> On Dec 30, 2006, at 03:27, Stephan Kurz wrote:
>>
>> On Sa, 30.12.2006, 12:21, Stephan Kurz wrote:
>>
>> Simon Spiegel wrote:
>>
>>> A suggestion on z39.50: Has anyone tried to either contact the
>>> developers of Sente or Bookend? Maybe some simple exchange format =20=

>>> for
>>> server settings which can be used across all three apps could be
>>> established? I know that the developers of both apps are very
>>> responding to user's feature requests, and maybe they're willing to
>>> help us out here. (forget Endnote, nobody will answer there)
>
> Feel free to contact Sente about this if you're using it or have some
> sort of relationship with them.  What options do they provide for
> z39.50 connections?

By now you must have gotten the mail I send to you and the developers =20=

of Bookends, Sente and Books. Jon of Sonny Software (Bookends) has =20
replied me privately. He wasn't too much interested, but maybe the =20
following is useful to you:

>> To be really concrete here: At the moment, z39.50 is integrated =20
>> into BibDesk, users from all over the world ask the developers to =20
>> include the servers of the libraries they use and everybody tries =20
>> to find out how to connect to his server and what information is =20
>> needed. It's not yet decided how this all will be integrated into =20
>> BibDesk, but information is flowing in from all sides. This seems =20
>> like a huge waste of time and energy to me, since much of this =20
>> information is already available in the existing apps. And even if =20=

>> it was not, every new app which comes after BibDesk would have to =20
>> do the same all over again, just because no centralized repository =20=

>> exist (Actually, Endnote has such a repository, but since they use =20=

>> a proprietary format, it doesn't help anyone besides Endnote =20
>> users). But let's say BibDesk uses a format for connection files =20
>> which can also be used by Bookends and Sente. Suddenly, we have =20
>> the users of all three apps participating in the repository. This =20
>> seems like a win-win situation to me.
>>
>>
>
> Concrete is good. I don't disagree with your intent, but as I said, =20=

> we all use different connection files (filters) because we all =20
> implement z39.50 differently and we all do different things with =20
> the data we retrieve (by different, I mean in the details). Being =20
> concrete, I see no way of having a standard file format that would =20
> satisfy the different applications, and I certainly don't see any =20
> of us being tied to a particular format (that we can't change if we =20=

> want to add new features). That's why I said there conceivably =20
> could be some sort of "metafile" format that contained the basic =20
> information that we could import into one of our connection files/=20
> filters. As it is now, BTW, it's pretty easy to open up an EN =20
> connection file (the EN demo is free to all) and copy the relevant =20
> information to one of our filters. So whatever developed (if =20
> anything) would have to be considerably easier. I'm skeptical that =20
> anything would be.
>
> Jon
> Sonny Software

simon


--
Simon Spiegel
Steinhaldenstr. 50
8002 Z=FCrich

Telephon: ++41 44 451 5334
Mobophon: ++41 76 459 60 39


http://www.simifilm.ch

"Was soll aus mir mal werden, wenn ich mal nicht mehr bin?" Robert =20
Gernhardt

On Dec 29, 2006, at 13:03, Simon Spiegel wrote:

>>> I tested it with the following  Swiss libraries
>>>
>>> opac.nebis.ch Port: 9909 Database: NEBIS
>>> aleph.unibas.ch Port: 9909 Database: IDS_ANSEL
>>> biblio.unizh.ch Port: 9909 Database: uzh01 Login: z39 Password: z39
[...]
>>> There
>>> definitely are problems with special characters though. Searching
>>> terms with umlauts seem to be completely ignored and in the the
>>> retrieved information, results are mixed. With nebis and unibas.ch,
>>> umlauts aren't properly rendered, with unizh.ch they are displayed
>>> just fine. I guess this depends on the encoding of the results, =20
>>> maybe
>>> this should also be definable by the user.

I think I've fixed the encoding problems with display of results, but =20=

would appreciate some testing.  If anyone knows of a z39.50 server =20
that returns UTF-8, let me know.

Searching for "Zurich" appears to match "Z=FCrich", so it's not clear =20=

how accents should be handled.  What do other apps do in this regard?

-- arm=

On 01.01.2007, at 02:09, Adam R. Maxwell wrote:

>
> On Dec 29, 2006, at 13:03, Simon Spiegel wrote:
>
>>>> I tested it with the following  Swiss libraries
>>>>
>>>> opac.nebis.ch Port: 9909 Database: NEBIS
>>>> aleph.unibas.ch Port: 9909 Database: IDS_ANSEL
>>>> biblio.unizh.ch Port: 9909 Database: uzh01 Login: z39 Password: z39
> [...]
>>>> There
>>>> definitely are problems with special characters though. Searching
>>>> terms with umlauts seem to be completely ignored and in the the
>>>> retrieved information, results are mixed. With nebis and unibas.ch,
>>>> umlauts aren't properly rendered, with unizh.ch they are displayed
>>>> just fine. I guess this depends on the encoding of the results,
>>>> maybe
>>>> this should also be definable by the user.
>
> I think I've fixed the encoding problems with display of results, but
> would appreciate some testing.  If anyone knows of a z39.50 server
> that returns UTF-8, let me know.
>
> Searching for "Zurich" appears to match "Z=FCrich", so it's not clear
> how accents should be handled.  What do other apps do in this regard?

I check it out, as soon as a nightly is available (I had problems =20
compiling BibDesk myself lately).

I you want to check it, aleph.unibas.ch seems to be able to handle =20
both ANSEL and UTF-8.

See this page for details: http://www.ub.unibas.ch/lib/aleph/=20
z3950.htm (it's in German, but I guess you'll find all information =20
needed).

As for "Zurich" and "Z=FCrich". I think it's ok, if the search "Zurich" =20=

also matches "Z=FCrich", I wouldn't consider this a bug or a big =20
problem. But what's really important is that the search term "Z=FCrich" =20=

produces a result.

simon


--
Simon Spiegel
Steinhaldenstr. 50
8002 Z=FCrich

Telephon: ++41 44 451 5334
Mobophon: ++41 76 459 60 39

http://www.simifilm.ch

"I'm not that easy to impress. =96 O, a blue car." Homer Simpson

On Jan 1, 2007, at 01:58, Simon Spiegel wrote:

> On 01.01.2007, at 02:09, Adam R. Maxwell wrote:
>
>> I think I've fixed the encoding problems with display of results, but
>> would appreciate some testing.  If anyone knows of a z39.50 server
>> that returns UTF-8, let me know.
>>
>> Searching for "Zurich" appears to match "Z=FCrich", so it's not clear
>> how accents should be handled.  What do other apps do in this regard?
>
> I check it out, as soon as a nightly is available (I had problems
> compiling BibDesk myself lately).

What sort of problems compiling?  Be sure to svn update =20
bibdesk_vendorsrc, and make sure the Bibdesk.xcodeproj is closed when =20=

you do that.

> I you want to check it, aleph.unibas.ch seems to be able to handle
> both ANSEL and UTF-8.

Thanks, I'll do that.  BTW, what is ANSEL?  I've only seen that in =20
Endnote's interface.

> As for "Zurich" and "Z=FCrich". I think it's ok, if the search =
"Zurich"
> also matches "Z=FCrich", I wouldn't consider this a bug or a big
> problem. But what's really important is that the search term "Z=FCrich"
> produces a result.

Yeah, I agree.  We're passing it to zoom as UTF-8, but it's not =20
handling it correctly, apparently.    As a last resort we can remove =20
diacritics from search strings.

-- arm

On 01.01.2007, at 17:23, Adam R. Maxwell wrote:

>
> On Jan 1, 2007, at 01:58, Simon Spiegel wrote:
>
>> On 01.01.2007, at 02:09, Adam R. Maxwell wrote:
>>
>>> I think I've fixed the encoding problems with display of results, =20=

>>> but
>>> would appreciate some testing.  If anyone knows of a z39.50 server
>>> that returns UTF-8, let me know.
>>>
>>> Searching for "Zurich" appears to match "Z=FCrich", so it's not =
clear
>>> how accents should be handled.  What do other apps do in this =20
>>> regard?
>>
>> I check it out, as soon as a nightly is available (I had problems
>> compiling BibDesk myself lately).
>
> What sort of problems compiling?  Be sure to svn update
> bibdesk_vendorsrc, and make sure the Bibdesk.xcodeproj is closed when
> you do that.

I get the following when compiling BibDesk itself:

     cd /Volumes/Daten/Bib/bibdesk
     /usr/bin/gcc-4.0 -x objective-c-header -arch ppc -pipe -Wno-=20
trigraphs -fobjc-exceptions -fpascal-strings -fasm-blocks -Os -=20
Wreturn-type -Wformat -fmessage-length=3D0 -fzero-link -mtune=3DG4 -=20
mmacosx-version-min=3D10.4 -I/Volumes/Daten/Developer/Bibdesk.build/=20
Default/BibDesk.build/BibDesk.hmap -F/Volumes/Daten/Developer/Default =20=

-I/Volumes/Daten/Developer/Default/include -I/Volumes/Daten/Developer/=20=

Bibdesk.build/Default/BibDesk.build/DerivedSources -isysroot /=20
Developer/SDKs/MacOSX10.4u.sdk -c /Volumes/Daten/Bib/bibdesk/=20
Bibdesk_Prefix.pch -o /Library/Caches/com.apple.Xcode.501/=20
SharedPrecompiledHeaders/Bibdesk_Prefix-daoatgpngjmkjgcnmgipknuospsb/=20
Bibdesk_Prefix.pch.gch
/Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:11:34: error: OmniBase/=20
OmniBase.h: No such file or directory
/Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:12:46: error: =20
OmniFoundation/OmniFoundation.h: No such file or directory
/Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:13:38: error: =20
OmniAppKit/OmniAppKit.h: No such file or directory
In file included from /Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:14:
/Volumes/Daten/Bib/bibdesk/NSString_BDSKExtensions.h:38:56: error: =20
OmniFoundation/NSMutableString-OFExtensions.h: No such file or directory
In file included from /Volumes/Daten/Bib/bibdesk/BDSKComplexString.h:40,
                  from /Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:15:
/Volumes/Daten/Bib/bibdesk/BibPrefController.h:36:40: error: =20
OmniFoundation/OFPreference.h: No such file or directory
In file included from /Volumes/Daten/Bib/bibdesk/BDSKComplexString.h:40,
                  from /Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:15:
/Volumes/Daten/Bib/bibdesk/BibPrefController.h:55: error: cannot find =20=

interface declaration for 'OAPreferenceController'
	/Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:11:34: error: =
OmniBase/=20
OmniBase.h: No such file or directory
	/Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:12:46: error: =20
OmniFoundation/OmniFoundation.h: No such file or directory
	/Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:13:38: error: =20
OmniAppKit/OmniAppKit.h: No such file or directory
	In file included from =
/Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:14:
		=
/Volumes/Daten/Bib/bibdesk/NSString_BDSKExtensions.h:38:56: error: =20
OmniFoundation/NSMutableString-OFExtensions.h: No such file or directory
	                 from =
/Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:15:
		In file included from /Volumes/Daten/Bib/bibdesk/=20
BDSKComplexString.h:40,
			=
/Volumes/Daten/Bib/bibdesk/BibPrefController.h:36:40: error: =20
OmniFoundation/OFPreference.h: No such file or directory
	                 from =
/Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:15:
		In file included from /Volumes/Daten/Bib/bibdesk/=20
BDSKComplexString.h:40,
			=
/Volumes/Daten/Bib/bibdesk/BibPrefController.h:55: error: cannot =20
find interface declaration for 'OAPreferenceController'

I think it's relaed to the build prefs. I set both, build products =20
and intermediate build files, up in the same directory which is =20
different from the one the source files are in. I understand that =20
this is the proper way to do it, but obviously, there is a problem.

>
>> I you want to check it, aleph.unibas.ch seems to be able to handle
>> both ANSEL and UTF-8.
>
> Thanks, I'll do that.  BTW, what is ANSEL?  I've only seen that in
> Endnote's interface.

No idea.

simon

--
Simon Spiegel
Steinhaldenstr. 50
8002 Z=FCrich

Telephon: ++41 44 451 5334
Mobophon: ++41 76 459 60 39

http://www.simifilm.ch

"In a world getting more and more democratic, film directing is the last
resort for dictators." Francis Ford Coppola

On Jan 1, 2007, at 09:43, Simon Spiegel wrote:

>
> On 01.01.2007, at 17:23, Adam R. Maxwell wrote:
>
>>
>> On Jan 1, 2007, at 01:58, Simon Spiegel wrote:
>>
>>> On 01.01.2007, at 02:09, Adam R. Maxwell wrote:
>>>
>>>> I think I've fixed the encoding problems with display of results,
>>>> but
>>>> would appreciate some testing.  If anyone knows of a z39.50 server
>>>> that returns UTF-8, let me know.
>>>>
>>>> Searching for "Zurich" appears to match "Z=FCrich", so it's not =
clear
>>>> how accents should be handled.  What do other apps do in this
>>>> regard?
>>>
>>> I check it out, as soon as a nightly is available (I had problems
>>> compiling BibDesk myself lately).
>>
>> What sort of problems compiling?  Be sure to svn update
>> bibdesk_vendorsrc, and make sure the Bibdesk.xcodeproj is closed when
>> you do that.

I just uploaded a new nightly, if you want to play around with it.

> I get the following when compiling BibDesk itself:
[...]
>
> 			=
/Volumes/Daten/Bib/bibdesk/BibPrefController.h:36:40: error:
> OmniFoundation/OFPreference.h: No such file or directory
> 	                 from =
/Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:=20
> 15:
> 		In file included from /Volumes/Daten/Bib/bibdesk/
> BDSKComplexString.h:40,
> 			=
/Volumes/Daten/Bib/bibdesk/BibPrefController.h:55: error: cannot
> find interface declaration for 'OAPreferenceController'
>
> I think it's relaed to the build prefs. I set both, build products
> and intermediate build files, up in the same directory which is
> different from the one the source files are in. I understand that
> this is the proper way to do it, but obviously, there is a problem.

That should work fine.  Make sure that bibdesk_vendorsrc is up to =20
date.  If it is, open Bibdesk.xcodeproj and make the BuildMeFirst =20
target active, then clean and rebuild it.  If that builds =20
successfully, switch to the BibDesk target and clean/rebuild it as =20
well.  Let us know if there are problems, since we like to keep that =20
easy for non-developers.

>>> I you want to check it, aleph.unibas.ch seems to be able to handle
>>> both ANSEL and UTF-8.
>>
>> Thanks, I'll do that.  BTW, what is ANSEL?  I've only seen that in
>> Endnote's interface.
>
> No idea.

Looks like it's part of MARC-8, which is the standard encoding for =20
USMARC; we now convert that to UTF-8 internally, so it should display =20=

correctly.

-- arm

On 01.01.2007, at 18:52, Adam R. Maxwell wrote:

>
> On Jan 1, 2007, at 09:43, Simon Spiegel wrote:
>
>>
>> On 01.01.2007, at 17:23, Adam R. Maxwell wrote:
>>
>>>
>>> On Jan 1, 2007, at 01:58, Simon Spiegel wrote:
>>>
>>>> On 01.01.2007, at 02:09, Adam R. Maxwell wrote:
>>>>
>>>>> I think I've fixed the encoding problems with display of results,
>>>>> but
>>>>> would appreciate some testing.  If anyone knows of a z39.50 server
>>>>> that returns UTF-8, let me know.
>>>>>
>>>>> Searching for "Zurich" appears to match "Z=C3=BCrich", so it's not =
=20
>>>>> clear
>>>>> how accents should be handled.  What do other apps do in this
>>>>> regard?
>>>>
>>>> I check it out, as soon as a nightly is available (I had problems
>>>> compiling BibDesk myself lately).
>>>
>>> What sort of problems compiling?  Be sure to svn update
>>> bibdesk_vendorsrc, and make sure the Bibdesk.xcodeproj is closed =20
>>> when
>>> you do that.
>
> I just uploaded a new nightly, if you want to play around with it.
>
>> I get the following when compiling BibDesk itself:
> [...]
>>
>> 			=
/Volumes/Daten/Bib/bibdesk/BibPrefController.h:36:40: error:
>> OmniFoundation/OFPreference.h: No such file or directory
>> 	                 from =
/Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:
>> 15:
>> 		In file included from /Volumes/Daten/Bib/bibdesk/
>> BDSKComplexString.h:40,
>> 			=
/Volumes/Daten/Bib/bibdesk/BibPrefController.h:55: error: cannot
>> find interface declaration for 'OAPreferenceController'
>>
>> I think it's relaed to the build prefs. I set both, build products
>> and intermediate build files, up in the same directory which is
>> different from the one the source files are in. I understand that
>> this is the proper way to do it, but obviously, there is a problem.
>
> That should work fine.  Make sure that bibdesk_vendorsrc is up to
> date.  If it is, open Bibdesk.xcodeproj and make the BuildMeFirst
> target active, then clean and rebuild it.  If that builds
> successfully, switch to the BibDesk target and clean/rebuild it as
> well.  Let us know if there are problems, since we like to keep that
> easy for non-developers.

I used the getBibDeskSVN script. Do I need to update anything else by =20=

hand if I use this script? I had all directories deleted before I =20
started the script.
>
>>>> I you want to check it, aleph.unibas.ch seems to be able to handle
>>>> both ANSEL and UTF-8.
>>>
>>> Thanks, I'll do that.  BTW, what is ANSEL?  I've only seen that in
>>> Endnote's interface.
>>
>> No idea.
>
> Looks like it's part of MARC-8, which is the standard encoding for
> USMARC; we now convert that to UTF-8 internally, so it should display
> correctly.


I'm just using the latest nightly. I like the new design of the =20
Search group settings window. Adding a server doesn't work yet, but I =20=

guess that's known. Oh, and why is one group of search servers called =20=

"Entrez"?

Searching IDS_UTF at aleph.unibas.ch now works with umlauts in the =20
search term, but the results are still rendered incorrectly, though =20
in a different incorrectly than before I think. Search for =20
"au=3Dw=C3=BCnsch" gives me results with "W=C2=A9=C6=A1nsch" as author.

simon


--
Simon Spiegel
Steinhaldenstr. 50
8002 Z=C3=BCrich

Telephon: ++41 44 451 5334
Mobophon: ++41 76 459 60 39


http://www.simifilm.ch

"I have never been certain that the moral of the Icarus myth is, as =20
is generally accepted, 'don't fly too high', or whether it might also =20=

be thought of as: 'forget about the wax and feathers, and do a better =20=

job on the wings." Stanley Kubrick

On Jan 1, 2007, at 10:02, Simon Spiegel wrote:

>
> On 01.01.2007, at 18:52, Adam R. Maxwell wrote:
>
>>
>> That should work fine.  Make sure that bibdesk_vendorsrc is up to
>> date.  If it is, open Bibdesk.xcodeproj and make the BuildMeFirst
>> target active, then clean and rebuild it.  If that builds
>> successfully, switch to the BibDesk target and clean/rebuild it as
>> well.  Let us know if there are problems, since we like to keep that
>> easy for non-developers.
>
> I used the getBibDeskSVN script. Do I need to update anything else by
> hand if I use this script? I had all directories deleted before I
> started the script.

It should work.  In terminal, cd to the bibdesk_vendorsrc directory =20
and run `svn update` manually to make sure you're up to date; if not, =20=

let us know.  When you open the Bibdesk.xcodeproj, do any of =20
the .xcodproj files from Subprojects show up as red in its main table?

You might want to manually remove the contents of your build directory =20=

(intermediates and products), then clean and build BuildMeFirst.

>>
>>>>> I you want to check it, aleph.unibas.ch seems to be able to handle
>>>>> both ANSEL and UTF-8.
>>>>
>>>> Thanks, I'll do that.  BTW, what is ANSEL?  I've only seen that in
>>>> Endnote's interface.
>>>
>>> No idea.
>>
>> Looks like it's part of MARC-8, which is the standard encoding for
>> USMARC; we now convert that to UTF-8 internally, so it should display
>> correctly.
>
>
> I'm just using the latest nightly. I like the new design of the
> Search group settings window. Adding a server doesn't work yet, but I
> guess that's known.

You just can't save them, since we haven't fully worked out the file =20
format details.

> Searching IDS_UTF at aleph.unibas.ch now works with umlauts in the
> search term, but the results are still rendered incorrectly, though
> in a different incorrectly than before I think. Search for
> "au=3Dw=C3=BCnsch" gives me results with "W=C2=A9=C6=A1nsch" as =
author.

Does it display correctly if you use IDS_ANSEL?  The server shouldn't =20=

be sending USMARC as UTF-8, I think, but we'll have to add an encoding =20=

popup to deal with this.

Adam

On 01.01.2007, at 19:19, Adam R. Maxwell wrote:

>
> On Jan 1, 2007, at 10:02, Simon Spiegel wrote:
>
>>
>> On 01.01.2007, at 18:52, Adam R. Maxwell wrote:
>>
>>>
>>> That should work fine.  Make sure that bibdesk_vendorsrc is up to
>>> date.  If it is, open Bibdesk.xcodeproj and make the BuildMeFirst
>>> target active, then clean and rebuild it.  If that builds
>>> successfully, switch to the BibDesk target and clean/rebuild it as
>>> well.  Let us know if there are problems, since we like to keep that
>>> easy for non-developers.
>>
>> I used the getBibDeskSVN script. Do I need to update anything else by
>> hand if I use this script? I had all directories deleted before I
>> started the script.
>
> It should work.  In terminal, cd to the bibdesk_vendorsrc directory
> and run `svn update` manually to make sure you're up to date; if not,
> let us know.

This gives me "At revision 8991." which I guess means it's okay.


> When you open the Bibdesk.xcodeproj, do any of
> the .xcodproj files from Subprojects show up as red in its main table?

No.
>
> You might want to manually remove the contents of your build directory
> (intermediates and products), then clean and build BuildMeFirst.

Did all that, still no luck:

Building target =E2=80=9CBibDesk=E2=80=9D of project =E2=80=9CBibdesk=E2=80=
=9D with =20
configuration =E2=80=9CDefault=E2=80=9D =E2=80=94 (6 errors)
	    cd /Volumes/Daten/Bib/bibdesk
     /usr/bin/gcc-4.0 -x objective-c-header -arch ppc -pipe -Wno-=20
trigraphs -fobjc-exceptions -fpascal-strings -fasm-blocks -Os -=20
Wreturn-type -Wformat -fmessage-length=3D0 -fzero-link -mtune=3DG4 -=20
mmacosx-version-min=3D10.4 -I/Volumes/Daten/Developer/Bibdesk.build/=20
Default/BibDesk.build/BibDesk.hmap -F/Volumes/Daten/Developer/Default =20=

-I/Volumes/Daten/Developer/Default/include -I/Volumes/Daten/Developer/=20=

Bibdesk.build/Default/BibDesk.build/DerivedSources -isysroot /=20
Developer/SDKs/MacOSX10.4u.sdk -c /Volumes/Daten/Bib/bibdesk/=20
Bibdesk_Prefix.pch -o /Library/Caches/com.apple.Xcode.501/=20
SharedPrecompiledHeaders/Bibdesk_Prefix-daoatgpngjmkjgcnmgipknuospsb/=20
Bibdesk_Prefix.pch.gch
/Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:11:34: error: OmniBase/=20
OmniBase.h: No such file or directory
/Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:12:46: error: =20
OmniFoundation/OmniFoundation.h: No such file or directory
/Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:13:38: error: =20
OmniAppKit/OmniAppKit.h: No such file or directory
In file included from /Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:14:
/Volumes/Daten/Bib/bibdesk/NSString_BDSKExtensions.h:38:56: error: =20
OmniFoundation/NSMutableString-OFExtensions.h: No such file or directory
In file included from /Volumes/Daten/Bib/bibdesk/BDSKComplexString.h:40,
                  from /Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:15:
/Volumes/Daten/Bib/bibdesk/BibPrefController.h:36:40: error: =20
OmniFoundation/OFPreference.h: No such file or directory
In file included from /Volumes/Daten/Bib/bibdesk/BDSKComplexString.h:40,
                  from /Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:15:
/Volumes/Daten/Bib/bibdesk/BibPrefController.h:55: error: cannot find =20=

interface declaration for 'OAPreferenceController'
		/Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:11:34: =
error: =20
OmniBase/OmniBase.h: No such file or directory
		/Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:12:46: =
error: =20
OmniFoundation/OmniFoundation.h: No such file or directory
		/Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:13:38: =
error: =20
OmniAppKit/OmniAppKit.h: No such file or directory
		In file included from =
/Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:=20
14:
			=
/Volumes/Daten/Bib/bibdesk/NSString_BDSKExtensions.h:38:56: error: =20
OmniFoundation/NSMutableString-OFExtensions.h: No such file or directory
		                 from =
/Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:=20
15:
			In file included from =
/Volumes/Daten/Bib/bibdesk/=20
BDSKComplexString.h:40,
				=
/Volumes/Daten/Bib/bibdesk/BibPrefController.h:36:40: error: =20
OmniFoundation/OFPreference.h: No such file or directory
		                 from =
/Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:=20
15:
			In file included from =
/Volumes/Daten/Bib/bibdesk/=20
BDSKComplexString.h:40,
				=
/Volumes/Daten/Bib/bibdesk/BibPrefController.h:55: error: cannot =20
find interface declaration for 'OAPreferenceController'
Build failed (6 errors)

>
>>>
>
>> Searching IDS_UTF at aleph.unibas.ch now works with umlauts in the
>> search term, but the results are still rendered incorrectly, though
>> in a different incorrectly than before I think. Search for
>> "au=3Dw=C3=BCnsch" gives me results with "W=C2=A9=C6=A1nsch" as =
author.
>
> Does it display correctly if you use IDS_ANSEL?  The server shouldn't
> be sending USMARC as UTF-8, I think, but we'll have to add an encoding
> popup to deal with this.

IDS_UTF uses MARC21 (see http://www.hbz.unizh.ch/hbz_eng/index.php?=20
option=3Dcontent&task=3Dview&id=3D279&Itemid=3D223). With IDS_UTF, I can =
=20
search for umlauts, but the results are wrong.

With uzh01 (which uses USMARC and Latin-1), searching for umlauts =20
doesn't work, and the results aren't presented properly either.

BTW: Maybe it would be good to display the name of the used server in =20=

the status line. If you have several search groups, there's no quick =20
way to find out, what server you use. The server name, is only =20
displayed in the search field when there are no results. So if you =20
happen to have several search groups with the same search going on =20
(which isn't a rare scenario for me), you don't really know which =20
search happens where.

simon
--
Simon Spiegel
Steinhaldenstr. 50
8002 Z=C3=BCrich

Telephon: ++41 44 451 5334
Mobophon: ++41 76 459 60 39

http://www.simifilm.ch

"In a world getting more and more democratic, film directing is the last
resort for dictators." Francis Ford Coppola

On Jan 1, 2007, at 11:25, Simon Spiegel wrote:

>
> On 01.01.2007, at 19:19, Adam R. Maxwell wrote:
>>
>> You might want to manually remove the contents of your build =20
>> directory
>> (intermediates and products), then clean and build BuildMeFirst.
>
> Did all that, still no luck:
>
> Building target =93BibDesk=94 of project =93Bibdesk=94 with
> configuration =93Default=94 =97 (6 errors)

Oops...we need to remove the "Default" configuration.  Select =20
"Release" instead from the popup (for BuildMeFirst also) and clean/=20
build.

-- arm=

On 01.01.2007, at 20:36, Adam R. Maxwell wrote:

>
> On Jan 1, 2007, at 11:25, Simon Spiegel wrote:
>
>>
>> On 01.01.2007, at 19:19, Adam R. Maxwell wrote:
>>>
>>> You might want to manually remove the contents of your build
>>> directory
>>> (intermediates and products), then clean and build BuildMeFirst.
>>
>> Did all that, still no luck:
>>
>> Building target =93BibDesk=94 of project =93Bibdesk=94 with
>> configuration =93Default=94 =97 (6 errors)
>
> Oops...we need to remove the "Default" configuration.  Select
> "Release" instead from the popup (for BuildMeFirst also) and clean/
> build.

It now fails at a much later stage, but still:

Building target =93BibDesk=94 of project =93Bibdesk=94 with =
configuration =20
=93Release=94 =97 (1 error, 7 warnings)
	    cd /Volumes/Daten/Bib/bibdesk
     /usr/bin/gcc-4.0 -x objective-c-header -arch ppc -pipe -Wno-=20
trigraphs -fobjc-exceptions -fpascal-strings -fasm-blocks -Os -=20
Wreturn-type -Wformat -Wswitch -Wunused-function -Wunused-label -=20
Wunused-parameter -Wunused-variable -Wunused-value -Wuninitialized -=20
Wsign-compare -fmessage-length=3D0 -fobjc-direct-dispatch -mtune=3DG4 -=20=

fvisibility=3Dhidden -mmacosx-version-min=3D10.4 -I/Volumes/Daten/=20
Developer/Bibdesk.build/Release/BibDesk.build/BibDesk.hmap -Wall -Wno-=20=

parentheses -Wundeclared-selector -Wfloat-equal -Winline -mdynamic-no-=20=

pic -F/Volumes/Daten/Developer/Release -I/Volumes/Daten/Developer/=20
Release/include -I/Volumes/Daten/Developer/Bibdesk.build/Release/=20
BibDesk.build/DerivedSources -isysroot /Developer/SDKs/=20
MacOSX10.4u.sdk -c /Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch -o /=20
Library/Caches/com.apple.Xcode.501/SharedPrecompiledHeaders/=20
Bibdesk_Prefix-ersifusiqtzwewcwrqmakkjpalft/Bibdesk_Prefix.pch.gch
In file included from /Volumes/Daten/Developer/Release/=20
OmniAppKit.framework/Headers/OmniAppKit.h:58,
                  from /Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:13:
/Volumes/Daten/Developer/Release/OmniAppKit.framework/Headers/=20
OAColorPalette.h: In function 'OAColorPaletteApplyGammaAndNormalize':
/Volumes/Daten/Developer/Release/OmniAppKit.framework/Headers/=20
OAColorPalette.h:35: warning: comparing floating point with =3D=3D or !=3D=
 =20
is unsafe
In file included from /Volumes/Daten/Developer/Release/=20
OmniAppKit.framework/Headers/OmniAppKit.h:112,
                  from /Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:13:
/Volumes/Daten/Developer/Release/OmniAppKit.framework/Headers/=20
OAUtilities.h: In function 'OAFastReciprocalSquareRoot':
/Volumes/Daten/Developer/Release/OmniAppKit.framework/Headers/=20
OAUtilities.h:25: warning: comparing floating point with =3D=3D or !=3D =
is =20
unsafe
		                 from =
/Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:=20
13:
			In file included from =
/Volumes/Daten/Developer/Release/=20
OmniAppKit.framework/Headers/OmniAppKit.h:58,
				=
/Volumes/Daten/Developer/Release/OmniAppKit.framework/Headers/=20
OAColorPalette.h:35: warning: comparing floating point with =3D=3D or !=3D=
 =20
is unsafe
		                 from =
/Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:=20
13:
			In file included from =
/Volumes/Daten/Developer/Release/=20
OmniAppKit.framework/Headers/OmniAppKit.h:112,
				=
/Volumes/Daten/Developer/Release/OmniAppKit.framework/Headers/=20
OAUtilities.h:25: warning: comparing floating point with =3D=3D or !=3D =
is =20
unsafe
	    cd /Volumes/Daten/Bib/bibdesk
     /usr/bin/gcc-4.0 -x objective-c-header -arch i386 -pipe -Wno-=20
trigraphs -fobjc-exceptions -fpascal-strings -fasm-blocks -Os -=20
Wreturn-type -Wformat -Wswitch -Wunused-function -Wunused-label -=20
Wunused-parameter -Wunused-variable -Wunused-value -Wuninitialized -=20
Wsign-compare -fmessage-length=3D0 -fobjc-direct-dispatch -=20
fvisibility=3Dhidden -mmacosx-version-min=3D10.4 -I/Volumes/Daten/=20
Developer/Bibdesk.build/Release/BibDesk.build/BibDesk.hmap -Wall -Wno-=20=

parentheses -Wundeclared-selector -Wfloat-equal -Winline -mdynamic-no-=20=

pic -F/Volumes/Daten/Developer/Release -I/Volumes/Daten/Developer/=20
Release/include -I/Volumes/Daten/Developer/Bibdesk.build/Release/=20
BibDesk.build/DerivedSources -isysroot /Developer/SDKs/=20
MacOSX10.4u.sdk -c /Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch -o /=20
Library/Caches/com.apple.Xcode.501/SharedPrecompiledHeaders/=20
Bibdesk_Prefix-dbmajsszbyximzgmwpeagpoeawju/Bibdesk_Prefix.pch.gch
In file included from /Volumes/Daten/Developer/Release/=20
OmniAppKit.framework/Headers/OmniAppKit.h:58,
                  from /Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:13:
/Volumes/Daten/Developer/Release/OmniAppKit.framework/Headers/=20
OAColorPalette.h: In function 'OAColorPaletteApplyGammaAndNormalize':
/Volumes/Daten/Developer/Release/OmniAppKit.framework/Headers/=20
OAColorPalette.h:35: warning: comparing floating point with =3D=3D or !=3D=
 =20
is unsafe
		                 from =
/Volumes/Daten/Bib/bibdesk/Bibdesk_Prefix.pch:=20
13:
			In file included from =
/Volumes/Daten/Developer/Release/=20
OmniAppKit.framework/Headers/OmniAppKit.h:58,
				=
/Volumes/Daten/Developer/Release/OmniAppKit.framework/Headers/=20
OAColorPalette.h:35: warning: comparing floating point with =3D=3D or !=3D=
 =20
is unsafe
	    cd /Volumes/Daten/Bib/bibdesk
     /usr/bin/gcc-4.0 -x objective-c -arch ppc -pipe -Wno-trigraphs -=20
fobjc-exceptions -fpascal-strings -fasm-blocks -Os -Wreturn-type -=20
Wformat -Wswitch -Wunused-function -Wunused-label -Wunused-parameter -=20=

Wunused-variable -Wunused-value -Wuninitialized -Wsign-compare -=20
fmessage-length=3D0 -fobjc-direct-dispatch -mtune=3DG4 -=20
fvisibility=3Dhidden -mmacosx-version-min=3D10.4 -I/Volumes/Daten/=20
Developer/Bibdesk.build/Release/BibDesk.build/BibDesk.hmap -Wall -Wno-=20=

parentheses -Wundeclared-selector -Wfloat-equal -Winline -mdynamic-no-=20=

pic -F/Volumes/Daten/Developer/Release -I/Volumes/Daten/Developer/=20
Release/include -I/Volumes/Daten/Developer/Bibdesk.build/Release/=20
BibDesk.build/DerivedSources -isysroot /Developer/SDKs/=20
MacOSX10.4u.sdk -include /Library/Caches/com.apple.Xcode.501/=20
SharedPrecompiledHeaders/Bibdesk_Prefix-ersifusiqtzwewcwrqmakkjpalft/=20
Bibdesk_Prefix.pch -c /Volumes/Daten/Bib/bibdesk/BibDocument_Groups.m =20=

-o /Volumes/Daten/Developer/Bibdesk.build/Release/BibDesk.build/=20
Objects-normal/ppc/BibDocument_Groups.o
/Volumes/Daten/Bib/bibdesk/BibDocument_Groups.m: In function '-=20
[BibDocument(Groups) showSearchGroupView]':
/Volumes/Daten/Bib/bibdesk/BibDocument_Groups.m:168: warning: unused =20
variable 'sv'
/Volumes/Daten/Bib/bibdesk/BibDocument_Groups.m: In function '-=20
[BibDocument(Groups) addSearchGroupAction:]':
/Volumes/Daten/Bib/bibdesk/BibDocument_Groups.m:872: warning: =20
undeclared selector 'searchGroupSheetDidEnd:returnCode:contextInfo:'
		/Volumes/Daten/Bib/bibdesk/BibDocument_Groups.m:168: =
warning: =20
unused variable 'sv'
		/Volumes/Daten/Bib/bibdesk/BibDocument_Groups.m:872: =
warning: =20
undeclared selector 'searchGroupSheetDidEnd:returnCode:contextInfo:'
	    cd /Volumes/Daten/Bib/bibdesk
     /usr/bin/gcc-4.0 -x objective-c -arch ppc -pipe -Wno-trigraphs -=20
fobjc-exceptions -fpascal-strings -fasm-blocks -Os -Wreturn-type -=20
Wformat -Wswitch -Wunused-function -Wunused-label -Wunused-parameter -=20=

Wunused-variable -Wunused-value -Wuninitialized -Wsign-compare -=20
fmessage-length=3D0 -fobjc-direct-dispatch -mtune=3DG4 -=20
fvisibility=3Dhidden -mmacosx-version-min=3D10.4 -I/Volumes/Daten/=20
Developer/Bibdesk.build/Release/BibDesk.build/BibDesk.hmap -Wall -Wno-=20=

parentheses -Wundeclared-selector -Wfloat-equal -Winline -mdynamic-no-=20=

pic -F/Volumes/Daten/Developer/Release -I/Volumes/Daten/Developer/=20
Release/include -I/Volumes/Daten/Developer/Bibdesk.build/Release/=20
BibDesk.build/DerivedSources -isysroot /Developer/SDKs/=20
MacOSX10.4u.sdk -include /Library/Caches/com.apple.Xcode.501/=20
SharedPrecompiledHeaders/Bibdesk_Prefix-ersifusiqtzwewcwrqmakkjpalft/=20
Bibdesk_Prefix.pch -c /Volumes/Daten/Bib/bibdesk/=20
BDSKSearchGroupSheetController.m -o /Volumes/Daten/Developer/=20
Bibdesk.build/Release/BibDesk.build/Objects-normal/ppc/=20
BDSKSearchGroupSheetController.o
/Volumes/Daten/Bib/bibdesk/BDSKSearchGroupSheetController.m: In =20
function '-[BDSKSearchGroupSheetController selectPredefinedServer:]':
/Volumes/Daten/Bib/bibdesk/BDSKSearchGroupSheetController.m:248: =20
warning: unused variable 'servers'
/Volumes/Daten/Bib/bibdesk/BDSKSearchGroupSheetController.m: In =20
function '-[BDSKSearchGroupSheetController resetServers:]':
/Volumes/Daten/Bib/bibdesk/BDSKSearchGroupSheetController.m:342: =20
warning: undeclared selector 'resetAlertDidEnd:returnCode:contextInfo:'
		=
/Volumes/Daten/Bib/bibdesk/BDSKSearchGroupSheetController.m:248: =20
warning: unused variable 'servers'
		=
/Volumes/Daten/Bib/bibdesk/BDSKSearchGroupSheetController.m:342: =20
warning: undeclared selector 'resetAlertDidEnd:returnCode:contextInfo:'
	    cd /Volumes/Daten/Bib/bibdesk
     /usr/bin/gcc-4.0 -x objective-c -arch ppc -pipe -Wno-trigraphs -=20
fobjc-exceptions -fpascal-strings -fasm-blocks -Os -Wreturn-type -=20
Wformat -Wswitch -Wunused-function -Wunused-label -Wunused-parameter -=20=

Wunused-variable -Wunused-value -Wuninitialized -Wsign-compare -=20
fmessage-length=3D0 -fobjc-direct-dispatch -mtune=3DG4 -=20
fvisibility=3Dhidden -mmacosx-version-min=3D10.4 -I/Volumes/Daten/=20
Developer/Bibdesk.build/Release/BibDesk.build/BibDesk.hmap -Wall -Wno-=20=

parentheses -Wundeclared-selector -Wfloat-equal -Winline -mdynamic-no-=20=

pic -F/Volumes/Daten/Developer/Release -I/Volumes/Daten/Developer/=20
Release/include -I/Volumes/Daten/Developer/Bibdesk.build/Release/=20
BibDesk.build/DerivedSources -isysroot /Developer/SDKs/=20
MacOSX10.4u.sdk -include /Library/Caches/com.apple.Xcode.501/=20
SharedPrecompiledHeaders/Bibdesk_Prefix-ersifusiqtzwewcwrqmakkjpalft/=20
Bibdesk_Prefix.pch -c /Volumes/Daten/Bib/bibdesk/=20
BDSKEntrezGroupServer.m -o /Volumes/Daten/Developer/Bibdesk.build/=20
Release/BibDesk.build/Objects-normal/ppc/BDSKEntrezGroupServer.o
/Volumes/Daten/Bib/bibdesk/BDSKEntrezGroupServer.m: In function '-=20
[BDSKEntrezGroupServer dealloc]':
/Volumes/Daten/Bib/bibdesk/BDSKEntrezGroupServer.m:73: error: =20
'publications' undeclared (first use in this function)
/Volumes/Daten/Bib/bibdesk/BDSKEntrezGroupServer.m:73: error: (Each =20
undeclared identifier is reported only once
/Volumes/Daten/Bib/bibdesk/BDSKEntrezGroupServer.m:73: error: for =20
each function it appears in.)
		/Volumes/Daten/Bib/bibdesk/BDSKEntrezGroupServer.m:73: =
error: =20
'publications' undeclared (first use in this function)
Build failed (1 error, 7 warnings)

--
Dr. des. Simon Spiegel
EDV-Koordinator

Seminar f=FCr Filmwissenschaft
Plattenstrasse 54
CH-8032 Z=FCrich
+41 44 634 35 37
 http://www.film.unizh.ch

B=FCro: Wilfriedstrasse 6, Raum 006, +41 44 634 35 06

On Jan 1, 2007, at 12:09, Simon Spiegel wrote:

> 		/Volumes/Daten/Bib/bibdesk/BDSKEntrezGroupServer.m:73: error:
> 'publications' undeclared (first use in this function)
> Build failed (1 error, 7 warnings)

svn update and try again; I just checked in a fix for that error.

On 01.01.2007, at 21:42, Adam R. Maxwell wrote:

>
> On Jan 1, 2007, at 12:09, Simon Spiegel wrote:
>
>> 		/Volumes/Daten/Bib/bibdesk/BDSKEntrezGroupServer.m:73: =
error:
>> 'publications' undeclared (first use in this function)
>> Build failed (1 error, 7 warnings)
>
> svn update and try again; I just checked in a fix for that error.

Ok, that did the trick. I can report a successful build.

simon
--
Simon Spiegel
Steinhaldenstr. 50
8002 Z=FCrich

Telephon: ++41 44 451 5334
Mobophon: ++41 76 459 60 39


http://www.simifilm.ch

"Was soll aus mir mal werden, wenn ich mal nicht mehr bin?" Robert =20
Gernhardt

On Jan 1, 2007, at 11:25, Simon Spiegel wrote:

>>> Searching IDS_UTF at aleph.unibas.ch now works with umlauts in the
>>> search term, but the results are still rendered incorrectly, though
>>> in a different incorrectly than before I think. Search for
>>> "au=3Dw=C3=BCnsch" gives me results with "W=C2=A9=C6=A1nsch" as =
author.
>>
>> Does it display correctly if you use IDS_ANSEL?  The server shouldn't
>> be sending USMARC as UTF-8, I think, but we'll have to add an =20
>> encoding
>> popup to deal with this.
>
> IDS_UTF uses MARC21 (see http://www.hbz.unizh.ch/hbz_eng/index.php?
> option=3Dcontent&task=3Dview&id=3D279&Itemid=3D223). With IDS_UTF, I =
can
> search for umlauts, but the results are wrong.

I haven't tried that server.  UB Basel lists their IDS_UTF database as =20=

USMARC, and they also incorrectly send a UTF-8 marker with MARC-8 =20
encoded data.  Because of that, I'm giving up on detecting the =20
encoding.  We now display a combo box that allows you to enter a =20
specific encoding.

> With uzh01 (which uses USMARC and Latin-1), searching for umlauts
> doesn't work, and the results aren't presented properly either.

With current svn or the next nightly, see if it works correctly.  =20
There's now an option to remove diacritics when searching, since I =20
can't get MARC-8 servers to correctly handle them; passing as UTF-8 =20
and MARC-8 both result in broken behavior.

> BTW: Maybe it would be good to display the name of the used server in
> the status line. If you have several search groups, there's no quick
> way to find out, what server you use. The server name, is only
> displayed in the search field when there are no results. So if you
> happen to have several search groups with the same search going on
> (which isn't a rare scenario for me), you don't really know which
> search happens where.

This should be doable.  File a bug or feature request so we don't =20
forget.  Maybe the group class itself should have a toolTipValue =20
accessor for custom tooltip display, as well.

-- arm=

On 02.01.2007, at 01:03, Adam R. Maxwell wrote:

>
> On Jan 1, 2007, at 11:25, Simon Spiegel wrote:
>
>>>> Searching IDS_UTF at aleph.unibas.ch now works with umlauts in the
>>>> search term, but the results are still rendered incorrectly, though
>>>> in a different incorrectly than before I think. Search for
>>>> "au=3Dw=C3=BCnsch" gives me results with "W=C2=A9=C6=A1nsch" as =
author.
>>>
>>> Does it display correctly if you use IDS_ANSEL?  The server =20
>>> shouldn't
>>> be sending USMARC as UTF-8, I think, but we'll have to add an
>>> encoding
>>> popup to deal with this.
>>
>> IDS_UTF uses MARC21 (see http://www.hbz.unizh.ch/hbz_eng/index.php?
>> option=3Dcontent&task=3Dview&id=3D279&Itemid=3D223). With IDS_UTF, I =
can
>> search for umlauts, but the results are wrong.
>
> I haven't tried that server.  UB Basel lists their IDS_UTF database as
> USMARC, and they also incorrectly send a UTF-8 marker with MARC-8
> encoded data.  Because of that, I'm giving up on detecting the
> encoding.  We now display a combo box that allows you to enter a
> specific encoding.

Ok, but there's still something not working. The search =20
"au=3Dw=C3=BCnsch" (which definitely should produce something) gives me =
an =20
empty search window. The status bar says "0 publications in search =20
group "au=3Dw=C3=BCnsch" . There were 114 matches. Hit "Search" to load =20=

more." Clicking search doesn't bring up results though. Somehow the =20
search seems to have been made, but the results aren't displayed. The =20=

same happens with "au=3Dwuensch".

If I search for "au=3Dwunsch", I get results, but only 17 out of 65 =20
matches are displayed.

There also remain problems with unizh.ch: If I chose "remove =20
diacritics", "au=3Dw=C3=BCnsch" results in a search for "wunsch", which =
is =20
wrong. And the results are stil not displayed properly.


This is with a build with a latest checkins.

>
>> With uzh01 (which uses USMARC and Latin-1), searching for umlauts
>> doesn't work, and the results aren't presented properly either.
>
> With current svn or the next nightly, see if it works correctly.
> There's now an option to remove diacritics when searching, since I
> can't get MARC-8 servers to correctly handle them; passing as UTF-8
> and MARC-8 both result in broken behavior.

See above.
>
>> BTW: Maybe it would be good to display the name of the used server in
>> the status line. If you have several search groups, there's no quick
>> way to find out, what server you use. The server name, is only
>> displayed in the search field when there are no results. So if you
>> happen to have several search groups with the same search going on
>> (which isn't a rare scenario for me), you don't really know which
>> search happens where.
>
> This should be doable.  File a bug or feature request so we don't
> forget.  Maybe the group class itself should have a toolTipValue
> accessor for custom tooltip display, as well.

Yeah, that's a good idea. And it would also be nice if the settings =20
of a server could be changed once the search group is created. I'll =20
file bugs for that.

simon


--
Simon Spiegel
Steinhaldenstr. 50
8002 Z=C3=BCrich

Telephon: ++41 44 451 5334
Mobophon: ++41 76 459 60 39

http://www.simifilm.ch

"I'm not that easy to impress. =E2=80=93 O, a blue car." Homer Simpson