Dear colleagues,
although they will most likely be of interest only to those librarians
who speak at least some German, we are pleased to share the German
National Library's first RDA training materials with the community. At
http://www.d-nb.de/eng/standardisierung/afs/frbr_schulungen.htm you
Scan RDA-L flinders
Please ignore the message sent earlier today (at 11.50). It was sent
to the RDA-L list erroneously. Apologies.
-Original Message-
From: Library and Archives Canada - Bibliotheque et Archives Canada
LISTSERV Server (16.0) [mailto:lists...@listserv.lac-bac.gc.ca]
Sent: 08 December 2010
Ideally, the software would convert from the controlled vocabulary to whatever
language makes makes sense to the user -- which could be different in
different systems -- translating to a different language is an obvious example
Wouldn't the same hold true for translating those incredibly obtuse
-Original Message-
From: hec...@dml.vic.edu.au [mailto:hec...@dml.vic.edu.au]
Sent: December 8, 2010 2:02 AM
To: Resource Description and Access / Resource Description and Access;
Brenndorfer, Thomas
Subject: Re: [RDA-L] Recording Relationships in MARC
Quoting Brenndorfer, Thomas
On 12/7/2010 7:19 PM, hec...@dml.vic.edu.au wrote:
In some catalogues they can be a hyperlink. An embedded relator $e or
$4 would compromise such a link.
Not unless the system is stupid. Which many of ours are.
But in our data format, we should not be constrained to recording only
data
Ideally, the software would convert from the controlled vocabulary to
whatever language makes makes sense to the user --
I can see translating into other languages, but for English patrons
would it not have been better to use language which makes sense in the
first place, rather than theory
-Original Message-
From: Resource Description and Access / Resource Description and Access
[mailto:rd...@listserv.lac-bac.gc.ca] On Behalf Of J. McRee Elrod
Sent: December 8, 2010 11:23 AM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] Recording Relationships in MARC
Concerning abbreviations, there are an entire range of options today instead of
the rather atavistic method of retyping everything. I personally think
automated methods, plus using our MARC fields and language of the item would
solve at least 90% of all of the abbreviation problem. Many
I don't think anyone is realistically suggesting that existing legacy
records be manually changed to not have abbreviations.
RDA is just suggesting that going forward they are not used.
For all the carping from catalogers that love abbreviations, I do not
understand what the benefit is
Jonathan Rochkind wrote:
snip
I don't think anyone is realistically suggesting that existing legacy
records be manually changed to not have abbreviations.
RDA is just suggesting that going forward they are not used.
For all the carping from catalogers that love abbreviations, I do not
Jonathan Rochkind said:
I don't think anyone is realistically suggesting that existing legacy
records be manually changed to not have abbreviations.
If RDA is adopted, for constancy in our database, we will either (1)
retrospectively automatedly spell our abbreviations (whether v. is
volumes or
Quoting J. McRee Elrod m...@slc.bc.ca:
Increasingly library catalogues are being consulted on hand held
electronic devices, with very limited display space.
If our data were appropriately coded, rather than being text, the
display could be changed based on the device. (And, yes, there is a
Data, rather than text, should even involve less keying on the part of
catalogers. If there is a field for number of pages, you only key in 357
not 357 p. or 357 pages. You should never have to key something that is in
a controlled vocabulary -- those should be check boxes or drop-downs. And
-Original Message-
From: Resource Description and Access / Resource Description and Access
[mailto:rd...@listserv.lac-bac.gc.ca] On Behalf Of Mike Tribby
Sent: December 8, 2010 2:30 PM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] Abbrevitions in RDA records
Data, rather
Would abbreviations constitute a substitute vocabulary encoding scheme?
Still waiting for the English translation,
Mike Tribby
Senior Cataloger
Quality Books Inc.
The Best of America's Independent Presses
mailto:mike.tri...@quality-books.com
On Dec 8, 2010, at 2:00 PM, Karen Coyle wrote:
Quoting J. McRee Elrod m...@slc.bc.ca:
Increasingly library catalogues are being consulted on hand held
electronic devices, with very limited display space.
If our data were appropriately coded, rather than being text, the
display could be
When I fill out forms on the web I never have to type in the name of a state.
I type in the first letter or letters until the state name appears in the form
box. So why should catalogers be typing in the entire state name? This is not
new technology.
There is a serious problem with our
Actually, it does for many elements. For example, date of birth, date of
death, period of activity of person are all separate elements. It's only
when we end up combining this data with a personal name in an access point
that we have to record both birth and death dates separated by a hyphen,
Jonathan Rochkind said:
and some people seem actively resistant to the idea, for reasons that
are somewhat mysterious to me.
Legacy data? Reinvention of a wheel which rolls along already?
The argument is vociferously made that spelling out edition instead of
writing ed. (saving 4
It is chicken and egg. Present systems do not fully utilize present
data, true; likewise, present data is, in some cases (but some
significant one) extraordinarily expensive, infeasible, or impossible
for software to make use of reliably and robustly.
So we've got to work on both at once, so
21 matches
Mail list logo
