“System X should provide support for BIBFRAME”
Secretive requirements document
It’s quite clear from this requirement specification that the system should support BIBFRAME, right? But, what does that actually mean?
In order to understand this question, one needs to realize that the move from MARC to BIBFRAME has one major issue: it is a move from one way of modelling data to another. The MARC model is document-oriented, while BIBFRAME is statement-oriented.
MARC encodes necessary information in a single document; the document may express some or all of the possible information that can be represented using the MARC format. A single MARC record is therefore an independent, self-contained document that can be interpreted using software tools that understand MARC. Given the development of MARC, it is important to recognize that this document-orientation is tied to the era when it was developed and the aims of those developing it.
MARC…standards for the representation and exchange of bibliographic, authority, holdings, classification, and community information data in machine-readable form
MARC is a format for bibliographic records, designed for data exchange. ISO 2907 and MARCXML are data exchange serializations. MARC is often confused with its serializations, which is natural as one cannot view MARC independently of these without reference to a non-standard view such as the linear formats seen in most MARC editors. Nevertheless, this again, is a confusion, as one does not “catalogue in MARC” as MARC only provides a container document for information, the information itself is encoded in a different framework, typically AACR2 or RDA.
The BIBFRAME model must therefore both broaden and narrow the format universe for exchange of bibliographic data.
BIBFRAME is also a carrier for similarly encoded data and is also an exchange format; it appears, however, that BIBFRAME provides more clues to how data should be structured at a basic level, thus entailing the BIBFRAME vocabulary is rather more of a schema than MARC21 is. Nevertheless, MARC21 and BIBFRAME are roughly equivalent in purpose. The major difference is how BIBFRAME represents information not in a document, but as a distributed collection of statements about a resource.
An example might help here: I have a resource “A doll’s house” by Henrik Ibsen. In BIBFRAME, I have a Creative Work that has authorizedAccessPoint “A doll’s house” an identifier “X1231224” and creator http://example.com/authority/01312351. The creator is represented by an identifier — an HTTP-URI that can be accessed over a network — which when accessed (or de-referenced, to use the correct Web terminology) provides information about that authority.
Note that each statement here, that the resource is a CreativeWork, the authorizedAccessPoint, the identifier and the creator, all exist independently of each other; there may be additional statements related to the resource, or some of the statements related here may be absent. Note that the resource itself has an identifier that makes it possible to get the record itself over the network in the same way as the authority document mentioned above.
Moving from documents to this distributed concept is more involved than simply converting data to a BIBFRAME representation of a MARC21 record; in order for the data to be truly compliant with the spirit of the BIBFRAME model, the identifiers used in the data must be provided as de-referencable data.
So, when one requires BIBFRAME data in a system, it is not a matter of “serialize data as BIBFRAME”, but rather “provide an entrypoint to the BIBFRAME ecosystem”, which is an entirely different matter.
[You might also enjoy Adding BIBFRAME support to your application: a hypothetical approach]