Bug 25603 - Add 001 and 003 to biblio table
Summary: Add 001 and 003 to biblio table
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: MARC Bibliographic data support (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-26 10:29 UTC by Magnus Enger
Modified: 2025-04-01 21:44 UTC (History)
7 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Magnus Enger 2020-05-26 10:29:58 UTC
Koha itself does not care too much about these fields, but sometimes they are used when importing/syncing in records from external sources, and then it can be work intensive to match on WHERE ExtractValue( metadata,\'//controlfield[@tag="001"]\' ). This would be much easier if the 001 and 003 fields from the record had their own database columns we could match on. 

Similar to: Bug 11529 - Add subtitle, medium and part fields to biblio table
Comment 1 Andreas Jonsson 2020-05-27 07:01:08 UTC
It would be nice to have one table for control fields and one table for data-fields.  We could make it configurable which fields that should be indexed in these tables if storage space would be an issue.
Comment 2 David Cook 2020-05-27 23:39:07 UTC
(In reply to Andreas Jonsson from comment #1)
> It would be nice to have one table for control fields and one table for
> data-fields.  

I don't think that's ever going to happen, as we're (slowly) trying to get away from MARC.

> We could make it configurable which fields that should be
> indexed in these tables if storage space would be an issue.

We wouldn't make the database schema configurable, and it would be the database indexing that would be valuable here. Indexing database columns for identifiers like 001 and 003 would be very reasonable though.
Comment 3 David Cook 2020-05-27 23:43:58 UTC
(In reply to Magnus Enger from comment #0)
> Koha itself does not care too much about these fields, but sometimes they
> are used when importing/syncing in records from external sources, and then
> it can be work intensive to match on WHERE ExtractValue(
> metadata,\'//controlfield[@tag="001"]\' ). This would be much easier if the
> 001 and 003 fields from the record had their own database columns we could
> match on. 
> 
> Similar to: Bug 11529 - Add subtitle, medium and part fields to biblio table

I'm trying to wrap my head around how we'd do this in practice. In theory, Koha should be resetting the 001 and 003, but it doesn't do that currently. 

I guess you'd be relying on that? Trying to match off the original 001 and 003 to improve the ease of matching records from external sources. I can see the logic there for sure.

Personally, I wish that we'd move the 001 and 003 to the 035 during import, although that would present its own matching problems, plus the 035 is a repeatable field.
Comment 4 David Cook 2020-05-28 00:07:47 UTC
I'm trying to think how we could do this in a more extensible way... and I might have an idea.

MARC:
001 - Control Number
003 - Control Number Identifier
005 - Date and Time of Latest Transaction

OAI-PMH:
identifier
baseURL
datestamp

These two schemas actually overlap pretty much perfectly, and those are the 3 criteria I use when I'm matching for my OAI-PMH imports. 

It's basically a record number, a record origin, and a last modified date. When matching, if the record number and origin match and the inbound record is newer, update the record. Easy.

Thinking about other metadata schemas... 
- Unqualified Dublin Core wouldn't fit that pattern, but that's partially because it's too simplistic of a schema. Qualified Dublin Core could. 
- I don't know BIBFRAME well enough. Looking at https://www.loc.gov/bibframe/implementation/register.html, I see a bf:changeDate. I suppose maybe their "Control Number Identifier" or "baseURL" could be empty since the BIBFRAME URI should be globally unique. Although BIBFRAME is just a whole other ball game anyway...
-MODS has a recordIdentifier for 001, and recordIdentifier "source" attribute for 003, and recordChangeDate for 005...

I suppose the reality is that we just support MARC for the time being, and we have no idea what a post-MARC world will actually look like, so maybe we should just develop against a MARC world.
Comment 5 David Cook 2020-05-28 00:17:53 UTC
But in any case... I think there's a difference between the Koha 001 and 003... and the original 001 and 003. 

I think we abuse the 001 and 003 in Koha, and I'm not sure we should develop functionality to further entrench that abuse.

But I would be interested in a table that tracks record imports better, so that it would be easier to find a local Koha identifier (ie biblionumber / 999$c) that was created during an import using the 001 and 003 (or OAI-PMH identifier and baseUrl).

However, how likely is it for source MARC data to have the 001 and 003 properly filled out? 

Looks like import_biblios has a control_number field, but cleanup_database.pl deletes all the records from the import_* tables periodically, so that's not useful.

Anyway, I'll stop spamming now.

I think that I'm probably just being too idealistic.
Comment 6 Magnus Enger 2020-05-28 07:04:22 UTC
(In reply to David Cook from comment #5)
> But in any case... I think there's a difference between the Koha 001 and
> 003... and the original 001 and 003. 

Could you expand on this? I thought Koha left these alone, pretty much? 

> However, how likely is it for source MARC data to have the 001 and 003
> properly filled out? 

In the case of Sweden and Norway: very. And I bet the Germans do it properly too?
Comment 7 Katrin Fischer 2020-05-28 08:21:53 UTC
> > However, how likely is it for source MARC data to have the 001 and 003
> > properly filled out? 
> 
> In the case of Sweden and Norway: very. And I bet the Germans do it properly
> too?

For libraries participating in a union catalog (a lot) 001 and 003 will be filled out. A lot of libraries not participating still use records from union catalogs in their cataloguing, so there is probably a high percentage there as well.
Comment 8 Katrin Fischer 2020-05-28 20:58:07 UTC
Hm, using ExtractValue is slow, especially on big databases. As Magnus says in lot of use cases a quick access to 001 and 003 for matching is really helpful. We have started to map the biblioitems.ean to 001 for use in reports etc. as the 001 is so important to us. The column is indexed and not mapped by default in MARC21 - but it remains a bit of a workaround and I'd be happy about a real controlnumber column.
Comment 9 David Cook 2020-05-29 00:22:45 UTC
(In reply to Magnus Enger from comment #6)
> (In reply to David Cook from comment #5)
> > But in any case... I think there's a difference between the Koha 001 and
> > 003... and the original 001 and 003. 
> 
> Could you expand on this? I thought Koha left these alone, pretty much? 
> 

It does but it shouldn't ﷐[U+1F923]﷑.

> > However, how likely is it for source MARC data to have the 001 and 003
> > properly filled out? 
> 
> In the case of Sweden and Norway: very. And I bet the Germans do it properly
> too?

I'm sure that's true, but I suppose I'm thinking about all the libraries (like all the ones I support) that don't use it.

But I suppose if it's unused that doesn't really create a problem. And if the database columns were there, maybe we would more highly recommend them to use the 001 and 003...
Comment 10 David Cook 2020-05-29 00:24:28 UTC
(In reply to Katrin Fischer from comment #8)
> Hm, using ExtractValue is slow, especially on big databases. As Magnus says
> in lot of use cases a quick access to 001 and 003 for matching is really
> helpful. We have started to map the biblioitems.ean to 001 for use in
> reports etc. as the 001 is so important to us. The column is indexed and not
> mapped by default in MARC21 - but it remains a bit of a workaround and I'd
> be happy about a real controlnumber column.

Hmm, ok, I think I'm convinced.

We're still living in a MARC centric world, so there's no reason not to add it.

And I doubt Koha will ever use the 001 instead of the 999$c, so even if it isn't ideal from a MARC perspective, it does seem like a practical move. 

I know I hate using ExtractValue in databases in the hundreds of thousands or millions of records O_O.
Comment 11 Mark Hofstetter 2025-03-19 12:12:09 UTC
actually extractvalue is no problem if you do it like this - we have this working for libraries with 1M+ records


alter table biblio_metadata add column   controlnumber varchar(100) GENERATED ALWAYS AS (trim(extractvalue(metadata,'//controlfield[@tag="001"]'))) STORED

create index controlnumber_ind on biblio_metadata (controlnumber);


What we are doing at the moment is to implement OAI-PMH for a customer where the identifier is the controlnumber

So in the OAI method of concern we'll simply look up the biblionumber for the given identifer (in our case the controlnumber) but 001+003 or 035a would also be trivial
Comment 12 David Cook 2025-03-19 23:34:53 UTC
Wait so what's the point of this controlnumber column? How does this affect importing records and sending them out by OAI-PMH?
Comment 13 Mark Hofstetter 2025-03-20 10:35:27 UTC
it helps insofar as you can address a record as quickly (databasewise) with the controlnumber column as with the biblionumber 

so for OAI you can easily a quickly map controlnumber to biblionumber and you are good to go (changing identifer url etc) but in the simplest case for our customer this works:

my ($biblionumber) = $dbh->selectrow_array('select biblionumber from biblio_metadata where controlnumber = ?', {}, $controlnumber);

(with error handling etc)
Comment 14 Mark Hofstetter 2025-03-20 15:15:39 UTC
if that was the question: it does not impact importing (I doubt you could measure the difference)
Comment 15 David Cook 2025-03-20 23:35:04 UTC
(In reply to Mark Hofstetter from comment #13)
> it helps insofar as you can address a record as quickly (databasewise) with
> the controlnumber column as with the biblionumber 
> 
> so for OAI you can easily a quickly map controlnumber to biblionumber and
> you are good to go (changing identifer url etc) but in the simplest case for
> our customer this works:
> 
> my ($biblionumber) = $dbh->selectrow_array('select biblionumber from
> biblio_metadata where controlnumber = ?', {}, $controlnumber);
> 
> (with error handling etc)

I'm sorry I still don't understand. Are you changing your OAI-PMH server code, or is this a custom OAI-PMH server, or something else? 

(In reply to Mark Hofstetter from comment #14)
> if that was the question: it does not impact importing (I doubt you could
> measure the difference)

Magnus said something about importing but I did not understand.
Comment 16 Mark Hofstetter 2025-03-21 11:41:01 UTC
we are changing 

Koha/OAI/Server/GetRecord.pm

my ($controlnumber) = $args{identifier} =~ /^$prefix(.*)/;
my ($biblionumber) = $dbh->selectrow_array('select biblionumber from biblio_metadata where controlnumber = ?', {}, $controlnumber);
 

    unless ($biblionumber) { 
        return HTTP::OAI::Response->new(
            requestURL  => $repository->self_url(),
            errors      => [HTTP::OAI::Error->new( 
                code    => 'idDoesNotExist', 
                message => "There is no biblio record with this controlnumber",
            )],
        );
    }

I am aware that this not a proper patch which can be applied globally, but it's good enough (tm) for us at the moment

what we should be used imho

oai:description/oai_id:oai-identifier/oai_id:repositoryIdentifier

is this to define which identifier is to be used in a given koha-instance
Comment 17 David Cook 2025-03-23 22:26:18 UTC
(In reply to Mark Hofstetter from comment #16)
> I am aware that this not a proper patch which can be applied globally, but
> it's good enough (tm) for us at the moment
> 
> what we should be used imho
> 
> oai:description/oai_id:oai-identifier/oai_id:repositoryIdentifier

I don't understand what you're saying here.

> is this to define which identifier is to be used in a given koha-instance

I still don't understand why it would matter though. The OAI-PMH record identifier just needs to be internally unique within the OAI-PMH server/repository. Technically, it can be arbitrary. 

I'm guessing you're trying to synchronize different systems using a control number which is meaningful in a third-party context? 

Without more information, I reckon this is not the direction we want to be heading with Koha. But I am curious about this use case.

Realistically, we should be moving to UUIDs for Koha internal record identifiers.