New Concepts: Nomens and Appellations

Editor's Notes

• #3: Some time ago the RDA Steering Committee agreed that RDA would be based on current international cataloging models, and so the revised RDA, likely to become official in 2020, is based on the new IFLA Library Reference Model or LRM. The advent of LRM is the main reason for the major revamping and restructuring of RDA that has been going on over the last few years.
• #5: LRM is not a set of cataloging rules, it is a conceptual model of our bibliographic universe. It also emphasizes linked-data in a greater way than earlier models.
• #7: Nomen is a relatively new concept to most of us, developed in the IFLA Library Resource Model—or LRM—on which the revised RDA is based, but it is a concept that builds on earlier cataloging theory. What in LRM and the revised RDA exists as the entity nomen started out in FRBR as an attribute. The principal (and in some cases the only) attribute for each entity was some sort of label, variously called “title”, “identifier”, “name”, or “term.” These were conceived of as attributes, meaning they were recorded as an element of the description of the entity. When translated into RDA this was the one element that, generally speaking, was required (or core) for every entity (by the time RDA was developed “title of the expression” had disappeared as an attribute—interestingly, it will be reinstated in the 2020 RDA)
• #8: Functional Requirements for Authority Data introduced several new entities to the FRBR cluster of entities, including Name, Identifier, and Controlled access point. “Name” encompassed what had been referred to in FRBR as attributes called “name,” “title”, or “term.” This was a significant change: rather than being conceived of as elements or attributes of another entity, Name, Identifier, and Controlled access point were now conceived of as separate entities, with relationships to other entities. For instance, rather than having an attribute of “name” or “identifier”, a person entity had a relationship to an entity called name, or identifier.
• #9: In the FRAD model a bibliographic entity, such as a person, or a work, is known by a name and/or identifier; in turn, the name and/or identifier is the basis for a controlled access point, all three of which are separate entities. Diagram from FRAD page 4.
• #10: Since “Name” was an entity, it could be assigned attributes. These are (read slide)
• #11: … and a new relationship was introduced, “appellation.” So here we see that the relationship between one of the FRBR bibliographic entities and the new entity “name” is “has appellation”, so for example a person “has appellation” “William Shakespeare”, where the phrase “William Shakespeare” is conceived of as a separate entity from the person. Illustration from FRAD p. 7 (simpliified)
• #12: The concept of nomen was introduced with Functional Requirements for Subject Authority Records (2011). [SUMMARIZE the slide] Definition from p. 15.
• #13: The entity nomen was assigned a number of attributes. To pause on a few, “type of nomen” included “identifier” or “controlled name“ “scheme” was the rules from which the nomen was derived (e.g. LCSH, DDC) “representation of nomen” = things like “alphanumeric,” “sound”, etc. “form of nomen” = things like “full name,” “abbreviation” “audience” included things like “English-speaking users”, “children”
• #14: FRSAD continued the use of the appellation element. [SUMMARIZE slide] FRSAD figure 3.5, page 18.
• #15: So that’s where we were when LRM was being developed: three related but differing models FRBR, FRAD, and FRSAD. In FRBR the labels were attributes; in FRAD they had morphed into three entities, name, identifier, and controlled access point; and in FRSAD the three had merged into one entity, called nomen. The definition in LRM moves us away from the idea that the nomen is the character string itself, which is called in LRM the “nomen string.” Instead, nomen is defined as an association between the designation and the entity, which might sound as though LRM is saying that nomen is a relationship rather than an entity. We will see that RDA’s definition clarifies this and moves us away from the idea that nomen is a relationship. It is clearly defined as an entity, not a relationship. An instance of an entity can be associated with more than one nomen (e.g. a person might be known by more than one name), but a given nomen can only apply to one instance of an entity. “The identity of a nomen is determined by the combination of the [entity] it involves, the choice and order of the symbols used within its nomen string attribute, and the values of all the other attributes.” We will examine later what the other attributes are. The point of the cardinality rule is that once a nomen has been associated with an instance of an entity, for example, a particular person, that nomen cannot be associated with another instance of any other entity (again, don’t forget that the nomen is not the same thing as the nomen string). Note that identical nomen strings, strings of characters, can be associated with more than one instance of the nomen entity. For instance, the nomen string “John Henry Smith” might be associated with several instances of the nomen entity, all pointing to different persons with this name. Nomen strings can have more than one part and may be derived from existing nomens. For example, an authorized access point for a work is a nomen string. In our cataloging culture this nomen string is derived from an already-existing nomen string for the principal creator and an already-existing nomen string for the preferred title.
• #16: Here are some examples of nomen strings; note that some of them will be associated with nomens that refer to the same entity, for example the two nomen strings for the title of the work named here, or the three nomen strings for Conrad’s name. A title in Latin characters A title in Chinese characters A name in direct order A name in indirect order A name in Hebrew characters in direct order Two strings of digits representing time spans. A string of digits representing an ISBN These are all nomen strings.
• #17: These identical nomen strings might exist as elements in separate instances of the nomen entity. The instances would be distinguished from each other by the presence of other distinguishing characteristics, including relationships with different creators, different audience, different context of use, etc. However, note: Although an entity can be related to more than one nomen, as seen on the previous slide, an instance of nomen can only be related to one entity. For instance, the nomen containing the string “heart of darkness” shown in the first line can be related to the work by Joseph Conrad only. The same nomen cannot be reused and related to, for example, the opera by Tarik O’Regan, or the episode of The Vampire Diaries, or to the race horse. Reuse of nomens would be a possible model (and apparently was the model in FRSAD), but it is not the model followed by LRM and RDA. Summarize strings on the slide.
• #18: Summarize the slide. [Not to use during the presentation: “For information, the development of LRMoo (to integrate with the CIDOC CRM) is querying the concept of a nomen having parts. It's an esoteric argument, and for the meantime it is safe to assume that part nomens are ok.”—communication from Gordon Dunsire, May 9, 2019]
• #19: LRM assigns attributes to the entity nomen. As you may notice, these are very similar to the attributes of nomen in FRSAD. We will not linger here, but instead will look in more detail at how this translated into RDA.
• #20: From LRM fig. 5.4. p. 85, FRSAD fig. 3.5, p. 18. In the two models “res” and “thema” more or less mean any entity in the model. So these diagrams show the relationship between nomen and any other entity. Note the single and double arrows. In FRSAD an instance of an entity could be related to more than one instance of nomen, and vice versa, an instance of nomen could be related to more than one instance of an entity (thema). In the current model, LRM, upon which RDA is based, while an instance of any entity (res) can be related to more than one instance of nomen, an instance of nomen can only be related to one instance of an entity.
• #21: Before we continue, I will be showing examples in upcoming slides using “metadata description sets” rather than familiar MARC records. Because the concept of a metadata description set is new to most of us we need to take a brief detour and explain what they are and how they work. And in order to do that we need to begin with a (very) brief explanation of linked data. Summarize slide
• #23: So back to the revised RDA. In the revised RDA every element has a section called “element reference.” If you open it you will see the element’s domain and in some cases its range. READ the definitions of domain and range from the glossary. Here we have the element reference for the date of birth element. What the Element Reference is telling us is that the “date of birth” element can be used in a description of a person entity because that is its domain; and it must link a person to a timespan entity because that is its range. Timespan will be discussed in one of the upcoming webinars. Here is an example of an RDF triple telling us something about the person Terry Pratchett.
• #27: You can see this is a series of RDF triples An instance of the Person entity is being described. This person has a preferred name: Helene Stöcker This person has a date of birth: 1869. This person has a date of death: 1943 This person has a language (the language she created works in): German This person has two fields of activity: Reproductive rights, and Peace. NOTE: any of the elements in RDA can be recorded more than once if appropriate. And so forth. The combination of all of these RDF triples describes the person.
• #28: Note that this metadata description set does not contain all possible elements that might have been used to describe this person, and this example should not be taken as advice as to which elements to include or the maximum number of elements to include. Any of the elements labeled as within the domain “person” can be included in a metadata description set for a person. For example, the element “authorized access point for person” could have been included in this metadata description set.
• #29: Final part of the RDA definition: RDA entity = any entity defined in RDA. The current definition (as of July 2019) in the beta Toolkit is “A designation that refers to an RDA entity. A designation includes a name, title, access point, identifier, and subject classification codes and headings.” In August 2019 the definition will be revised to exclude “nomen”—that is, a nomen cannot refer to itself, a nomen doesn’t itself have a nomen, unlike all the other RDA entities.
• #30: From Nomens and appellations, under Guidance tab in RDA. As in LRM, RDA requires at least one instance of nomen per instance of entity; instances of entities can be associated with multiple instances of nomen.
• #32: There is currently no RDA vocabulary encoding scheme for category of nomen, but RDA permits structured descriptions using another vocabulary encoding scheme if one exists. As far as I know none currently exists, but this element can be recorded as an unstructured description. The terms on this slide are possible examples of the types of concepts that might be recorded for “category of nomen”. Common name and Browse name from Gordon Dunsire “Deeper Dive into Nomens” 28 January 2019
• #34: LRM definition: Information as to the context(s) in which a nomen is used by the agent who is referred to through it. There is currently no vocabulary encoding scheme for context of use, but it can be recorded as an unstructured description.
• #37: Joseph Conrad, in direct order, in Hebrew script. This is all quite new so in best practice, intended audience to indicate language groups may be better recorded as "language of nomen" or "script of nomen“ [Gordon Dunsire comment, 6 May 2019]. On the other hand, we’re familiar with the concept that certain nomens have an intended audience of children. It could probably be said, for instance, that all the terms found in the LC Children’s Subject Headings list, which are nomen strings that could be used in descriptions of nomens, have an intended audience of children.
• #38: LRM: The language in which the nomen is attested
• #39: Joseph Conrad, in direct order, in Hebrew script. Preferred title of War and peace, in Latin script. Note the language of nomen element is still Russian. Preferred title of War and peace, in Cyrillic script
• #40: Summarize slide. This is a data provenance element.
• #41: Joseph Conrad, in direct order, in Hebrew script.
• #42: Summarize slide. Agent includes collective agent, corporate body, family, person. Like scheme of nomen, the “assigned by agent” element is a data provenance element. It explains something about where the data come from.
• #43: Diagram showing relationships Agent includes collective agent, corporate body, family, person
• #44: Variant for Joseph Conrad added by Princeton University Library. Jacqueline Kennedy Onassis changed her name in 1968 when she married Aristotle Onassis. A metadata description set (if any) for the related timespan would have this element: has scheme of nomen EDTF
• #46: This is the broadest appellation relationship.
• #47: Poster image from https://www.1stdibs.com/furniture/wall-decorations/posters/wizard-oz-film-poster/id-f_1220960/ In our current MARC context many of these appellation elements—that is, the authorized and variant access point elements—would be recorded in access point fields and that would be it. In other words, we (currently) just record the nomen string and that’s that. In a fully developed RDA system, this nomen string would be a link to a nomen metadata element set, where the attributes of the individual nomens would be recorded. The “preferred title” and “variant title” appellation elements are not currently formally recorded in a MARC field of their own. In my opinion it would be a good idea to open up this possibility by adding some new fields.
• #48: Summarize the slide The preferred title in RDA does not have the same form as the “title” portion of the authorized access point because in Program for Cooperative Cataloging practice the preferred title has been manipulated by removing the article to create the authorized access point. So the nomen for the preferred title can’t be said to be “part of” the nomen for the authorized access point. The title portion of the authorized access point was derived from the preferred title, however, so perhaps an “is derivation of” relationship exists. This slide also illustrates the “is part of” relationship from the nomen for the numeral in the timespan. For this illustration “1939” was declared the authorized access point for the timespan because it is following the rules of EDTF, PCC’s preferred scheme for recording timespan. Note: “has category of work” has been left as a descriptive element in the work metadata description set, but it could also be modeled as a cluster of related nomens.
• #49: Poster image from https://www.1stdibs.com/furniture/wall-decorations/posters/wizard-oz-film-poster/id-f_1220960/ As with the example of the work Wizard of Oz, so to with an example of a person. In our current MARC context many of these appellation elements—that is, the authorized and variant access point elements—would be recorded in access point fields and that would be it. In other words, we (currently) just record the nomen string and that’s that. In a fully developed RDA system, this nomen string would be a link to a nomen metadata element set, where the attributes of the individual nomens would be recorded. The “preferred name” and “variant name” appellation elements are not currently formally recorded in a MARC field of their own. Again, in my opinion it would be a good idea to open up this possibility by adding some new fields.
• #50: Note the nomen for the preferred name has a relationship link to a timespan entity for date of usage. Judy Garland adopted her stage name in 1935 when she was signed by MGM. The corresponding nomen for the timespan is not illustrated due to lack of space. Note also: the authorized access point is derived from the preferred name; the variant access point is derived from the variant name.
• #51: Over the years of development of the FRBR model it became more and more evident that labels (names, titles, terms, etc.) could not be modeled simply as attributes of entities, because those labels had many attributes themselves. It isn’t possible to assign an attribute to an attribute, but it is possible to assign attributes to entities. If we do record attributes of nomens—something we don’t do now—we will be able to do quite wonderful things with our database. We could, for example, allow an agency to prefer to display names and titles in Cyrillic, or Chinese, or Hebrew script—this could be done for the database as a whole (e.g. for a library that caters to Hebrew speakers), or the database could allow individual users to make choices about how the data are displayed. This isn’t possible in the current MARC environment because we don’t label access points as “Cyrillic” or “Chinese” or “Hebrew.” Specialized researchers could isolate nomens by particular attributes, such as stage names, or dates of usage, or context (find nomens that have been used for fantasy fiction writing)
• #53: Note in Μάγος του Οζ (Motion picture : 1939) the first part is Greek script but the rest isn’t. Related development in INTERMARC: http://library.ifla.org/2204/
• #54: 008/32 = undifferentiated personal name Full MARC implementation would be somewhat more complicated, but probably doable and might be worth thinking about.
• #55: I will be glad to answer questions to the extent I’m able, but remember this is almost as new to me as it is to you. But I’d also be glad of anyone wants to comment on the ideas we’ve discussed today. Thanks.