Karen Coyle recently pointed to a paper by Allen Renear and Yunseon Choi [pdf] in which they claim that inheritance is a poor way of describing the hierarchy in Group 1 FRBR entities. Renear/Choi mistakenly claim that the work entity is a model of an abstract thing and therefore work entities have some kind of “is-abstract” attribute. There is no thing like an “is-abstract” attribute for works. Rather the attributes of a works, expressions, manifestations and items are the pieces of bibliographic description such as “title”, “uniform title”, “copy number”, “call number” etc…

Karen Coyle has is right and Renear/Choi are confused in there concept of FRBR Group 1 entities. Coyle states, “I tend to consider all aspects of metadata to be abstract in nature, since it is a representation of something else.” Renear/Choi state

The argument is simple: FRBR describes works as abstract and items as concrete. If all properties of “higher” entities are inherited by “lower” entities then items inherit the property of being abstract, and therefore items will be both abstract and concrete. But nothing is both abstract and concrete – therefore there is no unlimited general property inheritance in FRBR.

They mistakenly seem to think that because works model something abstract that the model has some kind of “is-abstract” attribute or property while items, which model concrete things have an attribute on par with “is-concrete”.

There is no “is-abstract” attribute for works, expressions or manifestations and there is no “is-concrete” attribute for items. The attributes of an item might be things like “copy number” or “location code.” The attributes of works might include a unique identifier that serves as a reference to collocate related expressions. However, that ID is still a concrete thing (likely an integer, see below). Or a work might have an attribute like “uniform title”. Expressions might add an attribute like “transcribed title” or “language”. Manifestations … well, you get the point. (See, for example, page 32 of the FRBR document.)

There is nothing abstract about an implementation of FRBR. Even if the Work was represented as nothing more than an arbitrary identifier in a system, it is still a concrete thing. Works may be no more concrete than integers, but it is important to remember that in a modern system integers are the thread that binds together the cloth of the fabric of content in a RDBMS. The work entity is simply the thread that binds together the more substantial entities one level down: the cloth-like expressions.

The hierarchy of the inherritance relationship still works because there is no logical conflict between any attributes of a work and any of an item. Renear/Choi come close to acknowledging this in their paper:

It may be objected that this argument is sound but irrelevant as the only properties ever at issue were the attributes (or attribute values, or attribute/value pairs) explicitly specified in FRBR. So for the work entity the only relevant properties are ones such as title, form, context, and so on; but not the property of being abstract. On this account only specified attributes (and/or attribute values) are inherited and the argument given does not apply as “abstract” and “concrete” are neither attributes nor attribute pairs. We believe that even this limited version of inheritance is misconceived, but before presenting our arguments against it we explore it further.

But what I think they miss is that works do not have a property of abstraction at all. I am not sure that Romeo and Julliet the work has any property of abstractness. As Meriam Webster points out “the word poem is concrete, poetry is abstract.” However, investigating the properties of poetry (being the productions of a poet, being poetic) we do not find a property corresponding to abstractness. It is the same with FRBR entities. “A work is an abstract entity” (FRBR document), but that does not mean that Romeo and Julliet the work has the property of abstractness.

Is this moot anyway?

The conflict they raise may actually be desirable. I think there is a bit of a tension between a theoretical model here and a practical model. I live in a practical realm and think about ways to implement a FRBR-based application. In the practical world there is at least one important solution to the conflict of interest that Renear/Choi raise: overriding an attribute (or behavior).

Take a programming language like Java as an example. In Java it is possible to override the behavior or attributes of an inherrited class in a subclass. In implementing a system and working in one of the prominent object-oriented programming languages you might be able to define works as abstract and items as concrete. This could then have useful implications in the display of items in your collection. A user interface could browse works and items differently. When just looking at lists of items you see things that you do not when merely taking a look at the work-view of a bibliographic entity (such as a shelf location).

No tags