New Concepts: Nomens and Appellations Transcript (March 2020)

1. REALTIME FILE
AMERICAN LIBRARY ASSOCIATION
NEW CONCEPTS: NOMENS AND APPELLAITONS
MARCH 4, 2020
CART CAPTIONING PROVIDED BY:
ALTERNATIVE COMMUNICATION SERVICES, LLC
www.captionfamily.com
* * * * *
Communication Access Realtime Translation (CART) is provided in order to
facilitate communication accessibility. CART captioning and this realtime file
may not be a totally verbatim record of the proceedings.
* * * *
>> DAN: This is Dan Freeman. This is an audio check. We will be doing a couple
more sound checks before we begin. We would like to encourage you to use the chat
space to introduce yourselves. Thanks, Brad and the group at Oregon state for
introducing yourselves. Anything you want to share about what brought you here and
what you hope to get out of today's event. Again, we will be starting in five minutes.
We will do one more audio check before we begin. Thanks.
>> DAN: Hi, this is Dan Freeman from ALA Publishing eLearning Solutions. The
final audio check. We will start in a little less than two minutes. So please stand by.
Thanks.
>> DAN: Hi, everybody. Welcome. This is Dan Freeman from ALA Publishing
eLearning Solutions. Glad to have you here with us today. Part two of the RDA New
Concepts: Nomens and Appellations with Robert Maxwell. I know everyone is eager to
get to the content.
I will take a quick run through the technical information to help things run a bit more
smoothly today. The chat space on the lower right-hand side of the screen. We would
like to encourage you to use the chat space to say hello and introduce yourself or your
group and share anything you would like to share. Also your place to ask questions. If
you need help, the host is webinar support.
Private chat her if you have an issue with audio or anything else. We will do Q&A
with Bob at the end of today's session. You don't need to wait until the designated Q&A
period to put your questions into the chat space. When you have questions, just ask
them, mark them down and we will make a note of them and relay them to Bob during
the Q&A period.
Please note, we are probably going to have over 100 people today so we will do our
best to get to every question, but we may not get to answer every single one of your
questions.

2. If you are having problems with the audio, most are probably listening to the audio
stream. Resolving that is easy. Go to communicate at the top of the screen, and then
select audio -- communicate and then select audio connection. That will bring up the
option that lets you disconnect and reconnect or call in. If you hear an echo, you have
probably gotten two broadcasts running simultaneously. So you can just close one, that
should resolve the issue right away. If it is cutting in and out, disconnect and reconnect
it.
We are recording today's event. If you are looking for a copy of the slides, we will
send that after we conclude today. We also encourage you to check out the ALA store
for additional eLearning university. We are delighted to have Robert Maxwell back
today. He has been involved in RDA basically since its inception. He is a wonderful
person to have presenting today.
So with that, I will turn things over to Bob and we will get started. Bob, glad to have
you here today. Just going to get your audio going. One second. Can we get Bob
unmuted? Hi, Bob, are you there?
>> ROBERT: Yes, thank you, Dan.
>> DAN: All right.
>> ROBERT: And welcome to all of you. I'm so glad you are all here.
I need to mention at the beginning that this is -- this series is a repeat from last July
and so if you attended last July, this will be a repeat and review.
I would also like to note that what I'm about to present will probably seem very, very
abstract. I gave a sort of a run-through yesterday at my institution and I'm afraid some
people's eyes glazed over and I'm trying to make sure that doesn't happen to any of you
today.
But this particular concept is pretty abstract. It might be the most abstract consent in
the new RDA. But it is pretty fundamental, so the model and it is important for us to try
to understand. And so let's go and see what happens.
So as a review. Let's talk for a moment about where the new RDA is coming from.
Some time ago the RDA steering committee agreed that RDA would be based on
current international standard cataloging models. The revised RDA which will welcome
official at the end of this year is based on the new IFLA library reference model or LRM
which is the new model on which cataloging is to be based.
The advent of LRM is the main reason for the major revamping and restructuring of
RDA going on over the last few years. And the reason why we are giving the seminar
today.
So LRM is a consolidation of these three documents. Functional Requirements for
Bibliographic Records from 1997. Functional Requirements for Authority Data from
2009 and Functional Requirements or Subject Authority Data which was in 2019.
These three were a set that were intended to build on each other but they found out that
authors were different of each one and they wound up taking slightly different
approaches or in some cases not so slightly different approaches to the data model.
And so one of the intents of LRM was to reconcile these three documents.
So like the three documents, LRM is a conceptual model of the bibliographic
universe. It is not a set of cataloging rules, it is a model. Based on entity relationship
and model which was developed a generation ago for databases. Emphasizes linked
data in a greater way than other models did. So LRM includes a new entity called

3. nomen. But it really isn't new when you fink about it. Back in FRBR, the first of the
three documents, FRBR had attributes which are really labels for entities. And so work,
title of the work. Expression had title of the expression and manifestation.
So the titles and then identifier for the item and then names of persons and corporate
bodies were attributes and then there were terms for concepts, and these were all what
I would just call labels for the entities.
>> DAN: Bob, this is Dan. People wondering if you could speak up a little bit or
move the microphone closer to your face.
>> ROBERT: It is about as close as it can get. I will try to speak up but maybe the
volume could go up a little, too.
>> DAN: Anyone having audio issues, crank your volume up a little bit. Sorry, Bob,
go ahead.
>> ROBERT: Thank you. Just to reiterate the labels were conceived of as attributes
which means they were recorded as an element of the description of the entity. When
translating to RDA this was the one element that generally speaking was required or
core for every editing except that by the time RDA was developed title of the expression
had disappeared as an attribute. Interestingly, it will be reinstated in the new RDA, the
data version.
The next document introduced several new entities into the FRBR cluster of entities
including name, identifying and controlled access points.
Name encompassed what it had been referred to in FRBR as the attribute name, title
or term. This was a significant change in the fact I remember when reading it I was
having double with getting my mind around the idea. Rather than being conceived of as
an element or attribute of an entity, name, identifier and controlled access points were
now conceived of as separate entities in themselves with relationships to other entities.
For instance, rather than attribute of name, a person entity had a relationship to an
entity called name or identifier. So in FRAD this concept is developing into being an
entity all by itself and not an attribute. Here is what it looks like in the diagramming of
FRAD.
So we have a bibliographic entity such as a person or a work. And it is known by a
name or identifier. It is in turn the name or identifier is the basis for a controlled access
point. And all three of these are conceived of as separate entities in FRADs. Because
they were separate entities FRAD could assign them attributes and these are type of
name, name string, scope of usage, data usage, language of name, script of name, and
transliteration scheme of the name. All of these could be included in the description of
the name to tell various aspects of what the name is all about.
And FRAD introduced a new relationship which it called appellation. Here we see
the diagram in FRAD about the relationship between one of the FRBR bibliographic
entities and the new entity name. So the big dotted line box on the top surrounds all of
the entities which means they can all have this relationship with name and the
relationship is has appellation. So a person may have an appellation of names. For
example Williams shack peer where the phrase William Shakespeare is conceived of as
a separate entity from the person report relationship of the person.
So -- or the relationship. So in FRSAD, the concept of nomen and the name nomen
was introduced. The definition was a sign or sequence of signs that a thema was
known by. A thema is another new concept that FRSAD introduced. Its definition was

4. an entity used a is a subject of a work, which means essentially any of the FRBR
entities. So thema was a term that encompassed all of the entities. And nomen was
related to theme la. And it was a superclass encompassing the three FRAD entity.
Name, identifier and access part. Nomen as in FRAD was a separate entity, not an
attribute. And so it in itself could have attributes and these are the attributes in FRSAD
or nomen. And to pause on a couple of these. Type of nomen include whether it was
an identifier for a controlled name.
Scheme the rules from which the nomen was derived. LCSH or DDC.
Representation of the nomen. Alpha numeric or sound. Form of nomen. The full name
or abbreviation. Things like that. And audience included things like English speakers,
children. So all of these things could be used to describe a nomen.
Which, again, is a sequence of signs that a thema, that is a FRBR entity is known by.
So FRSAD continued using the same relationship appellations. Theme ma can have
an appellation of a nomen and a nomen can be the appellation of a thema.
So now we are to LRM. We had three related but differing approaches, FRBR,
FRAD and FRSAD. In FRBR the labels were attributes. In FRAD they morphed into
three entities. Name, identifier and controlled access point and in FRSAD into one
entity called nomen. The definition in LRM moves away from the idea that the nomen is
the character string itself. In LRM called the nomen stream and that is an element of
the nomen entity in LRM. Instead, nomen is defined as an association between the
designation and the entity and that may make it sound as if LRM is saying it as
relationship rather than an entity but we will see that RDA's definition clarifies this and
moves away from the idea that nomen is a relationship. It is clearly defined as an entity,
not a relationship. An instance can be associated with more than one nomen. A person
might be known by more than one name but in the LRM model a given nomen can
apply to only one intense 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 of the attributes. We will examine later what
the other attributes are. The point of this rule which is called the cardinality rule, only
one nomen with a given entity, instance of an entity or sorry the other way, a nomen can
only apply to one particular instance of an entity. The point of this 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. Once again, don't forget that the nomen entity is not the same thing as the
nomen string which is an attribute or element within the nomen entity.
So identical nomen strings which are strings of characters can be associated with
more than one instance of the nomen entity. We will see this in a few slides with some
examples. Don't worry if this isn't making too much sense yet but I hope it will in the
end. The nomen string John Henry Smith might be associated with several instances of
the nomen entity and all point to different persons with this name.
Another point in LRM is that nomen strings can have more than one part and may be
deceived 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 principle creator and already existing nomen string for the
preferred title.

5. This is the point that LRM makes that the nomen string with be composed from other
nomens. So here are some examples of nomen strings. So Noel that some will be
associated with nomens that refer to the same entity. For example, two strings for the
title of the work. You "Heart of Darkness" and then the nomen string in Chinese
characters which may refer to the expression of "Heart of Darknes." We have three
different nomen strings that refer to the author, Joseph Conrad that could be used to
refer to the author. Conrad comma Joseph is another spring of Latin characters. And
then we have a Hebrew string of characters which is a nomen string.
And that could also refer to the same author. And then we have a couple of date --
well, we know they are dates, but they are strings of numbers. The first one is a string
of digits that could refer to Conrad's birth date which is a time span. That is another
new entity that we are not going to talk about this week. In a couple of weeks we will
talk about the time span.
The next one is the string of digits that may refer to Conrad's lifetime, life span.
Another time span that is also a nomen string. And then we have a nomen string which
you will recognize as an ISBN but it is a string of digits that may refer to the 2019
manifestation of "Heart of Darkness." These are all nomen strings.
And they -- and a nomen string, again.
To remind you is one of the elements of the nomen entity. This slide points out that
identical nomen strings can exist in separate instances of the nomen entity. But I just
want to reiterate in the LRM model each instance of a nomen can refer to only one
entity.
So, potentially we have eight different nomen strings that all seem to be pretty much
identical here. They could be elements or attributes of a different nomen entity. Nomen
-- instances of the nomen entity.
Now, the instances of the nomen entity would be distinguished from each other since
the string is identical in each one they would be distinguished by the presence of other
distinguishing characteristics. Relationships to different creators, a different audience.
Different context of use and so forth. But note although an entity can be related to more
than one nomen, as seen in the previous slide, I'm reiterating again, the instance of the
nomen itself can only be related to one entity.
So an entity can be related to more than one nomen but a nomen can only be
related to one instance of an entity. For example the string containing "heart of
darkness" in the first line can be related to the work of by Joseph Conrad only. The
same nomen cannot be reused and related for example to the opera by Tarik O’Regan
or the episode of "The Vampire Diaries" or to the race horse. We could have a nomen
and have a linked to all of the entities that use that string. And in fact, that appears to
have been the model in FRSAD, but it is not the model followed by LRM and RDA.
So to go on to the point about the parts. Nomen strings I mentioned already, and
this is examples can be composed of parts derived from other nomens. So we have
Conrad, Joseph. Another nomen string, 1857-1924 which might refer to the Conrad
lifespan and they can be combined to create a nomen string to execute the authorized
access point for Conrad which is derived from the two different nomen strings.
And then if you add in the other nomen string "Heart of Darkness," you wind up with
the authorized access point for the work which is derived from two or maybe three
nomens.

6. So in LRM as in the previous couple of iterations of FRBR, nomen is an entity on its
own and has attributes and these are the attributes of the entity nomen. As you may.
notice, they are very similar to the attributes of nomen in FRSAD. So we are not going
to linger here. We will look more in detail when we see how this got translated into
RDA. The relationships in LRM are similar but not quite the same as FRSAD. So in
LRM, LRM has an entity called RES which is as far as I can tell more or less the same
as the thema of FRSAD. RES means all of the LRM entities or actually any entities.
In the two models, RES and thema, the diagrams show the relationship between
nomen and any other entity.
Now do note, though, the single and double arrows. In FRSAD on the bottom, an
instance of an entity could be related to more than one instance of a nomen. And vice
versa. And the instance of nomen could be related to more than one instance of an
entity, that is a thema. In the current model LRM upon which RDA is based an instance
of any entity which is a RES can be related to more than one instance of nomen. That
is what the two double arrow means.
An instance of nomen back the other way can be related to only one instance of an
entity. That is why I have been emphasizing the last two slides about the nomen related
to only one instance of an entity.
Before we continue, I will be showing examples using metadata sets rather than
familiar mark. Because it is new to most of us, we need to take a brief detour and
explain what they are and how they work. I talked about this a couple of weeks ago. I
think it is a good review for us as many of us this is not really on our -- it is on our
horizon but not within our mental view of how things work yet. We will be talking about
linked data for a few slides here.
Linked data is used to describe a framework that links data from different data
sources on the web. And this framework is called the Resource Description Framework
or people call it RDF. This is usually written in a computer language called XML
designed to be understood by computers. It isn't designed to be displayed to people but
there is a concept called RDF triples which are a translation of the XML that is
comprehensible to humans. Linked data consists of a series of triples, many of which
may be needed to describe a particular entity.
An RDF trip St. Louis a statement about a particular element in the description of an
entity and follows a quasi-English language syntax. The basic triple, subject, predicate,
object. A person has a name. Predicate and the object is John. That tells us
something about that person.
Back to the revised RDA. This is what one of the elements in the revised RDA looks
like. In the revised RDA every element has a section called element reference. Begins
with the name of the element and then always the element reference. The blue box
with an I and if you click on it you will get the display I'm showing on the screen here.
This shows you the elements domain and tells about the range. Let's read the
definitions of domain and range. Because people for years were talking about domain
and range and they didn't know ha they were talking about. Domain, this comes out of
the RDA glossary from the new RDA. The RDA entity that is described by an element,
is domain. So that means that the element is data of birth on the example. And so the
RDA entity that is described by the date of birth is a person. You can see the domain

7. word. It tells us that the entity person can be used or date of birth can be used to
describe a person.
The range is the RDA entity that is the value of the relationship element. And if there
is a range, not all of the RDA elements have a range, but if there is a range it tells what
entity the range can be. This is telling us that the date of birth element can be used to
describe a person and it must -- its value must be a time span which is a separate
element -- entity, separate entity in RDA.
So we will discuss time span in the seminar, webinar two, two weeks from now. So
we will not really linger on it now. Here is an example of an RDF triple. The triple can
be this element reference in the RDA can be used to turn the elements into triples. So
domain, the subject. Predicate is the name of the element. And object is the range.
And so person is the element here. Has date of birth is the predicate. And timespan
is going to be the range so to put it into a specific example, Terry Pratchett has a date of
birth of April 28, 1948. It has one element of the person. So that is an RDF triple.
RDA introduced a concept called metadata description sets. And I want you not to
get worried about it because it is pretty much a record which we in the past called
authority records for persons.
>> , it also brings out the linked data aspect. The RDA glossary definition is one or
more metadata statements that describes an individual instance of an RDA entity. A
metadata designs a value to an RDA element that describes an individual instance of an
RDA entity. So that RDF triple was an example of a metadata statement.
So if we have a set of those estimates because the -- the data -- the birth of Terry
Pratchett is not enough. When we combine the triples, that is a metadata description
set.
Now the toolkit has examples. Some of the elements have at the bottom of the
element a label that says view in context example. And if you click on it, what you get is
a metadata description set. There is an example in the new RDA under the
biographical information element.
So let's have a look at it. Here we are looking at the biographical information
element of the new RDA. If you scroll to the bottom and click on the view in context
example, you will see a metadata description set. It is a set of triples. The first part is
person in all of instances. And then the predicate is whatever the Italicize the word ofs
are and then the object or the range, the value is the part to the right of the italicize the
portion. A person has a preferred name of person, Helene stocker. A date of birth of
1869 and date of birth of 1943. The person has a language which is German. This
person has two fields of activity, reproductive rights and peace. So note here that any
of the elements can be recorded more than once from RDA if appropriate. And so on.
So all of these put together are a metadata description set which more or less fully
describes this person at least to the point we want to describe the person in our
bibliographic data.
So the combination again of all of the RDF triples shown right here are a metadata
description set. This slide I just want to point out that the entity and description sets in
the examples in RDA are not prescriptive and do not say this is all you can put in it. For
example the metadata for in person in RDA does not include the element who
authorized access point, but it could. So the point of this slide is you are not limited by

8. what you see in the examples in RDA. You can have more or less in your piece of
metadata description sets.
Now after all that we are back to nomen. The first part of the RDA definition -- sorry.
Refers to an RDA entity. An RDA entity actually an entity in RDA and means any entity
defined in RDA.
Just for you information if you look in the data I did not include the full definition here
because it may just add confusion. It mentions full current definition in the data
mentions that it is a -- the nomen is a designation that refers to any RDA entity except
nomen itself. No men itself, that entity doesn't have any nomen referring to itself. I
would not worry about that at this point.
The definition in LRM was an association between an entity and a designation that
refers to it. So notice that I -- the change when the definition came into RDA de-
emphasizes the word association and, in my opinion, emphasizes that nomen is an
entity. It has relationship with all of the other RDA entities.
This is a review of LRM itself. Any entity referred to in an RDA context is named
through at least one nomen which tells us there can be more than one nomen but there
must be at least one. This is one of the -- the concept, of course, does not come up in
the new RDA that this is one of the few pieces that really are required. Any RDA entity
must be related to at least one nomen and be named through at least one nomen.
Okay. Description of the nomen, imagine this is as if you want you can pretend there
is an authority record for a nomen. So the description would contain as an element a
nomen string which is the combination of signs or symbols in a particular order. We
have seen lots of examples of nomen strings today already. In RDA, variations of the
symbols that are used or variations in their order results in a new nomen string. And
this almost always results in a new instance of nomen as an entity. RDA does say,
though, that variations in the visual representation of the string, for example, different
fonts or sizes does not result in a different nomen.
So these are the descriptive elements of nomen. Category of nomen. Context of
use, intended audience of nomen, language of nomen, foe men string, a note on the
nomen, reference source, scheme of nomen, script of nomen, status of identification
and undifferentiated name indicator. We will look in detail at several of these in the next
couple of slides. Let's talk about category of nomen.
It is defined as the type to which the nomen belongs. There is currently no RDA
vocabulary encoding scheme for this element category of nomen, but RDA permits
structured descriptions which would be using terms from the vocabulary encoding
scheme using another coding scheme if one exists. In case you are not familiar with
vocabulary encoding scheme, it is a list of words that are sort of the authorized words
for example the content type words that we can use. There isn't one at the moment for
category of nomen. And as far as I know there isn't any vocabulary encoding scheme
from any other vocabulary besides RDA. But it can also be recorded a is an
unstructured description. The terms are examples most of which I made up as types of
context that might be recorded for category of nomen.
Personal name might be an example of a category of a nomen. Common name
versus browse name. The name that is common to be used for Joseph Conrad and this
name we used for form in our catalogs, Conrad, Joseph. A spine title. Identifier.
Controlled access point. A pseudonym might be a category of nomen. A married

9. name, preferred name, variant name, nickname, Stage name. All sorts of things that we
could use to say what is the type that this nomen is. To which it belongs. Here are
some metadata description sets that might include the element category of nomen.
The spring, Lewis Carroll and I thought of three categories. This nomen string might
fall into. It is a common name because it is the normal form that we would find it. Not
any kind of manipulation like in version or anything. It as pseudonym. It is a preferred
name in the context of our authority file.
So those are all possible categories of nomen for this instance of a nomen.
There is another instance of a nomen. So we have a second the metadata
description set on the slide. It has the nomen string Dodgson, Charles Lutwidge. The
would be the browse name which is the format we use for indexing. These are two
separate nomens in the RDA context.
Another element is context of use. Defined as the Kirks in which an appellation is to
be used. For example, literary works. Mathematical works. Detective novels. Critical
work. That sort of things. The context of a use of a particular nomen perhaps. So here
we have this nomen string Lewis Carroll and I added a new element. Context of use.
And the context of use of this nomen string Lewis Carroll, the context of use of the
nomen, I should say, is literary works. It has another context. Works for children and
humorous works. Three different contexts.
The other nomen, Charles Lutwidge Dodgson is the prefer 9 name and has a context
of use. This nomen has been used for mathematical works by the person to which the
nomen is related.
You are looking at two separate instances of nomen here. And okay. Let's move on.
Descriptive elements. Another is the intended audience of the nomen.
So it is defined as a class of users to which a nomen -- for which a nomen is
intended. Some examples might be Chinese speakers or Hebrew speakers or
something like that, or children or adults. Those are examples of intended audience for
a particular nomen.
Here we have that Hebrew nomen string we saw earlier for Joseph Conrad. To the
nomen which contains that nomen string has an intended audience and the intended
audience is someone who can read it and speaks and reads Hebrew.
Second nomen shown on the screen, Mister Rogers. We could categorize as a
common name and it does have an intended audience, children. The third nomen string
here is war and peace. Its category of nomen is a preferred Title and that is in the
context of the LC children's subject heading list. And so its intended audience is
children. If you remember or you probably know the preferred title of "War and Peace"
is the Russian title. This string which is contained in this nomen we are look at in the
bottom of the slide, has an intended audience of children. So you see how as we build
up the metadata description set for a nomen we are able to distinguish one in another
even though they may have identical nomen strings.
Here are a couple of more descriptive elements that can be used to descibe a
nomen. We have the language -- describe a nomen. The language of appellation and
script of the nomen. We might record as the word Hindi which is the natural language.
Record it as an URI which points to that. Or use the MARC code for Hindi. And this
depends on the application profile which is another word we are hearing a lot about.

10. A set of rules about how we apply RDA in a given context. For instance, our own
library may have an application profile that tells us to use the natural language when
recording of the nomen Hindi or point to the loc.gov. Descriptive nomen is not the same
asking language of the nomen. It is the characters in which the appellation is formed.
So Tibetan and Cyrillic and Latin might be examples. Here is the three nomens.
The first one the same that we saw about Joseph Conrad. The language of the nomen
is Hebrew and the script of the nomen is also Hebrew script. If it got transliterated into
Roman we would have a separate string with the Roman characters and probably say
that the category of the language was still the same but the script of the nomen was
different. It would be Latin in that case.
Here the second one. The nomen string. A preferred title in the concept of the
authority file. The preferred title. A language of Roman which is Russian. And Voina I
mir means war and peace in Russian. That particular nomen has the nomen string. It
is in Latin script. So that is the one that makes it different from one of the things that
makes it different from the nomen at the bottom of the screen.
The know man string at the bottom is pronounced exactly the same as the one in the
middle, Voina i mir. I'm assuming that is close to how it is said. It is in the context of the
variant title but it might be a referred title.
preferred title. The language is Russian but the script is different in Cyrillic script.
That differentiates the two nomens. We might say in our minds they are the same thing
but they are differentiated because they have different script.
Another element is the scheme of the nomen. A scheme in which an appellation is
established. AACR2. Or RDA or LCMPT which is the LC performance terms category.
Maybe we established using ISO 8601. Maybe we are using the extended date and
time format to figure out how to do the nomen string in this particular nomen. That is
the scheme in which we are -- we have established our nomen string mainly I think it
what it is mainly talking about.
Here we have examples. These are all abbreviated metadata description sets. The
nomen at the top ha is a nomen string the word flute and has a category of nomen.
Medium of performance name. And it has a scheme. It was constructed according to
the rules of lcmpt the library of Congress medium of performance thesaurus. The
second one Mister Rogers. I decided that its scheme in the context is RDA. The
nomen string war and peace has the category of nomen preferred title. Which is again
in the context we can add all of this into a much longer metadata set. It would be lcmpt
childrens subject heading list and according to the rules of the Library of Congress
children's subject heading. That is another element we could include in the nomen
descriptions.
Okay. So I have one talking about the descriptive elements. RDA does not --
descriptive elements. RDA does not provide the elements but do I in my mind because
the descriptive elements are pretty much elements that we think of as we would use to
include in a record or metadata description set describing an entity.
Relationship elements which really aren't distinguished at the moment from what I'm
calling descriptive elements in RDA are elements that show relationship to another
entity. There are quite a lot that link to nomen. Because a nomen is related to any of
the RDA entities. If you go through the beta RDA you will see appellation of RDA entity
of something. Any of those are relationship elements.

11. There is an element called assigned by agent which would link a nomen to a
description of an agent, probably a corporate body, possibly a person.
Data of usage is a relationship element which would link a nomen to a time span
entity.
Derivation of would link a nomen to another nomen. Part of nomen would also be a
relationship to another nomen.
And we can see these in this slide now. The nomen in the middle. All of those in the
words on the previous slide are now sort of in the diagram. We can see this nomen is
assigned by an agent.
(Break in audio). It can be derived in another nomen. The relationship to the nomen
on the right-hand side. It can be a part of the nomen on the left-hand side or below on
the right. The one we were just looking at. Agent, I just want to note in RDA includes
the entity's collective agent. Agent and collective agents are new entities in RDA but
also include the familiar entities, corporate body, family and person. So here are
examples of metadata description sets that have relationship elements in them.
The first nomen, the string Konrant, Tzozeph. This is a nomen to agent relationship.
I found this in the current file and I was able to figure out by going backwards through
the history of the record which library added this particular variant to the authority
record. And I discovered that Princeton university library was the agent that assigned
this particular nomen string to that record there.
If the nomen were its own separate entity it would be easier to identify because it
would be identified there in the record for the nomen itself.
The next one shows the time pan relationship. The nomen -- time span. Jacqueline
Kennedy Onassis. It has a date of usage 1968 on. It is hard to identify this in the
current authority record for Mrs. Onassis but if we had a nomen as an entity and this
were an instance of that entity it would be very easy to know that this particular name
was used beginning in 1968.
Now we turn to the concept in RDA called appellations. Any relationship element -- I
talked about what I'm deciding between the descriptive elements and relationship
elements and there is a subcategory of relationship elements called appellation
elements and these are elements that link a nomen to an entity identified by its nomen
string.
The broadest of the elements are appellation of something or other. If you look lieu
the RDA list of elements you will see appellation of and then the entities, work,
expression. Corporate body. All those things. There are narrower elements which you
will find in RDA. Access point for any of the entities. Authorized access point for
something. Identifier for. Name of. Preferred name of. Preferred title of. Title of.
Variant access point for whatever the entity is. Variant name of. And variant title of. I'm
showing this slide to make some sense when you look in the new RDA toolkit which I
hope you will all do pretty soon after looking at this. Because it will make more sense if
you are realizing what all this area of huge multiplicity. These are all appellation
elements. They are relationship elements that link a nomen to the entity that is
identified by the nomen string. Those are appellation elements.
And this is the relationship between them and an entity. You see an RDA entity
which can be any of the entities, either has an appellation and that is the nomen or vice
versa. We can say the nomen is an appellation of the RDA entity.

12. Now we will look at a real example. For a work. This is edited description set for the
work. The film “The Wizard of Oz." Many of Appellation Elements Would Be Recorded
In Access Point Fields.
Because We Are Not Actually Pointing to a separate nomen entity, we would just
record, for instance, the access point which is an appellation elements in the 130 field.
And variant access points in the 430 field. We do not actually have a place to record
the preferred Title or the variant titles separately. In our current MARC setup. You will
notice that the preferred title is "The Wizard of Oz." But these are elements in the new
RDA and examples of appellation elements. So everything in red on the metadata
description set is an example of an appellation elements which, again, is an element
that points toward a nomen.
And all of these would point towards different nomens. In fact, here we have a slide
that shows if we had a sort of a fully developed data base in which we were applying the
RDA and LRM principles we would have separate description sets for all of these
nomens. And here we would have a description set for the work up in the upper left-
hand corner. That is the film "The Wizard of Oz." These are categories of the work.
But we are talking about nomens now, not the work.
Let's talk about the nomen metadata description sets at the top and then at the
bottom. So note first the preferred title of the work in the new RDA is not the same thing
as the access point for the work. Because of one thing the program for cooperating
cataloging in its practice the preferred title gets manipulated by removing part of it.
Removing the article and then manipulated by adding stuff at the end in parentheses. It
is a preferred title. The script of nomen is Latin.
The nomen second nomen down is another related nomen to that work. But it is a
variant title. So this work has a variant title. It is a variant title and its language is
Spanish. It has a script investment nomen that is lat in script. The third one down on
the right the work "wizard of OZ" has a variant title and it has a variant string and
category. The language is Greek and script is Greek. The next one is another variant
title related to this work. It has a nomen the same Omagostou Oz. That distinguishes
the two nomens from each other.
And let's look at something we will be talking about in two weeks, the time span that
here we have this work has a date of work and time span it an entity on its own. The
time span is 1939. The little characters 1939 are a nomen string. And so they
themselves in a fully worked out database would have a nomen entity that's -- that the
time span is related to. And the relationship is has authorized access point for the
sometime span. I just decided and that is that.
So in the nomen Box, right below time span, you can see this nomen has a nomen
string, 1939. It has a category. It as date and it is also an authorized access point for
the particular time span. And it has a scheme. And the scheme is ADTS. That is how
it was formulated. But that particular nomen, I just wanted to show a part of nomen
example here is a part of the string for the authorized access for the work. Look at the
arrow pointing to the box farthest down. The work has an authorized access point and
the nomen for that work includes a nomen -- for that authorized access point includes a
nomen string, wizard of Oz, that is an authorized access point.?
English, that is its language and the Latin script. I'm just pointing out here that the
1939 piece of the nomen string is a part of that -- or part of the nomen in the bottom is

13. just 1939. I know this looks complicated but to machines it makes sense to the machine
and helps the machine organize the data.
Another example here an example for the person, Judy Garland, the star of the
Wizard of Oz. The preferred name and variant name and access point for the person
and the variant access point for the person. As an appellation element, that means they
all point to in a relationship to a nomen.
That is what an appellation element is. An element that points to a nomen.
So just to look at this description set. The preferred name is Judy garland. I point
out in the new RDA Judy Garland is the feared name. In the current before we choose
we are told to ma nip plate into Garland, Judy. This is a fairly profound in the new RDA.
The first name is how it was recorded exactly as you find it. In this case the preferred
Jim is Judy Garland and a variant name Frances Ethel Gumm. And the inversion bit
happens in the instructions for authorize the access point. Exploring the new RDA that
is where you find the instructions to invert a name.
It has a variant access point. Gumm, Frances Ethel. And these are all appellation
elements. This has two more elements. The date of her birth and the date of her death.
An. And I have given them in the EDTF format here. Here is the cluster for Judy
Garland that might happen in a fully developed database that employs nomen as an
entity. The person. She has a preferred name that points to a nomen. It has a nomen
string, Judy garland. It also has a category of Stage name if you are looking on the
right-hand side of the screen.
The language of this nomen is English. It is in Latin script and has a text of use.
She used this nomen in motion pictures and in acting. Going down one more box.
Another nomen. It is the person has a variant name and that is a nomen. And the
nomen string is Ethel Gumm. Also her birth name. The language is English and the
script is Latin script. The person has another variant name, Garland, Judy. That is the
access point of the nomen. The language of the nomen is English. The script is Latin.
In a fully developed database that has all of these entities and links like I'm showing
here, we may do away with the authorize the access point. But it is still there. So I will
say that is the authorized access point for Garland, Judy. And another at the bottom for
the variant access point. We are given instructions to take the name and invert it.
Gumm, Frances Ethel. I'm showing to the far right on the curved blue arrows that the
nomens are related to each other and the relationship is the derivation of. The third one
from the top, Garland, Judy is a derivation of the nomen Judy garland. And this is a
derivation of the nomen string Frances Ethel Gumm.
Looking down on the left-hand side, Judy Garland has time spans. They will be
talked about in two weeks. And, once again, as on the previous slide showing the film
the time spans themselves are related to nomens that contain the nomen string that we
used to identify the time span.
So number one has the nomen string 1922.
0610. And then related to the nomen string 1969, 0622. And another time span
entity 1935-1969 which stands for the beginning and end dates of this person's life. And
that is related to -- can be related to the nomen -- different nomens. Sorry. The 1939-
1969 is the time span and date of usage for the first nomen. Judy Garland. That is
when she began using 1935.

14. So I'm sure many of you were saying gosh, this seems so complicated, why in the
heck is RDA doing this?
Well, theoretical model calls for and has many for years now. And the reason the
theoretical model which is LRM and FRSAD and FRAD calls for this, they all have
attributes that need to be recorded or can usefully be recorded to make the database
better. If we use the nomen entity we could create custom displays based on the
audience. We could prefer that the display and indexing of the nomens only display the
ones meant for children or let the user choose that I only want to see nomens for
children or for Chinese speakers or people who can read Cyrillic alphabet. If we have
the nomen entity and this contained those elements, the intended audience or the script
elements, then we could pull them out and we could have users or library itself decide I
just want to display Chinese character Nomens.
We could also isolate the Nomens by attributes such as dates of use and or context
which could be useful in the evaluation of the database or in the evaluation of the use of
the database. There are all sorts of uses for being able to isolate this information.
For example, we could -- a researcher might want to find all of the Nomens used for
fantasy fiction writing. That is an example of a possible use.
Okay. After one slide I'm going to assume that I have convinced you all so let's say
you're all convinced. So the next question is I want to do it. How can I do it? And the
answer is we can't do it right now. Full implementation of the nomen entity would
require major changes to our communications and exchange standards such as MARC
21 and developing standards such as Marc frame. It could be done. We could record
for an entity relationship application using MARC. This would require a new field 1 XX
field for the nomen string and new fields to accommodate the other nomens that we
talked about today. The second is that the MARC advisory committee could allow
partial implementation by authorizing subfield codes where certain aspects could be
recorded. I will show what I mean.
If we had a full MARC implementation -- no, this is partial. Where is my -- sorry, I
had a slide. This is what partial might look like.
We could assign subfields to the elements of the nomen entity that would not display
and not index but would be associated with a particular nomen string in the actual Marc
record as is exists today. For example the 100 field in the record is Garland, Judy and
we would record in the field this is a stage name and used in the context of motion
pictures and used between 1935 and 1969. I have just made up symbols for the
subfield codes.
Which all could possibly be used but we never used symbols like this. That is just so
I don't usurp anybody's authority in choosing a subfield letter for these. This is one way
we could implement this. We could say okay, a nomen string, Garland Judy. The
nomen that that would respond to and fully implemented RDA situation or a database
would have all of the elements and we could record them. We could record the same
elements with the 400 field, we could say it is the birth name as the category of nomen.
It was used from 1922 to 1935 as the dates of usage and same with the two inertance
on the authority record for the motion picture. We could say that the first one is in the
Greek language and it is in Greek script. And we could say that the second is in Latin
script and is also in the Greek language. We could record this sort of information right

15. now if we had the right subfield codes without too much disruption to what we are doing
already in our system.
If we wanted to do a full implementation we would probably need a new 1XX field for
the nomen string. We would need a new 1XX field for the nomen string. And some use
the XD fields for the other descriptive elements of nomen. Some we already -- perhaps
we could use 368. Right now it is only used for persons or corporate bodies. Context of
use doesn't exist anywhere. Probably a new perhaps 3XX field. In ended audience.
We could use 385. It is already there. Language, 377 could be used. A note 667
perhaps could used for that element for the reference source. Presumably 670 just like
we do for any other record now. Scheme of nomen would presumably be subfield E.
Script of nomen we could perhaps expand the definition of 348. Status of identification.
There is a fixed field already. We could also expand the fixed field code for that
although they sort of declared that we are not going to use that anymore. Just pointing
out that most of the descriptive elements for nomens are already there and could be
repurposed for nomen if we wanted to full play implement that in MARC. The ability to
link to other entities including related nomens. Agent time set and place would need to
be there but we already have the structure in the 5XX fields in MARC records. We can't
right now implement this but it wouldn't be impossible even if we have not left MARC. I
hope as we move into new post mark database structures that nomen will be
implemented and L. be taken into account as those structures are designed.
Okay. So I'm coming to a time where we can ask some questions or make
comments if you want to make comments that is fine, too. Thank you very much for
being here.
>> DAN: Thanks, Bob. So the first question this actually goes -- this was asked way
back at the beginning of the preparation.
An author of a work can use a real name or a pseudonym. Sometimes editions are
first published with the pseudonym and later with the real name. How is it possible to
categorize the author's name and add an addition.
>> ROBERT: That doesn't depend on RDA or Nomens or anything like that. It
depends on policies of the agency you are cataloging for. I think the current policy is to
only link to one of the names. And so in the to speak of Nomens we use the nomen for
the pseudonym when linked to a novel that was written under the pseudonym and the
nomen for the person to link to the real nomen, the real name to link to other things that
weren't written using the pseudonym right now in our -- in our current practice and I
believe our current practice is if later on a novel which was first published using a
pseudonym later gets published using another name we just choose one or the other.
We uniformly refer to it using one or the other for its authorized access point which
consists of a name, preferred name.
That would defend in the future where we -- depend in the future where we might
have this as entities, which one would you point to and that would be a policy decision
of the agency to decide whether to uniformly point to only one nomen and link it to a
works. Or are we going to allow the work to be linked to more than one nomen. That
would be I think a policy decision.
Okay. Next question, can a nomen entity be both a name and an identifier?
>> No. I mean an instance of a nomen entity, I believe it is either one or the other.
The IEP stance. And nomen comprises names and identifiers, the nomen entity itself.

16. Partly because there is really only one given string in a given nomen. You can repeat
all of the other elements. The nomen string in almost all cases except where I said well
the font size is bigger, the nomen string is just one per instance of a nomen. An
identifier of the nomen string could be different from the name of the nomen string. I
would say yes the identifier and the name, I think we could probably say could not be in
the same instance of a nomen entity. But they both are nomens. They would just be
different instances of the nomen.
>> DAN: Okay. Why would we do away with authorized access points?
>> ROBERT: Well, I'm not saying we should. I personally think that we will always
need some way to label as the people are doing searches and we want to label the
results, I think there is always going to be a benefit in my opinion to having a uniform
way for the result to come back for CS Lewis or Joseph Conrad or something so they
can all be grouped together in one form. I'm saying there is talk in the community that
there may not be a need in the future for authorized access point. I think I agree
probably with the questioner that in my opinion I think we will need some sort of chosen
preferred label for all of these things.
But I am just -- I mentioned that since there are people who think that in the future
we may not need the authorized access point concept. I'm not that -- but it is possible.
>> DAN: Right. We had a request from someone to share slide 22 again. So we
popped that up on the screen. Next question --
>> ROBERT: Let me point out here, I wanted to point out if you are looking at this,
this is FRSAD and I wanted to just remind you that in the double arrows are significant
in this diagram. In FRSAD, a nomen can point to more than one entity. Just a thema
here.
In the RDA and the LRM implementation version of this, there is only going to be one
arrow going towards the race. Let's see if we can find that one. Here. Looking now at
the slide 28, everybody. Notice in the LRM there is only one arrow pointing to the race
which is the same as the thema. And so that means that in that modal nomen can only
point to one entity. So that is a difference between the two models. Okay. Go ahead
with the next question.
>> DAN: We are going to pop slide 28 up there.
>> ROBERT: I thought I had moved.
>> DAN: We had taken back control to show the slide.
>> ROBERT: Okay. Back to slide 28.
>> DAN: Here we are now. So next question if Judy Garland's authorized name
included in her birth and death dates, would the category of nomen for Garland, Judy
still be authorized access point, or would that be something different?
>> ROBERT: It would probably be something different I chose the are rise the
access list as it is now. That would be a different nomen and we would have to say it
was a different category because the authorized access point is the form with the dates.
So that's correct, it would be a different nomen. I'm not sure what I would call the
category of nomen we would have to come up with a name for it, for the one without the
dates. We might say it is a variant access point. Probably a variant access point
because it would be a form that was not the form that was chosen as the author as to
access point. Okay. Go ahead.

17. >> DAN: Here is a lengthier question that just came in. The follow-up on the
question of the pseudonym and addition is there a place in the model where a nomen of
the session gets linked to the work of the WEMI entity. I thought because it was to the
agents and the agents have nomens if you want to specify in a record for an addition of
WEMI entity associated with a specific agent who in the context of this work uses a
particular nomen, sorry I'm trying to scroll through the question here. Sorry. I was
scrolling through the question.
>> ROBERT: I'm looking at it, too. Maybe it means who has the nomen.
Okay, first of all, let me just look at this question, too. The work is associated directly
with nomens. So a work has an authorized access point in our current RDA in our
model.
And so that and the authorized access point is a nomen. So I suppose that's another
way of saying what I was saying in the earlier spots, in our current environment in the
PC environment anyway the authorized access point for a work that has a -- that is
associated with a pseudonym if the work sometimes is published under the pseudonym
and sometimes under the real name we are required in the current system to choose
one or the other for the authorized access point. So it will either begin with the name of
the pseudonym or the real name depending on the various manifestations of work.
That is another way of saying we would uniformly choose one or another and not use
more than one. Each work has a single one authorized access point. The same thing
would hold if we had this system of relationships to nomens. One of the nomens if we
still have the concept of authorized access point would be a nomen for the authorized
access point and that would be linked directly to the work. It doesn't -- there is no -- it is
not a direct linking through the agent.
The agent, this is a link from the work to the agent, that is correct. And it -- and the
agent itself has nomens associated with it. But the work also is directly linked to
nomens that name that work. And one of the nomens right now and could be in the
future a nomen designated as the authorized access point. And if we have only one
single authorized access point we have to choose between the authorize the access
point with the name of pseudonym or the one that names the other names that are used
on the manifestations of the work.
So I guess that's -- I have sort of gone on a little bit about that. But is that answering
the question or is there more that I'm not quite seeing in the question here?
>> DAN: I think you have got it.
>> ROBERT: If there is further, please put it in the chat. We have a few minutes.
>> DAN: And we are just about at the end of our time. So I think we are at the -- we
will wrap up there. But thank you all so much.
And thank you, Bob, for the wonderful presentation. Thor those who signed up for
the whole series we will see you back next week. And we will make sure you get a
follow-up e-mail soon with a copy of the recording. We'll send out the transcript and the
slides as well. So thank you all so much. And I hope everyone has a great day. And
thank you, Bob.
>> ROBERT: You're welcome and thank you for being here, everyone.
>> DAN: Take care, everyone.