...
| Item | Who | Notes | Action Items |
|---|---|---|---|
| Product Council update | Doreen |
| |
| Discussing Knowledge Base and Metadata - Scope and Domain | All | The questions below came from Anne Highsmith. They are used here as a launching point for discussion. | |
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? | Marc Johnson comments:
Doreen asked for a citation or resource to give the group information to help the group understand this. Anne - Is the intent to translate the records coming in to a single format? Paul - Some of the metadata that is going into FOLIO will need to be edited, some will not. Several possibilities of how FOLIO will work, depending on how data will be edited. Marc
Peter - We could have apps that do not need to understand the underlying data format. For example, with circulation, that app does not need to understand MARC in its entirety. It only needs to understand basic descriptive info. Idea is to have circ apps that can be somewhat interchangeable, while allowing for description to Christy - What is the relationship between the source records and stored record? Peter - Distinct metadata formats would have distinct editors. Example: something in BibFrame would have a BibFrame editor, etc. What is "agreed upon between apps" is a high level of metadata. Sometimes this is expressed in Dublin Core. There would be translators in FOLIO that would help apps that understand different metadata formats do what they need to do. Some work was done on this over the summer, the output of which are two Google Documents with abundant comments (Kabalog Discussion and Descriptive Metadata Handling in FOLIO). He would like to take these documents clean them up, and provide a further reference point for this SIG.
| ||
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. | Marc - Thinks new diagram, in development, that will be shown soon will clarify some of these questions. "Entitlement" is a word that implies commonalities between Electronic and Physical items: users are "entitled" to use a book or an electronic book. This is not intended to pull in acquisitions, licensing history. The definition and diagram will be refined. "Location" is an example of what might be a common piece of information. Both Electronic and Physical items have "locations". Entitlements have a common set of attributes. "Location" is one example of a common attribute for entitlements. | ||
| 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. | Anne emphasized value of keeping original information in FOLIO when migrating. Marc - Value in distinguishing types of metadata | ||
| 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. | Terms "external" and "internal" may be causing confusion. Key thing, the arrow and Internal Instance knows about the External Instance it was derived from. An internal instance "remembers" it was derived form an external one. Anne - Is Instance "a copy of a record"? Marc - Instance is meant in the BibFrame definition of the word, i.e. 1st edition of a book, but not the specific copy of a book. Lynn - How can linked data be woven into this diagram? Marc - Attributes can be expressed at the Work level, don't need to be re-expressed at the Instance level often. "Trickling down attributes." Lynn - How would we actually connect the FOLIO connect to an external authority record? How then, does that link to discovery? | ||
| Could you please explain “reference cataloging.” | Marc - "Reference cataloging" is the notion that the system remembers the external source of the original metadata. With that remembered by the system, that change can get pulled into the local copy of the record. Lynn - Instead of an internal record, would it make sense to only pull locally needed info and the system an call up the external info as needed? Why bring the whole record into your system when you can pull bits of it and "layer" the parts? Marc - Yes, they have been talking about it this way. Doreen - Example: URL can be institution specific and reside at the most granular level, whereas it is often given at the Instance level.
| ||
| 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 | Marc and Peter will try to answer these questions online, on discuss.folio.org. Paul - Observation: We would want a distributed storage of bibliographic information, where different pieces can reference each other. Reminder: Link to discussion Knowledge Base and Metadata - Scope and Domain |