Some thoughts on when a new instance is minted, and how instances come together again (are rolled up) for administration or discovery. There are a few different ways to look at it… part of it is (perhaps) a migration question, part of it is a question of local policy, part of it might even be a perspective of what “we” as in the FOLIO community, would like to encourage, if not enforce.
First of all, Vince’s response is right – if you wish to add a MARC record with minimal change, then the most simple view of the Codex is that this record is viewed as a brand new Codex instance, and if you want more meat than what is visible through that, you (or your app) can refer to the source record. That is the most fundamental approach and it needs to be thus, I think, to allow people to import their catalog without having to make big and difficult decisions about refactoring their catalogs… at its simplest, the codex can naively represent a silo of MARC (or any other format) of records.
But suppose you wanted to take a step further and actually “refactor” your catalog, to move closer to a model that explicitly recognized works as groupings of instances. A simple way to do that would be, during your import process, to use something like this: https://www.loc.gov/bibframe/mtbf/ to map your MARC records to BIBFRAME and make those records the source. In that process, the mapping might generate Work entities which would make certain instances group together with a shared Work parent. In the first rollout of the Codex, the instances would still be separate because we haven’t made a space for Works yet, but the intent is definitely to do so… when that’s done, you’ll have a model for administratively or algorithmically clustering instances around a shared work within the system. Going forward, you would want your cataloging workflows to similarly honor this clustering… i.e. make it easy when a new Instance is created to link it to a Work… this is made complicated because there are of course many different processes by which instances are added to a catalog, and this completely ignores the electronic KB model where Someone Else is responsible for curating the instances.
The second answer to ‘roling up’ instances into larger units (works) is, it can be done dynamically by the Discovery layer even if the library is not administratively maintaining works structures. One big advantage of this approach is that the merging/clustering rules can easily be changed over time without impact to cataloging rules or the structure of the catalog. The rules can even be adapted to the audience and application. End-users might prefer much more inclusive/aggressive merging rules than professional librarians.
So if work-level clustering is potentially in the eye of the beholder, if it can be done well by a Discovery ‘crawl’ of your catalog, are there still advantages to administratively curating the work/instance relationships? I think there can be, and if BIBFRAME is the strongest candidate for an intersection point between library craft and the linked open web, then this would seem to support that idea also. If I want a link from the wikipedia page about a work, it makes more sense to make that link to/from a representation of the work than some random instance. Becoming more mindful about explicit, hard relationships between the different entities in our space (instances, work, people, subjects) is also one path to finally force ourselves to get identifiers right.
This is a long (sorry) way of saying that there’s more than one way to skin a cat in the Codex, and there will be many many more ways than one in FOLIO, where the Codex is just a hub for a particular range of approaches, but it doesn’t have to be the only hub.
As for what we do in FOLIO in the short term, I think we definitely need an implementation of the Codex that will let you ingest and work with a set of MARC-flavored data viewed through the Codex service interface, with access to full MARC for apps that want it. I tend to think we also owe it to ourselves to have an implementation that lets you switch to BIBFRAME if you want it, just because we would learn a lot from thinking about what it would look like.
Full disclosure… we at ID have been working with the LoC on the Marc/BIBFRAME crosswalk, and we created the reference implementation which can be downloaded from that same site. We already went through the exercise of playing with it as a microservice in FOLIO, albeit without a storage module based on the Codex, there hasn’t been much we could use it for.