https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22972
--- Comment #50 from [email protected] <[email protected]> --- Hi David, Thanks for the detailed response, and for staying engaged even though we disagree. I'd like to address several of your points directly. > "Except that Koha is a MARC-based system and it does have $0 and $1 subfields > which do work semantically here." $0 indeed works for the local authority link. But $1 in bibliographic records is still relatively rarely used in production, despite being defined for Real World Object URIs. The fact that it "works semantically" per the MARC documentation for a different purpose doesn't mean this use is wrong - it just means it hasn't been exercised this way yet. Every extension of practice has to start somewhere. > "Except if we look at the Library of Congress [...] they don't bring in all > those valuable external identifiers into the Bib/Work. They keep them in the > Authority record which is linked from the Bib/Work." That's true for the LoC ecosystem, where every consumer of bibliographic data is assumed to also be able to resolve the authority side via id.loc.gov. That's not the reality for many Koha installations. Our bib data constantly leaves the system without the authority records attached: OAI-PMH harvesting, MARCXML export to union catalogues, indexing into Solr/Elasticsearch for discovery layers, data exchange with APIs, etc. All of those consumers see only the bib record. If the external ID lives solely in the authority, it's invisible to that entire chain unless every downstream consumer sets up a live link into our Koha authority table - which in practice nobody does. > "To me, if you wanted those 024$a identifiers in the $1, I don't see why you > wouldn't copy them by hand. [...] I don't see the merit of including them > automatically." Copying by hand undermines exactly what authority control is for: one point of maintenance, automatically consistent everywhere the authority is used. With hundreds or thousands of bib records linked to a single authority, manual upkeep isn't realistic, and any correction or merge of the authority would again require touching every linked record by hand. That's precisely the problem authority control already solves for $a/$9; we're only asking to extend that same logic to $1. > "Essentially, copying the Auth 024$a into the $1 of the Bib record is just > denormalising the data, and for what gain?" Yes, it's denormalisation - just like the 6XX$a we already populate with the authority's preferred term, or the $9 we already populate with the authid. Denormalisation for the sake of portability is already standard practice in library data, not an exception. The gain is that the external identifier can leave the bib record without requiring an extra join. > "If it's 3rd party tools, why would they be interested in the other $1 URLs? > Surely, it would be enough to link to 1 $1 URL to create the linkage." There isn't one universal "best" identifier: one consumer wants Wikidata (as we do – it's a citizen science-compliant recognized Digital Public Good), another wants VIAF (which is mostly included in Wikidata entities), another wants ISNI, etc. Multiple $1s let each consumer pick up the identifier relevant to their use case, without us as a library having to decide in advance which consumer we're serving. Finally, you're right that this sits in core and that the configuration is at the authority-type level rather than a system preference. That seems like a fair point to carry into further QA - an explicit system preference to toggle this globally could address the concern about "silent, bespoke behaviour." But the core point stands for us: without this, external identifiers stay locked in the authority silo, invisible to anything outside Koha itself. That's exactly the problem the Semantic Web is meant to solve, and it's why we consider this worth pursuing further - not out of stubbornness, but because it answers a real interoperability problem. Happy to keep working toward a form that's also acceptable to you - a system preference layered on top, for instance. Best, Bruno -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected] website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
