If back on track is back to the questions about what identifying characteristics are important for users to find, identify, select, or obtain information, we have decades, in fact centuries, of research and use information that has led us to the identifying elements in cataloging codes, such as RDA: Resource Description and Access.
RDA built on research and international consensus in the library community (not just the experience of catalogers, but also reference/public service staff helping users every day) - which includes public and academic and all kinds of libraries and library-related service providers, as well as archivists and curators from museums.
The basic, essential elements are identified in RDA as "core" elements and other identifying characteristics are included for all types of resources - to be used or added as appropriate to fulfill a user task (find. identify, select, obtain, etc.). Identifying information can be added at any time - by the creator of the resource, by the publisher, by catalogers over time, by others able to do so, etc. This becomes even more do-able in the Internet, where experts could augment descriptions and provide relationships (links).
Let's please not dumb down the possible elements for the sake of a very simple element set - that was done with Dublin Core, which has proven helpful for limited applications but has limits when more granularity/detail is needed. Let's learn from that and enable the future framework to meet the needs of all users.
Our future framework really must accommodate details that will be important for humans. Plus we need to do it in a way that machines can easily manipulate so humans can understand and see connections/relationships and confirm/distinguish among similar things in order to do what they wish with information. If we can accommodate details, then we can simplify our display and uses of that data - condensed into a shorter/brief view of data or mapped to broader categories of data; but if we only provide a few elements, we can't go from generalities to details when that is needed.
Dr. Barbara B. Tillett
Chair, Joint Steering Committee for Development of RDA
On Jan 17, 2013, at 10:25 PM, Tennant,Roy wrote:
Re: [BIBFRAME] Input screens
Here I was about to call for closure on the “Input screens” thread, before it truly went down the electronic discussion rabbit hole.
But then comes this post by Kathleen Goldfarb, which, I believe, gets us back on track. That is, what are the aspects of a work we really must record to make it findable and relatable to other works in ways that actual users want their systems to work? That must be at the very center of our discussions, and not merely an afterthought after debating the relative merits of a 245 $h. Or whatever.
Please let us simply acknowledge that appropriate input/editing methods will be created to deal with the New World and get back to discussing what truly matters — the data being recorded, and how.
On 1/17/13 1/17/13 • 6:03 PM, "Goldfarb, Kathie" <[log in to unmask]> wrote:
Yes, some of those differences are meaningless, but some are important, at least to some people for some reasons. Difference between $x and $v? If your system can do it, some people may want to find books OF poetry, rather than those ABOUT poetry. If your system can at least identify that information, or even better yet, allow you to search or filter by that info, it can be a big help for patrons. A lot of this depends on the ILS or Discovery system you are using.
Do we need to know the diameter of a CD-ROM? Probably not, since most of them are the same, and even the few smaller ones out there can be played on a standard player. It is a holdover from a time when phonograph records came in different sizes and that was importatant to know.
Is it important to know the height of a book? Ususally no, but when we cannot find a book on the shelf, that height might help find it. Is it worth putting the height in every book? I don’t know. If we decide not to do so, it’s not going to bother me. We have a lot of older records in our catalog without height. I don’t even think of trying to find it an update the record.
Do some patrons want to know whether that name they are looking at is an author, illustrator, subject of a book? We are forgetting those that do have specific wants and needs. Any kind of a new coding system has to allow for methods of letting people know what they found, so they can decide if it is what they want. Maybe we need to be asking researchers what they need in order to identify the materials they need.
Technical Services Librarian
College of the Mainland
Texas City, TX 77539
409 933 8202
P Please consider whether it is necessary to print this email.
From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Simon Spero
Sent: Thursday, January 17, 2013 7:26 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Input screens
On Thu, Jan 17, 2013 at 6:20 PM, Kevin M Randall <[log in to unmask]> wrote:
Yes, certainly, as long as the language of input is MARC, then absolutely anyone who does inputting needs to be able to understand that language. My point is that we haven't created everyday-use tools that do the MARC translation in the background so people can do cataloging work without knowing MARC. My point is that we're requiring people to learn a language that they really shouldn't have to learn. Programmers should know it; managers should know it; but lower level cataloging assistants shouldn't have to know it.
Why should even managers have to know the difference between 650 $x and $v (answer: they shouldn't because $v is an abomination).
Rarer tags have higher error rates (the rarest are almost always miskeying ; do statistical analysis of tag frequencies and co-occurrences, and you'll spot all sorts of mistakes (e.g. hitting a key twice, pushing the last digit of the tag into the first indicator).
For that matter, if the only study every conducted on the, er, subject, found only about a 50% success rate for *technical services* professionals in generating paraphrases of pre-combined subject heading strings, with reference and general adults scoring worse, do they have a meaning (and in what language game)?
If collapsing two fields changes neither recall not precision when searching, does it make a sound?
If splitting a field changes recall or precision, which is it not split?
Why must we know the diameter of a cd-rom?
Is this ruler really necessary?