The presentation discusses relationship elements in RDA, which have increased significantly in the new RDA Toolkit. Relationship elements describe associations between entities, with each entity playing a domain or range role. The presentation explores where RDA relationships originated from the FRBR entity-relationship model. It examines the related corporate body relationship in detail and briefly discusses other new relationship concepts like meta-data works. The goals are to help participants better understand relationships and explore additional elements in the new RDA Toolkit.

1. ROUGHLY EDITED COPY
AMERICAN LIBRARY ASSOCIATION
NEW CONCEPTS: RELATIONSHIP ELEMENTS
MARCH 11, 2020, 10:00 A.M.
REMOTE CART PROVIDED BY:
ALTERNATIVE COMMUNICATION SERVICES, LLC
www.CaptionFamily.com
***
This is being provided in a rough-draft format. Remote CART,
Communication Access Realtime Translation, is provided in order to
facilitate communication accessibility and may not be a totally
verbatim record of the proceedings.
***
>> Hi everyone, this is Colton Ursiny coming on to do another sound
check. We are five minutes away from our start time. We are happy
to hear from you. And if you haven't already please feel free to chime
in. We would love to hear who you are, where you are, anything else
you would like to share. We will do one more sound check before we
get started in five minutes at noon eastern. And in between our sound
checks there will be only silence. Thank you.
>> Hi everyone. This is Colton Ursiny doing a final sound check for
today's workshop. We will start in just under two minutes. If you
haven't already, feel free to introduce yourself and your group in
the chat space on the right of your screen. We will be getting started
in just under two minutes. Stay tuned and continue chatting and
introducing yourself as we are getting started. No need to go guy
why the once we launch. Thank you.
>> Okay, it's 12:00 p.m. eastern time. Thank you for being with us
today. I'm Colton Ursiny with ALA publishing solutions and we are
happy to bring you the fourth session in this RDA on-line series on
new concepts, relationship elements with Thomas Brenndorfer. I will
cover brief technical information and we will get right to it.
Today's event is being live captioned. You can view the
captions in the multi-media viewer in the right-hand side of your
screen. If you see an external site message in the viewer, click
continue as it is a safe site. You can use the chat area to interact
with the presenter and fellow attendees. You will see that some chat

2. has occurred in the area. You can chat in that space at any time if
you do not see the chat window, hit the chat icon in the bottom menu
row.
If you have technical questions during the event, questions
about audio or trouble using WebEx, we ask you private chat host. We
will help you personally without dropping the discussion in chat. The
private chat to simply click on the pull down window and select user,
host. Type your chat and it will go directly to us. We will have
a Q&A session at the end of the workshop to ask Thomas questions type
your question into the chat space making sure that two box is set to
all participants. You can chat your questions at any time. Keep in
mind we might not get to every single question.
If your audio breaks up or drops out during the presentation,
you can always reconnect by either hanging up or closing your audio
broadcast window and clicking communicate at the top of your screen
or the three dots in the menu row and selecting audio connection. Then
select either use audio or call-in. If you are listening through the
audio broadcasting and notice an ECHO, make sure you don't have two
broadcast windows open simultaneously if you do simply close one.
Note that the internet audio quality can be affected by any number
of factors of network, speed or traffic. If you have troubles, try
disconnecting and reconnecting. We are recording the presentation.
Within a day you will receive a e-mail with a link to the slides and
the archived recording which includes the full audio, video and chat
record.
ALA publishing Learning Solutions offers an array of workshops
and courses throughout the year. You can view additional
opportunities on the ALA store.
And we are thrilled to have Thomas Brenndorfer with us for
today's event. Thomas is currently the North American RDA committee
representative to the RDA steering committee. He is one of the
Canadian representatives on the North American RDA committee
representing the Canadian committee on cataloging. Thomas began his
career in 1989 at the national library of Canada. He worked at the
Supreme Court of Canada library as well as the Canadian forces college
forces library in Toronto. Since 1994, he has worked as cataloging
librarian at the library. Led to providing presentations and writing
guides starting in 2006. He also the author of RDA essentials and
upcoming second edition from ALA. With all of that out of the way
I will turn things over to Thomas. Welcome, Thomas. Let's get you
off mute here. There you go hi, Thomas.

3. >> The topic is RDA relationship elements and this is part of the new
concept series. This presentation will involve both old and new
concepts and you might find some overlap with the other topics in the
RDA orientation series, but I do hope people listening will learn
several new things today.
And so this is the description written for the session. Let's
review why everyone is here today. There are many, many new
relationship elements in the RDA Toolkits. The bulk of the elements
in the new Toolkit are relationship elements. And that's the reason
why we may cover some the same ground from the other presentations,
but I hope I can offer a unique take. I will say that overall the
relationship elements in the new RDA Toolkit are treated with more
consistency. There is a balance here. Yes, there are a lot of
relationship elements, but once you become familiar with several of
them and see how they fit into the new tool kit, learning the others
becomes much faster.
You will learn what became of the relationship designators which
were originally put into appendices in the tool kit. I do remember
being glad when the original tool kit came out to have a list of all
of the relationships gathered up from the ACR tube text but these were
stuck in the back of the appendices of the tool kit and through the
recognition of the designators this is where some important
information from the ACR2 was found. One thing that is certainly new
is that many elements defined as attributes in the current tool kit
have now become relationship elements. And we will go over the why
and the how of that.
Relationships are between things or entities. And so there are
always two entities. One on each side of the relationship element.
Those entities are called domain and range. Relationship elements
also need to be identified, each in a unique specific way or as unique
as possible. But alternate labels are of interest since end users
may want to see relationships with familiar labels. Then at the end
of the presentation we will explore some of the relationship elements
in the new tool kit. We will probably not cover everything about
relationships, but hopefully this presentation will provide the
guidance for all of you -- guidance to explore the rest of the Toolkit
on your own.
Here is a bit more specific detail on the topics in this
presentation. We can't really talk about relationships without
explaining where the concept of relationships came from which was the

4. FR or functional requirements efforts that began in the 1990, and were
only consolidated with the library reference model, LRM in 2017. We
will then look at a case study, the relationship element related
corporate body of person and this is a good case that covers several
of the changes in the new concepts.
We will then make quick visits to some areas of the new Toolkit.
We will look at nomen which form interesting relationships. Also we
will look at the new concept of meta data work and with a -- meta data
work and what relationships are involved with that. Other new
concepts in the new Toolkit tie in with our consideration of
relationships like the concepts of coherent and minimum descriptions.
We will look at short-cut relationships and there are several new ones
especially around aggregates. We will quickly look at the
relationships called transformation relationships which have to do
with dichonic works or cereals. And -- serials. And we will look
at the element subject and how these are integrated with the RDA
specific relationships.
A good place to begin with a discussion of relationships is the
entity relationship analysis. Any time there is a need to produce
or evaluate a database or design good systems, there is a need to
develop a high level logical data model where all of the things or
entities of interest are enumerated and their properties, their
attributes and relationships are identified. All of that data can
be analyzed to see if they are justified or can be improved, so on.
You will hear me say variations of this a few times in this
presentation. An attribute of an entity is a particular property that
describes the entity, relationships are the associations that
describe the interaction between entities.
And here is a simple representation of a relationship from an
entity relationship diagram. A relationship between entities.
These entities, entity one and entity, have their own properties or
attributes. But once we have defined these entities, the
possibilities then exist for making relationships. Now it's
important to model things out this way because we have to ask, what
is the business case for defining a particular entity? Why track
certain attributes and not others? What relationships should be
defined? And the rationale for that is sometimes it's just defined
by making an efficient database. So consider a common very simple
example. An employee database. For each employee we can have an
attribute that says here is the department they are working in.
Sometimes there might be a need to track information about each
department, therefore, it makes more sense to treat department as an

5. entity. Now we can relate employees to departments. We can record
all of the attributes of a department with that entity department.
And quite significantly the department as an entity can then go on
to have relationships with other entities in the data model.
So an entity relationship analysis was the starting point.
This needed to be done with bibliographic data. So find out how it
was being implemented. The resulting analyses were called the
functional requirements and conceptual models were produced. These
models are high level displays of the different entities bibliographic
data, their attributes and how they relate to each other. 1998, the
functional requirements for bibliographic records came out. In 2009,
the functional requirement for authority data followed in 2010 by the
functional requirements for subject authority data.
The way I look at this and I think today if this -- if none of
this had come out, if this entity relationship analysis was never done,
then I think the debate today would be about getting this done. We
need to move forward and to do so we need to define the things we are
recording in our data. We need to know what needs to be added or
clarified, especially as we implement bibliographic data in new
scenarios or systems. Sometimes I hear a special pleading argument
that catalog data is somehow special. Or it's to artisanal. We
should be able to describe what we are doing to database designers
in standardized terms and that's what an entity relationship analysis
does.
Now here is a statement of the method used as quoted from FRBR.
FRBR was the quality of entity relationship analysis. It was
incomplete and not fully developed data model at the time. I can
relate some of my memories when I encountered FRBR. I remember
reading about this in the late 1990s and the early 2000s. At that
time I had gone through transitioning through three different library
and cataloging systems including figuring out how to map indexes and
displays to a web based catalog. I experienced frustration and
looking at library system, limits and mark and realizing there was
limits in the content standard itself in the ACR2. There was
frustration in trying to translate and reverse between different
implementations from instructions that were very catalog card centric
to different database approaches to mark, to what to do with web
interfaces. Hyperlinks, just trying to get these things to work well
was a challenge. And eventually I saw the entity relationship
analysis as producing a lingua franca. Something independent of the
different ways of implementing the catalog data. For example, saying
something very specific like record the main entry in a 100 field is

6. not as clear as stating relate a person to a resource as the author
of the intellectual content of that resource. Or saying, identify
that work by using the name of its author and title.
So there is no pre-supposition about how data is to be
implemented. Just relatively simple statements and assertions about
the data.
And here is another very useful quote from FRBR. This helps
explain why some of the terms in traditional cataloging needed to
change. Why sometimes the new labels seem so different. As stated
here they are needed in context of the entity to define the model.
For example, there is a difference between large print version, which
relates to a manifestation and French language version which is about
the expression. And I think this results in rather sobering
realization. There was relationship information scattered
everywhere in catalog data. Some of which really could and should
have been acted upon better by machines.
Once we defined the model, we defined the entity and then we
could get a better handle on all of these different relationships.
And just to throw in one more quote from FRBR, and I think this is
an interesting one. Here is an early indication in FRBR of the
importance of explicitly identifying each side of the relationship.
Each entity should be named at a sufficient level so that the
relationship is operative. And in the beta Toolkit, we have four
recording methods to explicitly identify the entity in those
relationships. And each reporting method represents increasing
levels of precision.
So when RDA finally came out, these president entities at the
time. The work expression, manifestation, item, person, corporate,
family was something new at that time. The ideas of names was present
and derived from the functional requirements for authority data, but
names, titles and identifiers in RDA were attributes and not
relationships and points were tucked away at the bottom of chapters
for identifying an entity. Subjects originally divided up as concept
object and place eventually simplified to -- or were simplified to
just subjects. And there were some groupings of these entities.
Group one the products of intellectual or artistic endeavor work
expression manifestation and item. Group two, the agents responsible
for the group one entities. And group three was subjects.
Now when entities are related. We can talk about some
restrictions and how they are related. There are the so-called many

7. to many, many to one and one to one relationships. And this is the
concept called cardinality. So picture how this works with
traditional bibliographic data. What are examples of many to many
relationships? We know that people can author multiple works. And
that the work can have multiple authors. That's many to many. And
think of what has to be done in -- to support the reality of those
many to many relationships. With authority control for person, and
the flexibility in records that needs to be there to support a variable
number of fields for authors. Think of one to many cases. We can
think of for example many items all belonging to one and only one
manifestation. Well, that makes sense. Likewise, we can think of
one work being realized several times in different expressions. Now
there is some overhead with that. We have to determine if a new
resource is a new work or another expression of that work. There is
value in drawing the different expressions together.
Now another case of a many to many relationship exists between
expressions to manifestations. An expression may be embody more than
one manifestation, and a manifestation may embody more than one
expression. We see this in the issue of aggregates. This
many-to-many aspect was identified right at the beginning in FRBR.
Now you may have heard of things called locks which are
one -- essentially this issue of cardinality of being recast as a
one-to-one relationship. And you see these being discussed in the
context of aggregating works and die chronic works. That's something
I won't get into but it's something to be aware of.
Overall, this is really -- this is why a diagram is helpful.
It helps to visualize what is happening. Why we need to keep track
of -- what we need to keep track of. Where the issues are such as
in the areas of cardinality, and where we need to add attributes and
relationships.
So moving on and looking back at the original Toolkit, the
current Toolkit, the relationship designators, they provided more
specific information about the nature of the relationship. For
example, author, editor. These designators seemed related in higher
ale ways, hierarchical ways, why are the main elements in one section
creator and contributor, let's say, and designators stuck in the back
of the appendices. In the new RDA Toolkit, all of the designators
are treated as elements given their own page with applicable
boilerplate and common language and structure for all such elements.
Now here we have some examples of what the entities are on either

8. side of the relationship designator in the original tool kit. And
we see some problems. Sometimes there are multiple -- in the
right-hand column. Sometimes the designator itself is qualified with
a specific entity.
Here is a screen shot. And here is the entity family. And we
see how this is organized. It's organized with the entities around
either side of the designator. You have a family to person set of
relationships and then person to family, et cetera. We see reciprocal
designators reference and they are kind of mixed in. And it's not
a bad organization except we may want more such as being able to see
different labels or identifiers for the designator. Maybe there
should be some pre-recording instructions for the designators. Maybe
a way to flag each designator what we should use to record the value.
Of course, I just described what's in the new beta tool kit and why
it's an improvement over the current Toolkit.
Here are cases are sometimes they are for a specific entity,
such as person, but sometimes the designator refer to the broader term,
agent, which covers person, family and corporate body. This looks
maybe a little disorienting as the scope of designators are shifting
and as we move up and down to different levels of entities.
So with that stroll through the FR models and the original RDA
Toolkit, we can now talk about some new concepts arising from the
consolidation of the FR model, the library reference model which came
out in 2017 and replaced all three FR models.
LRM triggered the new development of the RDA Toolkit. There
was a goal to be international, amenable to link data concepts, and
there were some updates to how relationships were handled. Now one
thing that didn't happen in the new Toolkit that is in LRM is the super
class entity RES or as I like to call it the everything in the
university entity. And trying to cover everything including subjects
was seen as quite outside the scope of what RDA should be about. So
RDA entity is the high level entity in the new tool kit. Covering
a range of familiar looking entities, person, work, manifestation.
As well as some new ones. Nomen, time spent, collective agent. Now
the new tool kit does have a variation of the super entity idea and
it's the use of the plane term entity. And this refers to the entity
outside of the scope of RDA. Relationships can be made to them, but
they are not covered in RDA. And these are relationship definitions
in the new RDA tool kit and they should look familiar from what we
discussed so far. There are entities on either side of a relationship
element call the domain and the range. I've added the definition for

9. attribute element here.
Sometimes the question comes up: How does this compare to
linked data? And so I will do a little digression here on that that
question has come up several times in the past. So in comparison with
linked data, attributes and relationships together are called
properties. And the key difference between attributes and
relationships is that attributes have values that are text strings
or sometimes called literals, or controlled vocabulary terms.
Relationships have an instance of an entity on either end as the
subject and object or as domain and range. So in linked data we can
say relationships are more useful and object, the range entity, in
one case can turn around and become a subject or the domain entity
in another case. Or as attributes while they are far limited. They
are useful and necessary, but I think maybe you can see the reason
why relationships are -- feel like they have more power to them.
In the new RDA Toolkit, there are some new entities and we see
RDA entity at the top. Not the everything in the university entity,
just the abroad entity that refers to the RDA specific entities. And
note specifically that subject, the subject entities are not covered
here.
Some of the new entities in the new RDA Toolkit result from
following the -- what's called the enhanced entity relationship
model. The enhanced entity relationship model has some efficiencies.
Super class entities are useful because common attributes could be
defined at a higher level and this means more generalization wherever
possible, more streamlining. And one of the big deals that came out
of L-RM is the agent entity. Agents are defined at capable of
deliberate actions of being granted rights and of being held
accountable for their actions. These are intentional relationships
with specifically with instances of bibliographic entities, works,
expressions, manifestations and items. So that means human beings,
not machines and not automations which are set up and used by actual
agents, those can't be agents. The relationships have to be
intentional.
Also note here how the super class entities are broken down here,
RDA entity to agent but also down to collective agent. So maybe what
are we going to use collective agent? But perhaps it's better to
describe using a metaphor sometimes the new RDA tool kit is described
as the pluming and electrical work for a house. I know the impulse
for the people looking at this is to rush in and to start furnishing
rooms and decorating things and putting familiar things into familiar

10. places, but sometimes you need the structure these super class
entities because they form utility that we need like running water.
They are there for structure.
Actually, let me go back. We may be mapping old data or just
poor data and just need to map to a higher level entity like such as
just agent. There is some efficiency with using super class entities
and some cases. And also we can define properties at higher level
and they can cascade down to the subtypes of entities.
Another way to look at that is to say given all of the different
scenarios we encounter when we cataloging, there are elements in the
new RDA tool kit but it may be a better way to look at that for whatever
task we need there is an element for that just like we say there is
an app for that. So there is -- I think an important characteristic.
It does seem overwhelming with all of these new elements and
relationships. But they are not -- no one is expected to run out and
use all of them immediately. They are there to be applicable to
whatever scenario or situation they are suitable for.
Over a year ago it was determined that a defining many key
element only at the super class agent level caused some problems so
the solution was what was called the agent breakout relationship
elements. So the same relationship concept repeated and defined for
each of the sub class agent entities. For example, you see author
and then it's broken down with author person as well as author
collective body, author family, author corporate body. This solves
several problems. The basic question is, where is the author
relationship for a person entity? Now there is a specific one
identified for that. It would also make it easier to develop
application profiles. It will make it more consistent because access
points were handled in this way. And it would also potentially solve
some problems with gender inflected languages. Issues about unique
labels that are applicable to one of those elements and not to others
would be solved by this agent breakout effort.
Here we see another impact of LRM, the new entities, place, which
was not entirely new and time spent. Now treating place and time span
as entities results in attribute elements becoming relationship
elements. And there is some obvious examples. Place of birth was
an attribute and now a relationship. Date of birth, now a
relationship.
Also several other attributes in the original tool kit have been
recast as relationships between entities for consistency. So a good

11. one and I will cover this one again which is affiliation which was
an attribute and really that's a relationship with a corporate body.
So it makes much more sense to define it that way. As I said at the
beginning, one of the goals of the tool kit is to make -- to treat
these elements with much greater levels of consistency. And we can
see that logic taking shape in the new Toolkit. And why this common
structure with the four recording methods helps when developing and
converting these elements. We don't need separate element that just
happen to use a different recording method. And the four recording
methods, unstructured descriptions when we are recording a
transcribed form like a name, an identifier or an IRI used in linked
data.
So taking that as a cue, let's dive in a bit to look at a
particular case study this relationship element related corporate
body of person and its reciprocal and you will see why it's important
to do both because there are details in one and not the other.
So let's look at this as a case here. Observe several things.
This is an example of poly hierarchy. I'm drawing attention to this
to be aware of where an element could have two broader elements. In
this case collective agent of person or related collective agent of
person and related corporate body of agents.
Another thing to observe, the bottom of each element page and
the related elements, we always see the inverse elements here. As
I said, this is a good example because there are certain legacy
practices that are captured in one of the elements but not the other.
And so I will switch to this other element, person, member of corporate
body.
So looking at this element page, just more details on what you
should expect to see. Under element reference, we can see an IRI,
and this is for the relationship element itself. It's not for the
range value. I can see the identifier, P50095. That's also an
identifier for that.
The domain, provides context so we know which entity we are
describing. This is the entity we are describing. And also at the
top in the bread crumbs, person greater than sign. You can see the
domain entity there as well. The rake entity, this is -- the range
entity, this is a flag for us. We have to get ready for what we have
to record. You will have to decide how you are going to record this
range entity. Is there an access point already created for it?
That's convenient. If not, well, then it might mean you may have to

12. construct an access point. For example, just looking farther down
we see alternate labels. We have the is or has form. There is a lot
of interest in looking at this for public display of this relationship
element. There is also interest in looking at that phrase, person,
member or corporate body of and seeing there is a better way to phrase
that. But for public consumption. I mean, as I noted before, the
IRI, is specific to this element. That overall name of the element,
person, member or corporate body of, has to be unique as the IRI.
Also in the alternate labels you will see the legacy labels that
were used in the old tool kit have been merged in this. This is a
result of treating these elements more consistently. And at the
bottom of element reference we have mapping to encoding schemes. And
it shows there where the value of this relationship element will be
recorded. Where the corporate body, the range, will be recorded.
And it specifies there, mark authority 510 and see also from tracing.
So leaving element and reference and moving down the element
page we come to the next section, pre-recording. In many cases there
is nothing in this pre-recording section. This is just part of a
template for every element page. But we do have a pre-recording
instruction here and it directs us to another element. Here pointing
to biographical information. So let's take a peek at what that is
saying here. Biographical information is another element.
Basically this is an option to record this as an attribute and the
reason why is because biographical information contains a lot more
than just identifying the range entity. It's basically a note. And
identifying a range entity it has to be an Appalachian element. A
name, an access point or an identifier or it can be an IRI. But
sometimes a more detailed note is needed so that's a case where we
still have to point to using different elements.
Moving down to pre-recording and move on to recording. And the
first line here which is boilerplate, and we have the specific instance
here of using appellation of corporate body to describe this range
of -- appellation of corporate body or from those IRI.
What is this? This is why this is an interesting example
because this is just carried forward from the Toolkit where basically
the instruction said use a specific recording method. Use a preferred
name of corporate body. So that's there if people want to continue
using the practice, but if you look at the marked authority in
documentation it says to use a controlled vocabulary, to use an access
point from the authority file. Basically it's saying don't use this.
Use a different recording method. Use an access point. Here is the

13. case in current practice where we have competing recording methods.
But with the new tool kit, all of the recording methods are available
as options. So here is the case where we have some current language
in the new tool kit but it's also in the context for we have options
for how to record the range value in that relationship.
And look at how recording methods have been handled. So
affiliation is the legacy element that has been rolled into this new
element. It says to record a preferred name. Go to the designator
and it says to record authorized access point or an identifier. But
now this is all been merged together. The three appellation elements
are brought together under one new relationship element. So to
summarize all of this, the changes between the old RDA and the new
RDA. The old RDA there were two different elements, affiliation and
the designator corporate body. Now there is one element with four
recording methods.
So let's look at another interesting topic under relationships.
Nomens. Nomens are entities. What is that all about? Well, here
is a case of attributes that have now been turned into relationships.
In the old Toolkit the access points were not even elements at all.
But we now have appellations elements for all of these for names and
titles. Access points and identifiers. So when we choose recording
methods, we are choosing an appellation element. -- appellation
recording element. When we are choosing a name, we are choosing a
certain relationship element if we are recording an access point
that's a different element. Access point for person for example.
Recording an identifier we use the relationship element identifier
for person.
The actual characters we are recording for this relationship
is called the nomen string. That's string alone is not the nomen
entity. So what exactly is the nomen entity? Well, the entity is
the Association of A nomen string with a specific RDA entity.
That -- I think when people are first introduced to that that seems
kind of flimsy as if it's just the association. Usually we think of
entities as fairly concrete things such as person or objects or works
and so on. But the reason for this is it's somewhat technical and
practical because as I said at the beginning, as soon as we create
an entity we have more flexibility. We can treat an association as
an entity and therefore that as an entity we can assign attributes
to it we can build out some description around that entity and some
of these examples for nomen entities or context of use, date of usage,
language of the nomen, reference scores or the scheme of the nomen.

14. Now a lot of our cataloging, we just focus in on constructing
nomen strings, transcribing and recording forms of names,
constructing access points. There is a lot of instructions for nomen
strings. Once in awhile it's useful to track this information. It's
a little difficult in our current systems but again the new RDA in
the special new RDA Toolkit makes no assumptions as to how well any
current system can handle this. It just presents these as options.
So looking at an example here, we can start right at the top
of the hierarchy, the highest level for identifying a person related
nomen of person. We can record a nomen stringture as unstructured
person, as structured or a nomen string as an identifier.
So let's look at this from another angle. This is a crude
relationship diagram. We see the nomen string is an attribute of the
nomen entity. What happens when we are recording this as a
relationship element, we are just plucking that nomen string out and
just saying, assigning it as the appellation of the person. So those
other values, other values associated with a nomen, that's the
plumbing and electrical wiring that is there behind the scenes. It's
there if we need it. As I said most of the time we were just focused
on recording the nomen string properly.
So diving down a bit and looking under appellation of person
we see the three cases again and how they are divided up. And again
it's a little odd to think of this. We are still recording the
relationships but the value we are recording, the name, the access
point, the identifier that's the nomen string from the nomen entity.
So this is where it's useful to think of these relationships because
sometimes the nomen strings or you have several nomen strings that
are identical, but they are actually different nomen which is to say
they are in fact different relationships. And here is an example.
We look at Apple as a name of a corporate body and the string is the
same as the corporate body, same nomen string and different nomen.
Therefore different corporate body nomen relationships. So what does
that mean? In practical terms? It means that as different nomen we
can assign different attributes to those nomen entities. So it's the
name of a corporate body and what we will be interested in is the
guidelines or scheme used for transcription. We will be interested
in the sources of information. However, as the different nomen entity
and if it's an access point for corporate body element, we would be
interested in other things. The vocabulary encoding string that is
used to construct that string.
So let's explore interesting examples of relationships in the

15. new tool kit. There are many kinds of works. Works share many common
relationships but there are some relationships tied to specific kinds
of works. So let's look at the concept of a meta data work. In this
example there is a example from the manifestation health. The meta
data we used to create to describe the manifestation is itself called
a work. Also consider individual meta data statements such as
manifestation has the title proper for whom the bell tolls. That's
a meta data statement and that meta data statement all on its own is
also called a work in the new RDA Toolkit. A-ha! So we have two
entities. A work the meta data description set or the meta data -- and
manifestation being described. That sounds like that could be a
relationship. And so the act of describing something and calling
those works means we can use the current infrastructure in the RDA
tool kit to map all of this out. With very a relationship element.
The description of the manifestation with the domain is work and the
range is manifestation.
Also that work, that meta data description set or the meta data
statement as an entity can make use of all of the other relationships
or as many are possible to build out more information. So somebody
created that meta data description set and somebody created that
catalog record so we will say that's the work relationship to an author
agent. Or there was a standard that was used as a basis for the meta
data description. So we could say a particular manifestation for the
content standard is related to that meta data work. A lot of
interesting recycling going on here.
Now let's explore some other interesting places in the new tool
kit where relationships show up and this is the coherent description
concept, but if you are familiar with what's -- the current tool kit,
these were just -- these were called primary relationships.
Essentially the same thing. Basically work, and went to
manifestation to an item. And we also had in the current tool kit
an example of a short-cut where we could go from the work directly
to the manifestation and there were element for that. I will come
back to short-cuts again because they have taken on a whole new
perspective in the new tool kit.
We have this concept of a minimum description. I will go back
to what I said right near the beginning when I had that quote from
FRBR about being clear about identifying the identities in the
relationship to make that relationship operational. This is an e-- a
follow-up to that minimum descriptions are about making sure we will
use at least one of the appellation elements. Users of a catalog need
something to identify the entity and remember these are called

16. relationship elements because the appellation elements relate work,
manifestation, et cetera, to a nomen entity.
And it also said everything is presented as an option. You are
not required to make access points for everything. You are required
for a minimum description to have some appellation for that entity.
And as I said, to make a relationship operational, you need to have
that entity identified.
So looking at another curious example in the new RDA Toolkit
or the statement elements, now these statement elements themselves
are not relationships but as we dive in a bit you will see, ah, there
are some interesting relationships going on in the elements that are
used to construct these statement elements or these super element
statements. So common one we are familiar with is publication
statements which is -- consists of several sub elements being brought
together. If you look closely, ah, okay. Date of publication is a
manifestation of time spent relationship. Name of publisher is
curious and manifestation nomen but not corporate body relationship.
We will look at that more closely in a bit. Place of publication is
somewhat obvious. The manifestation to place relationships -- as I
said, all four recording methods are applicable but we need to choose
one that's going to suit in our application for how we are going to
record the publication statement. Also some of the components of
elements are themselves relationships and in this case the appellation
elements or nomen relationships.
So just looking at short-cut relationships again, we have
encountered one which is the short-cut that goes from the work to the
manifestation. Now one thing that's important with this is it doesn't
mean the expression does not exist. It just means we don't have a
minimum description of that expression. There is no appellation that
at a minimum would need to be described. The logic behind these
relationships include in their definition the expression
So using that logic, let's look back at this name of publisher
and why was it specifying the nomen? Instead of the corporate body,
the publisher? It's because it's a short-cut. It does refer to the
publisher but what we were recording as a nomen is the nomen string
as it is found on the publication. So this in a sense restricts us
to what we are recording. We are restricted to just that particular
nomen string as it's found on the publication. It is otherwise
defined as a short-cut. We are ultimately getting to the publisher
but this relationship is just a nomen relationship. It forces us to
look at this one particular nomen string only.

17. So with hopefully that bit of a primer and short-cut
relationship elements, I will move on to aggregates, which have made
extensive use of short-cuts in the new Toolkit. While these short-cut
relationships they solve a problem with aggregates. One important
issue with aggregates which I described earlier, multiple expressions
that are embodied in a single manifestation, when we catalog these,
there are degrees to which we decide how much we are going to describe.
Perhaps we will describe them in great detail where all of the works
and expressions are described fully or maybe we are just making a note
of those expressions. In the cases where we are not fully describing
every one of those expressions that are manifested. We still may want
to draw attention to an agent that is responsible for one of the
expressions that have been aggregated. So without identifying with
a minimum description of that expression or a multiple expressions,
we can use a short-cut relationships, relationship and link the agent
responsible for the aggregated expression, link that to the
manifestation and define that as a short-cut relationship to say that
we are going to be pointing back to the aggregate expression. So the
name of this -- the broadest label for all of these short-cuts is
contributor agent through aggregate. Now in the course of cataloging
aggregate, we recognize something as an aggregate and then we have
to say there are different content here that's been aggregated so we
do have to know, well, there is text. So there are multiple short
stories or maybe it's just an introduction. It's text in most cases.
So at minimum we do need to know what the content type is so the next
level of detail in terms of the defining the short-cut relationship
elements we can say contributor agent of text one important thing to
add about this is the short-cut is a short-cut that all of the creators
that are related to what's been embodied in a manifestation and this
has led to just a tweak in the definition for creator agent of
expression which absorbs into it the creator agent of work. So really
this is not all creators of any aspect of the content that's been
aggregated. So it's not just creators of expressions. It's creators
of work. So in many ways what this has done is if you go back to
traditional cataloging, we would say just make an added entry for
somebody -- for an agent that has written an introduction and so on.
So this essentially gives that same level of flexibility.
So that covers the short-cuts. Aggregates themselves have a
set of relationship elements. We are familiar with expression
manifested, so each of the aggregated expressions uses that well
established relationship element. The aggregating work, the
activity of assembling the different expressions can have an agent
responsible for it. And also the individual aggregated expressions

18. can be related to the aggregating expressions of these new
relationship elements, the aggregates and aggregated by.
So a few more relationship elements. Just cover these briefly.
As I said in the beginning there is a lot of detail to cover here and
my hope is that this is a good starter to explain these in more detail.
And I have included a transformation relationships to just let people
know they exist and generally where we will find them. And these have
to do with dichronic works which is work plans for resources that
change over time, and we think of serials in this way. And so as the
work changes over time, work-to-work relationships are formed so one
work is transformed into another work. And you will see how this is
organized here with the different transformation elements.
This is almost a whole topic itself and I will leave this and
go on to another interesting topic.
These are the outward facing elements in the new tool kit. One
of the characteristics of these is that there is no range, but they
are still considered relationship elements. These are designed to
relate an established RDA entity with an unspecified entity outside
the scope of RDA. So this was also a solution to how to deal with
say animal entities that can't be agents and so therefore they can't
really fall under any RDA entity at all. But we may want to include
them if they are a non-RDA entity, this is how they can find their
way back into RDA in some form. They can be related to work and
expressions. It's just that RDA itself won't take on the task of
establishing these as entities in their own right. That can be done
external to RDA.
These relationship elements allow any other kind of mapping to
occur. So if entities have been defined outside of RDA and they are
comparable to any RDA entity, this is another mechanism by which they
can be tied into RDA.
An example of an outward facing relationship element is subject.
Now if we look at the element reference, we see there is a domain.
We are describing a work. Assigning a subject but no range. But
sometimes the subject is an RDA entity so any time that happens you
do link the RDA entity work as -- and that it has a subject another
RDA entity and that could be an agent or expression, person, place,
et cetera. Or another work.
Nearing the end here are some final things to look at. As you
can see there is a tool under the resources tab to navigate

19. relationships. The relationship matrix. And you can also see that
it's a bit under development for quite sometime. You can see it does
not contain current or complete element listings. And as I said there
are a lot of relationship elements and each has an inverse relationship
associated with it as well. And one -- maybe one of the problems here
is we have to know what the domain is to find the relationship that
we are interested in.
What was in the old Toolkit using the designator at the
appropriate level of specificity for whatever purposes the agency has
decided they are creating data. So this hierarchical nature for the
relationship elements allow that flexibility and choice and that's
carried forward in the tool kit.
You can see it's presented alphabetically. And once you come
across an element if it has narrower elements you can see that. Here
is a question. Can this be improved. The final slide opens the door
to thoughts and ideas for how these things can be improved. There
was talk about creating a visual browser for the elements so you can
skip through different relationships and see them all connected in
a visual way. Earlier attempts at that just produced more text heavy
displays and it's hard to get away from text and the top here actually
this first box under the heading there, the current thinking is to
have a limit box that would limit the two different ranges. If you
are looking at person, you could have a range limiter that will say
show me all of the relationships between a person and a work and that
list will shrink down to just those relationships. Break crumbs
another navigation tool that provides context for elements and
relationships.
So, yeah, I think I will leave it at that and open up to at this
point to any questions. I know that was a fair amount to go over there.
As I said, it may be quite a bit to absorb all at once but if people
have additional questions or want me to go back and explain something
in more detail. I'm just a little sensitive to the timing. Maybe
20, 20 minutes or so. So with that, I will thank everyone.
>> Thank you. So everyone please feel free we have about 20 minutes
for Q&A. So if there is anything that you wanted to go over again
or any questions you have please feel free. This is your time to ask
questions and get answers. Thomas, we had a request for you to go
back to slide 48. 4880s filler slide that's being referenced or maybe
the number is different -- actually, the numbering may sequence off
the introduction so it's not going to be the same. It will be in the
50s maybe. My 48 is a nothing slide actually on my notes here. So

20. I'm not sure --
>> The 48 in here should -- it's got content here.
>> This one, oh, okay. Yeah, okay. That's a bit different. Okay.
Let's -- here we go. This is the case where I went through the
elements in the old RDA and recast those as -- look for ones that could
be recast as relationship elements. Affiliation kind of stuck out
there because that is a corporate body relationship. Limits to a
particular recording method so it made more sense to put it under the
broader of relationship element and then leave as a choice the
recording method. So the mapping to pass practice would be to the
element and then the choice of recording method that creates the
equivalents practice from the past. But this way it's more consistent
and we don't have the stray elements that stick out and are associated
with just one recording method. It's consolidates all of the stray
elements. Hopefully that address the question and I don't know what
the actual question was and that's what the slide is about.
>> There wasn't a follow-up question for that yet but I will keep an
eye out. We did have a question. Could you provide an example or
explain more about person, member of corporate body of?
>> Maybe I could go over that. Now the reason why I focused on this
one what looks like the reciprocal is that's actually the equivalent
to -- what was in the original tool kit? We are describing the person
so at the top you can see the domain is a person and the bread crumbs
at the top. The range is the corporate body. And so a person is a
member of corporate body of and then the value corporate body. I know
the phrasing is a bit awkward. So it's all boiler plate phrasing.
So you do have to parse this a bit to look at what is the domain and
what's the range. Oh, I see. Describing a person and we are saying
what corporate body is that person related to? And in this case it's
a specific kind of relationship. A person, member, corporate body.
And since this is similar to that idea of affiliation, but we also
had a designator that did a similar thing that when we are describing
a person, we assign a designate and record the corporate body that's
associated with that person. Hopefully that answers that.
>> Thank you so much. And if you do need more clarification, please
feel free to type into the chat. We had a question here, does this
concept change? I record in a bib record and how it's recorded?
>> Well, that -- now not sure which concept specifically. In this
case it gathers up current practice and puts it in a new light. So

21. there is not like a need to change practice. It's just how it's been
categorized. And what it gets mapped to once we use these elements
in say linked data. Remember, these elements are all associated with
specific IRIs so they have computer logic behind them. Ideally that's
what we will use in the future to record this. For current practice
it's a matter of just mapping to whatever system we are using now.
That being said, because of LRM and so on, there are new elements and
the short-cut elements for aggregates I think is one that's been
interesting how that's going to be dealt with. So there is -- and
the issue about what label to present to the public. I mean, there
is this tension between all of these elements having to be unique and
specific and equivalent to an IRI and a lot don't look that friendly,
how do we display this to the public is the other thing. And that's
really ultimately a system mapping thing. We don't display the marked
tags to the public. These elements are essentially are technical as
mark tags are. So the labels we display to the public to convey this
organization, this relationship information, is something that's
being worked on. I know the North American RDA committee has spent
a lot of time on this and they are testing out different friendly labels
then the whole issue of how these things get translated and so on.
>> Thank you, Thomas. And here is another question. Will matrix
replace the structure of bib record?
>> I'm not sure what that means. Maybe clarification of what matrix
means. I only think of the movie offhand.
>> Yeah, whoever asked the question wants to clarify in the chat and
we will be happy to follow-up on that. Here is one, our current
software environments are restrictive. Many catalogers are shoe
horning into marketing. What other environments demonstrate this
work?
>> In terms of the new Toolkits? One tool people can download and
experiment with is called RIMF. It's up to version four now which
ties into all of the registered elements that are available for free
actually. The link data elements are freely available in RDA registry
and this software tool already plugs into that. And you can
experiment with creating data and also round tripping it with marked
data and so on. Might be generous there. There is all some data lost
when you go to other systems. So that's the one that the steering
committee has worked extensively with, it's RIMF4 and that's something
that people can experiment with.
>> Thank you so much. I want to play out this comment in the chat

22. from Bob. An example of the person member of corporate body of
relationship would be Paul McCartney is a person member of the
corporate body of the Beatles. So thank you for that example.
>> Yes, and most of those cases you have preferred name which is an
unstructured description. Neither of those are access points. So
there is also another choice going on there in how you are conveying
in a clear way and making that relationship to element functional you
are identifying the two entities. The person, the names identified
by that string Paul McCartney, but if it was an access point, McCartney
comes first, likewise Beatles, you drop at least there, well, but in
either case, it's the same relationship element. It's just other
choice has been made for identifying the range and domain entities
involved with that relationship element. You are required to have
appellation. That is the place where a core has devolved to in the
new Toolkit.
>> Thank you, Thomas. And thank you to you in the chat for typing
that. And mentioned RIMMF. It's up to verse four now, too. Thank
you.
This may be beyond your scope, Thomas, but do you know if elsey
has a plan to incorporate these new relationships into the subject
authority file?
>> Do we have a plan? I better not answer that, yeah. I better let
LC speak about that.
>> Just in case wanted to bring it up.
>> I could speculate what they are thinking about doing there.
>> Are all of these relationship designators part of the authorized
access point for names or will this be decided later?
>> Now, well, there is two different things there. The relationship
element itself and there is maybe the distinction, it's like a mark
tag. So it's not like the thing that's identifying the entity at the
end of that relationship, the person or corporate body. Are these
part of the -- oh, I think -- oh, okay. Because sometimes you think
strings where a name and title and then sometimes the designator author
was stuck between the name and the title. Well, that's not an official
part of the access point for work. That was a way to formulate an
access point for work is to have the access point for the author
followed by the preferred title of work. So there is no requirement

23. to do that. I mean, you can display things however you want to display
things. But the actual value is constructed according to whatever
scheme you are going to follow. And the end result is you created
something that identifies that entity of work. Let's say. And there
is no requirement to include a designator in the course of that
construction, although come to think of it I don't think there is any
restriction on it per se. It's just whatever scheme you choose to
follow and that's another choice. I mean, we when talk about access
points there is an assumption there is one way and only one way to
construct an access point. You have to specify what scheme you are
going to follow. Once you have done that, you say what elements will
you include when you construct an access point. It does leave it open.
This whole issue of options and choices which are kind of scary but
in some ways -- well, there aren't really at the end of the day maybe
that many options because you are following some agency's rules. You
will follow some scheme that is going to have made all of those choices
already. That's an interesting question. I think it leads to some
good further discussions as well. Good question.
>> Yes, thank you so much for that. And we have ten minutes left.
So feel free continue putting in your questions or requests for more
examples or anything like that we have ten minutes left and plenty
of time to go over some things.
Let's see here. Do you have recommendations for simplifying
this process of relationship elements in regards to the terminology
or words? Does it matter of going through it? What do you think,
Thomas? Is there a way of simplifying it? I hope what I did helped
simplify it. I seem to be always coming back to this. Having worked
on various things and explain RDA and simplify. I will keep at it.
I think it just individuals have to find ways to make this work. And
a lot of it is also for the particular context. I mean, try to explain
this for everybody. It's not going to work I don't think. I think
you have to start with who your users are and look at this and say
I need this and this but I'm not going to use this, this and that and
that's automatically how to simplify it. You will pull out what you
need and have the rest be there because somebody else may need it or
down the road you may have a different application. There are all
kinds of new elements like these new manifestation elements that are
used by people that are harvesting data. Elements that are specific
for that job. So if you are not doing that job, certainly simplify
it by skipping over all of that. In terms of just the chore of going
through these and I said this at the beginning is once you see the
patterns, yes, there is a learning curve. But the flip side is it
is consistent, it is logical. Once you see the pattern it gets faster

24. and faster. And also because so many things are choices, it should
also simplify. Things like proposals for changes. If things are a
choice, the change is you make a different choice. You don't have
to write something brand-new and put it into the catalog standard.
It's like the choices are the framework choices there. And so that's
already a simplification and streamline of things. And also a big
help in terms of efficiency for things like internationalization and
translation. Yes, the language is dry, but my goodness it's actually
very much a big cost saving when it comes to translating it. And at
the end of the day, if -- and this is described this way, if someone
wants a more colorful description of RDA, well that's another
expression of the RDA tool kit if you would like. It's the same
content but people are free to describe it in ways that are suitable
for their audience. I think it's maybe -- and as such it my be an
unfair burden to say, no, RDA, the editors and the writers of that
have to be cognizant of every end user possible right from the get-go.
And I think that's not really a driving principle behind the
development of the new Toolkit. Really the core is to get the
structure and the logic in place so -- and to create the ground work
for all of these efficiencies. And then subsequently when people
start writing application profiles and so on, that's where you will
see the simplification occurring.
>> Thank you, Thomas. I see a question here about offering RDA
training to a wider audience. We are going to recommend that you
contact RDA for that. I will have an e-mail I will post in the chat
so you can have some of the contact and thanks for that question.
Danielle asks, does the new RDA still require core
elements/requirements.
>> No and yes. In fact, when I did cover the core and coherent minimum,
I guess that's the equivalent of what's left of core. Another issue
of core, if you look carefully at the Toolkit, the core was -- it's
core because it's needed for an access point. That's all been redone.
So that need for core elements changed. Core is just defined by
whatever scheme you are using for constructing an access point. RDA's
job is not to tell people what is core in that context. And one other
category is requirements for an effective description and that puts
the burden on agencies to define what's core efficient or mandatory
for their usage. So the idea of core exists, but it wasn't needed
in one case for the access points, and just that coherent minimum
description that is in RDA effective description with what core
elements are needed that are up to agencies to decide that.

25. >> Thank you so much, Thomas. That's the end of the questions we have
so far. We will give people a moment here to make sure that they are
not trying to rush in any last questions. Was there anything else
you wanted to touch on? Any final thoughts you wanted to wrap up with?
>> Goodness. I hope everyone enjoyed these orientation sessions. I
know they can be -- the criticism I get is they are still high level
and so on. And there has been work or effort to be done to make
training more practical. I did participate in winter for the
pre-conference that was put on there. And the feedback from that was
that they were grateful to have very concrete examples to work through
and we are hoping to replicate that. Annual ways we are working on
next and that might be a good model to follow for any other training
as well.
>> Thank you so much. And thanks to all of you for all of your
questions. We appreciate you asking questions and trying to get
answers. Thank you for making this participatory session. All
right, with that, I think we can go ahead and close out. Thanks again,
Thomas. And we hope to see you all at another workshop soon. Bye,
Thomas.
>> Bye-bye.