Mark & Judie:
Let me try to clarify some of this--I agree that it can be very confusing.
Dublin Core and the RDA Vocabularies are separate element vocabularies,
and either one can be used by a digital asset management system
(normally the system you choose already comes with something someone
J. McRee Elrod writes:
> Gene Fieg said:
>
> >Not to include certain fields, whether variable or fixed, does a disservice
> >to the patron who might be looking for specific types of information in
> >those books.
>
> Some standards should be considered as very low floors, not ceilings,
> for what w
OCLC is pleased to offer a webinar series "Changes from AACR2 to RDA."
This webinar uses side-by-side examples in MARC format to show the most
significant changes between AACR2 and RDA cataloging practices. The
webinar is presented in two parts: Part 1 covers description, and Part 2
covers access
Gene Fieg said:
>Not to include certain fields, whether variable or fixed, does a disservice
>to the patron who might be looking for specific types of information in
>those books.
Some standards should be considered as very low floors, not ceilings,
for what we should be doing.
Omission of fie
So your argument is that every single possible field must be created to
be the briefest informative record possible? Really?
Regardless, that's an argument to take up with bibco/PCC I guess.
Apparently they decided that not every single possible field was
neccesary for a BIBCO Standard Record
The XML of Dublin Core would relate to how the information was recorded only.
Since you plan on using a digital asset management system, I am assuming there
is some database in place that would record the DC metadata elements. There is
a DC task group looking at incorporating RDA elements into R
Thanks for the documents on bibco records.
Not to include certain fields, whether variable or fixed, does a disservice
to the patron who might be looking for specific types of information in
those books. Our goal should not only create the briefest record possible,
but the briefest informative re
Hi,
I'm trying to set up a dam system for all of our photos, documents,
publications and things that we have. Basically catalog it all. We aren't going
to use MARC and are looking at Dublin Core, but really great explanations of
how this works especially in conjunction with RDA are not easy to
This record is coded as a BIBCO record.
The BIBCO Standard Record does not require the bibliographical references
and indexes note(s) nor most fixed fields to be filled in. The particular
fields that Mr. Fieg criticizes as lacking are not required for PCC
records.
Please see the BIBCO Stand
But submit to whom? I think PCC oversaw the last revision of the NACO
Heading Comparison rules (formerly NACO normalization). LC manages the
DCM, which is closer to being an internal document than the LCRIs have
been, and less open to community input. (DCM's instructions on using
pairs of 670s in
OCLC record: *690085810: Fixed field for index should be marked as "1".
It also should have 504 stating that it contains bibliographical references
and index.
I guess we are too busy adding fields 336-338 and forgetting what may be
truly useful to the patron.
--
Gene Fieg
Cataloger/Serials Libra
> My guess is there are other rules that I haven't spotted yet,
> but these three--DCM Z1 008/32, NACO Heading Comparison, and
> RDA/LCPS--would need to change to correct the current practice.
The desire to have the UndifPNA practice/records changed has been expressed
repeatedly over the years.
I've been trying to identify the linchpins in our documentation that
hold the sorry UndifPNA practice together. One is the DCM instruction
cited earlier. Another is the revised NACO Heading Comparison Rules
which forbid identical 100s. All AACR2 says is that identical
"headings" should be used in b
Just to point out a few things here:
If we were not making the text of the name serve double duty, we would
be providing an identifier to every newly established name, and the
description would provide information on where that name appeared (a
title page, for instance), which would thereby p
WHY does it take a new set of rules to make this change? If a name has been
undifferentiated under AACR2, there is every reason to believe we will need
that undifferentiated heading again under AACR2, even if the last 670 is
removed. I have been 'begging' for a workable change to undifferentiat
On 4/25/2011 1:42 PM, Stephen Hearn wrote:
Actually it doesn't remain the same. The current rules say that
identities can and should move on and off of an undifferentiated
personal name authority (UndiffPNA). When an UndiffPNA is reduced to
representing a single identity again, it is recoded as "
Yep, that's exactly why using URI's has become conventional, you've got
it actually.
Instead of just using "1234567" as an identifier for an authority file,
running into the problems you talk about, you use something like:
http://id.loc.gov/subjects/12345678
Or whatever. This is in fact exac
Actually it doesn't remain the same. The current rules say that
identities can and should move on and off of an undifferentiated
personal name authority (UndiffPNA). When an UndiffPNA is reduced to
representing a single identity again, it is recoded as "unique"
(UniqPNA), until another person with
I see where we're going here, but it may not be quite as bad as you think.
Our monthly updates from Marcive are indeed based on 010, not based on
unstable character strings and I guess others' are also. I hadn't reckoned
with authority numbers in bib records, but, (like Mac's long-lamented
UTLAS).
Undifferentiated personal name authority records exist only because we use the
preferred label (the heading) as our identifiers. They made sense in a card
file, but not in a computer-based system. It's surprising that RDA carried
them over. We should be creating a separate record for each bib
On 04/25/2011 06:20 PM, Jonathan Rochkind wrote:
Seriously, it is a fundamental idea in identifier management, decades
old, that you should not change your identifiers, and for this reason
you should not use strings you will be displaying to users as
identifiers. One way this idea is expressed
I'd interprett it differently, I'd say that an "undifferentiated name
authority" always refers to the same thing -- a sort of fake person that
isn't really a known person at all. But this remains the same, it's just
the way it is.
It turns out that "person" is a slippery concept in the first
Jonathan Rochkind wrote:
> This [database linkages and identifiers] is a pretty
> fundamental concept of data design accepted by every single contemporary era
> data/database/metadata designer. ... It's not a controversial
> principle. At all. Anywhere except among library catalogers, apparently
Another fundamental rule of identifiers is that what is identified
should not change significantly. That generally holds true in LC
authority practice, but not in the case of undifferentiated personal
name authorities. By rule and standard procedure, an LCCN for an
authority of this kind can refer
I am talking about our library-community database as "the database
[someone] is linking to."
If we're always changing our identifiers (considering our authority 1xx
"preferred display forms" to be identifiers), that makes it very hard
for anyone to link to things in our database.
Even just f
On 04/25/2011 05:56 PM, Jonathan Rochkind wrote:
If you maintain the "preferred display form" as your _identifier_,
then whenever the preferred display form changes, all those links will
need to be changed.
This is why contemporary computer-era identifier practice does NOT use
"preferred dis
Book in hand: God's empire / Hilary M. Carey.
OCLC record: *656771606
I won't change the record in OCLC, but for our library here, we will
transform it back to AACR2.
While we are spelling out pages and illustrations, etc., I guess we forgot
to include the information that the book includes maps.
If you maintain the "preferred display form" as your _identifier_, then
whenever the preferred display form changes, all those links will need
to be changed.
This is why contemporary computer-era identifier practice does NOT use
"preferred display form" as an identifier. Because preferred disp
On 04/25/2011 04:27 PM, Jonathan Rochkind wrote:
I agree entirely, controlled headings from authority files ARE a sort
of archaic version of identifiers and should be considered as such.
The thing is, that they aren't all that succesful as identifiers in
the modern environment. For instance,
"We've got identifiers" -- do you mean the 1xx "preferred display forms"
are identifiers? That is what James was suggesting, and I was agreeing
that they were a pre-computer-era form of identifier, and it is helpful
to understand them as being that.
But they aren't good identifiers, at least
I don't think I understand.
We've got identifiers.
We all do our authority updates by authority record numbers, which (by and
large) don't change.
We do change 1xx forms, which one should perhaps think of as "preferred
display forms", and I think it would be unwise to think the desire to change
p
Jonathan Rochkind wrote:
> One idea is if perhaps the matching algorithm could use the new 3xx fields
> instead of the 300 "type of unit" free text. Of course, that relies on the
> new 3xx fields using only controlled terms, which I'm not sure is the case
> (but should be!).
Assuming 3xx is limi
On 4/22/2011 3:30 PM, Deborah Fritz wrote:
People *will* be entering free text as this RDA element, so I would like to
know whether anyone has figured out some way that matching algorythms will
be able to reliably match descriptions without the use of consistent terms
in this element.
No, and n
On 4/22/2011 1:13 PM, James Weinheimer wrote:
There is another way of looking at our headings than solely as textual
strings, which is not entirely correct, but rather as identifying
something *unambiguously*. This is exactly what our headings are
designed to do. An identifier does not have t
On 4/21/2011 7:27 PM, J. McRee Elrod wrote:
Karen Coyle said:
Linking is not the same as using identifiers rather than text strings
for entities, although both are considered "best practices" and
linking depends greatly on clear identification.
So these identifiers link to *inhouse* files? "Sh
35 matches
Mail list logo
