Building RDA using the FRBR Library Reference Model

Transcription

1 Submitted on: RDA in the Wider World Date: 11 August 2016 Location: OCLC, Dublin, OH, USA Co-Sponsor: Committee of Principals/Joint Steering Committee for Development of RDA Building RDA using the FRBR Library Reference Model Pat Riva Collection Services, Concordia University Library, Montreal, Quebec, Canada. address: Copyright 2016 by Pat Riva. This work is made available under the terms of the Creative Commons Attribution 4.0 International License: Abstract: RDA was innovative in adopting a very close alignment with the IFLA conceptual models FRBR and FRAD throughout. The IFLA FRBR Library Reference Model is being developed as a consolidation of the three previous FR models. As the models are intended as high-level conceptual models, not full data models, some adaptation is inherent in developing a cataloguing code around the LRM, as with its predecessors. Two opposite mechanisms can be used in adapting a cataloguing code around a conceptual model: omission of specific attributes, relationships, or even entities, or expansion of any of these elements in the model. Mechanisms for expanding a conceptual model into cataloguing rules are shown, illustrated using the IFLA LRM and RDA. Keywords: Resource Description and Access, FRBR Library Reference Model, IFLA LRM, Cataloguing codes, Conceptual Models. 1 Cataloguing Codes and Conceptual Models The relationship between conceptual models and cataloguing rules is complex and in many ways is still being defined. Prior to the adoption and publication of FRBR in 1998 there was no commonly agreed conceptual model for bibliographic or library data. Traditionally, cataloguing codes were developed based on principles and on pragmatic considerations, following bibliographic traditions. IFLA contributed to the establishment of cataloguing principles, and to the very idea that national cataloguing codes should be based on internationally agreed upon principles, with the adoption of the Paris Principles in These principles have been updated as the Statement of International Cataloguing Principles (ICP 2009 and 2016) and are still used by bodies developing cataloguing codes. 1

2 A new element came into the mix in 1998 with the FRBR model. Now cataloguing codes can be, and in fact are, based upon a model that accounts for the entities, relationships and attributes revealed through bibliographic data. Resource Description and Access (RDA) is a major example of a new type of cataloguing code, one that is firmly and explicitly aligned with a chosen conceptual model. RDA has adopted the application of both the IFLA conceptual models (at the time of its original development these were FRBR and FRAD, later including also FRSAD) and the ICP as part of its design principles. The alignment with the models is stated at RDA 0.2.1: A key element in the design of RDA is its alignment with the conceptual models for bibliographic and authority data developed by the International Federation of Library Associations and Institutions (IFLA): Functional Requirements for Bibliographic Records (FRBR) Functional Requirements for Authority Data (FRAD) Functional Requirements for Subject Authority Data (FRSAD). And the use of ICP at RDA 0.4.1: The IFLA Statement of International Cataloguing Principles informs the cataloguing principles used throughout RDA. The fidelity of RDA's interpretation of the models can then be objectively assessed as in Riva & Oliver (2012). But the IFLA conceptual models are evolving. In particular, a single model is being defined to consolidate, or combine into one statement, the three existing models in the FR family. The February 2016 draft of the new model, provisionally titled the FRBR Library Reference Model or FRBR-LRM, was issued for world-wide review ending May 1, 2016 and further refinements will be considered by the FRBR Review Group during its meetings at the 2016 IFLA WLIC conference 1. How does this affect RDA and its use of the IFLA models? Does this mean that basing cataloguing guidelines on conceptual models is a new way of building a house on shifting sands? In this paper I will argue that, despite the complexities, developing cataloguing guidelines around a conceptual model is still feasible and worthwhile, and additionally, will refine what is intended in this relationship. Although the mechanisms involved in developing a set of cataloguing rules around the IFLA FRBR-LRM conceptual model are of general applicability, examples drawn from RDA will be used for illustration. 2 What Goes into a Set of Cataloguing Guidelines? Clearly a full set of cataloguing guidelines is far more than a simple transposition of its underlying conceptual framework or of its principles. First, we need to sort out which aspects of cataloguing rules are governed by what. Then, we will look at the aspects that are related to the underlying conceptual model that is adopted by the set of cataloguing rules and consider in greater detail what the relationship between the model and the rules might entail. Some aspects of cataloguing practice are solely under the control of the cataloguing rules, without any outside reference (unless the rules choose to defer to an outside source, such as a 1 The title of the model for the 2016 world-wide review was the FRBR Library Reference Model (or FRBR- LRM), at its meeting on August 19, 2016 the FRBR Review Group adopted the title IFLA Library Reference Model (or IFLA LRM). Both titles appear in this paper. 2

3 published style manual, for convenience, such as is permitted by the alternative at RDA 1.7.1, General Guidelines on Transcription). Focusing on an RDA context, things wholly in the realm of the cataloguing guidelines include: Sources of information (RDA 2.2, Sources of Information): specifies which sources may be used to gather the information that will be recorded in the various RDA data elements. Whether recording of the data in a given element is done via transcription (RDA 1.4, Language and Script, provides the list of data elements considered transcribed) or by normalized data capture and recording, and subsequently, what the applicable transcription rules are (given at RDA 1.7), or for non-transcribed data, what other recording rules or practices apply (such as in RDA 1.8, Numbers, and RDA 1.9, Dates). Other instructions relating to recording data, including the normalization practices that apply, or whether a controlled vocabulary is chosen for a particular data element, and if so, which vocabulary is to be used. The vocabularies may be defined within RDA or RDA may refer to external vocabularies, such as those from ISO. Data retrieval methods that will be supported, such as whether access points consisting of textual strings are devised. Encoding standards may come into play at this point in deciding how exactly the recorded information is captured. For instance, is a controlled vocabulary referred to via a URI in a namespace, or some other form of coding? RDA often refers to outside standards, particularly ISO standards, in the recording of identifiers and certain controlled vocabularies. The criteria to apply in making certain crucial distinctions are spelled out in the cataloguing guidelines, not in the model. A very important case is that the boundaries between distinct works are determined entirely by decision-making criteria specific to the cataloguing guidelines. This is described in LRM section 2.2: A wide range of decisions made in cataloguing rules can be accommodated by the model. For example, the exact criteria that determine instances of the work entity are not governed by the model. As a result, the model does not prescribe the level of adaptation from which a given expression based on an existing expression should be regarded as just another expression of the same work as the source expression, rather than as an expression of a distinct work. RDA provides such criteria at RDA Once the determination of new work versus new expression is made, then the model indicates which relationships may be applied. The ICP specifically covers principles of design, and provides the principles on which cataloguer judgment, an important feature of RDA, can be based. An indication of the most essential data elements, the RDA core elements, that are obligatory for even the most minimal description also are built around the minimum essential data elements mandated by ICP. Given all this, what is left for the conceptual model is to govern structure: the structure of the domain of interest. This is also termed the universe of discourse, meaning the kinds of things we want to use the model to talk about, and the sorts of conversations we want to be able to have about those things. Adopting a conceptual model implies making a choice relating to priorities. For instance, choosing the FR family models which are based on user tasks, indicates an outlook or philosophy behind RDA as being end-user focused. RDA explicitly acknowledges this in RDA 0.0, Purpose and Scope, where the FRBR and FRAD user tasks (slightly rephrased) are used to define the scope of RDA. 3

4 3 Structure of Models Every model must choose and work within a modelling framework. Several such frameworks exist and have their advantages and disadvantages. The IFLA LRM is an entity-relationship model that works with three elements: entities, attributes, relationships. The basic structure is built around the entities (giving us nodes to which properties can be attached) and then the network of possible relationships between entities gives a framework. Attributes are additional properties of entities, which characterize the instances of entities, but are not structural. To claim conformance with a conceptual model, any cataloguing system based on it must respect its structure, which in the case of the IFLA LRM includes the definitions of the entities, along with their hierarchical structure, as well as the attachment and constraints of the relationships. This is stated in LRM section 2.2: However, for an implementation to be viewed as a faithful implementation of the model, the basic structure of the entities and the relationships among them (including the cardinality constraints), and the attachment of those attributes implemented, needs to be respected. 4 From Model to Cataloguing Code Some level of adaptation is inherent in developing a cataloguing code around the IFLA LRM and its predecessors. The models are intended as high-level conceptual models, not full data models. The models in the FR family of conceptual models were not intended to contain exhaustive lists of all the attributes or relationships that might be needed by cataloguing codes, nor were the attributes present given at a sufficient level of granularity for general cataloguing, and this despite the fairly extensive list of attributes of the Group 1 entities declared in FRBR. Even more so with LRM which deliberately avoided defining an extensive list of attributes and stuck to essential or representative attributes and also to the most commonly occurring relationships: The model is comprehensive at the conceptual level, but only indicative in terms of the attributes and relationships that are defined. (LRM section 2.1) 4

5 There are two opposite mechanisms both of which can be used as needed in adapting a cataloguing code around a conceptual model: omission of specific parts of the model, or expansion of the model. 5 Omissions from LRM Despite the already minimal approach taken in the IFLA LRM, it is still possible that some of the elements declared in it are not relevant for a particular cataloguing code or implementation that is based on LRM. No element of the model may be considered mandatory in the absolute, although certain omissions would severely reduce its power or compromise the basic structure. 5.1 Attributes The IFLA LRM defines a number of attributes relating to the entities (attributes are defined in LRM table 4.3). However, there is no requirement to use all of these attributes in an implementation. Although LRM sought to select attributes that were generally viewed as useful and frequently occurring in actual bibliographic practice, omitting attributes is no impediment to conformance. The AACR/RDA family of cataloguing codes has not traditionally explicitly captured, for instance, Intended audience or many aspects of Use rights. Nor did most authority files, until the implementation of RDA, explicitly capture agent attributes such as Contact information, Field of activity, Language. These omissions, whether in specific records, in an application profile, or even in a whole cataloguing code, do not signal any lack of conformance with the model. It would, however, be an impediment to conformance to not recognize the definition of the attribute, or mis-attach an attribute in the entity hierarchy. For instance, LRM indicates that an agent may have Contact information as an attribute; it would be incorrect to claim that such an attribute is only logically applicable to collective agents. This is distinct from deciding that, while logically valid for all agents, the cataloguing rules will only recommend the recording of the Contact information attribute for collective agents, due to the inherent privacy issues surrounding recording this information for persons. At present RDA has taken the valid option of defining the data elements RDA 9.12, Address of the Person, and RDA 11.9, Address of the Corporate Body. However, RDA has not defined an equivalent data element for families (considered a type of collective agent, along with corporate bodies, in the IFLA LRM). LRM defines a small number of type-of-resource specific expression attributes (such as the attributes Language, Cartographic scale, Key, Medium of performance). Naturally, in an implementation that did not include the relevant resource type, one would simply omit the irrelevant expression attributes. 5.2 Relationships The structural relationships between WEMI (the FRBR Group 1 primary relationships) are expected to be implemented as is. Similarly as with attributes, other relationships that are not 5

6 needed in a particular implementation can simply be omitted, as long as all entities remain connected in the model. Consider, for example, the ownership relationship declared in the IFLA LRM between the entities agent and item. A set of rules that does not seek to cover any aspects of the present ownership, custodial history, or provenance of specific items can omit this relationship, as it is not structural. However, it does not make sense for the rules to generalize this relationship as being between any res and items, since not all res can logically be recognized as owning items. The LRM membership relationship can be used to record that any agent (a person or another collective agent) may be a member of a collective agent. In some contexts membership information may not be sufficiently significant and the relationship would be omitted. However, if implemented, the domain and range of the membership relationship must be respected, as agents of type person cannot have members. 5.3 Entities The entities, being the most fundamental aspect of the model, would generally be expected to be retained. However, some entities may be omitted from an implementation in specific cases. For instance, it could be argued that pure national bibliographies do not need to implement the item entity at all. This case is described in LRM section 2.2: It is possible for a compatible implementation to omit one of the entities declared in FRBR-LRM. For example, the entity item may be unneeded in a national bibliography that does not provide any item-level information. In that case, none of the attributes defined for the item entity, and none of the relationships involving the item entity, can be implemented. When entities are omitted, logic and consistency requires that the relationships that attach to those entities are also dropped, and that their attributes are not implemented. The choice to omit an entity such as item would generally be taken precisely because item attributes and 6

7 characteristics are not considered relevant. For other entities, the attributes and relationships are likely too significant to be omitted, providing a reason for retaining the entity in an implementation. Consider for instance, the entity nomen. The IFLA LRM defines several attributes of nomens, such as Language, Script, Script conversion, Scheme, which are basic to the utility of a nomen functioning as an access point in RDA. Significant relationships include that a nomen is assigned by an agent. Relationships among nomens, such as equivalence, derivation, and whole-part, underlie the structure of variant and authorized access points in RDA. 6 Mechanisms for Expansion The IFLA LRM provides mechanisms to expand any of the model elements. This is where things get more interesting as several techniques can be applied in succession to grow the model into a full-scale implementation. 6.1 Additional Attributes or Relationships Just as unneeded attributes and relationships can be omitted, new attributes and relationships can be added. This is the easiest route for expansion. RDA includes many attributes not included in the IFLA LRM. Consider all the attributes specific to manifestations in particular forms that are found in RDA chapter 3, Describing Carriers, such as RDA 3.6, Base Material, or RDA , Video Format, and for expressions of specific forms in RDA chapter 7, Describing Content, such as RDA , Form of Musical Notation, or RDA 7.19, Aspect Ratio. 7

8 By defining relationship designators in RDA I.2.2 for roles other than the creation of a work, such as Addressee or Honouree, RDA includes relationships between agents and works that are in addition to the work-creation relationship provided between those entities in LRM. 6.2 Sub-types of Attributes Many attributes declared in the IFLA LRM are generic and in any application are meant to be fleshed out with sub-types. The Category attribute is a place-holder permitting subcategorization of any entity, but the model does not prescribe the use of any specific categorization schemes or taxonomies for any of the entities, although some categorization schemes are given as illustrations of the model. The Note attribute also serves as a parent attribute for all the specific types of notes that are defined throughout RDA. The attribute of the manifestation entity defined as Manifestation statement is specifically intended to be implemented using multiple sub-types. In fact, most of the ISBD consists of sub-types of this attribute. In RDA, most the data elements in chapter 2, Identifying Manifestations and Items, are sub-types of this attribute. Any RDA data element that is transcribed (see RDA 1.4 for the list) is actually a sub-type of the Manifestation statement attribute, showing the importance of expanding this attribute to turn a conceptual model into a functional set of cataloguing guidelines. 6.3 Refinement of Relationships While any relationship in the model can be made more specific, the IFLA LRM includes some key relationships which are very general and are placed in the model so as to serve as points of attachment for more specific, more granular, relationships. LRM has a single work-creation relationship. This relationship is refined in RDA, which defines many relationship designators in RDA I.2.1 to qualify the creation relationship between 8

9 agents and works. Similarly, the LRM expression-creation relationship is refined into sub-types by the many relationship designators found in RDA I.3.1. The relationship designators in RDA J.2.2, Derivative Work Relationships, are all refinements of the LRM work-transformation relationship, and so on. Another mechanism for creating refinements of relationships is by implementing paths that make use of the hierarchical structure of the entities to restrict either the domain or range entity of a relationship to one of the subclasses of that entity. For example, by making use of the fact that the entity person is a subclass of the entity agent, and that LRM declares a work-creation relationship, the more granular relationship work is created by person can be defined. These two mechanisms are intended to be used in concert to provide more specific semantics to the very general association relationships between any res and the entities place and timespan. RDA takes advantage of this increased granularity when it defines data elements for the date of birth or death of a person (RDA and 9.3.3) and associates a corporate body with its date of establishment or termination (RDA and ). Similarly, with the place of birth or death or residence of a person (RDA 9.8, 9.9, 9.11), or the location of a conference (RDA ). The power of these mechanisms is only limited by the needs of the application. To ensure that it is always possible to attach any relationship deemed necessary by an implementation to the framework provided by the model, a top-level relationship (res is-associated-with res) was declared. This serves as a broad umbrella that allows the creation of whatever specialized relationship refinement is needed. A refinement of the top relationship can be used to link between res of sub-types that do not fall into any of the specific entities defined in the model, or can link entities that do not have any other generic link. 6.4 Entities and Subclasses The expansion mechanism for attributes can be applied to create new entities at lower levels in the entity hierarchy. The Category attribute defined for the entity res can be applied under each entity, whether explicitly indicated in the model or not, as all other entities are subclasses of res. This allows a categorization scheme to be used to subdivide the instances of that entity. If a sufficiently robust categorization scheme is used (particularly one that is a taxonomy of that 9

10 entity, meaning it covers all possible instances in mutually exclusive classes) then the types so defined can be implemented as subclasses of the entity and function as fully-fledged entities in their own right. Once these new entities are defined, this permits a new round of expansion of the model by defining new attributes and relationships around those entities, and by refining the attributes inherited by each of the types from the superclass, as well as by refining the relationships that are inherited. A specific example of this in an RDA context would be categorizing collective agents as either families or corporate bodies: these two types cover all collective agents. These two specific subclasses can be implemented as entities in the cataloguing guidelines, instead of (or in addition to) the parent entity collective agent. Then, for example, the has-part relationship (collective agent is a part of collective agent) can be refined into specific relationships, such as: family is a part of family corporate body is a part of corporate body This could also be done with attributes, and so the Contact information attribute for a family might have sub-attributes (refinements) different from those for the contact information for corporate bodies. More important is that additional relationships (all of them refinements of the umbrella relationship res is associated with res) can be implemented that make sense only for these specific entities. An example is the ownership relationship, which is not declared (for agents) in the IFLA LRM as it is considered too specialized. However, once corporate body is created as an entity, then the relationship person is owner of corporate body can be defined. This is an example of a relationship that could not have been defined at a higher level in the entity hierarchy, by substituting collective agent for corporate body, because a person cannot own a family, another type of collective agent. These very powerful expansion mechanisms can be applied recursively, subdividing the new entities and expanding again and again. 10

11 7 Conclusion RDA has defined over 300 data elements and dozens of relationship designators. Yet, given the many expansion mechanisms built into the IFLA LRM, it will remain feasible to maintain alignment between RDA and the new IFLA conceptual model. This alignment benefits RDA by providing a logical structure with defined mechanisms and principles for expansion. References (FRAD) Functional requirements for authority data : a conceptual model / edited by Glenn E. Patton, IFLA Working Group on Functional Requirements and Numbering of Authority Records (FRANAR). München : K.G. Saur, (IFLA series on bibliographic control ; vol. 34). As amended and corrected through July Available at: (FRBR) Functional requirements for bibliographic records : final report / IFLA Study Group on the Functional Requirements for Bibliographic Records. München : K.G. Saur, (UBCIM publications ; new series, vol. 19). As amended and corrected through February Available at: (FRSAD) Functional requirements for subject authority data (FRSAD) : a conceptual model / edited by Marcia Lei Zeng, Maja Žumer and Athena Salaba. München : De Gruyter Saur, (IFLA series on bibliographic control ; vol. 43). Available at: Errata for section 5.4.2, October 2011, available at: (LRM) FRBR-Library Reference Model. Pat Riva, Patrick Le Boeuf, and Maja Žumer. Draft for World-Wide Review, Available at: (ICP 2009) IFLA Cataloguing Principles : Statement of International Cataloguing Principles (ICP) and its Glossary. München: K.G. Saur, (IFLA Series on Bibliographic Control ; v. 37). Statement available at (ICP 2016) Statement of International Cataloguing Principles (ICP) Edition. [forthcoming]. Version for 2015 world-wide review available at: (Paris Principles) International Conference on Cataloguing Principles (Paris : 1961). Report. London: International Federation of Library Associations, 1963, p Also available in: Library Resources & Technical Services, v. 6 (1962), p ; and Statement of principles adopted at the International Conference on Cataloguing Principles, Paris, October, Annotated edition with commentary and examples by Eva Verona. London: IFLA Committee on Cataloguing, (RDA) Resource Description and Access Available at: 11

12 (Riva & Oliver 2012) Riva, Pat & Chris Oliver. Evaluation of RDA as an Implementation of FRBR and FRAD. Cataloging & Classification Quarterly, v.50, no.5/7 (2012), p (Riva & Žumer 2015) Riva, Pat & Maja Žumer. Introducing the FRBR Library Reference Model. Paper presented at World Library and Information Congress, 81st IFLA General Conference and Assembly, Cape Town, South Africa, Available at: 12