https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22972
--- Comment #49 from David Cook <[email protected]> --- (In reply to [email protected] from comment #48) > I want to check in as one of the libraries behind this patch, on the > question of whether it's "in tune with MARC." Thanks, Bruno. That's much appreciated. > I'd push back gently on using strict MARC field semantics as the bar here. > MARC was never designed with Linked Open Data or FAIR principles in mind - > it predates them by decades, and its rigidity around what belongs in which > subfield is precisely one of the things libraries are trying to move past. > If we treat "MARC wasn't designed to work that way" as a blocking argument, > we will structurally block almost every attempt to bring external, > resolvable identifiers into bibliographic data, because MARC's field > definitions simply don't anticipate this use case anywhere. Except that Koha is a MARC-based system and it does have $0 and $1 subfields which do work semantically here. > The actual goal of this patch is straightforward: authority records already > accumulate valuable external identifiers (VIAF, Wikidata, ISNI, etc.), and > we want those identifiers to be discoverable directly from the bibliographic > record, not locked behind a join to the authority table that most external > tooling, harvesters, and discovery layers never perform. That's a > FAIR-compliance goal - and it's squarely in the direction libraries are > moving, whether or not it maps onto a pre-existing MARC pattern. Except if we look at the Library of Congress (the entity behind BIBFRAME), we can see that 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. In this example, MARC is actually irrelevant. Conceptually, authority and bibliographic identifiers are kept where they're supposed to be. Authority: https://id.loc.gov/authorities/names/no2015039717.html Bib/Work: https://id.loc.gov/resources/works/24239840.html > On the specific technical objections: they're valid critiques of the current > implementation (handling of repeated fields, $2, UNIMARC scoping, > validation) and the QA follow-ups have already addressed most of them. > That's normal patch maturation, not evidence the underlying idea is wrong. I > don't think "this isn't how MARC traditionally does things" should be > conflated with "this shouldn't be built." It's not about tradition. It's about standards. An open source system like Koha is wonderful because you can see the code and make any changes you want. But that doesn't mean that it's the right decision for all the Koha libraries in the world. > On core vs. plugin: this is a small, opt-in, configurable feature restricted > to MARC21. That's a reasonable footprint which directly serves libraries > actively investing in LOD. It's small but it touches core libraries and it touches them without any system-level configuration/system preference. The only configuration is in the auth type which is a library-level config. It makes Koha's authority system, which is already too bespoke even more bespoke. To me, if you wanted those 024$a identifiers in the $1, I don't see why you wouldn't copy them by hand. Personally, I don't see the merit of including them automatically. Essentially, copying the Auth 024$a into the $1 of the Bib record is just denormalising the data, and for what gain? If it was a display thing, then an API call to fetch the authority data at display time would work well. 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 for the Linked Open Data. I mean that's part of the point of linking. So that you don't have to copy data like this. > In sum, we'd like to keep this moving so that everyone can benefit from this > investment. That makes a lot of sense, and I want to re-iterate that I don't want to be a blocker. I'm happy for people to reset the status. I just want to have people re-consider if this is really the best design for Koha. Thank you for sharing your perspective. It's really valuable. I would love to hear from more libraries interested in working with LoD. And I would love to hear more from you, Bruno, about how you'd like to work with LoD and Koha. The more use cases we get from libraries, the more we can shape Koha to work for you (and other libraries around the world). -- 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/
