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 <[log in to unmask] 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
>>