The various domains shown expose selective elements (or objects) in each domain in order to illustrate key points in the model. There are more objects in the various domains, than shown in the diagram; the diagram is not intended to be comprehensive.
I fully appreciate that the BIBFRAME model identifies three, and only three, core classes. As you point out those can be mapped to the objects shown here; Work=Work; Instance=Instance; Item=Holding. However, I view the BIBFRAME model as very specific to describing resources and therefore by necessity resource-centric. I approached this model from a different perspective.
Originally, there were only three objects shown in this Diagram’s Codex Domain: Instance; Location; Holding. The Work item was added later to reinforce the ability of this model to support BIBFRAME. But the model was not intended to be an implementation of BIBFRAME.
- The Instance represents the what of the resource. It contains the immutable properties of the resource.
- The Holding represents the how of the resource. It’s about the conditions under which a resource came to be held by the library. These are somewhat mutable properties.
- The Location (for lack of a better name) represents the where of the resource. But more specifically, the where can I consume it? - which I viewed as highly mutable.
There is great value from a platform perspective to separate the immutable from the highly mutable.
One of the goals of Folio is to a provide a platform for the future, and therefore we must attempt to anticipate what the future needs might be. From this viewpoint I felt it important to elevate the importance of the Location object.
It’s easy see how from a resource-centric view it might suffice to treat the Location as merely a property on the Item. However, we should be attempting to extrapolate trends into future needs. I believe that there is a current trend away from the resource-centric perspective. This can be seen in an ever increasing number of available electronic resources. The trend can also be seen in everyday life: the focus has shifted from an analog resource such as an LP record, to a digital one such as a CD, to iTunes then Spotify and any number of streaming services. These offer essentially interchangeable versions of the same thing, and focus has changed from “the thing” to “where to access it”. It is no longer sufficient to support all of these with a simple property, hence the Location object.
A location object can also be thought of where one would hang other objects: link templates for an OpenURL resolver; proxy rules; etc…
Why is the location property so special, what about format and licensing? Well those are all objects too, not just properties. They’re just not shown in this particular diagram.