Just a reminder that we don't all have to use the same elements in order 
to play in this space. Some bibliographic data can be as minimal as a 
normal academic citation, and other data can be as complex as that 
turned out by large research libraries. Yet these can play together well 
if they use the Semantic Web technologies (which I assume are solidly 
behind the BIBFRAME design). So there is little need to argue about what 
our "one true record" will be, but we should be listening to a wide 
variety of communities about their needs and how we can connect 
bibliographic data from different sources, each of whom has their own 
point of view.

Carrying forward the complexity of MARC may be of interest to some but 
it shouldn't be a requirement for everyone. I would also feel better 
about that complexity if it weren't such a Rube Goldberg mess of 40 
years of modifications, some of which were shoe-horned in awkwardly. A 
few posts back someone (sorry -- names escape me more often than not) 
said that we should be carrying forward the intended *meaning* of the 
bibliographic data. I salute you, whoever said that!


On 1/18/13 6:55 AM, Barbara Tillett wrote:
> 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
> [log in to unmask] <mailto:[log in to unmask]>
> 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.
>> Roy
>> On 1/17/13 1/17/13 • 6:03 PM, "Goldfarb, Kathie" <[log in to unmask] 
>> <mailto:[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.
>>> kathie
>>> Kathleen Goldfarb
>>> Technical Services Librarian
>>> College of the Mainland
>>> Texas City, TX 77539
>>> 409 933 8202
>>> PPlease 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] <mailto:[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] <mailto:[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?

Karen Coyle
[log in to unmask]
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet