> -----Original Message----- > From: Resource Description and Access / Resource Description and Access > [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of John Attig > Sent: August 4, 2011 4:09 PM > To: RDA-L@LISTSERV.LAC-BAC.GC.CA > Subject: Re: [RDA-L] Browse and search BNB open data >
... > > Access points are treated rather strangely in RDA. The access point is > not itself an element, but is a construct made up of other elements, > which contains instructions about what and when to include various > elements in an access point. > > [Note: In this, RDA follows the FRBR model, which lacks elements for > access points. On the other hand, FRAD treats the access point as an > entity in its own right, separate from the person, family, corporate > body, work, expression, manifestation, or item that it represents. At > some point, RDA may decide to adopt this FRAD structure (assuming that > it survives the reconciliation of the FR models).] There are a few areas where the distinction between the access point as an "element" and as an "entity" can be confusing. The equivalent of the "undifferentiated name indicator" in FRAD is an attribute of the entity "controlled access point". In RDA 8.11, it's an attribute for a Person entity-- it's used when the core elements for a Person are not sufficient for differentiation. [I'm aware of the error in RDA that is being corrected-- the placement of this element in 8.11 suggests it applies also to corporate bodies and families when it does not]. However, in RDA 9.19.1.1, there is an instruction to use the undifferentiated name indicator when the "access point" cannot make use of any suitable addition to differentiate persons with the same name. Those instructions suggest there's a relationship between the core elements and the elements that go into forming an authorized access point. The relationship between the two processes (recording core elements and constructing access points) is not spelled out sufficiently to leave the impression that there really is not a conflict between the two instructions. There are some other areas where the connections between the elements and the access point suggest implications that are not readily apparent from the basic instructions. For example, when settling upon a "preferred name" or "preferred title", RDA consistently instructs to do so in light of their use as "the basis for the authorized access point" (example at RDA 9.2.2.1). That suggests that in environments that don't use authorized access points, decisions still need to be made that support the ongoing existence of authorized access points. In the RDA Element Set View (under the Tools tab in the RDA Toolkit), one FRAD entity is listed, and that is "Name". It has attributes such as "Date of usage" and "Scope of usage"-- attributes that don't really make sense applied to the Person entity. Rather, they belong to the Name entity (and in FRAD, the Name entity is also separate from the Person entity and the Access point entity-- there are relationships between these entities that are spelled out in FRAD). While the main text of RDA subsumes entities like "access point" and "name" into the instructions for the main entity, such as Person, there are points at which it seems that the FRAD approach might be useful. As an example, access points in FRAD have relationships to "Rules" and "Agencies", as well as a set of attributes such as "language" and "script". These additional bits of information would make sense clustered together as attributes and relationships around the respective entities. Thomas Brenndorfer Guelph Public Library
