Kyle,
This is actually very good advice. We can't rely on any receiving system
not munging, overriding, or otherwise fiddling with our 001. For that
reason alone, if the UUID is important to us, it makes more sense to put
it elsewhere in the record if we care about finding it later.
--Sebastian
On 12/21/18 9:55 AM, Kyle Banerjee wrote:
I would advise against using 001 for this purpose and using 035 instead.
Although use of 001 varies, it's most often used as an internal matchpoint.
This means using it all but guarantees that the field already has a
competing use in the system -- making it a questionable idea to accept
them. Be aware that systems may have validation or normalization rules that
choke on your syntax or significantly modify the value.
It's not safe to presume any specific behavior on ingest into another
system as this is determined by whoever set up the load process. It's
totally legit for a system to spit the record out, strip the field,
normalize it (e.g. strip nonnumeric data), map it to another field, or
accept it as is.
Kyle
On Thu, Dec 20, 2018, 11:50 AM Sebastian Hammer <[email protected] wrote:
Hey folks,
The FOLIO LSP uses UUIDs
(https://en.wikipedia.org/wiki/Universally_unique_identifier) internally
to uniquely identify all things, including bibliographic instances. When
exchanging instance entities with other systems using MARC
(bibliographic), we'd kind of like to use those UUIDs as our 001
identifiers since they're the closest thing to a true system ID we have.
But I wonder if anyone has tried this and experienced problems with MARC
consumers croaking on something like
001 123e4567-e89b-12d3-a456-426655440000
which is not your grandfather's identifier. The LOC MARC documentation
is silent on the length of the 001 field but the MARCBreaker/maker
software recommends staying within 12 characters... I can imagine if
some systems wanted to stick the identifier in a fixed-with database
table, hilarity might ensue.
Any thoughts?
--Sebastian
