Please reply to this topic to further the Metadata SIG’s 4/13/2017 presentation and discussion concerning the Resource Management Data Domains Diagram.
Meeting minutes about the information we have so far can be found here: https://wiki.folio.org/display/MM/Meeting+Minutes
Does the symbol below from the diagram have a special meaning?
A one-to-many relationship
I’m struggling to understand the need for an Instance, Work, Location, and Holding. The Bibframe model makes a clear case for Work, Instance, and Item. If I go by the Bibframe model and translate it to what we see in this diagram, it seems like there only two levels are needed: A Work level (that would serve to aggregate) and another more specific level that would represent a resource of the work owned by the library. That resource could have the specific properties of format, location, licensing. That seems further evidenced by the one-to-one relationship of Holding and Instance.
Does the way information arrives in libraries, drive this model to a certain extent? Does our current reality makes it more logical to split out Location, Instance and Holding?
This is great! I really like the overall logic. I have questions / or need for clarity that might be located elsewhere. These include: How early up stream is data captured? In Acquisition? Authority control (yup, that challenging concept) - how does this play in? Connecting to other KBs might be the answer - but I’m interested in authority control in various areas of the workflow - from acquisition all the way though lending. Cutting down on duplicative data where ever possible but understanding when it might be too constraining.
During our meeting last week, we spoke quite a bit about “Local” and “Remote” and how the diagram might be re-labeled. Afterwards, as I was re-reading the data dictionary below the actual diagram, I realized that local and remote there are referring to metadata, not resources. However, during the discussion of the diagram, I thought we were talking about sources of library resources, not sources of metadata. I think that using/re-using the same words to refer to 2 different types of data (library resources vs. metadata about library resources) makes the diagram less than clear. When it says data in the title, I do not naturally think of metadata around print (local) or electronic (generally remotely accessed) resources.
I may have muddled things in my comments during the meeting based on my own preconceptions on what the diagrams was meant to convey.
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.
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.