Re: [RDA-L] MARC records in a bilingual catalogue
From: Resource Description and Access / Resource Description and Access [RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Hal Cain [hegc...@gmail.com] Sent: January-31-12 12:13 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] MARC records in a bilingual catalogue But then, Jim Weinheimer wrote, although for another reason: I am just saying that a simple belief that going to linked data will be the solution, could actually lead to nightmares. This, I think, deserves consideration. We need to come to terms about how we are actually going to encode our data in our real-world environments. Indeed. But maybe a consensus, even a preliminary one, about what to encode matters, and can't be postponed too long; otherwise we risk not just putting the cart before the horse but getting the features of the cart wrong; (yes, it needs wheels, then the horse can push it; a wheel-less cart, i.e. a sled, can't very well be pushed). The current parallel discussion of recording/displaying dates with names in MARC21 is going on in a context where the range of practically available subfields in 1XX tags is full, so birth, death and activity dates can't be distinguished by coding. This early document in RDA development reviews the use of MARC as a proxy encoding scheme until such time as a proper element set can be developed (which is happening with http://rdvocab.info/ ): http://www.rda-jsc.org/docs/5editor3.pdf MARC has too many placeholders that can hold only unstructured value strings, and sporadically supplies fixed field values that can be mapped to some RDA elements, with overlap and redundancy resulting. (The status quo is a nightmare.) Currently in MARC, elements like Date of Birth for a person can be encoded in 046 in an authority record, as well as added to the authorized access point. All elements in RDA are defined separately from their use in the construction of authorized access points (a significant reason for the bulk and complexity of RDA is the seemingly repetitive instructions for the construction of authorized access points out of previously defined elements). Authorized access points are need for some catalog scenarios, but the elements are needed for all scenarios. I think one future approach to the elements is to have them automatically create authorized access points on-the-fly. But even better would be the use of those elements in a disambiguation function, where sufficient data from a range of appropriate elements could be displayed to help people differentiate names better in a search result (like Wikipedia or IMDB). It's difficult to get to this level of functionality with the current constraints in MARC. The best idea would be to utilize MARC as much as possible as a proxy encoding scheme, through the use of the new MARC fields for separately defined RDA elements (these already appear in many authority records particularly in the 3XX range -- and these are very helpful I've found). ILS interface design could also assist in the use of drop-down values or macros to make variable fields become more like registered value fields. In the long run, a data entry form with just RDA elements would be much simpler than encoding in MARC, since one is no longer conflating display issues with required data, and encoding consistently where appropriate in registered values to assist in the internationalization of cataloging data. Thomas Brenndorfer Guelph Public Library
Re: [RDA-L] MARC records in a bilingual catalogue
Am 27.01.2012 22:11, schrieb J. McRee Elrod: Do the bibliographic records that SLC produces contain only internationally acceptable abbreviations or words? I should have added that for French items going to a French or French/English bilingual catalogue, we will change map to carte. The ISBD abbreviations p., v., ill., col. present no problem, and need not be changed. RDA will create *much* more work. But Barbara Tillett had written: Even better will be when we can move beyond MARC and use linked data with URLs to identify entities and then display whatever language/script the user wants. We have seen the proof of that concept with VIAF-the Virtual International Authority File. In a full-fledged Linked Data implementation, we might have, for example (as long as we are stuck with MARC, but this kind of thing wouldn't change, or would it?) 336 $1 http://rdvocab.info/termList/RDAContentType/1020 337 $1 http://rdvocab.info/termList/RDAMediaType/1007 338 $1 http://rdvocab.info/termList/RDACarrierType/1049 instead of 336 $a text 337 $a unmediated 338 $a volume if the resource is a book. So, instead of those textual terms we'd have those stable URI's, and these would resolve to the current language terms actually needed by the catalog or wanted by the user. The German ones are already there. Are we going, then, to create another set of URIs like those for p., v., ill. and so on? But then, Jim Weinheimer wrote, although for another reason: I am just saying that a simple belief that going to linked data will be the solution, could actually lead to nightmares. This, I think, deserves consideration. We need to come to terms about how we are actually going to encode our data in our real-world environments. B.Eversberg
Re: [RDA-L] MARC records in a bilingual catalogue
On Mon, 30 Jan 2012 09:54:22 +0100, Bernhard Eversberg e...@biblio.tu-bs.de wrote: But then, Jim Weinheimer wrote, although for another reason: I am just saying that a simple belief that going to linked data will be the solution, could actually lead to nightmares. This, I think, deserves consideration. We need to come to terms about how we are actually going to encode our data in our real-world environments. Indeed. But maybe a consensus, even a preliminary one, about what to encode matters, and can't be postponed too long; otherwise we risk not just putting the cart before the horse but getting the features of the cart wrong; (yes, it needs wheels, then the horse can push it; a wheel-less cart, i.e. a sled, can't very well be pushed). The current parallel discussion of recording/displaying dates with names in MARC21 is going on in a context where the range of practically available subfields in 1XX tags is full, so birth, death and activity dates can't be distinguished by coding. (I say practically because in theory upper-case letters could be used as additional subfield identifiers, but the MARC community rejects that idea; they also reject using more than one character.) Hal Cain Melbourne, Australia hegc...@gmail.com
Re: [RDA-L] MARC records in a bilingual catalogue
Damian Iseminger asked:
Do the bibliographic records that SLC produces contain only
internationally acceptable abbreviations or words?
I should have added that for French items going to a French or
French/English bilingual catalogue, we will change map to carte.
The ISBD abbreviations p., v., ill., col. present no
problem, and need not be changed. RDA will create *much* more work.
I suspect we are already charging the highest prices our clients can
afford in this economic climate. (One client has already cut back on
505 contents of more than 10 chapters, for which there is an
additional charge.) Our present plan is to continue with ISBD and
AACR2 abbreviations as part of the export program.
The abbreviations remain the same in UKMARC records for British
libraries still using UKMARC.
For a German catalogue the abbreviations would need to be changed, and
we have no German only catalogue client at present; our European
clients are at least bilingual if not trilingual.
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
