New Concepts: Timespan and Place (Transcript)

1. ROUGH EDITED COPY
ALA-NEW CONCEPTS-TIMESPAN AND PLACE
AUGUST 14, 2019
CART CAPTIONING PROVIDED BY:
ALTERNATIVE COMMUNICATION SERVICES, LLC
www.CaptionFamily.com
* * * * *
This is being provided in a rough-draft format.
Communication Access Realtime Translation
(CART) is provided in order to facilitate
communication accessibility and may not be a
totally verbatim record of the proceedings
* * * * *
>> Hi, everyone, this is Colton with ALA
Publishing to do another sound check. Thanks to
those of you who have introduced yourself in the chat
space. If you haven't already, chime in. We'd love
to learn who you are and where you are, anything else
you would like to share. We'll be starting at noon
eastern. We'll do two more sound checks before we
get started. In between sound checks, there will be
only silence. Thank you.
>> Hi, everyone, this is Colton Ursiny with ALA
Publishing. We're about five minutes away from the
start of today's event. Thanks, everyone who's
introduced themselves in the chat space. We would
love to hear who you are, where review, anything else
you would like to share. We'll do one more sound
check before we get started at noon eastern and in
between sound checks there will be only silence.
Thank you.
>> Hi, everyone, this Colton Ursiny, coming on
to do the final sound check for today's workshop.
Feel free to introduce yourself or your group if you

2. haven't already. The chat space is on the right side
of your screen. We'll be starting in just under two
minutes so stay tuned. Thank you!
>> It's noon Eastern Time so we are going to go
ahead and get started. I'm Colton Ursiny with ALA
Publishing. I know a lot of you have been here for
other sessions in the series but for those who are
joining for the first time I'm going to cover some
brief information and then we'll get right to it.
You can use the chat area to interact with the
presenter and fellow attendees. You should see chat
on the right side of your screen. If you don't see
the chat window, click on the chat icon on the bottom
of the screen. Today's meeting is being live
captioned. You can view the captions in the
multimedia viewer in the lower right-hand side of
your screen. If you don't see that, we posted the
link to the caption site into the chat so you can click
on that. If you see an external site message in the
viewer or when viewing the site, click continue as
it is a safe site. If you have technical questions,
questions about audio or trouble using WebEx, we ask
that you private chat host. We'll help you
personally without interrupting the meeting. We
will have Q&A at the end of today's session. To ask
Bob questions, type the questions into the chat space
and make sure that your to box is set to all
participants. You can chat your questions at any
time and we'll keep track of them for Q&A. Please
keep in mind that we might not get to every single
question. If your audio breaks up or drops out
during the presentation, you can hang up or close your
audio broadcast window and click communicate at the
top of your screen or via the three dots icon at the
bottom menu row and selecting audio connection and
select I will call in or call using computer. If
you're listening through the audio broadcast and
notice an echo, make sure you don't have two broadcast
windows open simultaneously. If you do simply close
one. Please note the internet audio quality can be
affected by any number of factors. If you're having
trouble, try clicking disconnect and reconnecting.
We are record this presentation. Within a day you'll
receive an email which includes the full audio, video

3. and chat record.
ALA Publishing offers an array of word processor
and online courses throughout the year. You can view
additional learning opportunities on the ALA store.
We are thrilled to have Robert L. Maxwell for today's
session. Bob is the senior librarian where he has
chaired the special collections and formats catalogs
department. He's currently the liaison between the
LX Committee on Cataloging description and access
among numerous other accolades. With all that out
of the way, I'm going to turn things over to you, Bob.
>> Welcome, everybody to the webinar.
We'll be discussing two separate topics today,
timespan and place. I do want to review from a couple
of previous webinars some basic information about
RDA. Some time ago the RDA steering committee agreed
that RDA would be based on current international
cataloging models so the revised RDA, which is likely
to become official in 2020, is based on the new IFLA
Library Reference Model or LRM. Advent of LRM is the
main reason for the restructuring of RDA that's been
going on for a few years now. LRM is a consolidation
of these three documents, Functional Requirements
for -- FRAD, FRSAD, and now moving to the topic for
today, in FRBR/LRM, the bibliographic universe is
described as an entity-relationship model and this
is a diagram from LRM of the whole universe showing
all the LRM entities and all of the LRM relationships.
We will be considering two of these today,
timespan and place, up in the upper right-hand corner
of the diagram. As you can see, both has a very
general relationship to an entity called race. Race
means any of the entity so timespan and place can be
related to any entity.
So we've always dealt with time in cataloging.
There's a major difference between LRM and FRBR and
other earlier models and that is previously timespan
has been modeled as an attribute of other entities
but in LRM timespan is in relationship to other
entities.
Its definition in LRM is a temporal extent having
a beginning, an end and a duration. So pretty
typical definition. It can be identified by
specifications its beginning and end and it can be

4. expressed as a year, even though a particular event
took place during only a piece of the year.
It only has two attributes in LRM, beginning and
ending. We will see RDA defines a few more
attributes for timespan than LRM does.
So since timespan is a brand new entity, I think
we need to talk about how to find out about it it in
RDA. If you want to find out more about it, go to
the entities tab and click on timespan down at the
bottom.
The definition in RDA is identical to LRMs, a
temporal extent having a beginning, an end, and a
duration.
It can be any length. It can be just a second
or even a mil second, mesozoic era. And then we are
also told in the prerecording section of RDA for
timespan that it's to be described as atus recording
of metadata description set. What is a metadata
description set?
I realized I've talked about this in my previous
presentations but I wanted to go through it with you
again. I've also heard that some of you are worried
about this and I want to reassure you that although
I will be describing metadata description sets in
terms of linked data, if you think about it as I
explain, we have been doing and creating metadata
description sets all along. Our bibliographic and
authority records can be thought of as metadata
description sets. However, it's important that we
all have an understanding of how these might appear
in a linked data environment.
I'll be showing examples in upcoming slides
using metadata description sets in addition to
familiar mark records because some of the new
concepts can't be described using MARC. Linked data
is a term that means it's a system that links data
from different data sources on the web. And this
system as a name, it's called the resource
description framework or RDF, it's usually written
in a language called XML which is designed to be
edited by computers and is not to be displayed to
people. However, RDF triples are a translation of
the XML that is understandable to humans.
Linked data consists of series of triples, many

5. of which may be needed to describe a particular
entity.
So here's an example. An RDF triple is a
statement, it has a quasi language -- a person has
a subject, name, predicate and John is the example.
Back to the revised RDA. If you look into any of the
elements, there is a little tab at the beginning
called element reference and if you open it, you will
see the elements domain and in some cases its range.
In the middle of the slide, I've taken the
glossary definitions of domain and range. I know
many of us have said this over and over but I'm going
to repeat. The domain is the RDA entity that is
described by an element. So in this case, date of
birth is used to describe the person entity. And the
range is the RDA entity that is the value of the
relationship element, meaning we use a timespan to
describe date of birth, we make a relationship to the
timespan to describe date of birth for a person.
So in the RDA triple, we will use alternate label
to be the predicate. So here's an example. -- RDF
triple telling us something about the person Kathryn
Hepburn. The subject, predicate has a date of birth,
and the object or range of the timespan is May 12,
1907; which I gather there's more than one
possibility for that, but that's what we are going
to go with.
As an aside, this has nothing to do to do with
today's presentation but if you look further down in
the element reference, this is where in the 2020 RDA
you will be able to find the mapping from the RDA to
the MARC formats.
So just a reminder. Although I'm talking about
metadata description sets in terms of linked data and
RDF triples, the term metadata description sets also
describes the traditional cataloging units we call
MARC records. So when the RD -- legitimate to use
a MARC record but it is important that we understand
them in terms of linked data if we want to understand
what everybody else is talking about. The new
vocabulary that many of us -- I'm going to try to start
using, for example, an authority record for a person
could be considered a metadata description set. The
definition of RDA of metadata description set is one

6. or more metadata statements that describe and relate
individual instances of one or more RDA entities.
And a metadata statement in turn is a piece of
metadata that assigns a value to an RDA element that
describes an individual instance in an RDA entity.
On the first bullet point, the MARC authority
record that describes Kathryn Hepburn consists of
metadata statements that describe a person so it is
a metadata description set. As for the second bullet
point, within that authority record if you think
about what the authority record looks like, the 046
record -- namely for birth date to RDA element, namely
the date of birth element. So the 046 field contains
metadata statements. So I just want to -- I'm saying
all this to reassure you that we don't all have to
leap into a new way of doing things to follow RDA.
We've been doing metadata description sets all along
but there's a different way of looking at them that
we'll be looking at in this webinar.
So an RDF triple is an example of metadata
statement. A set of them turns into a metadata
description set. There are examples in the toolkit
which I have noted in the previous couple of webinars.
If you find an element that has a label at the very
bottom that says view in context example, it will
display a metadata description set consisting of RDF
triples. And there's an example under the
bibliographic information element, if you go to the
very bottom bibliographic information and you click
on viewing in context example, you will see this.
And we see a whole bunch of RDF triples. The subject
of all of them is person. The predicate is the italic
words. And then the object is the thing to the right.
So this person, for instance, has a date of birth.
1869. And that is a timespan. And she has a date
of death, 1943. That's another timespan. Those are
a couple of RDF triples and they all together make
a metadata description set. If you look through it,
you can see all the things that describe her by RDF
triples. One point I want to make here, the presence
or absence of elements in any of these examples does
not mean anything about whether they are required or
not required. For example, another possible element
could have been added to this one, this person's

7. authorized access point. So these examples are
merely exemplary, they are not saying what's required
to make a metadata description set.
But I bring it up because there are quite a few
of these examples already in the new RDA so if you
want to see some examples of metadata description
sets that are based on RDA, go have a look for these.
So back to timespan.
Do we use timespan in current cataloging?
And the answer is oh my goodness, do we ever.
What we don't generally do is describe the timespan
as a separate entity although there are exceptions
to that. Let's look at an authority record or
metadata description set. For Kathryn Hepburn,
there are several nomen strings in this record
representing timespan. In fact, it's stuffed full
of timespan elements representing things as diverse
as the day the authority record was created, which
is July 18, 1980. The exact moment the record was
last replaced, August 24, 2012 at 7:40:52:00 a.m.
having a precise timespan is important to the machine
for determining which record has priority. May 12,
is her birth date. We have another time span nomen
string. For June 29, 2003 in EDD format. We have
a timespan in the authorized access point
representing Hepburn's birth and death year. That
timespan happens to be composed of two separate
timespan elements, we have 1997 in 2003 and three
timespans representing days in more normal intended
for humans in this 670 field.
Have a look at that record. There's timespan
all over the place.
Here is an abbreviated bibliographic record on
which Kathryn Hepburn appears. We have several
nomen strings in this record to represent timespans.
Like the authority record, the bibliographic record
is also stuffed with timespan elements. When the
bibliographic was created and the second the record
was last replaced, as we saw on the authority record.
We have two other timespans in the fixed field. Code
134 in the time field stands for the length of film.
Additionally, 045 contains a nomen string which is
the date this historical film takes place, that's a
timespan. 046 encodes the date of the work, another

8. timespan. The first 264 subfield C contains the data
publication. The second 264 contains a copyright
date. 300 field contains the length of field in
another format. There's a couple of instances of
1968, 1969 in the notes. Dates of birth and death
for Henry the second and [Away from mic]. Periods
of division for Great Britain. A fast string
representing a time period. And finally, there's a
nomen string representing the last [Away from mic]
of Kathryn Hepburn. Look at all the timespans in the
little record. You might say these are descriptive
elements. Do we describe timespans themselves in
current cataloging?
And the answer is yes. If you remember, that 648
field in the previous slide, showing a bibliographic
record containing a FAST heading, that heading is
backed up by an authority record, in other words a
metadata description set for a timespan. And here
it is. But FAST isn't the only system describing
timespan. Here is a record for a timespan as a
subject heading straight out of LCHH and these aren't
just made for broad periods like the 20th Century or
Middle Ages. They're being used to create records
for decades.
And even single years.
Authority records are being created to represent
timespans in literature. Historical periods. And
many, many other things.
Additionally, records are being created for
subdivisions representing timespans that are not
connected to any particular place or literary genre
or any other subject heading. So the profession is
now creating and using descriptions of timespan in
formal MARC records. What RDA is now introducing it
into what we might call descriptive cataloging. And
provides us with a lot more elements or attributes
and relationships that we can now use to describe a
timespan.
So how do we create a description of a timespan
using RDA. First there are a few ground rules under
prerecording we describe an instance of a timespan
by recording a metadata description set. This could
be a MARC record but MARC does not yet have coding
for all the elements. So from here on out we'll be

9. using linked data metadata description sets.
Another of the ground rules is any element can
be repeated in RDA. And other recording methods can
be used but certain of the subelements only allow
limited methods.
So a description of a timespan does have a
minimum element to it.
It must record an appellation element as we
talked about in an earlier webinar, the webinar
that -- it has to have a name of a timespan or a
preferred name or access point for the timespan or
an authorized access point for the timespan or
indentifier of a timespan. Any of those qualifies
as an appellation element but one of them must be in
the records. In terms of MARC that means there
probably needs to be a minimum of 1XX field with the
name of the timespan in it.
We also learned that if we're using Greg
Gregorian -- dates span both DC and AD. That's
exactly the same rule we have been using. And yes,
RDA still does use AD and BC, but I believe agencies
can use other designations if they choose. This is
would be an appellation profile question.
So going back to our FAST example, the preferred
name of this timespan is 1154-1189. This is the name
selected for preference in a specific application or
context. That's the definition of preferred name.
And then this context is FAST.
Technically speaking this string is recorded as
a value of a nomen entity. It's a nomen string. And
the preferred name is recorded as an unstructured
description. So thestician for a minimum
description. We might want more in our description.
We might want an authorized access point for the
timespan.
So the authorized access point for a timespan is
an access point selected for preference in a specific
vocabulary encoding scheme.
It is based on the preferred name of the timespan
and we've already seen in this case that's 1154-1189.
In the FAST vocabulary encoding scheme, the
authorized access point for a timespan is recorded
as a structured description, although, as we can see
here, this sometimes turns out to be exactly the same

10. string as what was recorded for the preferred name,
which was technically speaking, unstructured.
You can add additional elements to distinguish
this access point from the access point for another
entity or to assist in the identification of the
entity or to follow the rules of a string encoding
scheme. Here, we will add no additional elements.
Why do we need an authorized access point?
In FAST, as in other schemes, the authorized
access point is used to link together all entities
that are related to this particular instance of a
timespan.
So it's a linking device.
So is there anything else we might want in this
description of this particular timespan?
Are there, for example, variants?
In this case, there is one. And there is an
available RDA element, surprisingly, called variant
access point for timespan.
So the variant access point for timespan is an
access point not selected as the authorized access
point within a particular vocabulary encoding
scheme, and there is one in the past record, and that
is Henry II, reign of Great Britain, so we can add
that to our metadata description set.
Variant access points for timespan could be
quite useful for bringing together various
calendars. For example, in a database that
preferred the Gregorian form -- equivalent dates from
other calendars could be recorded as variant access
points. Here at the top we have the date for the
beginning of the Russian Revolution, also known as
the October revolution except in the Gregorian
calendar it began in November, November 7, 1917.
The variant nomen string represents the same day as
October 25, 1917 in the Julian calendar which was
still in use in Russia at the time. In addition to
the TV it would be appropriate to include that as a
variant access point. Here following the
instructions I have added a question of lawer to
distinguish this from the otherwise identical one
which would represent a different day in the
Gregorian calendar. Or as the second example, the
date of -- the Hebrew calendar might appropriately

11. be given as a variant access point.
I added a qualifier here, representing a
different timespan to assist in the identification
of the entity, one of the conditions for adding a
qualifier to a variant access point for a timespan.
By the way, RDA does not prescribe the form of
the date. I am imagining from my examples, at least
these two, an application profile that calls for the
gre Gorn form as the preferred name and the access
point be day, month, year.
So we've looked at ways to name timespans. Here
are some other elements that could be used to describe
timespans.
Beginning, category of timespan, ending, and
note on timespan.
If you look at these elements in RDA, what they
share in common is they have no range, which means
they can be used to describe timespan but they do not
point to another entity.
Category of timespan let's consider that first.
Its definition is a type to which a timespan belongs.
It can be recorded using any of the recording methods.
If the method is structured, then it is to come from
a vocabulary encoding scheme. Currently there is no
vocabulary encoding scheme that I know of for this
element. But the RFC is considering adding a VES for
what they are calling Caldrical vocabulary. Up to
century. The terms shown on this slide do not come
from any vocabulary encoding scheme, I made them up
myself, but they are all possible terms to describe
a category of timespan.
So if we want to apply that, here's some
examples. 7, November, 1917, I decided its category
was day.
The second one, Jurassic period, category of
timespan is geological era, according to my
vocabulary encoding scheme I made up.
Two related elements are beginning and ending
and the definition and scope are about the same,
beginning says the time at which the timespan starts.
Ending says time at which a timespan ends.
As I mentioned in the couple of slides ago, these
elements have no range. In my opinion, there is no
reason they couldn't have a range of timespan.

12. Thereby allowing a timespan to be related to another
timespan as its beginning or ending. This is
something for the RDA developers to think about. I
realize the reason it doesn't now is the LRM think
it would be a good idea to allow a timespan to be
related to another timespan as a beginning or ending.
Here is an example. That Jurassic period
timespan, I gave it a variant access point to a
1.3 billion BC to 145 million BC. It has a
beginning, it has an ending. There is another
element called note on timespan and its definition
is a broad, unstructured description of one or more
attributes of a timespan. I thought I could make up
a note on timespan for the example just by describing
what it was.
[Reading.] that would be an example of a possible
note on a timespan and there are many other things
you could make notes about.
So timespan, as we saw in the LRM diagram, can
be related to any element, including itself.
There are dozens and probably dozens and dozens
of specific relationship developments that are
available. Copyright date, date of birth, date of
capture, date of death, date of work, duration, part
of timespan, period of activity of person, related
corporate body of timespan, timespan described in
year degree. These are all examples of
relationships between one RDA entity and a timespan.
I've made up a little very simple cluster of
metadata description sets that might demonstrate
this. We have Judy Garland. She has a date of birth
and a date of death and what's display in the metadata
description set for Judy Garland is actually a
reflection of what is in the record for the timespan
for each of these two elements and they just link to
each other in this way. And by the way, we are not
going into this in this presentation, we are not going
to get this involved, but the name of timespan in the
timespan element itself is a reflection of the nomen
string in the corresponding nomen entity instance.
But we are not going to show that here, you will
be happy to know.
So we've started in this example with a record
for a person pointing to some timespans, conversely

13. we could start out with the metadata description set
for a timespan and jump back to other related
entities.
So here we have the same relationship between
Judy Garland and this timespan for date of death but
that particular timespan also relates to the date of
birth to this Douglas Mitchell who is a football
player and Derrick Russell who is a heavy metal artist
and also the date of establishment of a corporate
body. So I can see a lot of potential for exploration
within the database using metadata description sets
for timespan.
Now, using timespan as a linking device is not
a novelty, though it may seem so in a library
database. Here is an example of a database,
Wikipedia that appears to link all persons born in
1942. The fact that this database offers this
functionality shows users are interested in this sort
of linking, presumably library database users would
also be interested in this sort of linking.
Here's another example of a database. IMDb,
that seems to be doing the same thing using something
like a timespan entity to link all persons born in
1922.
I'm showing you these to say that this does seem
to be something that database users are beginning to
be interested in and actually perhaps will be
expecting the databases one of these days.
Just a reminder, timespan may be given as a range
of element. In this case, date of birth, domain is
person, it can be used to describe a person, and the
range is timespan, meaning that it can only be related
to an instance of the timespan entity.
The expectation of the domain and range is that
there will be descriptions at either end. In this
case a relationship between an instance of person and
an instance of a timespan. This implies to me that
RDA expects us to begin creating descriptions or
metadata description sets to fully take advantage of
this new entity.
So can I do it in MARC?
Not quite yet. We can't yet create an authority
record in the authority file for a timespan.
Although in many ways that's mostly kind of a policy

14. question, as we'll see in the upcoming slides. But
RDA does conceive of times with a timespan of entity
with relationship to other entities so we need to
think about it. And I've noted we already do record
timespan in subject cataloging.
The framework is partially there already and
already being used in the FAST authority records. So
the authorized access point for timespan for RDA can
be recorded in the MARC 148 field. 548 can be used
as a relationship between an instance of an RDA
timespan entity.
For the descriptive elements, some development
is needed. We do need a place to record beginning
and ending unless it could be considered a
relationship, as I mentioned earlier. And that
would happen by RDA defining its range as a timespan
instead of having no range at all. In which case,
beginning and ending could be recorded in 548 along
with a relationship label beginning or ending.
368 could be refined, perhaps renaming it other
attributes of entity rather than other attributes of
person or corporate body. And defining a new
subfield for category or type of timespan.
And there are numerous available note fields for
the note on timespan.
So I think we could fairly easily implement the
timespan entity if we wanted to with minimal
tinkering with MARC even before we go on to some other
system.
So okay. I can take a few questions or comments
right now before we go on to place. I think we have
time to do that if that's okay with the moderators.
>> MODERATOR: Yeah, absolutely. We do have a
few questions in. Our first question is if my
timespan is a certain day, could the variant access
points be EG, something like date of birth of person
A, date of birth of person B, date of event X?
I think this is what I find confusing.
>> I suppose you could do that. RDA doesn't
say what the variants can be or don't have to be. I
believe that's better treated as a relationship.
Let's go back to the Judy Garland example.
So Judy Garland, the person, I've forgotten how
to make a pointer here.

15. Never mind. So look at the metadata description
set at the upper left for the person Judy Garland.
She has a date of birth. A date of death here, that
relates to a timespan description for that day. I
suppose we could put in variants that say date of
death of Judy Garland if we want to, but I think better
is to link it with a relationship link, as you see
on this example. So the timespan 1969, 06, 22. Is
the date of death of Judy Garland. I would say that
would be a better way of handling it than making all
sorts of variant access points for various things
that happened on that date, although I am not sure
that RDA would forbid that.
>> MODERATOR: Thanks, Bob. We have another
example question. So what if 1154 to 1189 is also
the lifespan of a Chinese poet, for example, not just
the reign of Henry II. Do we need two authority
records with qualifier differentiate?
>> I don't know. This will all depend on how
we put all this into practice. In my opinion, it's
the same timespan and so I would think that we
wouldn't need to have different records, different
metadata description sets for different timespans
that are the same just simply because one is
somebody's date of birth and death and the other one
is period. I would say probably not. In my opinion,
ever since I have been thinking about relationship
structures, the whole beauty is you can use one
description set over and over to describe or make
relationships to many, many other entities. So I
think in my opinion, the best thing would be to reuse
the timespan that FAST timespan description for
example, for whatever it is appropriate to use it for.
So I admit, I don't know what FAST was thinking
when it made that record, but the mention of Henry
as part of the variant access point does imply that
it seems to be for a particular purpose but I don't
see any reason why it couldn't be used for another
purpose.
>> MODERATOR: All right. Thank you. I see
some discussion in chat, and I'll go to a question
which is: How will RDA accommodate relationships to
approximate or uncertain timespans?
>> I would expect it would be -- well, I think

16. you would make a timespan entity and the category
would be approximate date, approximate. That could
be a category, approximations. So I would say I'm
not sure that RDA needs to do anything more than it
already has done to accommodate that sort of
relationship. But again, none of us has done this
yet, so I don't know for sure. My thinking right now
is that you could make an approximate timespan, just
as we do now, saying let's say approximately 1555 as
the name of the timespan and then the category could
be year and then it could have a second category of
approximate timespan or something like that.
I'm not sure that the model needs to be changed
at all to accommodate approximate dates.
>> MODERATOR: Thank you, Bob. I think that's
all the questions we have so far. So feel free to
continue. And if anyone has any other questions,
feel free to type them and we'll save them for the
end.
So on to place.
Place is something that we have been doing for
a long time as an entity.
But like timespan, there is a rather large
difference in LRM and the FRBR models for place. It
was previously modeled in most cases as an attribute
of other entities although it also had been modeled
as an entity on its own, which was a little confusing,
in my opinion, in the model itself. In FRBR, places
are treated as entities only to the extent that they
are subject of the work. So otherwise, elsewhere in
FRBR they were treated as an attribute instead of as
an entity on its own. LRM on the other hand
emphasizes place as a separate entity that has
relationships to other entities.
Following the path of LRM, the 2020 RDA gives us
more opportunity and encouragement to conceive of
place as an entity rather than simply as an attribute
of some other entity.
For example, place of publication. All four
recording methods are available and are legitimate
for recording places publication.
Here we have a place of publication. If you can
see, this is the first edition of Alice in Wonderland,
one of my favorite books, place of publication is

17. given on the title page as London. So our practice
up to now would be to give an unstructured description
and simply copy down the word London, but RDA permits
us also to record this element as a structured
description which would be London England if we're
following the vocabulary encoding scheme of the
authority file. Or we can record it as an
indentifier or we can record it as an IRI, which we
do will depend on application for files of the agency
that we're cataloging for. For example, possibly
the DCC. As I mentioned, unstructured is the
traditional recording method and it is excellent for
identifying and representing exactly what's on the
manifestation but it isn't very good for bringing
together other instances of resources published in
London. Structured descriptions, identifiers and
IRIs all excel at that and these last three emphasize
the relationship between the manifestation and the
place of publication.
To 20 RDA's emphasis is further brought out by
further element reference related to the place. The
place has a domain, it is manifestation, meaning that
it can be used as an element to describe a
manifestation. And it has a range, place, meaning
that the metadata statement is expected to point to
a description of a place, at least in linked data
applications. Of course the object of an RDF triple
can be expressed as something called an unstructured
literal, but that doesn't seem to be the preferred
method in linked data.
I want to talk for a few slides about what I'm
calling the place problem. In Anglo American
cataloging description we have used the same
description for two things that are really different.
The geographic area of place and the jurisdiction
governing that area.
This causes significant problems and confusion.
Not only about MARC but MARC coding difficulties are
exemplary of the underlying problem, which the
problem is we're using the same description to
represent two different entities. So the question
for MARC is do we use X5 or X51?
A book about Provo, Utah, the place, is coded in
651. A book about Provo, Utah the city government

18. is also coded in 61. But a book containing city
ordinances of Provo is coded in 110. And a book about
the subdivision of the government is coded in 610,
even though it starts with Provo Utah's.
So I'm just bringing up the MARC problems as
exemplary of the basic problem we're using to -- we're
using one description to describe two different
entities.
This also relates to the problem of we put it it
in the name or subject authority file?
It's all related.
This problem is not solved in the 2020 RDA. So
we are not going to linger on it. But it's important
to think carefully about it because it is problem
underlies many of the difficulties we get into when
dealing with place.
The instructions in the 2020 RDA still envision
using the same descriptions to represent the
jurisdiction of physical place. As an example of
that, under pre--- told name of place may be used as
a value of corporate body, name of corporate body,
for a government or community. In my opinion, more
work is needed. Are jurisdictions more like
corporate bodies?
Should they be described as corporate bodies
rather than the place of entity?
I have been informed that the RFC is aware of and
further work is forthcoming. Leaving that aside, we
record the place entity all the time in our
cataloging.
Of course, we record places in authority records
that describe places as here. But note that even
within this authority record or metadata description
set, there are a number of places where places have
been recorded. The 043 field gives a structured
description for California. The 151, the 370, there
are two places there. All of these would be
structured descriptions and we also find
unstructured descriptions in the 670 field.
Here is place in a MARC metadata description set
for a person. There are some structured
descriptions in 370 and some unstructured
descriptions in 670.
Maybe I should say structured strings and

19. unstructured strings rather than descriptions here.
Here is an abbreviated bibliographic record,
that same record we looked at before on which Kathryn
Hepburn appears. There are several nomen strings in
this record that record places. The code and the fix
field is a structured description of the place of
publication. The codes in 043 are structured
strings for places that the film is about. In 257
we find a structured string for a place that is the
place of the production company. Subfield A of 264
contains an unstructured string for the place of
publication. The GLC subheadings contain places.
I guess I've edited this slide. The FAST headings
also contain place names.
Note that a place name is even part of the
authorized access points of the persons named, Henry
and Eleanor. There are certainly other places that
could have been recorded in this record. For
example, the place of the production or filming. I
think we can say that place is quite important to our
catalog records.
So I am not going to go into all the ins and outs
of describing places using the 2020 RDA. Places are
quite complex and they aren't going to get any less
so. I intend in the next few slides only to go
through some of the basics to help you read and
interpret the new RDA language.
Place is defined as a given extent of space.
This is identical to the glossary definition of place
in the current RDA. So there's no change here. Note
as usual we are told to describe an instance of a place
by recording a metadata description set. We've
talked about these already today.
Several times.
RDA does have a minimum requirement for the
description of place. It must contain at least one
of the appellation elements listed here.
In a NACO authority record for place, a metadata
description set, this would translate to it has to
have at least an -- in a 1XX field. To reiterate,
depending on the circumstances, any of the four
recording methods is possible.
Now, there are some clear improvements in the
2020 RDA with regard to place. And the first of these

20. is the separation of preferred name from authorized
access point. So preferred name of place is a name
of place that is selected for preference in a specific
application or context. And it's recorded using a
value of the name and place, name of place is an
unstructured description and is simply recorded with
no additions. And I contrast with the current RDA
as well as the ARC2 in which the preferred name
included that qualifier that we are used to adding
but it does not in the new RDA.
So the name of place element is as found on this
manifestation is simply Paris.
Same familiar conditions apply as existing in
the current RDA for choosing name of place. The RDA
gives instructions for choosing between different
forms and the options sound quite familiar. Choose
the preferred name by consulting gazetteers
and -- choose the one that is in general use or that
appears most frequently in sources in the language
preferred by the agency. In other words the bedrock
principle which has been in cataloging forever is
here to remains. We choose the name most likely to
be known by users of the database as the preferred
name.
So here are a whole bunch of possible names that
I found for Paris. And the winner is Paris. Not any
of those others for the preferred name, following the
instructions. But unlike the current RDA I'm going
to repeat, the preferred name is not Paris
parentheses France. For that we need to go to
instructions for authorized access point.
So we start with the preferred name. If you go
to authorized access point for place and scroll down,
you will find a section called basis for authorized
access point of place and it says exclude the
value -- picked that preferred name, it is Paris.
Next we are told in the instructions for the
element authorized access point for place to add
additional elements. The intent is to -- well, I
don't know whose intent it was. We wind up with at
least one result is the same result as current RDA
at least as an option but we are using a different
route. Rather than manipulating the name while
choosing the preferred name, which violates the

21. principle of representation, we are going to
manipulate string as we create the authorized access
point. And this is quite important. I think this
is a change that's happened throughout RDA and it's
the same with the names of person and any entity. We
start by choosing the preferred name and recording
it exactly as we find it and then we only start
manipulating it when we get to the authorized point
rules.
So clicking on the link under authorized access
point for place, the option in the first box, you can
see there, takes us actually to a different element
to access point for place. Do not be confused by
this. This is simply because this particular option
applies to all kinds of access points for place, not
just the authorized access point. Adam Baren
described this last week in his webinar on access
points. Instructions that apply to a lot of narrower
elements are only given in the broader element.
Going on to the element access point for place and
the section on conditions, there is a condition that
says a place is located in a larger place or belongs
to a larger jurisdiction. Paris both is located in
a larger place and belongs to a larger jurisdiction.
So this first condition applies to Paris. We are
instructed to add the access point for the larger
place or jurisdiction. But there is one more detail
to take account of before we do that.
Let me go back to the element for authorized
access point for place. In reading through the
conditions for adding elements and we come to a
condition that says the place is in a larger place
or belongs to a larger jurisdiction, as we already
figured that out for Paris, but also this place, IE,
the larger jurisdiction, is not a state, et cetera,
in Australia, Canada, U.S. -- Scotland or Wales.
The new RDA didn't solve anything about the
complexity of the current rules in RDA. This is
actually nothing new. I'm just pointing out this
condition does apply to Paris. So we are to record
the authorized access point for the larger
jurisdiction which is France.
But how do we get the parentheses around the
qualifier like we expect?

22. Before we proceed, I need to state that the 2020
RDA remains a work in progress. That's why people
are still referring to it as the beta RDA and there
continue to be some issues. Adam Baren pointed out
last week that there is no prescribed punctuation in
the 2020 RDA for the access points. He added the
periods and so forth following traditional patterns.
So we might not expect any instructions for enclosing
France in parentheses or any other punctuation.
Punctuation for qualifiers for corporate body is a
similar case in the new RDA. Unless I missed
something, there are no instructions there for
enclosing corporate body qualifiers in parentheses
other than their appearance in a few examples.
Unusually, however, there are instructions for
punctuation of authorized access points for places.
So if we continue to scroll down a bit, we come
to what may seem a peculiar set of options. Although
they only say peculiar because we are not used to
seeing this sort of thing before. The first option
says it is to be used as a pattern for a government
or community. So that would be Paris. The
punctuation pattern says value 1 comma value 2 comma
... So value one in this case is Paris, then we're
told to put in a comma.
Then we put in value 2, which is France.
Paris is indeed a government or community, but
this is not the result that we expect from past
practice.
The second option is the pattern for all other
cases. It's not as clear to me that this would apply
to Paris but the punctuation pattern is value one,
Paris, opening printing, value -- authorized access
point we are familiar with. I have to admit, I don't
know what to make of this, perhaps 2020 RDA is
obliquely -- versus other places. I do think some
clarification is necessary here. I've communicated
the [Away from mic] RFC -- encoding schemes
throughout RDA possibly making it clear that they
will depend on community application profiles. And
moreover, those of you who attended Gordon Dunsire's
webinar day before yesterday on application profiles
will have seen a slide showing this very same section
with the label under construction. And I believe I'm

23. now quoting him correctly when he said don't pay too
much attention to this just now. Let's try not to
get tied into too many knots over this particular
issue. I assume many application profiles including
PCCs will say to use an option similar to what we're
doing now. Including those of jurisdictions. Stay
tuned.
So let's leave aside punctuation for the moment
and go back to one other issue here. Remember that
a few slides back under the access point for place,
we were instructed to include a value of access point
for a place. We have seen how this applies to Paris.
This slide shows the option which should be familiar
to all of us who have been cataloging any amount of
time, including way back, dealing with the exceptions
we have been used to for Australia Canada,
United States and so forth. We are instructed if the
place is in one of the places, we are to treat the
state, province -- not go all the way to the top.
Wind up with Provo Utah and not Provo United States
or Provo Utah United States. This follows current
practice. Note this -- this instruction is labeled
as an option. So I believe that communities could
choose to follow other practices, for example, to use
a lower jurisdiction for a place in China as an
example, even though China is not listed here, rather
than qualify all the places in that huge country with
the top level China. This does not represent a
change from current RDA.
The same confusing string punctuation patterns
apply for something of RDA -- we are not going to
discuss it here again but we are going to discuss
another difficulty and that is the abbreviations in
the 2020 version of RDA. The element access point
for place does mention the abbreviations list under
recording. And it says for abbreviations for the
names of certain countries and states, provinces,
territories, et cetera, of Australia, Canada and the
United States, see abbreviation symbols, names of
countries and so forth. And if we click through it,
you find yourself at the familiar abbreviations list.
However, that is the last time these abbreviations
are mentioned in the instructions dealing with the
place entity. As far as I can find, there are no

24. instructions or options anywhere except one place I
will show you that actually allow us to use the
abbreviations list so someone new to the RDA can be
forgiven for why this list is even there. I would
like to state that I have no -- I agree that this would
be disruptive but the use of abbreviations list is
confusing to novice catalogers and library users
alike. How many U.S. catalog users know what ACT or
NSW stand for.
So if RFC would like to take the opportunity to
get rid of them now would be a good time to do what
we have been talking about for years. But the RSC
stated intent of -- avoid major disruption in
practice as a result of the new presentation of the
instructions. So some options are clarifications do
need to be added to use the abbreviations of
the -- wish to continue to use them.
There's a small clue in the section on
abbreviations in symbols that the intent of 2020 RDA
is to at least allow the continuation of current
practice of abbreviation within qualifiers to place
names. In the resources section on abbreviations
and symbols, under names of many agents and places,
we are here today to use only the following
abbreviations. Certain names of larger places
recorded as components of access points. And those
certain names are the names in the list shown on the
previous slide. This is not really an instruction
any more than the equivalent in the current RDA is
an instruction. In current RDA we are specifically
told to use the abbreviations in the instructions for
the specific elements where they come into play.
Further, this is an odd place to look for this
information and it's unlikely to be obvious to
somebody who doesn't know the practice. But the
hints are there, confirming RSF's intent was not to
disrupt current practices for communities that wish
to -- this is something that RSC will be looking at.
So what about the abbreviations?
Again, I personally have no problem with the
spelled out form and the painthetical qualifier, in
fact I would favor going forward with that but I don't
think requiring it was the intent. I fully
anticipate that this will be taken care of by the time

25. the beta version becomes official. So stay tuned.
Perhaps the solution is just not to attempt for RDA
not to attempt to spell out string patterns or
abbreviation practices in RDA itself, leaving it to
communities to decide how to punctuate and whether
to use the abbreviations or not.
Meanwhile, I kind of like Los Angeles with
California spelled out.
But I'm pretty sure we will [Away from mic]. So
what else do we do in places?
We can have variant access points for places.
2020 RDA does have an element for variant access
points for place. There are other descriptive
elements for place. Category of place, location and
note on place.
We can use an unstructured description for
category of place or use a structured description
following a vocabulary encoding scheme. Here are
examples from the AAT vocabulary encoding scheme.
LCSH is another good place to go for category of place
terms to use. And back in our metadata description
set for Los Angeles, we do have two examples of
category and place recorded in 368 fields, one from
LCSH and one from AAP.
The location element interestingly, this
element can only be described using a structured
description.
So here are three different instances of the
location element being used to describe Los Angeles.
One from N [Away from mic] another from the MARC
vocabulary encoding scheme in 043, and another from
the LC neighboring oh authority file vocabulary
encoding scheme. These are examples of the location
element. Looking at the 034, a few of you might
wonder why I said it was location and not coordinates
of cartographic content. Looking at the range, we
see the domain is work. The description of Los
Angeles is a place, not a work. So within the domain
of Los Angeles the coordinates of cartographic
content element are not appropriate.
They presumably would be used to record the
coordinates of a cartographic work such as a map.
So there are lots of available relationships to
place. These are just a few. We can look them over.

26. You can all look them over while we pause here a
second. The last three are very general and they are
just examples of other similar ones. There are about
a dozen of these that just say related something of
place. They show that the most general level, place
can be related to almost any entity.
So if we do this right, we can cluster everything
that's related to the place Los Angeles, particularly
if we record places using structured descriptions,
identifiers or IRIs, which allow different entities
to be linked together more easily. We can see we
could have a record for the place Los Angeles and it
could be linked to this person, that's place of birth,
manifestation, place of publication of that
manifestation, place of capture, place of death of
Marilyn Monroe. This clustering of the metadata
description sets using entities and relationships is
one of the real beauties of really implementing RDA
as I think it was intended, as a entity-relationship
database structure because it really allows people
to explore by going from one thing to the next and
finding things they wouldn't have thought of before.
With that, I am done saying everything I wanted
to say about place today. If there's questions or
comments we can talk about it.
>> MODERATOR: We have got about 15 minutes left
for Q&A. Feel free to ask any questions you may have.
A question in the chat, currently we record
California and here they're using the abbreviated
California. If it is seen that way on the resource,
but from 2020 on we would spell it out?
>> The preferred name is going to be spelled out
if you choose that as the preferred name. The
abbreviations are -- if we are recording a form, we
would only record an abbreviation if that's the form
we actually find on the manifestation. If we find
California spelled out on the manifestation, that's
how we will record it. With the question about
choosing the preferred name, I don't have the
question in front of me. Can you say that again so
I can see what the gift was?
>> MODERATOR: Yeah, it's currently we record
California and here you're using CALIF period. If
it is seen that way on the resource.

27. >> If you see that on the resource, that's what
you would record.
Was there more to the question than that?
>> MODERATOR: No, they were asking if they
would spell it out or not.
>> We would never take an abbreviation and say
that must mean California and spell it out and that's
how we record it. If we are talking about
transcribing a recording. The question about the
abbreviations comes up with what we are going to be
using in the qualifier and that will be a matter of
the application profile.
>> MODERATOR: Thank you so much, Bob. I'm not
seeing any other questions at the moment. We'll give
people a minute to type in any questions they may
have. And while we do, I want to remind everyone that
we have been recording and that within a day you'll
receive a follow-up email with a link to the archive
and slides. Bob, while we wait for any questions
that come in, I want to make sure there wasn't
anything else you wanted to touch on?
>> No. I hope I've conveyed I am never going
to say there are no problems with the language of RDA
or things that need to be worked out but I am quite
enthusiastic about the directions that RDA is taking
and I hope we will be able to really use it to its
full potential when we actually get it implemented
fully.
>> MODERATOR: All right. Thank you so much,
Bob. I'm still not seeing other questions so I think
we can go ahead and wrap things up. Thank you so
much, Bob, for the great presentation. Thanks, all
you of you, we're happy to have you here and thanks
for the great discussion in the chat and we hope you
all have a wonderful rest of your week. Take care!