Re: [RDA-L] Browse and search BNB open data
05.08.2011 00:36, Karen Coyle: John Attig: Access points are treated rather strangely in RDA. The access point is not itself an element, but is a construct made up of other elements, which contains instructions about what and when to include various elements in an access point. That actually makes sense from a data design point of view. It means that compound things can be built up of simple things, and that means that you have flexibility in what you can build. (read: tinker-toys, or, for the younger set, Legos) Very important indeed, but elementary for any data technician. Not quite so for those who have been raised on AACR+MARC. They find it strange, as John seems to indicate. Why is that so? Starting out from the mental image of MARC, one may find it natural that everything that can be accessed in a search must be recorded in some data field, and exactly in the way it is needed for the access. This notion needs to be shattered. It has led to such extremes that, for instance, in authority records you have 53 variant names, each and every one of them carrying the same dates for that person. The access points for the variant names can, however, easily be contructed out of a name field plus a date field - the latter always the same. MARC derives from the requirements of card printing. There, each heading (access point in the card catalog) had to be complete and correctly formed as part of the record. This is no longer true, and has never been true in data processing systems: 1. Headings can be constructed out of arbitrary elements, they need not be stored as monolithic strings inside the record 2. New access points can be constructed that had never been possible in card catalogs. All kinds of combinations and reformattings of field contents can be programmed, no need to have every access point prepared in advance and stored in its own field. For example, extract the publisher's name out of the 260 and remove certain particles from it, and then get the date out of the fixed fields to make a useful index entry (access point) like name:date This is easy to understand, but as a consequence, the rules, and thus the data model, will become more abstract and more difficult to understand. But maybe only for someone who has been brought up on the notions of the card catalog and later those of MARC. For someone with a background in abstract data structures, John Attig's clarifications are no surprise at all. One more reason, one might think, to get rid of MARC ASAP. Not really, though. Firstly, because it is utterly unrealistic, and second. because MARC is flexible enough to be used in new software applications that do new tricks with the old stuff AND are able to deal with some new data elements in novel ways. It is not the worst of ideas to look at the additions Germans and Austrians have thought up for their MARC dialect. It will allow us to continue with our scenario 2 applications as they are long since in operation, and the further step to scenario 1, if at all necessary and useful, would not be very difficult either. We are not using MARC internally, and are not going to, but our internal formats are no less complex. They are only not rooted in the mental image of the card. B.Eversberg
Re: [RDA-L] Browse and search BNB open data
On 04/08/2011 21:33, Karen Coyle wrote: snip But the rule is that mostly, you use the publication date of the first manifestation of the expression. (I can't find the rule for this right now, since I don't have access to a lot) The only example I can find right now is King Kong: http://lccn.loc.gov/90715189, where if you look at the related titles, you will see 1933, while the date of publication of this item is 1984. King Kong (Motion picture : 1933) Aha! Thanks. Although... isn't this an even more arcane bit of data than the first date of the work? And many (including you) were doubtful that catalogers could supply that. /snip Not really, because focusing on the manifestation assumes that there has been something published somewhere. Most of the time this is fairly simple, because often, your (later) item discusses the earlier version and saves you a lot of time. If your item does not supply this information, too bad, but by following the rule of Seek and ye shall find, which sometimes might take quite a bit of work, by using Worldcat, the NUC, and all kinds of other catalogs out there, plus a bit of ingenuity, you can normally find a record or citation to that first item published. Besides, most normal catalogers do such an amount of research very rarely. It wouldn't surprise me that if the lack of real consistency in these fields reflects the cataloger's lack of time, plus the general feeling that few patrons understand, use, or want uniform titles so it is not worthwhile spending the time. (I don't necessarily agree, as I discuss below, but the feeling is out there) Comparing this to hunting out a first date of something as vague as the work, which would have to be done much more often and would probably always require research, is quite a different matter. snip In general I am having a hard time understanding how we will treat these kinds of composite headings in any future data carrier. They seem to be somewhat idiosyncratic, in that what data gets added is up to the cataloger, depends on the context, and probably cannot be generated algorithmically. This whole part about headings (access points in RDA, I believe) has me rather stumped from a design point of view. At the same time, if all of the individual elements are available, and one links manifestations of a single expression, then some system feature may be able to display this distinction to the user without the use of individual cataloger-formed headings. This would also mean that the records can be created without being dependent on a particular context, which should make sharing of data even more accurate. /snip In defense of catalogers, the entire system was originally designed for a card/print world where everyone had no choice except to browse, and the method worked fairly well back then. This is shown in Princeton's scanned catalog for Cicero's Pro Milone (http://imagecat1.princeton.edu/cgi-bin/ECC/cards.pl/disk3/0892/B4159?d=fp=Cicero,+Marcus+Tullius--Individual+works--Pro+Archia+%3Eg=52977.50n=47r=1.00thisname=.0047.tiff) and browsing forward from there, you can see how the uniform titles worked, and kept things more or less in order. (At Princeton, most of the uniform titles were handwritten in pencil in the top right hand corner and unfortunately pencil came out very poorly in the scans. Still, I think you can make out the titles and dates.) You will see that the language translations are mostly mixed together, although one includes the qualifier Greek. In spite of this, the final product worked fairly well though, because it was pretty easy--once you got to Cicero. Pro Archia to browse through the cards. Still, I think that instead of trying to shoehorn our data, which was created for another time, to function more or less crudely in the new environment, it would be far more more progressive to reconsider how to use the power of the current systems we have at our disposal. Uniform titles are a great case in point. As we saw in the Princeton catalog, even when they weren't done perfectly, uniform titles worked pretty well in a physical environment where browsing was the only way of finding things, but they fell apart in a computerized/keyword environment, just as much of the rest of the catalog. (For those interested in more on this, see my posting on Autocat http://catalogingmatters.blogspot.com/2010_10_01_archive.html) Today using Worldcat, I can search for au: homer and ti: odyssey http://www.worldcat.org/search?q=ti%3Aodyssey+au%3Ahomer and get a very handy, useful list that I can do a lot with: limit to books, by language, by dates, by translators, novel sorting etc. Today, Zebra-type indexing extracts the headings and other information and makes them available for further refinements, so we get something that so far as I am concerned, is far better than how the clunky, old card/printed catalog ever worked. (Compare the Cicero example
[RDA-L] Cataloging Matters Podcast #12
Apologies for cross-posting I would like to announce my latest Cataloging Matters podcast, which is A Conversation Between a Patron and the Library Catalog. This one is an experiment that I hope you will enjoy. It's available at http://catalogingmatters.blogspot.com/2011/08/cataloging-matters-podcast-12.html There is also a shorter version at http://www.xtranormal.com/watch/12351402/conversation-between-a-patron-and-the-library-catalog-short, and I think you'll see why. Please share this link with anyone you think may be interested. -- James Weinheimer weinheimer.ji...@gmail.com First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
[RDA-L] Get galvanized now!
If you don't feel decently galvanized yet, find stimulating stuff on the JSC website, now updated with loads of presentations, by Barbara Tillett and Judy Kuhagen. http://www.rda-jsc.org/rdapresentations.html The latest one by Judy Kuhagen should do the trick. On slides 116/116, she says *Implementing RDA?* . If yes to that question, need to get ready . If no to that question, still need to get ready --RDA bibliographic and authority records in shared databases local catalogs --RDA access points in non-RDA records . If you don't know the answer yet, *still need* to get ready *Who needs to get ready?* . You . Your library colleagues . Your library's ILS . Your library's users Have a thrilling weekend, B.Eversberg
Re: [RDA-L] Article on RDA implementation
Bernhard: Just a clarification: The Open Metadata Registry was originally funded by the US National Science Foundation, e.g., with 'public' money, not as part of a private initiative. It was intended to be (and still is) an open-source project based on a set of freely available services. Although we have been working with ALA Publishing on integrating the RDA Vocabularies with the Toolkit, primarily to ensure appropriate exchange of information between the two applications, the basis of our work with them includes our common commitment to keeping the Vocabularies openly available and not to subsume the vocabularies as part of the Toolkit. Perhaps the best way to think of that 'integration' is that our approach is to set up the Toolkit as the RDA Vocabularies first institutional 'user', modeling the way other large, machine-based users will access the vocabularies through the OMR services, maintaining a synchronized connection between them as change happens in their separate contexts. We appreciate your continuing recognition of our work and its importance, and welcome your questions about where we're going! Diane On 8/4/11 2:35 AM, Bernhard Eversberg wrote: http://www.libraryjournal.com/lj/home/891482-264/cataloging_community_galvanized_as_u.s..csp [snip] 3. The report says, The elements in RDA have been registered as an element set at the Open Metadata Registry, which should facilitate its integration with the Semantic Web once it has been developed. First: What is this it: The Semantic Web? The Registry? RDA? Second: It ought to be made clear that the Registry started as a more or less private initiative, not supported and not funded by the RDA developers, and officially recognized only recently. The names of those who did the work thus deserve to be mentioned. Third: Will the Registry become part of the toolkit and thus of the monopoly? [snip]
Re: [RDA-L] RDA and collective title
J. McRee Elrod m...@slc.bc.ca wrote: *It seems to me such as container should be added here as a source of title representing the resource as a whole. This is often true of boxed sets of videorecordings (VHS and DVD), boxed sets of CDs, kits, games, and boxed pieces to be assembled. all of which could be mentioned as examples. Look under 2.2.2. -- Mark K. Ehlert Minitex Coordinator University of Minnesota Bibliographic Technical 15 Andersen Library Services (BATS) Unit 222 21st Avenue South Phone: 612-624-0805 Minneapolis, MN 55455-0439 http://www.minitex.umn.edu/
Re: [RDA-L] RDA and collective title
-Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of J. McRee Elrod Sent: August 4, 2011 8:14 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: [RDA-L] RDA and collective title RDA 2.1.2.2 -- Overview Resource Issued as a Single Unit When preparing a comprehensive description for a resource issued as a single unit (e.g., a textbook in one volume), choose a source of information identifying the resource as a whole*. If there is no source of information identifying the resource as a whole (e.g., a single videodisc containing multiple feature films but with no source of information identifying the resource as a whole), treat the sources of information identifying its individual contents as a collective source of information for the resource as a whole *It seems to me such as container should be added here as a source of title representing the resource as a whole. This is often true of boxed sets of videorecordings (VHS and DVD), boxed sets of CDs, kits, games, and boxed pieces to be assembled. all of which could be mentioned as examples. Container is defined in 2.2.2.1 as being part of the resource itself (if the container is issued with the resource, and kit is given as an example in this instruction). Therefore, container is already defined as a possible source of information identifying the resource as a whole, whether the resource is a single unit (2.1.2.2) or a multipart resource (2.1.2.3). Kits come up as an example again in 2.1.2.3, since kits would tend to be characterized as multipart resources not single unit resources. I would think the Mode of issuance element in 2.13.1.3 would be multipart monograph for a kit, and so 2.1.2.3 applies when choosing a source of information for the title for a kit, and that would mean the container is already included as an option for a source, based on 2.2.2.1. Thomas Brenndorfer Guelph Public Library
Re: [RDA-L] RDA and collective title
Is the usefulness of RDA going to require this kind of exegesis? Whew! On Fri, Aug 5, 2011 at 7:18 AM, Brenndorfer, Thomas tbrenndor...@library.guelph.on.ca wrote: -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of J. McRee Elrod Sent: August 4, 2011 8:14 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: [RDA-L] RDA and collective title RDA 2.1.2.2 -- Overview Resource Issued as a Single Unit When preparing a comprehensive description for a resource issued as a single unit (e.g., a textbook in one volume), choose a source of information identifying the resource as a whole*. If there is no source of information identifying the resource as a whole (e.g., a single videodisc containing multiple feature films but with no source of information identifying the resource as a whole), treat the sources of information identifying its individual contents as a collective source of information for the resource as a whole *It seems to me such as container should be added here as a source of title representing the resource as a whole. This is often true of boxed sets of videorecordings (VHS and DVD), boxed sets of CDs, kits, games, and boxed pieces to be assembled. all of which could be mentioned as examples. Container is defined in 2.2.2.1 as being part of the resource itself (if the container is issued with the resource, and kit is given as an example in this instruction). Therefore, container is already defined as a possible source of information identifying the resource as a whole, whether the resource is a single unit (2.1.2.2) or a multipart resource (2.1.2.3). Kits come up as an example again in 2.1.2.3, since kits would tend to be characterized as multipart resources not single unit resources. I would think the Mode of issuance element in 2.13.1.3 would be multipart monograph for a kit, and so 2.1.2.3 applies when choosing a source of information for the title for a kit, and that would mean the container is already included as an option for a source, based on 2.2.2.1. Thomas Brenndorfer Guelph Public Library -- Gene Fieg Cataloger/Serials Librarian Claremont School of Theology gf...@cst.edu
[RDA-L] Possible uses of MARC (was: Browse and search BNB open data)
Bernhard said:
One more reason, one might think, to get rid of MARC ASAP.
Not really, though. Firstly, because it is utterly unrealistic,
and second. because MARC is flexible enough to be used in
new software applications that do new tricks with the old
stuff AND are able to deal with some new data elements in
novel ways.
Not so new and not so novel. UTLAS in the 1970s used a mix and match
method for entry verification. If a heading did not match, one
subfield at a time was dropped until a portion did match. The later
portions, matching with their own authorities, were then nested.
You had a string of ASNs representing the entry in the bibliographic
record (or URIs in Karen speak). For persons, $d death dates were
ignored in matching, since it might or might not be there.
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
Re: [RDA-L] RDA and collective title
Thomas said:
Kits come up as an example again in 2.1.2.3, since kits would tend to
be characterized as multipart resources not single unit resources.
You've put your finger on why we had such difficulty doing an
intelligible record for a kit using RDA. A kit is a single item,
often the only manifestation of the only expression of the work it
represents. Perhaps we need kit added as a carrier term (although
it would not fit under any of the carrier categories - possibly having
parts from any of them), and mixed as a content term. A kit needs
to be treated as a single whole (which is why I wanted container
added at 2.1.2.2 and not only at 2.2.2).
AACR2 works better for kits, but not for a growing category: kits for
assembly. While Tinkertoy and Leggo can be called [toy], that does
not work for a kit designed to teach physics students the structure of
an atom, a molecule, or the solar system. Since there is only one
material - usually wood or plastic pieces - cataloguers have been
calling them [realia]. While many are used to create a [model]. as
issued and circulated they are not yet models. (Seems to me [realia]
would be the actual solar system, molecule or atom :-{)}.)
Library resources are becoming increasingly varied, and neither AACR2
nor RDA are up to the task, RDA even less so that AACR2.
I would think the Mode of issuance element in 2.13.1.3 would be
multipart monograph for a kit ...
But it is in one box, as are boxed sets of DVDs and CDs. It's not like
a multivolume set of books. People accuse us of thinking in terms of
the catalogue card. Seems to me tend to think more in terms of printed
books.
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
Re: [RDA-L] Browse and search BNB open data
Quoting Bernhard Eversberg e...@biblio.tu-bs.de: One more reason, one might think, to get rid of MARC ASAP. Not really, though. Firstly, because it is utterly unrealistic, and second. because MARC is flexible enough to be used in new software applications that do new tricks with the old stuff AND are able to deal with some new data elements in novel ways. The MARC format, aka ISO 2709, may have that flexibility, but I'm not convinced that the way that we have used MARC lives up to that. The atomized data that we do have, which is found in the fixed fields and some of the 0XX fields, is often not filled in when it should be. The same is true for structured headings, like the current uniform title. It is easy to find records for translations that do not have a uniform title for the original. Music catalogers are diligent about the music uniform title, but considerably less diligent in filling in the 047 which is a structured form of musical composition, or the 048 for number of instruments or voices. The fact is that the computable area of our record has been treated as secondary. And don't anyone come back and tell me that it's because systems don't do anything with it. It's a chicken and egg problem: systems can't do anything with it unless the data has been provided consistently, and the data isn't provided consistently because systems don't do anything with it. The foundation of this problem is that catalogers are being asked to create two parallel sets of data: one that is visible to the users, and one that should satisfy machine needs. We should be doing everything we can with a single set of data because it is just human nature that doing things twice will mean that something -- especially the less visible thing -- doesn't get done. kc -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
[RDA-L] Fwd: [RDA-L] Browse and search BNB open data
-- Forwarded message -- From: Gene Fieg gf...@cst.edu Date: Fri, Aug 5, 2011 at 12:42 PM Subject: Re: [RDA-L] Browse and search BNB open data To: kco...@kcoyle.net Sometimes that MARC data isn't there because of local policies as well. As for systems not being able to use the data, the system people here finally changed a 7XX 02 from alternate title to Contains... On Fri, Aug 5, 2011 at 12:11 PM, Karen Coyle li...@kcoyle.net wrote: Quoting Bernhard Eversberg e...@biblio.tu-bs.de: One more reason, one might think, to get rid of MARC ASAP. Not really, though. Firstly, because it is utterly unrealistic, and second. because MARC is flexible enough to be used in new software applications that do new tricks with the old stuff AND are able to deal with some new data elements in novel ways. The MARC format, aka ISO 2709, may have that flexibility, but I'm not convinced that the way that we have used MARC lives up to that. The atomized data that we do have, which is found in the fixed fields and some of the 0XX fields, is often not filled in when it should be. The same is true for structured headings, like the current uniform title. It is easy to find records for translations that do not have a uniform title for the original. Music catalogers are diligent about the music uniform title, but considerably less diligent in filling in the 047 which is a structured form of musical composition, or the 048 for number of instruments or voices. The fact is that the computable area of our record has been treated as secondary. And don't anyone come back and tell me that it's because systems don't do anything with it. It's a chicken and egg problem: systems can't do anything with it unless the data has been provided consistently, and the data isn't provided consistently because systems don't do anything with it. The foundation of this problem is that catalogers are being asked to create two parallel sets of data: one that is visible to the users, and one that should satisfy machine needs. We should be doing everything we can with a single set of data because it is just human nature that doing things twice will mean that something -- especially the less visible thing -- doesn't get done. kc -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet -- Gene Fieg Cataloger/Serials Librarian Claremont School of Theology gf...@cst.edu -- Gene Fieg Cataloger/Serials Librarian Claremont School of Theology gf...@cst.edu
Re: [RDA-L] Completeness of records (was: Browse and search BNB open data)
Karen said:
It is easy to find records for translations that do not have a uniform
title for the original.
Our smaller clients strongly object to a 240 for translations,
particularly if the foreign language text is not on the title page;
they say it confuses patrons. We change the 240 to to 246 3
$iTranslation of:$a. They accept 240 for classical music and
Shakespeare, but little else.
There is also the case in Canada of simultaneous publications in English
and French. There is no way of know which is a translation of the other.
Don't assume failure on the part of the cataloguer; it may be patron
desire. Patron convenience seems to be the forgotten factor in much
or our discussions.
My preference would be address the problem though systems, rather than
changing records, e.g., to have 240s suppressed in display and
hitlists, but that would remove 240s from classical music and
Shakespeare as well.
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
Re: [RDA-L] Completeness of records (was: Browse and search BNB open data) (fwd)
I said:
Our smaller clients strongly object to a 240 for translations ...
I should have added they are not very fond of 130s either,
particularly when the 130 says (motion picture) and the 245 says
[videorecording]. They say patrons see it as a contradiction.
They will accept 130s for Bible, and we've had no complaints about
Arabian nights.
There seems to be a gap between those who make these decisions, and
the resulting experience of many library users. RDA seems even further
removed than AACR2, since it does not address display.
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
Re: [RDA-L] Completeness of records (was: Browse and search BNB open data)
Quoting J. McRee Elrod m...@slc.bc.ca: Don't assume failure on the part of the cataloguer; it may be patron desire. Patron convenience seems to be the forgotten factor in much or our discussions. Not only do I not assume failure on the part of the cataloguer, I don't assume failure at all. But the fact is that we can only work with the data we have in our bibliographic records regardless of what data *possibilities* there are in the MARC record. I believe this is indisputable. My preference would be address the problem though systems, rather than changing records, e.g., to have 240s suppressed in display and hitlists, but that would remove 240s from classical music and Shakespeare as well. It's not rocket science to keep 240's in music records, as long as they are coded as music records, and drop them from text records. It's not even rocket science to display uniform titles for items with multiple Expressions. There are a lot of possibilities, but for these possibilities to become realities we have to get the data out of MARC in into a more manipulable format. These things are a pain to do with our current data, but I think they become much more plausible with a format that is less based on the structure of the display and more on the meaning of the data. In fact, the RDA elements, as defined, are closer to this concept of manipulable data elements than MARC is. That's not to say that RDA is perfect as a cataloging code, but it is based on more modern data concepts than AACR/MARC was. kc -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] RDA and collective title
-Original Message- From: J. McRee Elrod [mailto:m...@slc.bc.ca] Sent: August 5, 2011 12:55 PM To: Brenndorfer, Thomas Cc: RDA-L@listserv.lac-bac.gc.ca Subject: Re: [RDA-L] RDA and collective title Thomas said: Kits come up as an example again in 2.1.2.3, since kits would tend to be characterized as multipart resources not single unit resources. You've put your finger on why we had such difficulty doing an intelligible record for a kit using RDA. A kit is a single item, often the only manifestation of the only expression of the work it represents. Perhaps we need kit added as a carrier term (although it would not fit under any of the carrier categories - possibly having parts from any of them), and mixed as a content term. A kit needs to be treated as a single whole (which is why I wanted container added at 2.1.2.2 and not only at 2.2.2). In looking at examples in RDA, it's clear that the number of units for each type of carrier, not the presence or absence of a container, is what determines if the manifestation is a single unit or a multipart monograph (or a kit). From RDA 1.5.2: a) a resource issued as a single unit (e.g., a single audio disc, a PDF document) b) a multipart monograph (e.g., three videocassettes issued as a set, a kit consisting of a digital videodisc, a model, and an instruction booklet) So it doesn't matter if a set of 3 DVDs come in separate jewel cases, a single jewel case, a box or sleeve of some sort-- we measure 3 separate UNITs for the carrier in the Extent, not the containers of 3 boxes or 3 jewel cases or 1 box or 1 jewel case. If the container is important, there are options to include it as part of the Dimensions (example at 3.1.4.20), but generally the container is not a determining factor declaring something a single unit or a kit. The container, though, is important for determining a chief source of information for the title, especially if it's a kit. It seems that the special kinds of objects with all the different kinds of material pieces can be handled quite well by using subunits in RDA. There are numerous examples in RDA where objects, such as games, can have subunits, as in 3.4.6.3: Extent: 1 game (1 board, 50 cards, 5 role cards, 2 dice) That's a single unit as far as RDA goes (and one carrier: object), even with all these constituent subunits, but I think we're in multipart monograph territory again with this example: Extent: 2 games (various pieces) as well as in cases where there are multiple heterogeneous carriers (designated with the phrase various pieces), but only one predominant carrier type (RDA 3.1.4.3): Carrier: sheet Extent: 43 various pieces Dimensions: box 20 x 12 x 6 cm Even with one container, there are multiple units (most, but not all, of them of the carrier type sheet), and so this is a multipart monograph with the 43 units for the different carriers. The collective title may very well have been on the box in this case, as the container does have an impact in the choice for chief source of information but not on the factors relating to carrier and extent. Thomas Brenndorfer Guelph Public Library
Re: [RDA-L] Completeness of records (was: Browse and search BNB open data)
On 8/5/11 at 2:16 PM, Karen Coyle wrote in part: But the fact is that we can only work with the data we have in our bibliographic records regardless of what data *possibilities* there are in the MARC record. I believe this is indisputable. I like this. I just hope that this indisputable fact begins to register with the admin folk who make budget and staffing decisions - - often, it seems to me, they ignore the simple fact that if no one creates metadata, then the shiny discovery interface only appears to be aiding our patrons because it's built over a shallow/poor resource. We should talk much less (in other professional areas) about baseline/standard records and more about enriched and quality records. Daniel -- Daniel CannCasciato Head of Cataloging Central Washington University Brooks Library Ellensburg, WA We offer solid services that people need, and we do so wearing sensible shoes. -- MT
