Hi,
I need to retrace my steps a bit here.
A few weeks ago I had the pleasure of listening to Tim Spalding of
LibraryThing. One thing he said leapt out at me: "link to a page, not to
a search!"
A few years ago, I had set up the Horizon web catalogue for my library.
A hyperlink in a record could launch two types of screen: a browse list
screen of titles under that heading, or, an index browse list screen for
that type of heading. For authors, I chose the title browse (called "bib
summary" screen). For subjects, I chose an index browse because I
thought it would be useful for the library user to see that subject
heading in context so that the subject headings with different
subdivisions would be visible.
There was no "link to a page" option.
In seeing this "link to a page" option implemented at LibraryThing, and
in varying degrees at IMDb.com and WorldCat Identities, I saw this type
of display as one that should be elevated to a high priority in building
a next gen catalogue.
What should be on that page? Authority data, but there might
ramifications for the choice of what data goes into an authority record
in the future, as well ramifications for the way authority records are
structured, stored, and shared. I also saw the possibility of enriched
content services like Syndetics and LibraryThing offering additional
data elements like photos, links, bibliographies, and so on. As a web
page, the entity of interest could be the target of social networking
services, so users (however you group or define them) could discuss,
feed updates with RSS, review, tag, and otherwise use that page as an
anchor to share information, perhaps contributing a little to the
bibliographic utility of the overall catalogue.
On that page would also be the title list AND an option to browse the
index (LibraryThing has both types of display under the LCSH subject
heading!!). So the conceptual leap of "link to a page, not a search"
means previous limits in thinking about what data to display are gone!
So by "link to a page" I mean the use of more types of encoded data and
more standards, not less. I also saw the most natural way of applying
FRBR as a possibility, especially when IMDb.com parses a keyword search
into the entity categories of titles, names, companies, etc. Each entity
then has its own web page, as opposed to an AACR2 heading with largely
inaccessible authority data lurking behind the scenes in most library
web catalogues I've seen so far.
Thomas Brenndorfer, B.A, M.L.I.S.
Guelph Public Library
100 Norfolk St.
Guelph, ON
N1H 4J6
(519) 824-6220 ext. 276
tbrenndorfer_at_library.guelph.on.ca
> -----Original Message-----
> From: Next generation catalogs for libraries
> [mailto:NGC4LIB_at_listserv.nd.edu] On Behalf Of Jonathan Rochkind
> Sent: May 15, 2007 1:12 PM
> To: NGC4LIB_at_listserv.nd.edu
> Subject: Re: [NGC4LIB] Next Gen Catalog and FRBR
>
> I agree. MARC is not as output neutral or as display neutral as we'd
> like it. But we want to get MORE in that direction, not less!
"Replacing
> authorities with web pages" sounds like less, to me. I think we are in
> agreement. Maybe?
>
> Jonathan
>
> Brenndorfer, Thomas wrote:
> > While I agree with most of what you are saying, I think there is
still a
> > gap in understanding here.
> >
> > There was a time when bibliographic and authority data was not
encoded
> > in any way at all. There was some good overarching theoretical work
in
> > the form of the Paris Principles and ISBD, which forms the basis of
> > AACR2. It wasn't a matter of MARC replacing cards any more than it's
a
> > matter of web pages replacing MARC. MARC originally encoded the
> > practices involved in producing catalogue cards, and many fields and
> > terms used in MARC really derive from very specific options in the
> > display of catalogue cards.
> >
> > For example, what does the series field 440 really mean?
> >
> > 440 has a practical effect in the production of catalogue cards. It
> > prints the series statement in brackets. It prints the word "Series"
in
> > the tracings field at the bottom of the catalogue card. It produces
an
> > added entry card. It actually produces an added entry card with
series
> > numbering that a file clerk could then file in series number order
in
> > the card catalogue.
> >
> > When to use a 440 and a 830 is very confusing for new cataloguers,
> > especially when one can't easily refer to the production of
catalogue
> > cards.
> >
> > I would argue we actually don't have an output-neutral or
> > display-neutral format with MARC. You have to change MARC to get the
> > display options and functionalities that are now only becoming
available
> > with web displays. For example, VTLS's Virtua system restructures
and
> > modifies MARC records into FRBR components. I can look at a VTLS web
> > catalogue and see some interesting FRBRized displays (a tree-like
> > structure). It seems to me that one can take what's been started
with
> > VTLS and add in more standards developed for the web to solve a
number
> > of the problems that have been identified and have prompted the
interest
> > in the next gen catalogue. This doesn't mean an end to encoded data
and
> > it doesn't mean the web is an endpoint.
> >
> > Thomas Brenndorfer, B.A, M.L.I.S.
> > Guelph Public Library
> > 100 Norfolk St.
> > Guelph, ON
> > N1H 4J6
> > (519) 824-6220 ext. 276
> > tbrenndorfer_at_library.guelph.on.ca
> >
> >
> >
> >> But we have much of this in MARC Authorities now. If our software
> >>
> > isn't
> >
> >> taking full advantage of it, that's our software's fault. If we're
> >> missing data that we need, that's our data's fault. But "replacing
> >>
> > MARC
> >
> >> with web pages" is not the answer, that would be a step backwards.
Web
> >> pages are a _presentation_ of authority data, the actual authority
> >>
> > data
> >
> >> needs to live in a structured way such that software can extract
all
> >>
> > the
> >
> >> meaning out of it that the cataloger's put in.
> >>
> >> Hope this make some sense, Thomas. The distinction between
> >>
> > presentation
> >
> >> and underlying structured data is an important one.
> >>
> >> Jonathan
> >>
> >>
> >>
> >
> >
>
> --
> Jonathan Rochkind
> Sr. Programmer/Analyst
> The Sheridan Libraries
> Johns Hopkins University
> 410.516.8886
> rochkind (at) jhu.edu
Received on Tue May 15 2007 - 11:49:10 EDT