bf:authorizedAccessPoint in Works

kiegel commented 9 years ago

There are two problems with the current use of bf:authorizedAccessPoint in Works.

First, the values given to authorizedAccessPoint in bf:Work are sometimes wrong from a cataloging point of view: for example, using the first 7XX field in combination with 245 when a work is entered under title. As an illustration, bf:authorizedAccessPoint "Crawford, D. H. Beowulf" should be bf:authorizedAccessPoint "Beowulf. English (Crawford)"

We suggest the following algorithm for assigning values to this property in converted MARC records to get results that are more compatible with cataloging rules:

When field 130 is present in the MARC record, use it (all subfields present). When a field 100/110/111 is present, use the 1XX field together with field 240 subfields a, n, p, k, f, g. If no 240 is present, in its place use 245 subfields a, n, p, k, f, g. When no 1XX field is present, use field 245 subfields a, n, p.

Second, the definition of authorizedAccessPoint does not match its use in bf:Work in converted MARC records. That is, “authorized” in the property name and “controlled” in the definition imply the application of cataloging rules, but this is not the case. authorizedAccessPoint is assigned values derived algorithmically and they are not necessarily based on cataloging rules or necessarily unique. We think it better to have two parallel properties that differentiate whether a string is created using cataloging rules or not. For example,

bf:resourceEntry “String form of a resource label intended to help identify it, such as a title or a name plus title.” bf:authorizedAccessPoint “Controlled string form of a resource label intended to help uniquely identify it, such as a unique title or a unique name plus title.”

authorizedAccessPoint will be useful when we do native RDA cataloging and map it to BIBFRAME. In that case, the name of a work is specifically constructed according to rules and is authorized. resourceEntry would be used when that is not the case, such as machine conversion.

kiegel commented 9 years ago

Non-roman script fields should not appear in an authorized access point.

<http://example.org/99131426860001452> a bf:Text,
        bf:Work ;
    bf:authorizedAccessPoint "Inō, Kanori, 1867-1925 Inō Kanori no Taiwan tōsa nikki.伊能嘉矩の臺湾踏柤日記",

(OCLC # 793950140)

kiegel commented 9 years ago

Another place that Work authorizedAccessPoints are generated are from linking entries.

For example:

<http://example.org/99161784508601452work17> a bf:Work ;
    bf:authorizedAccessPoint "Yu, Yingshi. Di 1 ban Guilin Shi : Guangxi shi fan da xue chu ban she, 2004- Works. Selections. 2004. Yu Yingshi wen ji.",
        "余英时. 第1版 桂林市 : 广西师范大学出版社, 2004- Works. Selections. 2004. 余英时文集."@zh .

The AAP contains extraneous information, such as edition statement ($b) and publication statement ($c). In general, the rules for generating AAPs here should be the same as above.

(OCLC # 891156210)

ntra00 / marc2bibframe

bf:authorizedAccessPoint in Works #151