Re: [CODE4LIB] UUIDs in MARC 001

[Andy Kohler]

I think the 001 only has meaning within the current system in which the
MARC record is stored.  It's the local control number and on its own has no
meaning outside of that system.

Presumably your records also contain an 003 field, a control number
identifier, so that if another system were to ingest records exported from
yours, the 001 and 003 together would have the proper context.  The
ingesting system probably would move the 001/003 to a new 035 field, and
replace the 001 with their own local identifier.

So, your use of a UUID in 001 should be fine, as long as you provide an
003.  Other systems should move your UUID to 035 on ingest, and assign the
new record an 001 which has meaning within their own system.

Andy Kohler / UCLA Library IT
akohler...@gmail.com

On Thu, Dec 20, 2018 at 8:50 AM Sebastian Hammer 
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-42665544
>
> 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
>

Re: [CODE4LIB] Interest in serial summary holdings parsing?

[Andy Kohler]

Hi Joe -

I'm https://github.com/akohler

Thanks --Andy

On Wed, Oct 11, 2017 at 12:13 PM, Joe Ferrie  wrote:

> Hi Andy,
>
>
> We are still working on the license terms before opening the project, but
> if you can give me your github account name I will send you a link.
>
>
> Wariness is understandable -- this works on very dirty data.
>
>
> Once you are added to the project you can look at our test cases in:
>  resources/test_holdings.xml>
>
>
>  resources/test_holdings.xml>
>
> https://github.com/cdlib/hparser/blob/master/src/test/
> resources/test_holdings.xml
>
>
> to see samples of the type of statements that it parses.
>
>
> We haven't had a lot of time to put into this project, so our hope is to
> find collaborators who can help us move forward  on improving it and adding
> some capabilities. We are currently using it production to find the
> earliest and last years held.
>
>
> Joe
>
>

Re: [CODE4LIB] Interest in serial summary holdings parsing?

[Andy Kohler]

"Interest" might be less appropriate than "wariness"... but sure.  My
institution (UCLA) is one which contributes holdings to these projects.  I
haven't done any 866 parsing in a long time, but have written (perl) code
to fix 85x/86x sequencing problems in the LHRs we generate for OCLC, so I
know my way around our holdings records.

Andy Kohler / UCLA

On Mon, Oct 9, 2017 at 8:25 AM, Joe Ferrie <joe.fer...@ucop.edu> wrote:

> We have some (Java) code at California Digital Library that parses serial
> summary holding statements derived from MARC holdings records, and are
> thinking of making it its own open source project. We would be interested
> in knowing if anyone would be interested in using the code  or working on
> it, and whether you already have code that does similar parsing.
>
>
> Our main use cases for this are determining which institutions in our
> consortium hold a specific year of a serial title for purposes of
> consortial resource sharing, and also which institution holds the deepest
> backlog of a title in the WEST shared print program.
>