[Koha-bugs] [Bug 24544] Add a script for inserting persistent identifiers to MARC records

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24544

--- Comment #13 from Marcel de Rooy <m.de.rooy at rijksmuseum.nl> ---
(In reply to David Cook from comment #11)
Thanks for your feedback.

> Personally, I think that it would be better to add a plugin to the
> authority/biblio/item records and allow you to mint PIDs while cataloguing.
> That's how most systems I've used have worked.

See also comment9. I chose here to not add stuff directly to core Koha
routines. But work my way thru the data with a cron job. Surely this would be a
next step. Problem with a cataloguing plugin is that you just know the record
number only after saving  it. Although a PID generator might theoretically not
need it, many implementations, including my own, do use it.

> That said, sometimes you want to batch mint PIDs, but I think that would be
> up to the entity doing the batch work. I don't see why we'd need anything
> special for that in Koha.

Not sure how much you saw from the patches, but this patch set provides an
interface via plugins to an external PID service.

> Or are you trying to create a local Koha PID minting service? If that's the
> case, I think storing the data in MARC fields is not a wise direction. It
> would be better to have a Koha PID lookup table mapping the PID to the
> record, so that PID resolution could be handled that way.

See before. No Koha should not mint its own PIDs. Formally the PID generator
may have its own PID lookup table. We do not really care here. (My local
generator does not, since it is based on a Koha identifier. Its result can be
found with a Standard-identifier index in Koha or even another future ILS. In
that way actually turning my ES or Zebra index into a PID lookup table..)
But even with a full resolver having its own table, I would still argue to save
a copy of the PID in the MARC record too for optimization, while respecting the
lookup table as authoritative.
As a side note: Could you give me another example of vital data on biblio level
that we do not store in MARC? Not meaning optimization or calculated aggregates
etc.

-- 
You are receiving this mail because:
You are watching all bug changes.