-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 17.10.2013 00:02, schrieb Charles Croissant: > The instruction at 9.4.1.3 is an exact parallel to the instruction at > 9.3.1.3, so I think you can apply the same line of reasoning in both > instances. There will be times when we record a person's dates or title as > a separate data element, times when we record dates or titles as parts of > access points, and times when we do both. If I recall correctly, RDA instructs us to determine the name of the person and several kinds of other data. From this we have to assemble the preferred access point according to syntactic rules which are chosen to yield results as far as possible identical to "headings" constructed under AACR2. You then have the /choice/ to additionally record the data collected in the process (or some of it) as such. While headings / access points coded in MARC are somewhat phrased by subfield delimiters, the amount of markup is not sufficient to preserve the information gathered as /data/. If this information shall be recorded as data (I don't think RDA has a stance with respect to this, but trashing immediately any information just laboriously gathered seems such a waste) it has to find a different place in the data format, preferably in an authority record. Even the most data-like X00$d in my opinion does not qualify as "data": Usually exact birth and death dates can be determined but months and days enter subfield $d only in cases where further disambiguation is needed... > An example of Heidrun's first case, that is, of recording someone's title > as a separate data element, would be including someone's title as one of > the elements in the person's authority record, even though it is not needed > as part of the person's access point, because having information about the > title contributes to an exact identification of the person. Then there are > a specific set of situations where we are asked to make a person's title > part of his or her access point, and those situations are defined in > 9.19.1.2. Completely agreed. But above you mentionend cases where information would only go into access points and not also in a dedicated data element? Personally I think that it must not be any cataloging codes' business to limit my recording of data gathered on the occasion of performing professional functions. Mandating (and also excluding) elements to be accounted for when constructing access points makes much sense, but naming elements or circumstances where these elements may not be recorded as data would be a completely different business. > Consider our practice with dates-- now that we have the 046 field, there > are many instances where a person's dates are being recorded in a separate > element, even though they are not used in the access point, and just as > many instances where someone's dates are being recorded both in separate > elements _and_ as part of their access point. There are also instances > where a person's dates have been recorded in an access point, but haven't > (yet) been recorded as separate elements. Maybe titles are different in the following respect: They sometimes happen to be already part of the /name/ and therefore are incorporated into the access point anyway. RDA instructs us now to determine the exact title as such (and in many cases incorporate it into the access point a second time). There is not much harm in this, since most often the title as occurring in the name deviates significantly from the title as such. viele Gruesse Thomas Berger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (Cygwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iJwEAQECAAYFAlJfItMACgkQYhMlmJ6W47OiQgP/fHpVjsEN4YMweE8plmDT5+fH zoQ8pkE5V6mxBPZXGBpGu6+u56BZ6fDs4y76pBTR2AbB5VYulsbARW/CcV1L0ozt Ko833RaGwlCPOdT/OXAwrC0Qfsq7igOE9kxOdo2bGe2p2vK80eLGuTHlLgr3ybHN wRMIAEbAAueV51mgEp0= =7FiQ -----END PGP SIGNATURE-----
