Note to the majority of readers on RDA-L: you should feel no guilt in
skipping the rest of this thread. It has veered off into a technical
discussion that you may simply have no time (or use) for - kc
On 5/14/12 12:50 PM, Simon Spero wrote:
On Mon, May 14, 2012 at 10:45 AM, Karen Coyle <li...@kcoyle.net
<mailto:li...@kcoyle.net>> wrote:
What happened with the MARC format is that when we moved it into
actual databases it turned out that certain things that people
expected or wanted didn't really work well. For example, many
librarians expected that you could *[a]* /replicate a card catalog
display/ with *[b]* /records/ /displaying in order by the/
/heading that was searched/. That is really hard to do (*[c]* /and
not possible to do efficiently/) using*[d]* /DBMS/ functionality,
which is based on *[e]* /retrieved sets/ not /linear ordering/,
and*[f] */especially using keyword searching/. [emphasis and
labels added]
BLUF: Not all DBMS are Relational; it is possible to efficiently
retrieve records in order from many different types of DBMS, including
Relational databases.
[c] and [d] make the claim that it is impossible to retrieve records
efficiently in some desired order using DBMS functionality. This is
justified by [e] which claims that the source of this necessary
inefficiency is that DBMS functionality is based on "retrieved sets"
not "linear ordering".
No, that is not what I meant. Of course you can retrieve records in a
given order, and we do all the time. It's about using the headings in
the MARC records to establish that order. So here's the question I put
to Mac:
***
let's say you have a record with 3 subject headings:
Working class -- France
Working class -- Dwellings -- France
Housing -- France
In a card catalog, these would result in 3 separate cards and therefore
should you look all through the subject card catalog you would see the
book in question 3 times.
In a keyword search limited to subject headings, most systems would
retrieve this record once and display it once. That has to do with how
the DBMS resolves from indexes to records. So even though a keyword may
appear more than once in a record, the record is only retrieved once.
In your catalog, which displays the subject headings on a line with the
author and title
1) will each of these subject headings appear in the display?
2) does that mean that the bibliographic record (represented by the
author and title) will display 3 times in the list of retrievals?
***
I could add to that: if the record had four subject headings:
Working class -- France
Working class -- Dwellings -- France
Housing -- France
Housing -- Europe
Then under what circumstances in your system design would the user see
all four subject entries (heading plus bib data) in a single display?
That's part of the question. The card catalog had a separate physical
entry for each "entry point" or heading associated with the
bibliographic description. Do we have a reasonably efficient way to
imitate this behavior using keyword (or keyword in heading, or
left-anchored string searching) in an online library catalog? (followed
by: is there any reason to do that?)
But I think another part is the difference between retrieval, in the
database sense of the term ("give me all of the records with the word
*france* in a subject heading") vs. the kind of alphabetical linear
access that the card catalog provided, which allows you to begin at:
France -- United States -- Commerce
and soon arrive at
Frances E. Willard Union (Yakima, Wash.)
I don't think you can get from one to the other in most online catalogs
because the set of records that you can see is determined by the search
that retrieves only those records with *france* in it.
I've designed a browse in DBMSs using a left-anchored search that
retrieves one heading (the first one hit) in a heading index followed by
a long series of "get next" commands. Naturally, "next" has to also be
next in alphabetical order, so the index you are traversing has to be in
alphabetical order. I should say: alphabetical order that is retained
even as records are added, modified or deleted. I think this may be more
feasible in some DBMSs than others.
However, what is obviously missing here is a display of the bib record
that goes with the heading (all of that "ISBD" stuff). It's possible
that DBMS's can do this fine today, but in my olden days when I
suggested to the DBA that we'd need to "get next," display that heading,
then retrieve and display the bibliographic record that went with it, 20
times in order to create a page of display, I practically had to revive
the DBA with a bucket of cold water.
Mac's system also cannot take the display from France--US--etc to
Frances E. Willard because the headings it has to work with have been
retrieved on a keyword search, thus only headings with the term *france*
in them are displayed. It also does display non-retrieved headings for
that same bibliographic record. It does not do what the card catalog
did, which is display every heading from every record in alphabetical
order. When the headings have been retrieved on a keyword, the headings
that do not have that keyword do not appear in the display.
All that to say that if we are not going to display our records in
alphabetical order by their headings, then I'm not sure if creating
headings during cataloging makes all that much sense. Or at least, not
the kinds of headings that we do create, which are designed to be viewed
in alphabetical order. You are supposed to see "Hamlet" before you see
Hamlet. French.
Hamlet. German.
Hamlet. German. 1919
Maybe you don't see "Hamlet" first, but the logic of adding on to the
right hand side of the heading implies that the order conveys something
to the user that facilitates finding what he is looking for.
Thus, I question to creation of headings that are designed to be
encountered in alphabetical order unless we adopt an ordered display
around those headings. And if we think it is important to adopt such a
display, we need to understand the implications for system design.
I hope this isn't too confusing,
Simon, I hardly know where to begin. :-)
kc
Simon
* In some situations involving multiple tables, some systems may
return records in a different order if no specific order is requested.
This is due to decisions that the DBMS makes on the fastest way of
answering the query. Since not asking for results to be returned in a
specific order tells the system that you don't care about ordering,
the system may choose to use different algorithms when running your
query. This extra freedom to optimize is why the order of results is
unspecified by default.
--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
