Identifiers and Display Labels again

An RDA-L post, more yet again on a topic I’ve been circling for some time, after Ed Jones usefully approaches it too.

Ed Jones wrote:

On a related question, as long as this collocating function is satisfied, I don’t know that it matters anymore whether a name is unique in its display form.

Yeah, this is something I’ve been talking about for a while too and trying to get people to think about.

If the collocating function is satisfied, then we can group works and show related works without any ambiguity, EVEN IF we have no unique display form. Now, it might result in a confusing display.

Ed Jones

• Work 1
• Work 2
• Work 3

Ed Jones

• Work A

Two different Ed Joneses, correctly grouped seperately, but both showing up as “Ed Jones”. So it might be going too far to say “it doesn’t matter”. It matters to some extent. We might prefer to have a display title that can disambiguate. On the other hand, we might not need one. Maybe the above display is sufficient. Maybe the works listed under each Ed Jones alone is enough to tell the user which is which! (A birth date isn’t neccesarily what the user needs). Maybe a calculation of most common LCSH strings assigned to Ed Jones(1)’s work would be helpful.

But regardless of how important you think display uniqueness is, or how you think it’s best accomplished, the important point is this: If we can just get collocation uniqueness (which we could call ‘identifier uniqueness’ too), is that better than nothing? Yeah it is! A lot better than nothing. Display uniqueness may just be icing on the cake.

This gets at the concepts I’ve been harping on for a while of conceptually separating the ideas of identifiers and display labels, because it makes it easier to think and talk about what we’re doing. Thanks Ed for explaining it very nicely.

(See my previous posts, The Purpose of Authority Control, Access Points as Identifiers, and
Two Meanings of ‘Identifier’)

Our current AACR2 headings serve both purposes. They serve the “identifier” purpose when they provide for collocation–but as Ed Notes this function could instead be served by a ‘dumb’ identifier. And they serve the “display label” purpose when they are used, well, as a display label—and this display label purpose could be served by something that is not unique, but could not be served by by a ‘dumb’ (say strictly numeric, like OCLC num; or a URI) identifier. Two different purposes.

One reason this matters regardless of how we change our own systems of control is that we will increasingly be interfacing with other people’s systems that DO separate these functions, or maybe provide only one but not both of them. To get these things to mesh with our systems, we’ve got to understand that they are two seperate functions. But I do think our systems of control can usefully be improved by separating these purposes to some extent too.

I keep meaning to write more about how the FRAD document totally misses the boat on this, but keep running into writer’s block. It’s unfortunate, because FRAD is the right place to try to get these things straight conceptually, but it totally confuses them instead.

 (The collocating function will be satisfied if its underlying identifier is unique.) In some ways, simply using an unadorned name in the display–even if this results in a series of
identical unadorned names–frees the catalog search engine for more interesting manipulations. At present, selecting my “John Smith” from pages and pages of the same name arranged and differentiated by birth year–not particularly useful–is a time-consuming task that will ultimately defeat me. If I can select my “John Smith” on a variety of useful criteria that I may be more likely to know–prolific author,
nationality, profession, affiliation–I can quickly reduce the mountain of “John Smiths” to a manageable few. And these useful differentiating criteria may have been added to the authority record from a variety of data sources.

Ed Jones
National University (San Diego, Calif.)