Quoting "Kevin M. Randall" (in part):
And I am so glad that 440 was retired. I'd be all for adding 130 or 240 to
all records, if the MARC format is going to have a long enough life ahead of
it. It shouldn't be too hard to come up with the logic for adding new
fields to existing records, but I
Stephen Hearn wrote:
> Entering the same data twice to serve two different purposes is not
redundant.
Maybe we need to start emphasizing the fact that for bibliographic
description and access purposes, they are not really the "same data". They
are two different elements, which just happen at tim
The RDA Toolkit's mapping of RDA to MARC appears to map the "Work
manifested" element in some cases to a 1XX/245 combination and in some
to 245 alone. Similarly, the LCPS on recording the "authorized access
point" for a work only resorts to 240 or 130 when the title differs
from what would appear i
Actually, "heading" in AACR2 is the equivalent of "authorized access point" in
RDA. Any element (or word in an element) can be an access point if your system
indexes that information.
Judy Kuhagen
Policy and Standards Division
Library of Congress
Washington, D.C.
-Original Message-
Fro
John Attig said:
>most systems/applications treat the linking-entry fields (760-787) as
>access points by *indexing* them -- and this is exactly the opposite of
>what we should be doing!
Thank you! This helps me understand why our clients prefer 530 to
776, the provider neutral electronic res
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 limitatio
On 2/3/2011 1:58 PM, Karen Coyle wrote:
Where does "controlled access point" fit in? Are there defined access
points in RDA that are not authority controlled? (I guess titles
proper aren't).
The title proper is not a controlled access point; I'm not sure that it
is defined as an access point
J. McRee Elrod wrote:
> See Mark's detailed list. He mentions titles transcribed in 246 and
> 247, edition statement - all for RDA, responsibility for AACR2 (250),
> manufacturing or production place and name (260$e$f), and series
> (490), but not:
>
> Pagination* (300$a)
I think of this one as
Where does "controlled access point" fit in? Are there defined access
points in RDA that are not authority controlled? (I guess titles
proper aren't).
We seem to have these categories in the rules:
- descriptive information (mainly text)
- authoritative/controlled access points
- other acces
Interesting point of theory here. We're working on a distinction between a
number of things here with an unfortunately small number of names.
We want to distinguish
transcription vs. controlled vocabulary
description vs. access points/entries
non-indexed ter
I stopped being surprised a LONG time ago when I found places where
various interlocking standards and documents (MARC, AACR2, ISBD, and
docs including: official documentation, cataloger's desktop, LCRI, OCLC)
were inconsistent, contradictory, or just not quite the same.
If many catalogers rea
In very general terms, the term "heading" in AACR is the equivalent of
"access point" in RDA.
However, the concept of "access point" is not properly a function of the
communications format (or of the cataloging rules). My rephrasing of
Kevin's point -- and it is one of my pet peeves as well -
Karen Coyle wrote:
> > Fields 760-787 have strictly speaking never been "dual function"
> > fields, because they are not defined in the MARC format as access
> > points
>
> This got me excited and I popped into the online MARC documentation to
> look at how it defines "access points" but I can't
I think what Kevin means is that neither AACR2 nor RDA treats these as access
points. On the other hand, many catalogs, including WorldCat, do. A WorldCat
search for "Journal of Balkan and Near Eastern Studies" will retrieve the
record for "Journal of Southern Europe and the Balkans Online" thou
Folks:
Note that the RDA Vocabularies provide both the granularity of separate
elements and the ability to combine them into prescribed order within
statements. Or, to be clear, we've set them up that way, but this isn't
to guarantee that they'll be used properly.
See the article in DLib l
Karen Coyle said:
>The downside to this is that it requires some information to be coded
>and carried twice - once as text and once as data.
I suspect this redundancy is one of the reasons simpler alternatives
to MARC are sought by some. There is considerable inconsistency in
what transcribed
Quoting "Kevin M. Randall" :
Fields 760-787 have strictly speaking never been "dual function"
fields, because they are not defined in the MARC format as access
points
This got me excited and I popped into the online MARC documentation to
look at how it defines "access points" but I can't
Fields 760-787 have strictly speaking never been "dual function" fields,
because they are not defined in the MARC format as access points (regardless of
whatever functionality may be provided in any specific system). They are
descriptive fields which may include coded data in subfield $w intend
The transcribed fields correspond to ISBD areas 1-4 and 6 (245, 250, 362 [for
serials; other fields for some other formats], 260, and 4XX. Note fields may
also contain transcribed data in some cases, but note fields typically consist
of a single subfield and are already "consolidated" in this se
Karen,
Add to your list:
- parallel titles
- subsequent titles (on source, without collective title)
- edition statement
- series statement
- parallel data for all of the above
But I don't think this approach will work if you want software to generate the
ISBD punctuation; in which case you nee
Karen Coyle wrote:
> It seems to me that the number of strictly transcribed fields is very small.
> Is this a full list?
>
> - title proper
> - subtitle
> - statement of responsibility
> - place
> - publisher
Those RDA elements off the top of my head that provide a place for
transcribed informati
Ed, that is a very interesting approach. If we treat
New York, NY, Random House, c1998
as a simple string with no data "capabilities" it also emphasizes
those areas where we would need to create separately actual data if we
wish to provide services, e.g. around place or date. In fact, this
"What we need to capture" may be the key phrase here. There are some MARC
fields that would not suffer a loss of information if they were treated as
single elements. For example, while the 260 field consists of several
separately delimited elements, these elements are all transcribed (more or
23 matches
Mail list logo
