Hi,
On Thu, Jan 13, 2011 at 11:27 AM, Jonathan Rochkind wrote:
> I don't see any significant increase in flexibility to share Marc records by
> 'switching' to MarcXML. Am I missing something? What exactly would be the
> advantages of 'switching' to MarcXML?
There are of course some technical a
Am 14.01.2011 16:13, schrieb Jonathan Rochkind:
And, unfortunately, it's actually the schema, NOT the transmission
format, that is a problem with MARC. It is, as everyone keeps
saying, easy enough to change the serialized transmission format to
something else (MarcXML, an tab delimited spreadsh
Jonathan Rochkind wrote:
Many ILS use the MARC _schema_ (aka "vocabulary", aka "list of fields and
subfields") as their internal data model, if not the serialized transmission
format. The MARC 'schema' is kind of implicit, defined as a byproduct of the
transmission format, which is in part wha
]
Sent: Friday, January 14, 2011 9:30 AM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] Browse and search RDA test data
On Fri, Jan 14, 2011 at 2:36 PM, Weinheimer Jim wrote:
>
> Internally, each database can be different, as each one is today. As I said
> ISO2709 no longer is used
On Fri, Jan 14, 2011 at 2:36 PM, Weinheimer Jim wrote:
>
> Internally, each database can be different, as each one is today. As I said
> ISO2709 no longer is used for internal purposes (except for some CDS-ISIS
> catalogs), and is used only for record transfer.
>
And even that is not a necessity
Bernhard Eversberg wrote:
Really, I'm not a great fan of MARC, but we do it injustice if we insist
it go away because of ISO2709. The latter has to go, and can go, and
isn't being used nor required nor standing in the way in many
applications right now, with no harm done to MARC whatsoever.
No,
Am 14.01.2011 13:19, schrieb Weinheimer Jim:
I hate to keep harping on this, but I think it is a crucial point
since I believe that ISO2709 is one of the key problems holding us
back; certainly more important than adopting FRBR or RDA. As I said
before, ISO2709 may be able to be revamped to hand
Bernhard Eversberg wrote:
Am 14.01.2011 12:24, schrieb Weinheimer Jim:
>
> Bernhard, Sorry to press the point but I think it is a vital one:
> using MARC in its ISO2709 form *cannot* work with linked data.
For all I know, I have to disagree. It is all a matter of field content
and then what the s
Am 14.01.2011 12:24, schrieb Weinheimer Jim:
Bernhard, Sorry to press the point but I think it is a vital one:
using MARC in its ISO2709 form *cannot* work with linked data.
For all I know, I have to disagree. It is all a matter of field content
and then what the software does with that - no m
Bernhard Eversberg wrote:
That may be true for some ILS systems but certainly not for all of them.
If it is, then it is a weakness of that system, not a feature of MARC.
Get rid of those systems or get vendors to understand that this mode
of communication is - though it needs not be thrown overboa
Am 14.01.2011 10:47, schrieb Weinheimer Jim:
... but when I then want to transfer that record that I worked with
into my catalog, I have to recompile it back into an IS2709 record so
that I import using Z39.50, when we are stuck with each and every one
of the limitations of ISO2709.
That may b
Bernhard Eversberg wrote:
Am 14.01.2011 09:54, schrieb Weinheimer Jim:
>
> When we talk about MARC as it is used by libraries today, we cannot
> separate it from the underlying ISO2709 format,...
Oh but we can, we certainly can and we should and we do. A MARC record
can easily be rendered like th
Am 14.01.2011 09:54, schrieb Weinheimer Jim:
When we talk about MARC as it is used by libraries today, we cannot
separate it from the underlying ISO2709 format,...
Oh but we can, we certainly can and we should and we do. A MARC record
can easily be rendered like this:
LDR 00851cam a2200253Ii
Jonathan Rochkind wrote:
I don't see any significant increase in flexibility to share Marc
records by 'switching' to MarcXML. Am I missing something? What
exactly would be the advantages of 'switching' to MarcXML?
When we talk about MARC as it is used by libraries today, we cannot separate i
I don't see any significant increase in flexibility to share Marc
records by 'switching' to MarcXML. Am I missing something? What
exactly would be the advantages of 'switching' to MarcXML?
Trying to think of some, I guess one is that it would be easier to then,
as a later step, incrementall
Quoting Bernhard Eversberg :
A MARC implementation would have to employ identifiers in all relevant
places, using the $w or $0 subfields that have been defined for that
purpose, and some new record types.
When the $0 was added, it was noted that there are many cases where a
MARC field conta
Bernhard Eversberg wrote:
About current MARC practice, your'e right.
While I've never been a dyed-in-the-wool MARC enthusiast, I'm realist
enough to recognize that any migration into something else, and then
what really?, would be a galactic task. There will have to be a MARC
implementation of tho
Am 13.01.2011 15:40, schrieb Karen Coyle:
Quoting Bernhard Eversberg :
We have to, I think, distinguish between our internal representation of
data, which may well be in an upgraded MARC structure, and the
potentially many external representations we use for communication with
anyone outside.
Quoting Bernhard Eversberg :
We have to, I think, distinguish between our internal representation of
data, which may well be in an upgraded MARC structure, and the
potentially many external representations we use for communication with
anyone outside. No one outside needs to be bothered with MA
12.01.2011 15:48, Karen Coyle wrote:
1. How are entities being mapped? can be inferred from certain
codes or the presence of certain fields. The subject entities are
not part of the test, and where is an example for the family type?
2. How are relationships coded? Nothing's different here fro
Quoting Jonathan Rochkind :
I don't see "value" in all caps, I am just not disturbed by them,
and see some sense in transcribing what's on the item in a
transcribed field, especially if it will make cataloging simpler or
cheaper or easier. Basically, I just don't see it matters too much
My experience has been different from Steven Arakawa's. Training beginners to
use AACR2 capitalization has been very easy. The basic lesson is "Use lower
case unless there's some reason to use upper case". There are then about five
common reasons (depending on the languages most commonly encou
Bernhard asked:
>So, what else is wrong with RDA?
What else is wrong?
Let me think.
It abandons ISBD, with no clear replacement guidance for display.
The wording is so fuzzy it can be interpreted in wildly different
ways.
It uses 10 words where 2 would suffice.
It uses esoteric terminology a
>The rules for capitalization in AACR2 (and default RDA, which carries them
>over) are very complex and quite difficult for trainees to grasp, even more so
>when working with multiple languages.
FWIW, in the approximately seventeen years I've been training new catalogers,
AACR2's capitalization
Jonathan Rochkind [rochk...@jhu.edu]
Sent: Wednesday, January 12, 2011 10:32 AM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] Browse and search RDA test data
I don't see "value" in all caps, I am just not disturbed by them, and see some
sense in transcribing what's on the
Adger Williams wrote:
> As to whether it is faithful to change case when transcribing, I have to ask
> just how faithful we are in our transcription if we don't use the same font
> as the chief source of information. I think we would probably all agree that
> matching fonts is clearly impossible
> -Original Message-
> Chris Cronin wrote on 1/11/11:
>
One of our catalogers has noted the
> consequence of this for users who import MARC records from our catalog
> into citation tools like EndNote or RefWorks, and the like, and how
> those tools will treat the data.
So much for inter
I wonder if the transcription of all caps is an anticipation of machine
transcription of titles, where that's the way it would come out, so it would
save catalogers' work to leave it.
Rich Aldred
On Tue, Jan 11, 2011 at 4:31 PM, J. McRee Elrod wrote:
> Lisa Hatt said in regard to all cap titles
tters too much either way.
From: Resource Description and Access / Resource Description and Access
[rd...@listserv.lac-bac.gc.ca] On Behalf Of Mike Tribby
[mike.tri...@quality-books.com]
Sent: Wednesday, January 12, 2011 10:14 AM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re:
Mike Tribby wrote:
Perhaps not surprisingly, I find myself in agreement with both Mac and Hal. And
I would ask Jonathan and any other list members who see value in all-caps
display of titles if they have any thoughts on how to transcribe a title in
which all letters are caps, but the letters at
nt: Wednesday, January 12, 2011 1:43 AM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] Browse and search RDA test data
Am 12.01.2011 03:44, schrieb Daniel CannCasciato:
>
> When I start seeing citations in ALL CAPS, then transcirption of
> titles in ALL CAPS MAKES SENSE.
>
Quoting "J. McRee Elrod" :
> Capitalization as found would be acceptable in 505 contents and 520
> summaries, but 245 titles are seen in hitlists with other titles, so
> uniformity is more important.
>
> In the upper case examples I checked, the all caps do not reflect the
> source, according to A
Quoting Bernhard Eversberg :
1. How are entities being mapped?
The entity type described in a record is not coded directly but
can be inferred from certain codes or the presence of certain fields.
The subject entities are not part of the test, and where is an
example for the family
As a visually impaired user, I can report that text in ALL CAPS is
considerably more difficult to read than text in lower or mixed case. I
could go into the reasons for this, but as Hal Cain states, it's more or
less generally understood to be true.
As to whether it is faithful to change case whe
Am 12.01.2011 03:44, schrieb Daniel CannCasciato:
When I start seeing citations in ALL CAPS, then transcirption of
titles in ALL CAPS MAKES SENSE.
The ALL CAPS issue was a sure bet to arouse a storm in the teacup. Up
until now, it turns out the ONLY item that has been voiced, in a dozen
posts.
Quoting "J. McRee Elrod" :
Capitalization as found would be acceptable in 505 contents and 520
summaries, but 245 titles are seen in hitlists with other titles, so
uniformity is more important.
In the upper case examples I checked, the all caps do not reflect the
source, according to Amazon ima
David Moody wrote in part, in response to Jonathan Rochkind:
"I would find it very disorienting to be constantly switching between various
transcription styles. As often happens, taking a concept to its logical
conclusion winds up being illogical. "
When I start seeing citations in ALL CAPS, th
Lisa Hatt said in regard to all cap titles:
>That's pretty ugly. If I ran across records so done in OCLC, I'd
>probably have to spend a lot of time changing them to sentence case
>before we would want them ...
So will we. Insofar as possible, we are attempting to limit our
changes to RDA reco
> If it's actually in all-caps on the item in hand, it makes sense
> to me
> to transcribe it accurately in the transcribed title. Why
> should this
> be the one exception to faithful transcription? Isn't the
> transcribed
> title supposed to be an exact transcription? Why do we avoid
> re
Nancy Lorimer wrote:
During the test period (at least), some institutions established
in-house guidelines that prescribed transcribing the capitalization
as it appeared on an item, whether digital or physical.
That's pretty ugly. If I ran across records so done in OCLC, I'd
probably have to
s / Resource Description and Access
[rd...@listserv.lac-bac.gc.ca] On Behalf Of Christopher Cronin
[cron...@uchicago.edu]
Sent: Tuesday, January 11, 2011 8:32 PM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] Browse and search RDA test data
Hi Karen,
My initial impression is that when we see al
matters.blogspot.com/
From: Resource Description and Access / Resource Description and Access
[rd...@listserv.lac-bac.gc.ca] On Behalf Of Christopher Cronin
[cron...@uchicago.edu]
Sent: Tuesday, January 11, 2011 8:32 PM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re
Karen Coyle wrote:
> I was rather surprised to
> see some titles presented in all upper case...
> Is this truly RDA compliant? Anyone know?
I cannot speak for RDA--I suspect it doesn't care--but some time ago (June
2010, I think) LC announced that it will be "re-purposing" publisher data
provi
Hi Karen,
My initial impression is that when we see all caps in fields like the 245, 250,
260, 490, it will often be the result of direct transcription of how those data
appeared on the resource, or will perhaps be an RDA record created from ONIX
data. One of our catalogers has noted the conse
This is an alternative rule to 1.7.1 General rules on transcription in RDA.
The rule reads:
When the instructions in chapters 2-4 specify transcription of an
element as it appears on the source of information, apply the general
guidelines on capitalization, punctuation, symbols, abbreviations,
Karen and others,
It is my understanding that RDA guidelines prefer taking titles directly
from the resource, rather than using sentence case (as in AACR2).
I believe that there is an option to use sentence case...but then, there's
an option to use something other than what's in the rules for alm
Thanks, Bernhard. This is very useful.
I was rather surprised (in my first foray into the data) to see some
titles presented in all upper case:
100 1\$aGentry, Paul,$ephotographer.
245 10$aNEW YORK :$bFROM LAND, SEA, & AIR /$cPRINCIPAL PHOTOGRAPHY BY
PAUL GENTRY.
260 \\$aNew York, NY :$bMu
Just where is the authority data that was constructed. This can't be the
future!
On Tue, Jan 11, 2011 at 3:20 AM, Bernhard Eversberg wrote:
> The official test data as made available by LC last week:
>
> http://www.loc.gov/catdir/cpso/RDAtest/rdatestrecords.html
>
> have been imported into a d
The official test data as made available by LC last week:
http://www.loc.gov/catdir/cpso/RDAtest/rdatestrecords.html
have been imported into a database and can now be browsed and searched:
http://www.biblio.tu-bs.de/db/a30/rdatest.htm
There are about 14.000 records, both bib and authorit
49 matches
Mail list logo
