I don't see why items (particularly, barcoded physical items) should be the focus. On the other hand, records are the core of a bibliographic system -- everything else (items and their attributes, access restrictions for electronic resources, libraries-as-places, etc) is a set of filter axes to apply atop the record when searching for or manipulating it. The record is the nucleus, and everything else enhances/vivifies/subdivides it.

to

But I contend that we don't traverse in either direction for a given relationship, nor do we have a need for ultimate flexibility at the cost of complexity. (I'm not referring to schema complexity here, but code complexity -- the need for inferences that will certainly come from commingling aggregation and dis-integration.)

The direction of traversal is critical, and should be ensconced in the schema. Not only does this make the code for each function simpler (we don't have to infer a relationship, it's dictated by the fact that we're using part or multi-home) but it models what libraries actually do: barcode parts of a work (volumes, disks, etc); or, collect manifestations of many records into a big binder (or e-reader) with one barcode on the outside.

can

IMO, the question one would ask is, "what and where are the things (nominally, barcoded physical items) that contain what I describe?" ISTM that it's very important to know, and perhaps even critical for efficient workflow, to list separately subsets of what a record describes (parts) and "bound" items that contain the described work along with others. With a unified map there's no mechanism other than a magic value (or a human hoping to interpret another human's label correctly) to distinguish these concepts. With parts and multi-home separate, it's obviously a natural property.

This is directly supported by multi-homed items, with the exception that you do need to look at the call number to get the primary record. I don't see a practical drawback to this, since that's what the code already does, and will still have to do as long as the record field exists on asset.call_number (null-ability or elimination of which is mentioned below).

There are three problems I see here:

* Call numbers will always have a first-class billing, regardless of how they're implemented, since they represent something physical. Two things, actually: the location in a range of other items (shelf order and position), and a tag pasted to the spine of the item. * I can't see any obvious benefit to eliminating the record<->call_number link (mentioned directly below, and intimated here) * The mounds and mounds of code that assume and depend on the existence of the record->call number->copy hierarchy that will instantly break

I see this as an oversimplification from the conceptual point of view -- it fails to recognize that the arity of the relationship (which I call direction) is important and different. IOW, record<<->item serves a completely different function from record<->>item, and forcing them both through a record<<->>item relational model does both a disservice.

a

Split-brain is probably a misnomer ... we have to commingle the logic for aggregation and dis-integration (disaggregation?) wherever we use either.

From a practical point of view, here are some more random-ish thoughts that don't seem to fit directly into this response elsewhere ... ;)

When going from records to items (via the Monograph Parts infrastructure as described), we need to be able to name label the subdivision that the part represents in relation to the record as a whole -- we need to be able to say "barcode X contains only Volume 1 of the content described by record A". This is not something we need to do for binding in the general case (note, however, that you can indeed use both at the same time -- multi-home and parts -- to get the effect of "volume 1 of record A is bound with some other things").

Also, the only purpose of the record-to-item path is to dis-integrate the record into constituent, separately barcoded items, so there is only one relationship type.

However, going in the other direction, from items to records (via Multi-homed Items as described) we do not need a label -- what we need instead is a /reason/ for the relationship. Bound-with, e-reader, etc. IOW, there are multiple potenial causes for the relationship being created.

Not surfacing these differences explicitly (in my case, by using separate, though admittedly superficially similar mechanisms) is inviting trouble down the road, IMO.

Now (fastforwarding to your schema outline below), IIUC, what you're attempting to do with the copy_type table is to have a magic value of "Multi-part" inform us that the direction is from record to item, and all others are the other direction. From a bibliographic point of view this is incorrect -- it's not the copy that is Multi-part, it is the record. From a normalization point of view, this is not modeling reality IMO, and because it uses magic rows in a table it's brittle against DML.

Or

You're not ... I interpreted what she was saying differently (that different libraries would be /able/ to spit records along different lines), and I see what you're saying. We could allow a copy to belong to multiple parts (it's a trivial change to the schema), but it would be the responsibility of the cataloger with the item in hand to make sure that the copy is in the appropriate parts -- not hard, except that some parts may not exist yet. ;) (And, of course, this existential problem exists no matter the scheme*.)

Converting from one part per copy to multiple is simple at the database level, and would be nearly trivial in higher level code, but until we have use in the field I think it's a solution without a problem, because of the cataloging overhead of trying to keep every copy current across all parts as parts are added to a bib when each library adds their own subdivision scheme for the bib. For that reason I left it out explicitly. (*It also invites the desire for a "collection of parts" concept that is a much bigger, and more importantly, controversial project. That too, though, is not barred from the future with the design as it stands.)

it

Given the codebase, that will be a large and separate project, if ever undertaken, and is not something we can look at now if we want anything discussed here to happen in a near-term release. I won't discount it out of hand for all time, just for this time. ;)

--miker