https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38425
--- Comment #17 from Alexander Wagner <[email protected]> --- Just to add to the discussion. I admit that what I implemented are very well known ids in a _scientific_ context. (Probably openlibrary being a corner case in this regard.) Let's take a look at DOI as the most well known kind of ID in 024 as a guinea pig here. The others really work the same way. > 1. The structure of the source code is explained by Library of Congress. The > documentation does not discuss a link. Agreee, wrt the documentation at LoC. But just printing these ids without a link behind them seems a bit strange for an _online_ catalogue and in 2026 where we do have Internet almost everywhere available all the times. Especially, if we look right now at a Koha landing page. So, I do not see a point in asking the user to copy & paste said IDs and transfer them to the proper resolvers manually. I mean, their purpose is to be resolve not to be printed. In this regard they differ from ISBN or ISSN which do not naturally resolve unambiguously. > 2. The 024 tag does not include a way to customize the link with a $u (link) > or $y (link text). Well, there is no need to customize anything here in the first place. These IDs (at least the ones I implemented in the code) have exactly one proper way to resolve and their value (probably with a prefix like `doi:`) is enough for users in question to know what the links will do and where they will lead them. IOW cataloguing $u would indeed be wasting time and resources: it should definitely be the same for all ids of a kind and adding some "flavour text" doen't help the user either, but would rather confuse the issue. Again, if one would really like this flavour text it would only make sense to add it automatically so it is the same for each ID of a kind in every record. Instead of printing the doi one could indeed create a link with a text like `See resource at the publisher`. However, this would deny the user to use the DOI e.g. to copy it to her literature management system or any other tool (e.g. the local publications database or CRIS system) she wants to feed the DOI into. So IMHO there is a reason to also print those ids literally and not hide them. > That means there will need to be hardcoded links, which are difficult to > update and customize. I agree. That's why I would prefer a hash that gives the resolver per id source and that's evaluated in the code. It scales better and easier to maintain. However, as mentioned, these resolvers are very stable even for a library. (For IT, eternity is usually 5 years, so they live way longer than "forever".) These resolver URLs are are _not_ URLs who usually are dead the moment you call them. As mentioned, we do have these links in join2 for nearly 15 years now and the updates I applied in join2 during that time were http://dx.doi.org/%s -> https://doi.org/%s (the old link still works, we just adopted CrossRefs recommendation for new systems) and to replace http -> https everywhere. In the latter case also all http-calls forward silently to https. IOW if I would have done nothing everything would still work. So, it's definitely not "adding URLs" which would indeed be a maintenance nightmare. So one could also live with some hard coded urls. Long story short: the code could be improved by said hash, but its not a deal breaker in my opinion. > Would the link would go to the primary domain of the source, and not directly > to the item? Usually, they link to the full texts (doi, arxiv, pmc) or very well known and established free literature databases in the field that offer additional services beyond the scope of Koha (eg. pmid for all medicine related sciences). So they do add quite some value to the user in areas where they are applicable. One could consider to extend it to persistent ids minted by open access repositories, e.g. handle used by DSpace repos. I also mentioned urn in the original issue, however to my knowledge there is no _universal_ resolver for URNs so they failed to fit the bill. openlibrary is probably the "worst" of the bunch, where I also don't know the stability. (AFAIK it is pretty stable though.) I added it as there was an explicit request to add openlibrary ids also to fetch covers. In my setting this is a bit out of the scope, but in my catalouge we just don't have openlibrary ids so issue solved. :) BTW: if we could somehow introduce the mentioned hash that tells the code `resolve x -> by y` one could pre-seed it with all well known ids and individually "switch off" unwanted ids easily by removing the resolver from the config. That's how I did it in join2, but all our instances provide all resolvers so one might also call this over-engineering. > 3. If the code functions as the link text, the code may not convey enough > meaning to the average user of what it is. I would disagree here. Sticking to the doi, I do understand that this would not convey enough meaning in e.g. a childrens library, of course. But you'd hardly ever catalogue a doi in this setting anyway. It will pop up quite a bit in scientific libraries and your scientists will know the doi (and(!) wonder quite a bit if you just print them and not add the proper link to the full text underneath). > 4. There are multiple fields, such as topical terms, that have a $2 source > code. These do not display or function with links. Which may be a pity for an online catalogue, but out of the scope for this issue. ;) Still note the slightly different meaning of source here. In 024 we can use the source in quite a few cases to construct an unambiguous link. So they convey a way to construct links to a resource, I do not have locally available. One might consider adding those links along the links generated via 856, if this is visually preferred. Still note that for a proper complete citation the doi should also show up with the citation. So these days it should read something like (style details may vary): Physical review letters 136(4), 043001 (2026) [10.1103/bvqj-pm3n] and not only Physical review letters 136(4), 043001 (2026) and leave the user to resolve the bibliographic blurb even though there is an unambiguous link via the doi. For topical terms OTOH, eg. if we know they are from Mesh this would not work. They do not point to "the resource(tm)". One could construct a link to Pubmed based on Mesh-terms that triggers a search there, which would be quite helpful for some, but also compete with the link of the topical term within your own catalogue. Hm. One could use LCSH to link to the LoC catalogue. Probably interesting, but I'd have to cross the Atlantic to make use of the resource just discovered. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
