Carolyn MCDONALD | 1 Jul 2006 15:22
Picon
Favicon

Re: Finding your library catalogue via Google - was Vendors, etc. (was "What LibraryThing means to OPACs")

Aren't there two aspects to this? The first being the ability for users to find out what exists, and the
second being their ability to identify where it is located in the physical world, or where they can obtain
it if it exists in the virtual?

I would see that for the first, we want them to be able to search everything that they can, as easily and
intuitively as possible, and preferably by going to as few places as possible. For the second, the sort of
clustering of locations etc that have been suggested already sound ideal - which depend on knowing at a
minimum where the searcher is located.

Carolyn

________________________________

From: Next generation catalogs for libraries on behalf of Grace Wiersma
Sent: Fri 30/06/2006 11:43 PM
To: NGC4LIB <at> listserv.nd.edu
Subject: Re: [NGC4LIB] Finding your library catalogue via Google - was Vendors, etc. (was "What
LibraryThing means to OPACs")

Quoting Karen Coyle:

>>What do we intend when we open our catalog to users who are searching the
web (implying searching
materials that are resolvable through the search engine)?

The catalog was opened to remote users with the first generation of Web
OPACS. Aren't the same assumptions still applicable? Surely we don't want to
go backward to a "gated community" (authentication required) where only
certain users are allowed to know what's in the library. Surely we don't
want to go toward a "smart" (dumbed-down) search that prevents users from
(Continue reading)

Dan Lester | 1 Jul 2006 19:02

Re: Did you ask? Are you asking? Are we asking? (was "People v. Collections")

Friday, June 30, 2006, 8:58:16 AM, you wrote:

>> If the library doesn't
>> have meaning or relevancy to the community then it will be much harder
>> to get the millage or budget that one might need to keep "in
>> business". It might be a board that approves things but if the public
>> in general doesn't care, and budgets get tight, then it's an easier
>> thing to cut.
KC> One thing we are REALLY bad at is showing the value of our services.
KC> This is ironic, because our services are hugely valuable.

Of course they are very valuable. But...

We don't do a decent job of selling them.

More important, they're not "sexy" or seen as "vital".  It is tough
competing with the police and fire departments, since anyone can watch
TV or read the paper to see those values almost every day.  Of course
we're hurt because most media don't cover much in the way of "good
news", but we could still improve our marketing.

Another thing making it difficult is that most people in the community
will NEVER get a library card, and most likely won't no matter how
well we market.  This is particularly true since everyone "knows that
all of the information anyone ever needs is on google".  And, these
days, a vast amount of the information that libraries have been the
exclusive resource for, is now available for free on the net. Finally,
in many communities the major press that libraries get is for "having
all those dirty books that will make my kid become gay" and all that.

(Continue reading)

Bernhard Eversberg | 3 Jul 2006 10:08
Picon
Picon
Favicon

Re: Did you ask? Are you asking? Are we asking? (was "People v. Collections")

Karen Coyle schrieb:
>
> One thing we are REALLY bad at is showing the value of our services.
> This is ironic, because our services are hugely valuable. Subscription
> to x journals (at retail) $nn / population = an impressive amount of
> money. Free internet access (at internet cafe prices) * number of hours
> * number of computer = an impressive amount of money. Library budgets
> get cut because no one understands how efficient our services are
> compared to individual access. And no one understands because we don't
> tell them.
>
We've tried to do a bit. There's a concise presentation, in English:

http://www.allegro-c.de/formate/wald/

entitled "What are libraries doing today?".
This was originally given to foreign students of computer science at
this university, and is therefore a bit biased toward the technical.
But it is now part of the English version of our Web presence.
The whys and hows of catalogs are at the core of it. But to show the
value of services, it should also give figures but presently doesn't.
Maybe we should expand it, and also do a German version ...

B. Eversberg

Jeanie McNair | 3 Jul 2006 14:03

Re: Did you ask? Are you asking? Are we asking? (was "People v. Collections")

One aspect of physical libraries, and the marketing thereof, that has not been addressed is that not all of the world's population is either computer-literate or has access to or owns a computer with internet access. When traveling within the United States, how many of us know where to look for an internet cafe? Starbucks may be wired for wireless, but that doesn't help if I don't have a laptop. Libraries need to plan for the future, but they will always serve economically and technologically challenged communities.

Jeanie McNair
Dan Lester | 3 Jul 2006 18:38

Re: Finding your library catalogue via Google - was Vendors, etc. (was "What LibraryThing means to OPACs")

Friday, June 30, 2006, 9:02:50 AM, you wrote:

KC> What are we
KC> implying by our participation in that program? What do we intend when we
KC> open our catalog to users who are searching the web (implying searching
KC> materials that are resolvable through the search engine)?

In most cases I'd expect the users to infer that they could get it on
ILL (with the usual caveats and limitations).

dan

--
Dan Lester, Data Wrangler  dan <at> RiverOfData.com 208-283-7711
3577 East Pecan, Boise, Idaho  83716-7115 USA
www.riverofdata.com  The Road Goes On Forever....

Dan Lester | 3 Jul 2006 19:20

Re: Damn straight!

Friday, June 30, 2006, 10:02:30 AM, you wrote:

KGS> As I understand it, WebTrends will only take you through transaction log
KGS> analysis (though pretty good transaction analysis): who hit you and where.
KGS> Catalogs need search analytics to provide information about the kind of
KGS> searches people are conducting, what searches work, etc.: top hits, lowest
KGS> hits, failed hits, how many searches are one, two, or three-term, whether
KGS> people are scoping you with subject/title searches, quoted searches, etc.
KGS> Plus it wouldn't hurt to have more expertise in general in LibraryLand about
KGS> understanding search.

KGS> Most decent search engines provide *some* analytical reporting capability.
KGS> It is possible to roll your own, but it underscores the limitations of
KGS> last-gen catalogs that these capabilities aren't built in. The last-gen
KGS> catalog is an inventory tool, not a discovery service.

It can be done.  See (PhD diss by my first ex-wife), WorldCat entry
below. No, it wasn't exactly what is described above, but was done
based on logs of all searches done in the system.  I know that she
found, as I've noted from informal browsing of other system search
logs, that many of the "bad searches" are because users can't type
and/or can't spell.  But you probably knew that too...

And I do agree that some further work needs to be done, and that
having it built in to an NGC would be a great feature.

dan

Title: Coincidence of user vocabulary and Library of Congress subject headings :
experiments to improve subject access in academic library online catalogs /
Author(s): Lester, Marilyn A., 1947-
Year: 1989
Description: xx, 411 leaves ; 29 cm.
Language: English
 SUBJECT(S)
Descriptor: Catalogs, On-line -- Subject access.
Subject headings -- Use studies.
Subject headings, Library of Congress.
Note(s): Vita./ Typescript (photocopy)./ Includes bibliographical references
(leaves 288-310)./ Dissertation: Thesis (Ph. D.)--University of Illinois--Urbana-Champaign,
1989./ Reproduction: Photocopy./ Ann Arbor, Mich. :/ University Microfilms International,/ 1992./ 22cm.
Class Descriptors: LC: Z695.Z8; Dewey: 025.49
Responsibility: by Marilyn A. Lester.
Material Type: Thesis/dissertation (deg); Manuscript (mss)
Document Type: Book; Archival Material
Entry: 19920820
Update: 20040528
Accession No: OCLC: 26457159
Database: WorldCat

--
Dan Lester, Data Wrangler  dan <at> RiverOfData.com 208-283-7711
3577 East Pecan, Boise, Idaho  83716-7115 USA
www.riverofdata.com  The Road Goes On Forever....

Dan Lester | 3 Jul 2006 19:31

Re: Finding your library catalogue via Google - was Vendors, etc. (was "What LibraryThing means to OPACs")

Friday, June 30, 2006, 11:24:42 AM, you wrote:

KGS> I wonder if easy/hard (fast/slow?) is not
KGS> indeed the most significant distinction (like the full-text limiter in
KGS> databases). We're talking format, but what we really mean is convenience and
KGS> speed.

Yes, format doesn't matter to most users.  They just want it, and want
it now.  Of course that sounds like the rest of us in some fast food
place....what do you mean I'll have to wait five minutes for you to
get some more fries done?

Users still wonder why we can't produce an ILL book in three days like
most articles come.  And many of them whine about it taking the three
days, too.  But if I could produce a copy of the whole book in three
days, even in unbound sheets, or PDF, or whatever, most would be
happy.

The ones who know that all the world's information is on the internet
for free naturally think we're trying to keep them from getting what
they want.  Right.  Same as our nutty local patron is sure that we're
blocking Al Jazeera when the AJ server is down.

dan

--
Dan Lester, Data Wrangler  dan <at> RiverOfData.com 208-283-7711
3577 East Pecan, Boise, Idaho  83716-7115 USA
www.riverofdata.com  The Road Goes On Forever....

Cindy Rankin | 5 Jul 2006 23:31
Favicon

Librarian database designer? (was What LibraryThing means to OPACs)


        After 12 years working in libraries I was unable to advance so I went to library school and got my degree.  That was a year ago. I am now going to school to get a MS in designing databases and systems analysis.
        I think what skills you will need as a "Librarian" will depend on where you work, who you work for, and where you want to end up.  I do not understand how anyone can say "Librarians simply aren't going to be _doing_ that sort of thing [database design, programming]."  How does s/he know??          In my current position I need SQL to understand the relational database behind my catalog (Horizon).  And I occasionally use SQL to do more efficiently what I could use the catalog software to do, or ask the vendor to do.  And when I worked for an academic library, I used MS Access (only b/c Oracle wasn't available) and XML/CSS to publish records of a collection available in the library.  The web page was linked to a MARC record within the school's catalog.
        For some of us, understanding the technologies truly enriches our performance.  For others, designing and programming are already apart of the job (whether we get the $$ or recognition for it).  For others, most of this has nothing to do with our job.  Our competencies are ever changing.
       
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(My opinion and my opinion alone.  Opinions should not be attributed to the CEAH Library or USDA.)

Cindy Rankin
CEAH Library, USDA-APHIS-VS-CEAH
(email) Cindy.L.Rankin <at> aphis.usda.gov
(catalog) http://ceah.ipac.dynixasp.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

> From:    Eric Lease Morgan <emorgan <at> ND.EDU>
Most of us couldn't design a relational database if we had to,
and most of us are unable to distinguish the difference between a
database and an index. I'm certainly not saying that understanding
these technologies are the only issues in the creation of "next
generation" library catalog...

>From Heather Yager <heather.yager <at> GMAIL.COM>
...I am currently in library school and receive mixed
messages from advisors and professors on the topic of studying
database design/theory and programming... I hear other
professors saying things like "I don't know why this is even being
taught... Librarians simply aren't going to be _doing_ that sort of
thing [database design, programming]." Meanwhile, I am convinced that the only way we are going to survive as
a profession and possibly move to the (gasp!) forefront in the
development of information organization tools is if we _do_ learn
these "sort of things", teach these things, design and generally
accept these things...knowledge of database design and programming is
going to be necessary...the contribution of a librarian who
understands computing is invaluable, whether she is directly designing
software or not.

>From Jeremy Dunck <jdunck <at> GMAIL.COM>
...My most enjoyable and productive development has been spent working with customers who knew
what sorts of problems computers were good for and how to clearly
communicate their needs.You may not really need to get down to writing SQL to gain that
perspective, ... if you want to start coding, good for you.  :)
Abigail Goben | 6 Jul 2006 04:46
Picon

Re: Librarian database designer? (was What LibraryThing means to OPACs)

May I jump on Cindy's bandwagon!  Learning database design in library school turned into about 75% of my current position--even though my business card says I'm an "Associate Editor"!  Half of a semester course made me the expert on hand when my company decided to use a database to track all of our projects and I'm still trying to fully figure out a design no one can seem to agree upon. 

Traditional library skills are still incredibly important, I wish we'd had more indepth cataloging courses (sign of true geekdom, I know).  However, knowing database design and especially programming languages makes you only that much more marketable and able to move into positions that are currently being posted (go read the job ads!). I'm jealous that students in other programs are getting more of the opportunities to learn programming languages--those classes weren't even offered to me as an option (and I'm not that far out of school).  I'll be headed back for continuing education as soon as the checkbook can cover it...but for now it's getting what's available at the public library for personal education.  If you have a chance to take those classes--GRAB IT. 
--
Abigail Goben
abigailgoben <at> gmail.com

Bill Dueber | 6 Jul 2006 17:28
Favicon

Re: Librarian database designer? (was What LibraryThing means to OPACs)

On 7/5/06, Abigail Goben <abigailgoben <at> gmail.com> wrote:
> May I jump on Cindy's bandwagon!  Learning database design in library school
> turned into about 75% of my current position--even though my business card
> says I'm an "Associate Editor"!  Half of a semester course made me the
> expert on hand when my company decided to use a database to track all of our
> projects and I'm still trying to fully figure out a design no one can seem
> to agree upon.

I would argue that this is less about absolutely needing someone with
a library degree to be able to understand the database, and more about
libraries being to cheap or impoverished to hire real database
designers. I would make the same claim about graphic designers and, of
course, programmers.

These aren't things that need a highly-skilled, highly-trainied MLS --
they would be best done by highly-skilled, highly-trained people in
the relevent disciplines. It just so happens that the MLS is a lot
cheaper.

--
Bill Dueber
Web Services Programmer
University of Michigan Library


Gmane
http://blog.gmane.org/gmane.culture.libraries.ngc4lib/month=20060701
blog.gmane.org
crawl=CC-MAIN-2013-20
58775
application/http; msgtype=response
sha1:CNDKW7554KS7TA3BWV3NVRDPFFZHSMTE
<urn:uuid:8cbdb2db-7bb8-4c64-b699-a38438a4c871>
2013-05-21T22:16:18Z
80.91.229.6
sha1:4J7V7YZGNSXPJKF2FVRAC52L6YEMJJ2W
<urn:uuid:f067a1d7-d813-4f8e-a73d-0369ea8b9c68>
http://blog.gmane.org/gmane.culture.libraries.ngc4lib/month=20060701
response
<urn:uuid:5e7d4010-2841-426c-865c-a5283cbba73a>
robots: classic
hostname: ip-10-60-113-184.ec2.internal
software: Nutch 1.6 (CC)/CC WarcExport 1.0
isPartOf: CC-MAIN-2013-20
operator: CommonCrawl Admin
description: Wide crawl of the web with URLs provided by Blekko for Spring 2013
publisher: CommonCrawl
format: WARC File Format 1.0
conformsTo: http://bibnum.bnf.fr/WARC/WARC_ISO_28500_version1_latestdraft.pdf