This thread has turned out to be very revealing in many ways. I feel compelled
to point out that our cataloging rules are *supposed* to be centered on the
user (or the patrons, or the public, or the readers, or however someone prefers
to label them). In fact, in the past I have had to endure
Mac wrote:
snip
The relationships among authors and works, manifestations and works,
are for too varied to be expressed in set vocabularies. Creating
them seems like a Medieval exercise in theology.
/snip
Jonathan Rochkind wrote:
snip
If catalogers are unwilling to create records that can be
Weinheimer Jim j.weinhei...@aur.edu:
In an earlier message, I pointed out that if an abbreviation
problem actually exists, then there should be some sort of focus on
the users and the real problems that *they* encounter. I will stick
my neck out and declare definitively that when a user
Sorry about the previous message. I pushed the wrong button!
Karen Coyle wrote:
snip
I don't think we can completely resolve the abbreviation issue in the
transcribed parts of our records, and I'm not convinced that is a
reasonable goal. It does make sense to me to continue to control the
All,
Apologies for cross-posting.
This is to announce that I just added the latest “Cataloging Matters” (no. 7)
podcast to my blog at
http://catalogingmatters.blogspot.com/2010/12/cataloging-matters-podcast-no-7-search.html.
This one discusses search.
Please feel free to forward this to
Erin Blake wrote:
snip
For my own research, and for many users I serve professionally (in an
independent research library), it is vital to have both transcribed and
normalized information for primary resources. I can find things published in
London, England, through MARC 752 ‡a Great Britain ‡b
In basic typography, all caps are avoided in regular body text because it is
considered to be the equivalent of screaming. All caps are normally reserved to
emphasize limited areas or words, such as section titles.
Here's an example of many: Three Reasons to Avoid Using “ALL CAPS” in Website
Mike Tribby wrote:
snip
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
Bernhard Eversberg wrote:
snip
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
Jonathan Rochkind wrote:
snip
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?
/snip
When we talk about MARC as it is used by libraries today, we cannot
Bernhard Eversberg wrote:
snip
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
Bernhard Eversberg wrote:
snip
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
Bernhard Eversberg wrote:
snip
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
Bernhard Eversberg wrote:
snip
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.
Jonathan Rochkind wrote:
snip
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
J. McRee Elrod wrote:
snip
So based on the URL definitions Kevin supplied, these UTLAS/Pica
databases are relational if linkages are inhouse, but linked if to
outside data, e.g., to the NAF as opposed to authorities in my system?
Or must the internal or external data meet some additional standard?
Karen Coyle wrote:
snip
One hint, though, if I may, is that the goal of linked data is NOT to
then put the data in a database. The goal is this one that you list as
the third rule
The third rule, that one should serve information on the web against a
URI ...
is the goal: to make your data
Karen Coyle wrote
snip
Actually, an OpenURL requires a program and a database to resolve it.
It doesn't link directly to the resource. In fact, that's the point of
the OpenURL: it goes through a resolver database in order to provide
the best source for the resource to the user.
/snip
Then how do
Bernhard Eversberg wrote:
snip
They could use the MARCXML records right away? You're sure about that?
Has this assumption been tested with users who know nothing about MARC?
Of course, they cannot use ISO-wrapped records. But even to use MARCXML
records, you still have to have quite a lot of MARC
Bernhard Eversberg wrote:
snip
So, please forget about ISO2709. For all the flaws that MARC is ridden
with, and I can give you a long list, this is not among them. It has
nothing to do with the *content* of MARC records, and about nothing
else do we need to worry, and we can easily give that
Bernhard Eversberg wrote:
snip
Where and how do you receive
ISO records from LC, as a non-librarian?
...
Jim, this gets us nowhere, your preoccupation with ISO! Rest assured,
it is a non-issue for as much as our dealings with the populace are
concerned. Where it still exists, it can be nicely
Bernhard Eversberg wrote:
snip
This tells us something about LC, but about MARC?
LC might, in fact should and certainly could, add MARCXML to the
options instead of providing merely ISO there. They might add EndNote
and BibTeX as well, and more.
/snip
I hate to keep repeating myself, but I feel
/
From: Jonathan Rochkind [rochk...@jhu.edu]
Sent: Wednesday, January 19, 2011 7:03 PM
To: Resource Description and Access / Resource Description and Access
Cc: Weinheimer Jim
Subject: Re: [RDA-L] Linked data
Again, as someone who knows cataloing rules, if there's an algorithm
you can give me
My own opinion is that the term access point should be relegated to the same
oblivion as we have placed the terms library hand and librarian's knot.
With keyword capability, each word in each field is now effectively a point of
access. The idea of access point is based on the limitations of
Hal Cain wrote:
snip
I think we could devise efficient ways to encode the necessary data in MARC
21, and in a way that will enable older systems (not designed for such
extended provisions) to use the data no worse than they do now
(supposing the data is actually there). Some may be better
All,
Please share this message with anyone you think may be interested.
I would like to announce that the next podcast of Cataloging Matters is
available. This one is a little different. It is the paper that I delivered at
the online RDA@yourlibrary conference last Friday (Feb. 4)
Brenndorfer, Thomas
snip
The entries are organized by his role in each film: actor, director, producer,
soundtrack, composer, miscellaneous crew, camera and electrical equipment. This
is a very user-friendly organization.
The whole point to RDA is to allow properly differentiated and
Nerissa Lindsey wrote:
snip
It is interesting to hear that RDA isn't being taught yet at many of these
programs. I personally think that this is unfortunate, because even if RDA is
not adopted I think all cataloging students should at least be learning the
fundamentals so they know why it is
Kelley McGrath wrote:
snip
There was a discussion a while ago now about the problems (or not) with
MARC. I gave a presentation at ALA Midwinter called Will RDA Kill MARC? I
was sort of waiting for the official version to be posted, but, although the
person organizing the presentation has tried to
-BAC.GC.CA] On Behalf Of Weinheimer Jim
Sent: Thursday, February 10, 2011 10:58 AM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] general interest in RDA
Diane Krall wrote:
snip
Sent: Thursday, February 10, 2011 4:22 PM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] general interest in RDA
Kevin M. Randall wrote:
snip
Jim, it sounds from this comment that you really are not grasping what RDA
is all about. If you look at it just in terms of the guidelines themselves,
or the resulting MARC records currently being created, certainly it would
seem that it's just a little tweaking here
Karen Coyle wrote:
snip
I'm not sure how you calculate this. There are only 9 single-digit
numbers (0-8, since 9 is for local use only), and most of them have
already been used: 0, 2, 3, 4, 5, 6, 7, 8. A decision was made early
on that the number subfields, to the extent possible, would retain the
J. McRee Elrod wrote:
snip
I've had not one suggestion on or off list with any provision in RDA
which makes it easier to catalogue electronic resources than using
AACR2, which might have been added to AACR2.
/snip
That is very interesting and it certainly mirrors my experience. Cataloging
Bernhard Eversberg wrote:
snip
Another reason why I think that not MARC is any of our troubles but the
glacial reluctance against using MARC intelligently or at least
in more reasonable and elegant ways. This would include abolishment of
ISO2709, without which MARC wouldn't lose any of its
Bernhard Eversberg wrote:
snip
Am 15.02.2011 15:27, schrieb Weinheimer Jim:
Of course, MARCXML doesn't solve all the problems, but one big one will be
out of the way.
Oh get real, Jim!
The plain text format of MarcEdit can do the same, with an absolute
minimum of effort when compared
Jonathan Rochkind wrote:
snip
On 2/15/2011 10:34 AM, Weinheimer Jim wrote:
I am being real. The plain text format of MarcEdit *absolutely cannot* do the
same as MARCXML. I'll prove this right now. Browsers are built to work with
XML, so right now, this second, any webmaster can work
Bernhard Eversberg wrote:
snip
15.02.2011 20:48, Weinheimer Jim:
In my opinion (and not only mine), this is the world we must enter,
whether we want to or not. How do you enter this world? By creating
Web Services. In order just to start to do this, you must use XML,
since
Hal Cain wrote:
snip
The dictum that context imparts meaning is, I think, relevant here.
In the context of an ISBD bibliographic record, printed or in a screen
display, standard abbreviations have a context; nowadays, even so,
possibly not all who see them in that context will understand
Jonathan Rochkind wrote:
snip
Because like I said, I suspect that whether illustrations are present in color
or not is not of much concern to 99% of patrons 99% of the time. In fact, if
you think about it too hard it's a bit frustrating that expensive cataloger
time is being spent marking down
Hal Cain wrote:
snip
My point is that what we provide in cataloguing should be accurate as
far as it goes, and it should go as far as is reasonably foreseeable
to be useful.
/snip
Absolutely agreed, but my point is: in the environment we are entering
willy-nilly, where everyone and
Diane I. Hillmann wrote:
snip
I think what this discussion points out is a gap in how we think about
who contributes to data and how it is created. In libraries we have
this fantasy that catalogers are 'objective' and that's what we're
trying to do when catalogers create data--provide
Karen Coyle wrote:
snip
Standards are only enforceable if they are measurable. There is no way
to enforce a standard on transcribed data elements. The more that our
data allows for free text input, the less we can do to ensure that
standards are followed.
/snip
What people are calling free
Mike Tribby wrote:
snip
Should cost of access and the possibility of universal access have been
concerns? I think they should have been-- but they were not. To perhaps put it
crassly: theoretical purity was a higher concern than access. It's hard to
blame the co-publishers very much since none
[tbrenndor...@library.guelph.on.ca]
Sent: Thursday, March 17, 2011 7:54 PM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] RDA draft
-Original Message-
From: Resource Description and Access / Resource Description and Access
[mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Weinheimer
Hal Cain wrote:
snip
Jim, I think you're over-thinking it. Confronted with a new book,
don't we examine it and check our favorite database(s) to verify
whether it's a new work or a version of an existing work? If new, we
just treat it at the manifestation level. Under the
currently-anticipated
On 08/04/2011 16:37, Brenndorfer, Thomas wrote:
snip
RDA would call those Derivative Works under the Related Work element.
LibraryThing calls them Related Movies.
Neither RDA nor LibraryThing calls them the same work.
/snip
So, what is this record? http://www.librarything.com/work/2264 Is it a
On 08/04/2011 22:19, Stephen Early wrote:
snip
Which reminds me of Marcel Duchamp's L.H.O.O.Q. (Mona Lisa with a mustache) and
the Andy Warhol silk screen prints of Mona Lisa. How would these fit into the
FRBR model? (enjoying this very interesting discussion)
/snip
I agree that this is an
Harden, Jean wrote:
snip
My experience leads me to the opposite conclusion. For people who don’t already
know how to catalog, much of RDA *is* simpler, more transparent, and so forth
than AACR2. It’s only those of us who have been using AACR2 for years that have
so much trouble grasping the new
Megan Curran wrote:
snip
I just feel like if our catalogs are on the web, and most of what we catalog is
in the web environment, then the rules should be made for that environment.
Using coding tricks and discovery layers to force paper-based cataloging rules
into a web environment amounts to
Myers, John F. wrote:
snip
One could argue interminably the pros and cons of abbreviating or not.
I can see merits to both sides, as well as to native language
representation of missing date issue. (That is, the replacement of
[s.l.] with [place of publication not identified], where [s.l.]
Kevin M. Randall wrote:
snip
James Weinheimer wrote:
I don't think I am missing the point of RDA, and the abbreviations are a
great example. Do we really believe that a simple rule change will solve
whatever problems the public supposedly has with abbreviations in the
catalog? Sorry, but I
All,
For those who are interested, I have just placed another of my podcasts on my
blog: this one a discussion of good enough means in relation to library
cataloging.
http://catalogingmatters.blogspot.com/2011/04/cataloging-matters-podcast-no-9.html
Please forward this to any others who may
Danskin, Alan wrote:
snip
Treating events consistently is a simplification of the instructions. The
decision to include frequency in the name of the event is justified by the
principle of representation if the event represents itself as an Annual
Conference or the Biennial Festival.
/snip
I
On 18/04/2011 19:34, Adam L. Schiff wrote:
snip
I think you are right, but then our patrons will demand that somehow, these
separate conferences all come together. People have plenty of problems already
with conferences--one of the worst is the idea that it is a conference *name*
and not a
Hal Cain wrote:
snip
Yebbut-- the hardest problems of achieving consistency usually arise
from the inconsistencies found in the resources themselves.
Regularizing such inconsistencies will infringe on the principle of
representation: there should be a clear match between the resource and
how it is
Amanda Xu wrote:
snip
Adopting and implementing RDA standards and technologies is different from
fixing a broken motorcycle or automobile. In the later case, you have to
replace parts that are not working or need to be modernized. The pipes or
wires that connect to the parts may not be
101 - 156 of 156 matches
Mail list logo
