...
https://meetings.webex.com/collabs/meetings/join?uuid=MBN9HHHWUB7P0RGHOGF388TIBA-2C6Z
Attendees
Discussion items
| Item | Who | Notes | Action Items |
|---|---|---|---|
| Product Council update | Doreen |
| |||
| Discussing Knowledge Base and Metadata - Scope and Domain | All | ||
Relative to the stated initial goal of “Establish the groundwork for support of data formats beyond MARC … ,“ information that I have read or heard about FOLIO seems to state that any external record, such as MARC21 or DC or Bibframe, would be translated into a FOLIO-specific data storage format. Is that correct? Additional comment/question: Initial reaction is: why create yet another metadata format? It seems that it would make more sense to facilitate conversion between existing metadata formats rather than producing another one... So is that because there is no desire to build FOLIO on Marc, but there is nothing else as yet that can be used? | |||
Perhaps I’m being premature, but I look at the stated goals, outcomes, and deliverables in the context of existing record conversion, especially bibliographic/holdings/item records. In that context, I find the “physical item” depending from the “entitlement” to be problematic. It implies to me that at the point of conversion we’d need to provide data on how we’re entitled to a given physical item; we don’t have such data for hundreds of thousands of our physical items because they were bought while we were using a previous system and the purchase data didn’t come with them into the current environment. Also, I would see Location connected to Physical Item rather than Entitlement. | |||
| On the other hand, I am somewhat reassured by the stated intent of maintaining the storage format of the original records because I don’t know what we’d do with the mountain of management metadata in our existing holdings records, as an example. I have an image of them being converted piece by piece as standards develop. | |||
| The typical workflow at this library (Texas A&M) is to create or update a bibliographic record on OCLC, then export it into the local Voyager catalog. Could you describe how that workflow relates to your use of instance, both internal and external? Would the record on OCLC be the “external instance” and the copy of the record within FOLIO the “internal instance”? On the model, the “derived from” arrow goes from the internal instance to the external. Shouldn’t there be two arrows, one in each direction? The answer, I guess, depends on whether I have correctly understood the definitions of external and internal instance. If I have, our library and I imagine many others derive records from the external instance and load into internal and almost never derive in the opposite direction. | |||
| Could you please explain “reference cataloging.” | |||
| Could you give some more detail about the relationship among the elements connected by the diamond, i.e. instance, package, platform, etc.? I think of packages as typically residing on platforms, for example, so I’d be interested in how you see the relationship. | |||
Regarding teh conceptual domain model, I would like to have clarification on what is meant my Instance - is this in a Bibframe sense or something else? If external/internal instances are sets of metadata either external to the institution or internal, I find the use of the word Instance in this context confusing: surely those sets of metadata would be more than relating to Instances only, but again it all depends what is meant here. If we also have Works, which would presumably be created as part of the FOLIO metadata format, then the external/internal metadata sets encompass more than Instances?
| |||
| Wrap up: Additional thoughts, comments, suggestions? | All |