Resource Management Data Domains

The following diagram serves to illustrate multiple concepts:

• delineation of the various areas of concerns or domains of responsibility
• identify the key objects, in all those domains, which relate to resource management in Folio
• illustrate the referential nature of metadata management within Folio and its suitability to supporting Linked Data

Domains

Folio Codex Domain

The Codex domain is the abstraction layer which is always stored locally to Folio. It consists of a minimal, but sufficient, set of core metadata that can represent a resource within a list of resources - e.g. a hit in a search result.

• The Instance is the primary object which represents a resource. It is also an abstraction which reconciles / merges / aggregates both electronic and physical items.
• The Work is the conceptual version of a resource; the conceptual essence of the resource, independent of any material embodiment of the resource.
• The Location is where / how one might consume the instance in question. This may be a URI for an electronic item or a set of coordinates for a physical item.
• The Holding is used to represent the possession of a resource by the institution. Whereas the "instance" describes the resource itself, the "holding" describes the relationship between the resource and the institution. This is also an abstraction which reconciles / merges / aggregates both electronic holdings and physical holdings.

This domain, as is the case for all the other domains illustrated there, contains many other objects which are not shown. These have been omitted here in order to provide clarity in illustrating the concepts being discussed.

Knowledge base (KB) Domain

The KB domain provides the context for objects that describe resources and their hierarchical organization. Shown on this diagram is an electronic knowledge base. The platform can support multiple knowledge bases, electronic, print, or otherwise. The KB domain contains a number of objects including:

• KB Title aka KB Instance. Each object contains the descriptive metadata associated with either a monograph or a serial publication. This is rich metadata which is linked to from the Folio Codex domain instance object. The KB title applies to both monographs and serials.
• KB Package. This object represents the bundling which may frequently be found when dealing with serial publications or ebook collections. There is no equivalent structure in the Codex domain.
• KB Location. Represent where the resource may be accessed. As shown in the diagram locations are specific to a combination of titles in packages. In the case of electronic resources this is typically a URI.

The KB domain is the authoritative source of truth for rich metadata which describe resources. It will be relied upon to dynamically deliver that metadata to the user experience though its API interfaces.

The Codex domain contains placeholder objects (Location, Instance) which only contain the set of core metadata. These are linked to the KB domain corresponding objects to allow for the dynamic retrieval of a more comprehensive set of metadata. This is basically the concept of linked data. Thus when the KB title metadata are updated in the KB, those changes will be immediately reflected in the detailed display in the user experience since this will be a dynamic retrieval call. However, an additional mechanism needs to exist to refresh the locally held core metadata in the Folio system.

Holdings Domain

Closely related to the KB domain is the holdings domain. Whereas the KB domain provides a description of the resources, the holdings domain represents the relationship between the resources and the tenant institution. For example, the KB domain may describe a package which contains 100 titles. A particular tenant institution may only have access to 90 of those. This fact and other tenant specific metadata, such as coverage and embargoes, are contained in the Holdings domain.

In this context the relevant object in the holdings domain is the Entitlement / Holding object. It is paired to the more abstract Holding object which is found in the Codex domain. However, in the case of electronic holdings in particular, a holding does not get represented locally to Folio until it has usage (patron or staff) produced against it. If this were not the case,then large portions of the KB domain would become duplicated for every tenant in the Codex domain. In effect, this would break the referential (linked) design and result in the undesirable movement and duplication of large amounts of metadata into multiple systems.

For either Entitlements or Holdings it is important to note that specific metadata values such as title lists, coverage dates or embargo dates may differ from the default values stored in the generic KB version of the metadata. These could have been established as part of the negotiations during purchase or renewal.

Acquisition Domain

The Acquisition domain is a complex domain onto itself, most of which is not shown in the above diagram. However, one particular object from that domain is relevant to the Codex context.

• Subscription. This represents the sales contract which has been negotiated during purchase or renewal. The subscription contains the terms agreed upon during purchase including any modifications to default title lists, coverage date or embargo dates. In turn, the subscription object defines the entitlements and holdings for the customer.

Inventory Domain

The Inventory domain is a venerable domain in library operations. However, as defined in this model, the Inventory really only applies to physical (e.g.. print items; historical artifacts). There is a close parallel between the objects in the Codex domain and those in the Inventory domain. These object data can be stored locally in the Folio system itself.

• Physical Item. This represents the physical copy of a book or journal; it is the digital proxy for a real world item. If there are 3 copies of a book there are 3 physical item records - i.e. 3 different barcodes. The ownership of a physical item by a tenant institution results in the creation of a corresponding Holding object in the Codex domain.
• Physical Instance. This is a higher level of abstraction to the Physical item. It provides for a consolidation of identical physical items for manipulation in cases where only the count of physical items is relevant. In the previous example if there are 3 identical copies of a book, each with their distinct barcode, then there is a single physical instance with a count property of 3. The physical instance object is linked directly from the Codex domain's Instance object. The physical instance is what would be reflected in a search result from the Inventory domain.
• Physical Location. These are the metadata which define the coordinates (e.g. library, floor, stack number, shelf number) needed to locate, and potentially retrieve, a physical item. There is one physical location tied to each physical instance. This object is referenced (linked) from the Codex domain's Location object.

As indicated on this diagram the physical objects may themselves be derived from authoritative KBs. However, unlike electronic content from KBs, the metadata from the print and other KBs would be extracted and copied into Folio structures.

Circulation Domain

The circulation domain has been introduced into this context, because it plays a role in gating the creating of Codex domain Holdings from Holdings domain Holdings. For the sake of providing symmetry between the physical and electronic stacks, the following objects are described here.

• User. This object is the model proxy for a user who consumes a resource. This may be a patron or a library staff member.
• Usage. This represents the consumption of a virtual (electronic) resource by a user. This could be accessing an online journal database, or even downloading an e-book, customizing the metadata record for Folio.
• Loan. This the consumption of a physical resource by a patron (user). The physical item, which found in the Inventory domain, is linked to the Loan object in the circulation domain. Note that there is no duplication of the physical item record in the circulation domain.

Relationship to BIBFRAME2 and MARC

The core data model used natively by Folio for resource management is found in the Codex domain. These are neither BIBFRAME2 nor MARC in their implementation. However, conceptually Folio embraces a linked data preference which can be closely aligned with BIBFRAME2.

MARC

The scope of MARC records is mostly limited to the Inventory domain.

Batch processes or other interactive tools may allow the import of MARC records representing resources into the system. When this occurs, Folio will interpret the MARC records and extract out the relevant fields, mapping them to the very limited set of core metadata that is kept in the Codex domain and used to describe the resource. The original MARC record is not discarded but is retained as an attachment tied to the new record - no information is lost. The MARC record format is being used as a data interchange format by Folio in this case.

Folio does not considers MARC records to be a data format. Rather, it considers them to be an interchange format - as was their original intent.

BIBFRAME2

The data format used by Folio is highly compatible with the design of BIBFRAME2. While Folio does not directly implement BIBFRAME, we can see that it is simple to create a crosswalk between the two.

Assumptions

This diagram reflects a number of key assumptions which need to be explicitly stated.

Merging electronic and print

The Folio platform strives to merge the treatment of electronic and physical (i.e. print) resources. This abstraction is achieved through the Folio Codex domain. Whenever the system needs to present a set of resources to the user experience, it should be doing so through the Codex domain objects. Clearly, the reality is that electronic and print items are different and they each possess distinct properties. This is supported by the Folio platform though the linking that exists between the Codex domain objects and the KB and Inventory domain objects. When the need occurs to delve deeper into the resource records, this is done through the specific domain (e.g. cataloging against physical records in the Inventory domain).

Merging monographs and serials

The Folio platform strives to be agnostic to differences between monographs and serials. The Codex domain provides objects, described by core metadata, may represent monographs or serials. There are underlying descriptions (found in the Inventory or KB domains) which contain richer and more specific metadata. The use of linking between the Codex and KB or Inventory domains minimizes the need to synchronize data between those domains.

Inventory vs. Knowledge Base

A fundamental assumption in this model is that the Inventory is a domain which only relates to physical (e.g. print) items. The purpose of the Inventory is to classify and manage an inventory of physical items. When it comes to electronic items, the classification and management of the inventory is typically provided by the vendor of the electronic items. The classification of electronic items is provided by a knowledge base service and their management, including circulation, is achieved through holdings management services closely tied to a particular knowledge base.

It is important to note that multiple knowledge bases are supported by this model. These will each represent areas of specialized content: e.g. Medical vs. Physics etc..

Local vs. Remote

A primary goal of this model is to avoid the local copying and duplication of metadata. Whenever possible there should be reference (i.e. link) made to an authoritative record. The local system should only retain a minimal set of core metadata relating to the item. Whenever the full, rich set of metadata are required, these should be retrieved dynamically from the authoritative source (e.g. knowledge base). Furthermore, the locally retained core metadata should only be present in the local Folio system when it is needed. For electronic items this implies that local placeholders are only present once an item has been accessed. In other words, it is access which converts an entitlement (a potential holding) into an actual holdings which may then be represented within the local Folio system.

https://discuss.folio.org/t/resource-management-data-domains-diagram/724