Re: How are we doing? (NGC4LIB progress)

On 11/30/06, Alexander Johannesen <alexander.johannesen <at> gmail.com> wrote:
> Code4Lib has quite a bit. We're working on Library Labs. Some guys in
> Norway are doing similar things. Some are venturing Freshmeat, others
> are putting their stuff on SourceForge. There's lots of stuff out
> there. I think what you perhaps is asking for is a joint international
> FOSS effort, and that I support wholeheartedly, but we need to know
> exactly what it is that we should be doing before we do it. :)

Also OSS4lib (http://oss4lib.org).  What exactly is this 'repository
of code' supposed to do, anyway?  I've never found straight code
repositories (like koders.com) terribly useful.  At any rate, if
you're just looking for 'example code' to work through a problem, I
would think any 'lay' code you find on Google would probably work
fine.  Our apps aren't so incredibly different than anybody else's.
If you're talking about library related, er, libraries, do some
searches in CPAN or RubyForge.   You'll find plenty.

There is a very amicable and tightly knit development community in
libraries (Code4lib, in all incarnations, esp.) and I've yet to meet
anybody that wasn't willing to give a helping hand to somebody that's
stuck.

-Ross.

Title page scanning and cat records

Re: How are we doing? (NGC4LIB progress)

Steve,

That's where I've come to on the issues, re: my recent posts on the subject.
The vendor side and the data side need a *lot* of work, but it's the
interface/customization I see as a paramount need, and to repeat myself,
it's best to do that work inside the tool/application most users *have*
already: a browser.

Best,
DrWeb

--
P. Michael McCulley aka DrWeb
mailto:drweb <at> san.rr.com
San Diego, CA
http://drweb.typepad.com/

Quote of the Moment:
 The ultimate smart weapon would be too smart to blow itself up.
Thursday, November 30, 2006 4:45:17 PM

>-----Original Message-----
>From: Next generation catalogs for libraries
>[mailto:NGC4LIB <at> listserv.nd.edu] On Behalf Of Stephen McLaughlin
>Sent: Thursday, November 30, 2006 9:25 AM
>To: NGC4LIB <at> listserv.nd.edu
>Subject: Re: [NGC4LIB] How are we doing? (NGC4LIB progress)
>
>I wrote:
>
>> I'll offer a small example that caused a fair portion of my hairs to
>seek
>> other employment. For a decade we had parallel systems, OPAC and
>> periodicals control. The cry every month was that people wanted a
>single
>> point of access to both books and periodicals, and this was
>one of the
>> major points spelled out in our RFP when we went out for a new system
>in
>> 2003. We got the new system, integrated periodicals into the catalog,
>and
>> you know what people have been asking for ever since? A separate
>catalog
>> for periodicals! Seems that they're having too much trouble locating
>> periodicals among the clutter of all the books; limiting a search by
>> "periodicals" (which we did) is not simple enough. People wanted a
>simple
>> list of periodical titles. So now we work with Serials Solutions to
>> provide us with a separate list of our own periodical titles. Yargh!
>But
>> that's what people wanted."
>
>To which Mark Andrews responded:
>
>> Question: which libraries (or, more particularly, library staffs and
>> library managers) do the best job of identifying what people want and
>> responding in a timely and affordable manner?  What can't the best
>> practices here be identified and replicated? <SNIP>
>
>The point I was trying to make is that different people want different
>things; we responded to the public and staff comments by doing exactly
>what was being expressed as a pressing need, and then as soon as we did
>it, we found out that other people had other needs, which were
>in direct
>conflict with the needs of the group we had responded to. There is no
>such thing as a single "best practice" for every patron. We need to
>think in terms of a wide spectrum of needs, and flexible
>interfaces that
>can meet all of those needs (or at least as many as possible).
>
>In many ways, I don't think the underlying data structure is as
>important as the interface to it; the MARC record has lots and lots of
>data, but we don't always present it to the user in the best way.
>Changing the data structure won't change the user's needs, although I
>happily grant that there may be ways in which changing the data
>structure may facilitate better interfaces. But to my mind the question
>of the interface, of usability, must precede the question of data
>structure. What are patrons trying to do, and how are they trying to do
>it?
>
>Karen G. Schneider wrote:
>
>> Put me in the "one interface, one view, one dataset to unite
>them all"
>> camp, and feel free to *prove* me wrong (not endlessly debate the
>point on
>> this list).
>
>By the same token, can you prove that one interface can meet the needs
>of the great majority of patrons? Why does one side have to prove its
>point? I'm not interested in debating the point endlessly
>either; what I
>want to see are some really good studies that would guide us
>in tackling
>this issue. Most of the studies I have seen focus on the academic user,
>because that's where the big money for studies is; I am suggesting that
>the public library is a very, very different environment, and I haven't
>seen any good studies lately on patron use of public library catalogs.
>
>Maybe I'm not expressing myself clearly on one point (or many points!).
>I am NOT suggesting either of the following:
>
>1) That different data sets are needed for different users;
>2) That an entirely separate catalog interface is needed for different
>users.
>
>I am suggesting that we need a *flexible* interface to our data, one
>that patrons can either self-customize, or will respond to clues from
>the user as a session progresses, or that can be set up by the library
>to offer different modes. Same basic interface, many faces. I do not
>think this is a cosmetic issue, merely putting different
>pretty pictures
>on the same underlying screens. We need to go deeper than that, somehow
>fining ways to respond to usage patterns. It is a fundamental
>problem in
>patron use of the catalog, and if we do not address it, all the data
>restructuring in the world will not lead to satisfied users.
>
>Sorry for the rant!
>
>Steve McLaughlin
>San Francisco Public Library

Re: How are we doing? (NGC4LIB progress)

I diagree, Ross. I use FireFox, and when a new plug-in is updated, it alerts
me and I can easily install that update from the update site. Easy as pie ;)
..

It's not really a standalone client - pick IE7, FireFox, Opera, whatever -
and the application (API/Java/whatever) would install to customize the user
experience and layout for OPACs/ILSs. You just need the updated piece
whenever it would change, which would update itself upon reload.

No behavior must change, but users would adopt it (I suspect) because it's
easy as pie.
You can still visit any library catalog or ILS direct, and get that
interface. This is just the customizable one ;).

Hope that helps, and best,
DrWeb

--
P. Michael McCulley aka DrWeb
mailto:drweb <at> san.rr.com
San Diego, CA
http://drweb.typepad.com/

Quote of the Moment:
 My cat makes me search the room for invisible intruders.
Thursday, November 30, 2006 4:55:18 PM

>-----Original Message-----
>From: rossfsinger <at> gmail.com [mailto:rossfsinger <at> gmail.com] On
>Behalf Of Ross Singer
>Sent: Thursday, November 30, 2006 4:43 AM
>To: drweb2 <at> gmail.com
>Cc: NGC4LIB <at> listserv.nd.edu
>Subject: Re: [NGC4LIB] How are we doing? (NGC4LIB progress)
>
>The fundamental problem with this idea is that you're asking the user
>to download what is basically a standalone client.  Not only that, but
>a standalone client for something incredibly marginal in most people's
>lives.
>
>If we need to resort to 'special browsers' or 'plugins' we're sunk.
>Downloads are the kiss of death.  In fact, your analogy of Google
>Documents vs. MS Word is doubly wrong -- Google Documents is easier to
>deploy because it will run in /any modern browser/, whereas
>installations of MS Word have to be deployed.  And maintained.  And
>when a bug fix comes out, has to be redeployed.
>
>No, we are in no position to expect our users to change their web
>behaviors and it would be much more worthwhile for us to figure out
>how to fit into their basic flow.
>
>-Ross.
>
>On 11/30/06, DrWeb <drweb2 <at> gmail.com> wrote:
>> >-----Original Message-----
>> >From: Next generation catalogs for libraries
>> >[mailto:NGC4LIB <at> listserv.nd.edu] On Behalf Of Alexander Johannesen
>> >Sent: Wednesday, November 29, 2006 7:17 PM
>> >To: NGC4LIB <at> listserv.nd.edu
>> >Subject: Re: [NGC4LIB] How are we doing? (NGC4LIB progress)
>> >
>> >On 11/30/06, DrWeb <drweb2 <at> gmail.com> wrote:
>> >> I was wondering why the path isn't towards a "GOPAC" (read:
>> >General OPAC)
>> >> *browser*?
>> >
>> >Because that path leads to darkness?
>>
>> Actually, no, but you'd have to explain your concept of why
>a browser-Web2.0
>> "application" in a browser is the Dark Side.
>>
>> >
>> >> Isn't there something to be said for the work on K-Meleon and the
>> >> Public Web Browser (PWB) (though it's adoption is less than
>> >I would have
>> >> expected at this point)? See
>> >http://www.libraryjournal.com/article/CA232354.html
>> >
>> >You can certainly say a lot, although in my eyes not a lot
>of it would
>> >be positive. Why *should* we offer a different browser
>experience than
>> >what they already have?
>>
>> Well, no, you misunderstand. You deliver inside the
>killer-app #2 (after
>> e-mail), since that is where much of the interaction a modern user
>> experiences, takes place. No need to "re-learn" a new
>application. It comes
>> to them, automagically :) ..
>>
>> >
>> >The power of the services we deliver doesn't sit in how you
>browse the
>> >data, but how that data is handled before you see it. That's the
>> >application. Sure you can customize a browser and install
>whistles and
>> >bells on it to better suit the library, but bear in mind that that
>> >means more maintainence for us, a steep learning curve for
>the patrons
>> >and a dent in the user experience. There is nothing a customised
>> >browser can offer that a good application can't.
>>
>> We disagree on this one; except, yes, I'm taking about
>transparsing the data
>> before you see it - but inside a browser. And, there's no
>more maintenance
>> on the library side individually. You would still have your
>OPAC, your
>> typical browser experience - if that's what users preferred.
>OTOH, many
>> might choose a plug-in (think:FireFox API+bells+whistles)
>that performs
>> transformations on the underlying data - to fit their
>user-preferences as a
>> browsing (cough) experience. The maintenance in this scenario is a
>> group-supported, open-source project that would create, develop, and
>> maintain this browser-application, the GPAC. Data (lives
>wherever) + Browser
>> Wrapper + GPAC application (3.x+) = user-defined "OPAC" in
>their browser.
>> What's wrong with this picture?
>>
>> On your last point, applications built-from-scratch do,  to
>my mind, take
>> more maintenance than browser plug-ins and applications. I
>can see several
>> valid reasons the browser world is superior to a stand-alone
>application;
>> think Google's products (all online inside browsers) vs.
>Windows WORD.
>>
>> >
>> >> Maybe a *browser* could be configured to smartly identify
>> >*each library's*
>> >> catalog, and provide the translation/format/layering and
>> >tools that are
>> >> needed - on demand?
>> >
>> >OpenURL and HTTP lollies already does this.
>>
>> And browser's technology and applications can do this, as well, same
>> toolsets, different hooks.
>>
>> >
>> >> It could use CSS, JS, whatever, and certainly toolbars
>> >> to do some of the interface and layout functions.
>Different types of
>> >> libraries could code their own browser experience/interface,
>> >based on a
>> >> template for the core library types.
>> >
>> >Maintainence, maintainence, maintainence.
>>
>> Again, you missed that I was speaking of an open-source
>project, maintained
>> for "all" by a core group of volunteers in the community.
>For the individual
>> library developer or webmaster or programmer, maintenance is
>nil except some
>> testing perhaps, and help documents relative to suggested
>configurations and
>> tweaks and some help on how-to's that would be localized to your
>> environment.
>>
>> >
>> >> I know this doesn't address the bad data, poor data, poorly
>> >stored and
>> >> accessible data in the OPAC. But, in some ways, isn't that a
>> >different
>> >> mission - involving local staff/coders, vendors, and others?
>> >Cleaning up and
>> >> transparsing the data is one part of what is need, but I see
>> >the interface
>> >> issue somehow more key. It would get back to that "any
>> >library, find any x"
>> >> model, because it's transparent (sort of) and automagic for
>> >"any library"
>> >> that participates in the GOPAC community.
>> >
>> >The browser is never going to replace our vendor lock-in. When all
>> >vendors do web services and deliver sensible XML to clients, then
>> >maybe, but even then a generalised normal browser experience is the
>> >key. All it takes is for libraries to think alike and share code,
>> >something we've sucked at in the past. (Code4Lib is just the thing
>> >that hopefully in the future will fix some of these issues ...)
>>
>> Nothing in my notes suggested we should continue even more on the
>> data/vendor side; quite the contrary..
>> We need to push the OPAC vendors with more open-source and more open
>> development *we* participate in. Having clean XML from the
>data would be a
>> prerequisite for the browser's plug-in/app I described to be
>"100%" optimal.
>>
>> Where is the current open-source library-related repository
>of code, btw? I
>> haven't seen it yet...
>>
>> >
>> >
>> >Alex
>> >--
>> >"Ultimately, all things are known because you want to believe
>> >you know."
>> >                                                         -
>> >Frank Herbert
>> >__ http://shelter.nu/
>>
>>
>> Best,
>> DrWeb
>>
>> --
>> P. Michael McCulley aka DrWeb
>> mailto:drweb <at> san.rr.com
>> San Diego, CA
>> http://drweb.typepad.com/
>>
>> Quote of the Moment:
>>  Whatever you can do, or dream you can, begin it.
>>  Boldness has genius, power and magic in it. - Goethe
>> Wednesday, November 29, 2006 11:00:16 PM
>>

Re: How are we doing? (NGC4LIB progress)

Similar to my notes to Ross.. it's not a new *browser* - it's an ILS-aware
smart plug-in that lives inside our current world of browsers. Development
of something along these lines wouldn't require decades :) I suspect. Look
at the fine world of plug-ins now for FireFox, and imagine a simple one like
that that can "talk the OPAC talk."

Best,
DrWeb

--
P. Michael McCulley aka DrWeb
mailto:drweb <at> san.rr.com
San Diego, CA
http://drweb.typepad.com/

Quote of the Moment:
 My computer's sick, I think my modem's a carrier
Thursday, November 30, 2006 4:55:18 PM

>-----Original Message-----
>From: Andrews, Mark J. [mailto:MarkAndrews <at> creighton.edu]
>Sent: Thursday, November 30, 2006 6:03 AM
>To: drweb2 <at> gmail.com
>Subject: RE: [NGC4LIB] How are we doing? (NGC4LIB progress)
>
>The development, deployment and maintenance costs of a
>library-specific,
>ILS-aware browser are too high.  Better to do all this stuff on the
>server side and allow library customers to use whatever browser they
>wish, on whatever device they wish.
>
>The last thing we need to do is spend 20 years developing a technology
>that nobody uses, like Z39.50 - a loss-leader if ever there was one.
>Yes it was a good proof-of-principle experiment, but there are FAR
>better models of inter-system communication available to libraries
>today, like those used by Google, Yahoo and Amazon.com.
>
>Mark Andrews

Re: Why the OPAC will never be like Google

You are correct, Ross.. as Gary Price often notes, Google is more limited in
what full-text document content it indexes than other indexers/search
engines. They just have a better PR department ;) that makes us *think* they
index the full-text.

Source: http://www.infotoday.com/searcher/oct01/price.htm
9. Google only crawls and makes searchable the first 110 k of a page. Long
documents may have substantial content invisible to Google.

Best,
DrWeb

--
P. Michael McCulley aka DrWeb
mailto:drweb <at> san.rr.com
San Diego, CA
http://drweb.typepad.com/

Quote of the Moment:
 My computer's sick, I think my modem's a carrier
Thursday, November 30, 2006 5:05:06 PM

>-----Original Message-----
>From: Next generation catalogs for libraries
>[mailto:NGC4LIB <at> listserv.nd.edu] On Behalf Of Ross Singer
>Sent: Thursday, November 30, 2006 12:40 PM
>To: NGC4LIB <at> listserv.nd.edu
>Subject: Re: [NGC4LIB] Why the OPAC will never be like Google
>
>I'm not so sure you'd need the full text.  I think abstracts, TOCs and
>keywords would go a long way to what you're talking about.  After all,
>Google doesn't generally index complete documents, from what I
>understand.  The real difference is the possibility of 'pagerank'.
>
>This can be simulated somewhat via circ records and clickthroughs, but
>it would be very cool if we could get some 'number of times cited'
>ranking a la Web of Science of Google Scholar, as well.
>
>Of course, that's a whole lot harder to do.
>
>-Ross.
>

Re: How are we doing? (NGC4LIB progress)

Google Answers is going away.. just FYI.
Source: http://googleblog.blogspot.com/2006/11/adieu-to-google-answers.html

Best,
DrWeb

--
P. Michael McCulley aka DrWeb
mailto:drweb <at> san.rr.com
San Diego, CA
http://drweb.typepad.com/

Quote of the Moment:
 Necessity is the mother of strange bedfellows.
 -Dave Farber
Thursday, November 30, 2006 5:05:06 PM

>-----Original Message-----
>From: Next generation catalogs for libraries
>[mailto:NGC4LIB <at> listserv.nd.edu] On Behalf Of Alexander Johannesen
>Sent: Thursday, November 30, 2006 2:49 PM
>To: NGC4LIB <at> listserv.nd.edu
>Subject: Re: [NGC4LIB] How are we doing? (NGC4LIB progress)
>
>Hi,
>
>On 12/1/06, Michael Ericson <mericson <at> roanokecountyva.gov> wrote:
>[stuff]
>
>I'll be the devils advocate, and turn this around slightly ;
>
>> Can you call and ask Google a question on the phone?
>
>Not by phone; http://answers.google.com/answers/ but I'm sure that's
>simple for them to add to the business model if they see fit. They
>might. Can you say for certain they never will?
>
>> Can you talk to Google staff and go see them in person?
>
>Well, I have actually, but I *think* you mean "for information
>purposes." :) Who's to say they may not open Google Shops?
>
>> Is there a Google physical location to go to in your city or town?
>
>No, one town over. Does this matter? they're an *internet* company,
>right? And we're not, right? :)
>
>> Does Google offer computer labs and classes, programs,
>meeting rooms in your
>> city or town?
>
>Neither does all libraries, so I'm not sure that's a fair comparison.
>
>> I could go on and on about this major difference but I need
>to help a patron here in
>> the library...
>
>.. me, too; he's found some stuff that Google claims is found on our
>website, but our OPAC can't find it ... :)
>
>
>Alex
>--
>"Ultimately, all things are known because you want to believe
>you know."
>                                                         -
>Frank Herbert
>__ http://shelter.nu/
>__________________________________________________

Re: How are we doing? (NGC4LIB progress)

Re: Title page scanning and cat records

I don't have any experience, but I heard that there is a German
consortium that is doing this.  I don't know which one so it might
require some creative research to find it.

 -- Michele

Alison Dellit wrote:

> I was wondering if anyone on the list had any experiences of using
> scanning of title pages/table of contents information to enhance or
> replace catalogue records? We are looking at the feasibility of using
> OCR technology at the NLA at the moment, and I would appreciate
> hearing about any experiences that people are aware of.
>
> Also, any experience with automated cataloguing in any form.
>
> Cheers,
>
> Alison
>
> *Alison Dellit* | Librarian, Bibliographic Policy | National Library
> of Australia
> Canberra ACT 2600 | Ph 02 6262 1212 | adellit <at> nla.gov.au  |
> _http://www.nla.gov.au_
>
>
>
>

--
PLEASE NOTE ADDRESS CHANGE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Michele Newberry        Assistant Director for Library Services
Florida Center for Library Automation              352-392-9020
5830 NW 39th Avenue                          352-392-9185 (fax)
Gainesville, FL  32606                       fclmin <at> cns.ufl.edu
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: How are we doing? (NGC4LIB progress)

On 12/1/06, DrWeb <drweb2 <at> gmail.com> wrote:
> Google Answers is going away.. just FYI.
> Source: http://googleblog.blogspot.com/2006/11/adieu-to-google-answers.html

That's truth with a modifier; Google just aquired someone (can't
remember, sorry) that does similar stuff.

Alex
--
"Ultimately, all things are known because you want to believe you know."
                                                         - Frank Herbert
__ http://shelter.nu/ __________________________________________________