In the latest versions of FOLIO that allow the viewing of associated MARC records from Inventory.
To reproduce: Go to FOLIO snapshot or FOLIO testing and look for a long title in the Inventory. When you display the detail instance record, you'll see a button for View source. Press the button.
the control field "001" should have that record's UUID. Instead, the record seems to contain a pre-existing identifier from another system or possibly an identifier created by a person.
This could be because the import tool is not yet built and operating and the records were loaded manually. But,
the MM SIG has decided that 001 should contain a human readable id in 001. This is problematic for multiple reasons:
1. 001 should be the system control number as defined by the MARC standard. The convention as per MARC is:
System Generation - Field 001 may be system generated. The structures of the Library of Congress and Library and Archives Canada control numbers are described in Input Conventions under field 010 (Library of Congress Control Number) and field 016 (National Bibliographic Agency Control Number), respectively. }}
While the text above uses the word "may", this has been the case for every system in existence for the last 20 years. A human provided human readable identifier is not used by the system, The UUIDs are. And, isn't MARC by definition "MAchine-Readable Cataloging"? Therefore if the library wants a more human readable ID, it should reside in some other field in the MARC record. In fact, one can easily argue that a human readable ID is really a Tag which is yet another option that could be used to handle this.
2. The unique system identifier is needed by external systems such as resource sharing, Union Catalogs, OAI-PMH harvesters, Discovery services and others. Eliminating the UUID might make it impossible for those external systems to retrieve and store the UUID which can break functionally of those systems. So this creates a legacy support issue.
3. There have been discussions for the need of human readable identifiers and that UUIDs are not human readable. However, UUID are letters and numbers just like any other identifier created by systems today and have the benefit of being nicely formatted with dashes. Why is this worse than existing systems identifiers? UUIDs are actually MORE human readable. And if the ID is needed for human communication, simply "copy and paste" as one would do with a human readable ID as well.
4. UUIDs are unique across FOLIO instances and tenants no matter the number of FOLIO installs and locations which make UUIDs especially useful for Union catalogs and resourcing systems. Today, huge amounts of effort go into trying to make existing data merge and de-dupe and be unique across systems because of the lack of a unique identifier. UUIDs provide FOLIO libraries world wide a special and unique advantage that most other systems lack. Eliminating UUID's from the record force FOLIO libraries to continue to work in the costly manner that they have for the last 20 years.
5. Has a thorough investigation been carried out to understand what the impact of this (HRID) data in 001 be throughout the rest of FOLIO? What are the implications?
6. FOLIO already has a system generated and unique control number. Handling HRIDs this way is building a parallel ID system that generates more complications in terms of extra code created to support this functionality that needs to be tested and debugged when one already exists. This is extra work that the project does not need right now. It's already causing some confusion with some of the dev teams that are encountering it as to what should be used as "the" unique identifier.
A new MARC field/subfield should be selected for human readable IDs for use by humans and it should be indexed to be used for searching by humans.