Re: The problem with OPACs [was: New subject keyword search]

From: Will Kurt <wkurt_at_nyob>
Date: Thu, 26 Jul 2007 14:19:41 -0400
To: NGC4LIB_at_listserv.nd.edu
Nathan,

I think Musicbrainz.org is a good example of RDF in action, and
metadata that is doing more than what current catalogs are
doing(while still maintaining the many of their strengths).  The
thing I feel is most interesting (and important) is the relationships
that RDF is able to show (which gets back to the browsing issue.)

If you do a search for the artist 'Justice'  (French, electronic)
you'll get records for a few groups that share this title with pretty
good descriptions of which 'Justice' is which.

When you actually view the record you get a tremendous amount of easy
to process info (I've only started using MusicBrainz recently, so I'm
not a pro at this by any means). Right away you get the very
important 'relationship' info. I now know that they have a myspace
page, a discogs page, I know what other groups they've worked with,
what songs they've remixed etc.  Additionally I have all the standard
info you'd expect: Albums, singles, EPs. Along with all the metadata
about them you'd want to know.

If I click on the record for the newest album I once again get the
relationship info.

Now let's try something a little tougher: Bonnie "Prince" Billy.
Bonnie "Prince" Billy is actually 'Will Oldham' who also performs as:
'Bonny Billy', 'Palace Brothers', 'Palace Music' and 'Palace Songs'.

If you search for Bonnie 'Prince' Billy you'll find in the
relationships that he identifies the person 'Will Oldham' and if you
look at the relationships for 'Will Oldham' you see a list of every
name he performs under.

A similar situation is true if you search for Stephin Merritt
(Magnetic Fields, Future Bible Heros, Gothic Archies, the 6ths)

Finally if you go to Musicbrainz wikipedia page you'll find a section
of software which by default works with Musicbrainz:
<http://en.wikipedia.org/wiki/Music_Brainz#Software>http://en.wikipedia.org/wiki/Music_Brainz#Software
Because it has easier to use APIs and the underlying metadata is
designed to be used with other services not only does RDF allow great
internal data navigation it allows for much easier external interaction.

I hope that answered your some of your questions.

Also I won't say that MusicBrainz is without any faults, I certainly
noticed some duplicate data, and I'm sure there are other problems I
will run into in the future.  But one thing I also want to point out
is that this is really just one organization (with user generated
content) that has produced over 5.7 million track records in just a few years.


--Will



At 12:43 PM 7/26/2007, you wrote:
>Will:
>
>
>
>"RDF, Topic Maps and other similar systems have many features that go
>above and beyond the type of information that simple marc records and
>LCSH can provide. And by working to make machine AND human readable
>formats they strive to create systems that are both easy to use and
>extremely complex in regards to the types of information and the
>relationships to other types of information they contain.
>
>
>
>The currently library catalog isn't just not easy enough to use; it
>doesn't come anywhere close to cutting edge regarding the quality and
>functionality of its metadata."
>
>
>
>Will, I like what you wrote.  I note (have I done so hear yet) that
>Thompson-Gale is promoting their "information organizer expert"
>credentials in a big way with their new PowerSearch database (see here:
>http://tinyurl.com/32xz5u  Methinks the market gets it.  Librarians
>don't.
>
>
>
>Re: RDF, can you point me to some working examples of sites that are
>using RDF in a way perhaps comparable to what library catalogs need?  I
>have read quite a bit on RDF, and I sometimes wonder how much is really
>workable at this time.  I am just echoing some of Peter Morville's
>sentiments here.
>
>
>
>Martha Yee just mentioned on AUTOCAT how the only problem that she sees
>with the new OPAC here library released and that Ted G. introduced here
>(she actually recommends subject searching as a default, and gives some
>pretty good reasons why this is a good idea) is because of what we'll
>call the "WWII problem".
>
>
>
>She says that we "still do not have software that recognizes the
>hierarchical relationship between a main subject heading and any other
>heading that consists of that main subject heading and a subdivision"
>Therefore, even though the subject heading "World War, 1939-1945" has a
>clearly indicated cross reference from "World War II" in the LC
>authority record, no system (does she only mean the most recent
>"up-to-date catalog software", or software in general - I do not know)
>she knows of can use the cross reference in the LC authority record to
>assist a user who types in 'france world war II' and needs to see the
>headings that begin 'World War, 1939-1945--France.'
>
>
>
>Here is the authority record, by the way:
>
>
>
>
>
>LC Control Number:
>
>sh 85148273
>
>HEADING <http://www.loc.gov/marc/authority/ecadhead.html> :
>
>World War, 1939-1945
>
>000
>
>01132cz a2200361n 450
>
>001
>
>6255138
>
>005
>
>20040524235755.0
>
>008
>
>860211i| anannbabn |a ana
>
>035
>
>__ |a (DLC)sh 85148273
>
>035
>
>__ |a (DLC)143170
>
>035
>
>__ |a (DLC)5352568
>
>035
>
>__ |a (DLC)sp 85148273
>
>035
>
>__ |a (DLC)269413
>
>035
>
>__ |a (DLC)4796485
>
>035
>
>__ |a (DLC)314916
>
>906
>
>__ |t 0419 |u te04 |v 0
>
>010
>
>__ |a sh 85148273
>
>040
>
>__ |a DLC |c DLC |d DLC |d AuSU |d DLC
>
>053
>
>_0 |a D731 |b D838
>
>150
>
>__ |a World War, 1939-1945
>
>450
>
>__ |a European War, 1939-1945
>
>450
>
>__ |a Second World War, 1939-1945
>
>450
>
>__ |a World War 2, 1939-1945
>
>450
>
>__ |a World War II, 1939-1945
>
>450
>
>__ |a World War Two, 1939-1945
>
>450
>
>__ |a WW II (World War, 1939-1945)
>
>450
>
>__ |a WWII (World War, 1939-1945)
>
>550
>
>__ |w g |a History, Modern |y 20th century
>
>670
>
>__ |a Women's fiction of the Second World War, 1996.
>
>670
>
>__ |a LC database, May 7, 2004 |b (titles: World War Two; World War 2;
>WW II)
>
>670
>
>__ |a Am. heritage dict. |b (WWII: abbr. World War II)
>
>681
>
>__ |i Example under reference from |a Wars
>
>953
>
>__ |a xx00 |b ta25
>
>
>
>So if someone puts in WW II or WWII or World War 2 or World War II, a
>system should be able to search the authority records as well, and be
>able to immediately go to or at least direct people to the simple
>heading, which is World War, 1939-1945.
>
>
>
>This seems simple enough.  Can RDF really help here?  Again, are there
>analogous examples?  Or is this an AI pipe dream?
>
>
>
>Of course, LC could also change the main authorities.  They do this of
>course (Vietnamese conflict -> Vietnam War) but with the cooperative
>nature of librarianship (not so hierarchical) this sometimes takes time.
>
>
>
>
>And I don't think we should take our time doing this.  :-)
>
>
>
>Regards,
>
>Nathan Rinne
>
>Media Cataloging Technician
>
>ISD 279 - Educational Service Center (ESC)
>
>11200 93rd Ave. North
>
>Maple Grove, MN. 55369
>
>Work phone: 763-391-7183
>
>
>
>
>
>-----Original Message-----
>From: Next generation catalogs for libraries
>[mailto:NGC4LIB_at_listserv.nd.edu] On Behalf Of Will Kurt
>Sent: Thursday, July 26, 2007 11:00 AM
>To: NGC4LIB_at_listserv.nd.edu
>Subject: Re: [NGC4LIB] The problem with OPACs [was: New subject keyword
>search]
>
>
>
>It's funny that you mention the idea of loosing metadata that assists
>
>in providing expert information on a subject when I was just reading
>
>a Gartner report the other day that cited one of the top reasons to
>
>use semantic technologies is when human expertise in a certain field
>
>is very costly.
>
>
>
>People aren't abandoning detailed, expertly created and highly
>
>structured metadata, in fact I would say that right now semantic
>
>metadata is becoming more and more in demand (especially in the
>
>healthcare industry, and biotechnology areas). I was at a conference
>
>a few months back, put on by a publisher in the biological sciences,
>
>and it was suggested by someone that strong, detailed, semantic
>
>metadata was so valuable to researchers that publishers could give
>
>away articles at no cost and simply charge for the metadata.
>
>
>
>More people than ever are "working together (to some extent) to
>
>cooperatively build amazingly devised systems to help people who
>
>suspected they needed expert human help" They just aren't all working
>
>in libraries.
>
>
>
>RDF, Topic Maps and other similar systems have many features that go
>
>above and beyond the type of information that simple marc records and
>
>LCSH can provide. And by working to make machine AND human readable
>
>formats they strive to create systems that are both easy to use and
>
>extremely complex in regards to the types of information and the
>
>relationships to other types of information they contain.
>
>
>
>The currently library catalog isn't just not easy enough to use; it
>
>doesn't come anywhere close to cutting edge regarding the quality and
>
>functionality of its metadata.
>
>
>
>A future we should be more concerned about is one where somebody else
>
>comes up with a better way to handle bibliographic metadata before we
>do.
>
>
>
>--Will
>
>
>
>
>
>
>
>At 11:01 AM 7/26/2007, you wrote:
>
> >Michael: " However, doing so will require that we resist the temptation
>
> >to create the ideal OPAC for *librarians*, but instead focus on
>creating
>
> >on OPAC that meets our *users'* search needs."
>
> >
>
> >Insofar as librarians ought to do everything possible to help users do
>a
>
> >lot themselves, *I agree with all of this*.  But at the same time, in
>
> >the midst of it all, I bemoan the reference librarian's potential loss
>
> >of specialized tools devised to treat the increasingly "rare condition"
>
> >of the truly questioning, curious, "leather-foot journalist"
>researcher,
>
> >scholar in this process.
>
> >
>
> >Years in the future, perhaps when people are even less curious about
>the
>
> >past and the history of ideas then they are now, some thoughtful
>
> >examiner of the world will read Thomas Mann and say, "Oh, the days when
>
> >there were experts who actually could listen to one another - and work
>
> >together (to some extent) to cooperatively build amazingly devised
>
> >systems to help people who suspected they needed expert human help...
>
> >it's a shame people did not realize their value... realize what they
>
> >had"  I think this is likely.
>
> >
>
> >In my mind, Karen Schneider's questions are still interesting... (and
>
> >worth doing some major soul-searching about and taking action), but
>
> >perhaps also reveal a certain shortsightedness.
>
> >
>
> >Regards,
>
> >Nathan Rinne
>
> >Media Cataloging Technician
>
> >ISD 279 - Educational Service Center (ESC)
>
> >11200 93rd Ave. North
>
> >Maple Grove, MN. 55369
>
> >Work phone: 763-391-7183
>
> >
>
> >
>
> >-----Original Message-----
>
> >From: Next generation catalogs for libraries
>
> >[mailto:NGC4LIB_at_listserv.nd.edu] On Behalf Of Doran, Michael D
>
> >Sent: Thursday, July 26, 2007 9:32 AM
>
> >To: NGC4LIB_at_listserv.nd.edu
>
> >Subject: [NGC4LIB] The problem with OPACs [was: New subject keyword
>
> >search]
>
> >
>
> > >  Selden Deemer wrote:
>
> > >
>
> > > Whatever the considerable benefits of browse displays (I
>
> > > read, and took to heart Thomas Mann's comments), the fact
>
> > > remains that, when I look at our search log stats, users (as
>
> > > opposed to librarians) simply do NOT browse (and it's not for
>
> > > lack of instruction).
>
> >
>
> >I'm convinced that the underlying "problem" with our OPACs (from a
>
> >usability perspective) is that they are sold once to librarians, rather
>
> >than many times to end users.  If each user was making an individual
>
> >purchase decision, OPACs would have quickly evolved to meet their
>needs.
>
> >I believe ILS vendors (who we often unfairly blame) are quite capable
>of
>
> >producing an awesome OPAC.  But the vendors are building OPACs to meet
>
> >our (i.e. librarians) perceived needs, because vendors are smart and
>are
>
> >in business to make money and they understand that *we* are the ones
>
> >writing that big check every 10-15 years or so.  As Selden points out,
>
> >OPAC features that are important/essential to us, are often ones that
>
> >our users could care less about, despite all our well-meaning
>
> >instruction.
>
> >
>
> >And that is assuming that OPAC functionality/usability is even a prime
>
> >consideration in the purchase decision of an ILS.  Very often that's
>not
>
> >the case, as acquisitions, cataloging, or circulation module features
>
> >drive the decision and the OPAC is an afterthought.  If we want to find
>
> >out who's responsible for sucky OPACs, the first place we need to look
>
> >is in the mirror [1].
>
> >
>
> >On the bright side, products like VUFind, Primo, AquaBrowser, and
>Endeca
>
> >unbundle the OPAC from the ILS, giving us a chance to atone for past
>ILS
>
> >purchase decisions (which can't easily be undone).  One of the problems
>
> >inherent in an ILS-bundled OPAC is that the 10-15 year (give or take)
>
> >ILS replacement cycle does not allow for significant changes to what
>
> >quickly becomes a calcified code base.  I'm particularly excited about
>
> >Andrew Nagy's recently released open-source OPAC; with VUFind, the
>
> >library-land development community has a golden opportunity to craft an
>
> >OPAC that genuinely meets our users needs.  However, doing so will
>
> >require that we resist the temptation to create the ideal OPAC for
>
> >*librarians*, but instead focus on creating on OPAC that meets our
>
> >*users'* search needs.  I think that would be an OPAC that doesn't
>
> >require instruction (however well-meaning) or require an initial search
>
> >page that is 80% search tips.
>
> >
>
> >Just my opinion...
>
> >
>
> >-- Michael
>
> >
>
> >[1] Karen Schneider asks: "But the interesting questions are: Why don't
>
> >online catalog vendors offer true search in the first place? and Why
>
> >[don't we] demand it? Save the time of the reader!"  I would answer
>that
>
> >vendors don't offer it, and we don't demand it, because the ILS (OPAC)
>
> >check-writers have other priorities.
>
> >See: Karen Schneider, How OPACs Suck, Part 1
>
> >http://www.techsource.ala.org/blog/2006/03/how-opacs-suck-part-1-releva
>n
>
> >ce-rank-or-the-lack-of-it.html
>
> >
>
> ># Michael Doran, Systems Librarian
>
> ># University of Texas at Arlington
>
> ># 817-272-5326 office
>
> ># 817-688-1926 mobile
>
> ># doran_at_uta.edu
>
> ># http://rocky.uta.edu/doran/
Received on Thu Jul 26 2007 - 12:02:08 EDT