Authorities FAQs
This page provides details as to the decision to add authorities to mod-inventory-storage.
Question | Response |
---|---|
Why add authorities to mod-inventory-storage? | Managing authorities in FOLIO is a critical need. Institutions have not/will not migrate to FOLIO until it is available. MM SIG outlined this need when it collected and prioritized key MARC features in FOLIO. When outlining search requirements for MARC authority app, it was decided to use Elasticsearch. Elasticsearch is a full text search engine for quick and robust search of data. Mod-search is created for working with Elasticsearch in FOLIO. This module provides universal mechanism to index entities and perform search over them. The mod-search is capable to make specialized parsing required for MARC format. So we developed a general authority schema NOT based on MARC. So then the question came where do we store these records? Decision was made to store in mod-inventory-storage since we can fully reuse the mechanism, that is implemented for instances which simplified development for the Lotus release. AND it also supports future development such as 1.) linking authority records to bib/instance records AND 2.) non-MARC authority record support. |
Why not create a new module (e.g. mod-authorities) to store authority records? | To ensure authority development was completed in the Lotus release, a decision was made to implement in the same way we support searching instance/holdings/items which is to index and search the records stored in mod-inventory-storage. |
Are we storing authority records in mod-inventory-storage because of a limitation in mod-search? | No. To ensure authority development was completed in the Lotus release, a decision was made to implement in the same way we support searching instance/holdings/items which is to search records stored in mod-inventory-storage. |
Are the authority records stored in mod-inventory-storage following MARC standards? | No. The records stored are not MARC. The records stored follow a generic schema that is somewhat similar to SKOS. |
How does this implementation support FOLIO's commitment be NOT MARC-centric? | Authority records stored in mod-inventory-storage do not follow MARC standards. It follows a generic schema. Its implementation is NO different from instance/holdings implementations whereby the underlying source is MARC and that MARC record is stored in source record storage. The implementation supports future development of an authority record that does NOT have a record in mod-source-record-storage and underlying source = MARC. IOW, it supports development of a FOLIO authority record where source = FOLIO. Our development is the reverse of past development efforts. Those efforts began with the development of a record with source = FOLIO stored in mod-inventory-storage THEN came the development of a record with source = MARC stored in mod-source-record-storage FOLLOWED by the connection of the that MARC record with the corresponding Inventory record stored mod-inventory-storage. Our development supports the above with the exception no display of the FOLIO Authority record. |
How does this implementation impact Entity Management Working Group objectives? | Hopefully it supports the objectives with the development of a FOLIO authority record. |
Can this implementation now support mod-inventory-storage storing authority records NOT in MARC? | Yes. There is additional work to expand the schema and to support the display of the FOLIO authority record. |
Any performance testing conducted? | |
Was the authority.json schema vetted by SMEs? What is it based on? | Yes, the schema was discussed at October 13th quickMARC subgroup meeting. We did have a member review the schema against SKOS and outline differences. |
My institution will not use the MARC authority app because we do not have any authority records in MARC. Are we required to install this app? | No. |
Any plans to support an Authority record with Source = FOLIO? | Our development set the foundation but it will be up to the community to decide the priority for this work. Our work will continue to address the critical features outlined by the MM SIG in Dec 2020 and by quickMARC subgroup priorities. |