headers
Tom Keays | 2 Oct 01:58
Picon

Re: hybrid library: from the users' perspective

On 9/30/06, K.G. Schneider <kgs <at> bluehighways.com> wrote:
> Oh, oh--the I-word...

LOL. You're right of course. But I clicked with the interface from the
first use. Just me, maybe.

> FRBR would clean up the versions problem, sort of anyway (let's wave our
> FRBR wand and just make it happen!), but it wouldn't clean up the apparent
> authority control problem. The latter is definitely not OCLC's problem,
> right? But then, whose problem is it? Are we agreed this is a problem
> requiring resolution? We are casting a bright light on our massive worldwide
> unified holdings... and once again the worms are crawling out. (It would be
> nice to be able to have a per-item feedback box so at the very least someone
> could ask, "Isn't record X just record Y?")

I certainly like the idea of FRBR and WorldCat is at least
baby-stepping the the right direction. I think FRBR offers a way...
perhaps THE way to go forward with NGCs. If the idea is to simplify
the results to something understandable and generic but simultaneously
offer a way to drill down (faceted searching seems like a good way) to
the specific, FRBR seems to be the real deal. But I have no
suggestions on how to make it happen.

The OTHER catalog of this type is RedLightGreen. It is similar in
approach to WorldCat in lumping editions together (which I guess is
not quite FRBR, but approaching it) and then allowing the user to
focus in. For some reason though, despite the nifty citation output
doohickey, I never warmed to it (and not for want of trying).

> Incidentally, after opting not to enter a zip code for the first couple of
(Continue reading)

Permalink | Reply | 8 comments |
headers
Marshall Breeding | 2 Oct 03:02
Picon
Favicon

Re: Next Generation Catalogs at NISO Workshop

Karen is quite right in that I point out that most researchers
begin the research process on Google or one of the other search
engines and not on the library Web site or catalog.  I don't
believe, however, that puts libraries out of the discovery
business.  If we think of library Web sites as destinations, not
starting points, an important component involves providing an
additional layer of discovery tools.  I see a multi-layered
discovery and delivery environment comprised of global,
institutional, and library-specific discovery and search tools.

The global discovery environments, such as Google, Yahoo,
worldcat.org, are not primary content providers.  I think that the
library's role as a provider of content and services related to
content is not substantially threatened by increasingly powerful
discovery tools on the global level.  In my opinion, if we play it
right, these global tools only serve to drive more users to our
content and services.

I hope that clarifies what I said at the NISO meeting.

-marshall

--On Friday, September 29, 2006 8:25 AM -0500 Marshall Breeding
<marshall.breeding <at> VANDERBILT.EDU> wrote:

> Thanks to Karen,
>
> I'm still on the road and rushing off to give another talk, so I
> don't have time quite yet to write up a summary of the talk I gave
> at the NISO conference. But here is a link to the PowerPoint
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mike Rylander | 2 Oct 03:57
Picon

Re: hybrid library: from the users' perspective

On 10/1/06, Tom Keays <tomkeays <at> gmail.com> wrote:

[snip]

>
> One of my biggest gripes about WorldCat.org's search interface has to
> do with this aspect. In particular, I would like to be able to embed
> the zipcode directly into the search form in order to predetermine the
> "epicenter" of my search results on my library. But, nope. You have to
> do the search. Select a record. Enter the zipcode. How lame is this? I
> can't imagine why nobody at OCLC hasn't addressed this. It should be
> noted, though, that until the browser cookie is cleared, WorldCat does
> remember the last zipcode entered.

My somewhat educated guess suggests one reason, and one reason only:
performance.

From personal experience, I know it's extremely difficult to come up
with a way to search 2 completely divergent axes (text of atomic
record, and location of one of 1B (in OCLCs case) holdings attached to
those records) at the same time (probably in separate databases in
Worldcat.org) without resorting to massively unmaintainable hacks.
It's by far the thorniest problem we tackled in the bib-search portion
of Evergreen, and PINES only has 8M items.

Granted, physical locality is one of the most important things for our
patrons -- they need to know what's on the shelf 20ft away -- and it's
not so much for the traditional OCLC patron/customer.  Worldcat.org is
certainly going to expose bits that need more work, especially in this
new-fangled, mashup crazy world we're moving into, but give them time
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jack Hall | 2 Oct 13:36
Picon

Re: Can we change the catalog without changing cataloging?

Contents notes (505 field) can be coded as "enhanced" with subfielding for
the title, author, and "miscellaneous information" such as volume number.
An opac system should be able to parse and display it as you wish.

Jack

At 05:28 AM 9/30/2006, Tim Hodson wrote:

>Access to data is most certainly NOT the only point.  What is the good of
>finding a record only to churn out a load of gobbeldygook to the user?  At
>the very least, the user should see a sensible representation of the
>record.  So when the record is for an audio recording with a number of
>tracks, the tracks should be presented in the correct numbered order as a
>list.  NOT as a big text blob on the page - currently a sensible list
>could not be reliably parsed from the MARC record.

Jack Hall
114L University of Houston Libraries
Houston, TX  77204-2000
telephone:(713) 743-9687
e-mail: jhall <at> uh.edu
fax: (713) 743-9748
Permalink | Reply | 0 comments |
headers
Montibello, Joseph P. | 2 Oct 15:32
Favicon

Re: Can we change the catalog without changing cataloging?

Karen Schneider wrote, "We'd need universal agreement on how to be
consistent in MARC, and universal compliance. It would also have to be
hard NOT to be compliant, and there would need to be ramifications.
(Plus hopefully we'd be able to justify all these rules and limits.)"

This is exactly right, and I still disagree with it.  I'm thinking about
the history of the web and HTML.  HTML was created, almost by fiat.
There have been browser wars ever since.  Different browsers disagree.
Shiny new browsers become old, broken browsers with some regularity.

There are HTML standards, well documented, well available.  Almost
everyone breaks them (almost) all the time.  Yet the web goes on - a
hundred miles a minute.  People risk the security of their finances and
identity every day, because it's just that convenient.

I don't think that an NGC can dream of such wild success.  The web works
because everybody who has access to it can find something to do with it.
It's potentially of interest to everyone in the world, whereas the NGC
is only potentially of interest to everyone in the world who has a
library card.

In a way, I think the NGC should be defined as the next library catalog
that causes a landslide.  The stagnation in the library market is the
problem.  Instead of creating a giant committee to democratically select
the most perfect set of standards and chisel them into stone (or
silicon), here's my idea:

1. Somebody get some venture capital.   (Is that vague enough?)

2. That Somebody take their capital and create a company, a corporation.
(Continue reading)

Permalink | Reply | 3 comments |
headers
K.G. Schneider | 2 Oct 18:50

Re: Can we change the catalog without changing cataloging?

> Karen Schneider wrote, "We'd need universal agreement on how to be
> consistent in MARC, and universal compliance. It would also have to be
> hard NOT to be compliant, and there would need to be ramifications.
> (Plus hopefully we'd be able to justify all these rules and limits.)"
>
> This is exactly right, and I still disagree with it.

... I'm not suggesting this route; I was trying to illustrate the
requirements of an approach to improving library services (that whole
inventory/discovery bundle) based on optimizing MARC records.

Another approach is to work with what we have, understanding that "what we
have" goes far beyond our own data; in a globally networked world, the
global network is our sandbox. There are many data sources that can improve
discovery. Take a look at Umlaut, Ross Singer's project, and how it
leverages a variety of data sources.

I keep circling back to these ideas:

* Our MARC data is just one pot of content among many.
* Using new tools to get mileage out of legacy data is cheaper, faster, and
more effective than attempting to optimize or standardize legacy data.
* Interfaces need to be simple, consistent, and pervasive.
* The starting point for library services needs to be something other than
the OPAC.
* The ending point for library services needs to be something other than the
OPAC.
* The next gen catalog is not a catalog.
* A good system never says "no" to a user. It always comes up with a
suggestion.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dan Lester | 2 Oct 19:11

Re: Can we change the catalog without changing cataloging?

Monday, October 2, 2006, 7:32:19 AM, you wrote:

MJP> 1. Somebody get some venture capital.   (Is that vague enough?)

MJP> 2. That Somebody take their capital and create a company, a corporation.
MJP> (I know, it's not pretty.)

As soon as you find someone with a few hundred million to throw down a
rathole, let us all know.

But your scenario is fun, and did wake me up this groggy Monday
morning.

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....
Permalink | Reply | 0 comments |
headers
Dan Lester | 2 Oct 19:18

Re: Can we change the catalog without changing cataloging?

I agree with all the other points you made, but....

Monday, October 2, 2006, 10:50:40 AM, you wrote:

KGS> * Using new tools to get mileage out of legacy data is cheaper, faster, and
KGS> more effective than attempting to optimize or standardize legacy data.

KGS> * Interfaces need to be simple, consistent, and pervasive.

These two seem mutually contradictory. In the first case, you seem to
say that we can and should work with what we have instead of trying to
standardize.  Absolutely no argument with that.  Many of us have gone
around on that one over the last several decades as we've been
involved with changing records due to changes in cataloging rules,
reclassing from DDC to LC, and so forth.  I'm not saying that all of
that is/was bad, but it is a bottomless pit.

The second one will never happen.  Just as catalogers will fuss
forever about angels on the head of a pin, or the interpretation of
some obscure rule, users, web designers, and administrators will fuss
forever about what the "best interface" is.  Pick a vendor's catalog
system and see if you can find any two libraries that have implemented
the interface in the same way.  Good luck in that search.  None of us
are ever happy with "plain vanilla", as we all think that our ideas
and styles are the best.  We've all seen the same thing in changes in
design of other interfaces, including all of our websites.

I think that on both we have to give up on the standardization, UNLESS
we all see that the implementation at XYZ is so wonderful that we all
spontaneously change to it due to its intrinsic brilliance and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ranti Junus | 2 Oct 19:24
Picon

Re: hybrid library: from the users' perspective

I'm curious which countries that are covered by OCLC based on the zipcode?
I believe there are countries that have the same 5-digit zip code
style like in the US.
So I take it OCLC cannot embed that information directly (at least not
yet) unless they know first where you're coming.

ranti.
--
 Michigan State University Libraries

On 10/1/06, Tom Keays <tomkeays <at> gmail.com> wrote:

> [...]
> The zipcode entry is one thing that is NOT intuitive. The only way to
> enter a postal code is to display a record (any record) with the
> "Libraries" (i.e., holdings) tab selected and then the "Enter location
> information" box is right below the tabs. E.G.,
>
> http://www.worldcat.org/oclc/289704?tab=holdings
>
> One of my biggest gripes about WorldCat.org's search interface has to
> do with this aspect. In particular, I would like to be able to embed
> the zipcode directly into the search form in order to predetermine the
> "epicenter" of my search results on my library. But, nope. You have to
> do the search. Select a record. Enter the zipcode. How lame is this? I
> can't imagine why nobody at OCLC hasn't addressed this. It should be
> noted, though, that until the browser cookie is cleared, WorldCat does
> remember the last zipcode entered.
>
> --
(Continue reading)

Permalink | Reply | 6 comments |
headers
Houghton,Andrew | 2 Oct 19:31
Picon
Favicon

Re: hybrid library: from the users' perspective

> From: Next generation catalogs for libraries
> [mailto:NGC4LIB <at> LISTSERV.ND.EDU] On Behalf Of Ranti Junus
> Sent: 02 October, 2006 13:24
> To: NGC4LIB <at> LISTSERV.ND.EDU
> Subject: Re: [NGC4LIB] hybrid library: from the users' perspective
>
> I'm curious which countries that are covered by OCLC based on
> the zipcode?
> I believe there are countries that have the same 5-digit zip
> code style like in the US.
> So I take it OCLC cannot embed that information directly (at least not
> yet) unless they know first where you're coming.
>
>
> On 10/1/06, Tom Keays <tomkeays <at> gmail.com> wrote:
>
> > [...]
> > The zipcode entry is one thing that is NOT intuitive. The
> only way to
> > enter a postal code is to display a record (any record) with the
> > "Libraries" (i.e., holdings) tab selected and then the
> "Enter location
> > information" box is right below the tabs. E.G.,
> >
> > http://www.worldcat.org/oclc/289704?tab=holdings
> >
> > One of my biggest gripes about WorldCat.org's search
> interface has to
> > do with this aspect. In particular, I would like to be able
> to embed
(Continue reading)

Permalink | Reply | 0 comments |

Gmane