https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38425 Alexander Wagner <alexander.wagner@desy.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|oleonard@myacpl.org |alexander.wagner@desy.de -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38425 Alexander Wagner <alexander.wagner@desy.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Small patch Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38425 --- Comment #3 from Alexander Wagner <alexander.wagner@desy.de> --- @Igor as I don't know a thing about UNIMARC: Is 017 working the same way as `024 7_` in Marc? Any indicators that should be taken into account? How are the subfields to be used? Just the same? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38425 Alexander Wagner <alexander.wagner@desy.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #174425|0 |1 is obsolete| | --- Comment #5 from Alexander Wagner <alexander.wagner@desy.de> --- Created attachment 181974 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=181974&action=edit Bug 38425: Add external links based on PIDs in 024 Render some (common) identifiers field 024 as links to external resources by evaluating `$2` and using the appropriate resolver URL. Currently implemented values for `$2`: arXiv, doi, inspire, openlibrary, pmc, pmid. The patch includes adds the class `resource_list` to the intranet scss to be able to use the identical XSLT code as for the OPAC. Test plan: 1. Open intranet interface and edit any record 2. Add several 024 fields with the following subfield layout: - $2 doi $a 10.2147/CIA.S157877 - $2 pmid $a 29942120 - $2 pmc $a PMC6005330 - $2 arxiv: $a arxiv:2411.05889 - $2 inspire $a 2835154 - $2 openlibrary $a OL27448W (May be all or any combination. The values of $a would not matter, the above just gives valid links to the external system in question.) 3. Check intranet detail display of the record: nothing appears 4. Check OPAC detail display of the record: nothing appears 5. Apply the patch 3. Check intranet detail display of the record. It now gives a new line: External Resource(s): <here links to whatever was added in step 2) The ids are clickable and lead to the external system 4. Check OPAC detail display of the record: External Resource(s): <here links to whatever was added in step 2) The ids are clickable and lead to the external system Sponsored-by: Deutsches Elektronen-Synchrotron DESY, Library -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38425 Alexander Wagner <alexander.wagner@desy.de> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=39852 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38425 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lucas@bywatersolutions.com --- Comment #7 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- *** Bug 39852 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38425 Roman Dolny <roman.dolny@jezuici.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=37995 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38425 Ludovic <ludovic.julien@inLibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #181975|0 |1 is obsolete| | --- Comment #10 from Ludovic <ludovic.julien@inLibro.com> --- Created attachment 186234 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=186234&action=edit Bug 38425: Add external links based on PIDs (UNIMARC) Render some (common) identifiers field UNIMARC 017 as links to external resources by evaluating `$2` and using the appropriate resolver URL. Currently implemented values for `$2`: arXiv, doi, inspire, openlibrary, pmc, pmid. The patch includes adds the class `resource_list` to the intranet scss to be able to use the identical XSLT code as for the OPAC. Test plan: 1. Open intranet interface and edit any record 2. Add PIDs to your records. For Marc21 use `024 7_` for UNIMARC use `017 7_` with the following subfield layout: - $2 doi $a 10.2147/CIA.S157877 - $2 pmid $a 29942120 - $2 pmc $a PMC6005330 - $2 arxiv: $a arxiv:2411.05889 - $2 inspire $a 2835154 - $2 openlibrary $a OL27448W (May be all or any combination. The values of $a would not matter, the above just gives valid links to the external system in question.) 3. Check intranet detail display of the record: nothing appears 4. Check OPAC detail display of the record: nothing appears 5. Apply the patch 6. Check intranet detail display of the record. It now gives a new line: External Resource(s): <here links to whatever was added in step 2) The ids are clickable and lead to the external system 7. Check OPAC detail display of the record: External Resource(s): <here links to whatever was added in step 2) The ids are clickable and lead to the external system Sponsored-by: Deutsches Elektronen-Synchrotron DESY, Library Signed-off-by: Ludovic <ludovic.julien@inlibro.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38425 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |esther.melander@bywatersolu | |tions.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38425 --- Comment #13 from Alexander Wagner <alexander.wagner@desy.de> --- AFAIS one could indeed do it with the procedures of Bug 39860. But then you'd need to do it on every instance individually, right? It moves more from a default behaviour to some customization. Indeed, if we do not want it as a default behaviour of Kohas, I'd go with 39860 on our instances once it is in the upcoming stable, so thanks for this pointer :) Anyway, my main concern with the hard coded links was the hard-coding of "magic strings". This is IMHO not nice, and also does not scale well if new ids should be added. OTOH for the use case here it's also not entirely bad, as it refers to base-URLs of PID-resolvers. So, yes, `http://dx.doi.org/` should read `https://doi.org/` these days, but this was also the only change of this kind we experienced in our old system in the past 10 years or so. Probably, I changed a few http calls to https as well, which is also not that common and mainly a point for not storing https://doi.org/<doi>, but just the DOI and leave the rest to the display logic. And of course one could streamline the code if we could just use a hash for the base urls. Something like `{'doi': 'https://doi.org/%s', 'pmid': 'https://pubmed.ncbi.nlm.nih.gov/%s'}` and loop over it. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38425 --- Comment #15 from Esther Melander <esther.melander@bywatersolutions.com> --- I wonder if this idea needs more discussion? While I can see the usefulness of a link, it does need some more consideration. 1. The structure of the source code is explained by Library of Congress. The documentation does not discuss a link. https://www.loc.gov/standards/sourcelist/index.html#structure 2. The 024 tag does not include a way to customize the link with a $u (link) or $y (link text). That means there will need to be hardcoded links, which are difficult to update and customize. Would the link would go to the primary domain of the source, and not directly to the item? https://www.loc.gov/marc/bibliographic/bd024.html 3. If the code functions as the link text, the code may not convey enough meaning to the average user of what it is. 4. There are multiple fields, such as topical terms, that have a $2 source code. These do not display or function with links. Adding links to the $2 of the 024 would be inconsistent to how the field is normally used. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38425 --- Comment #17 from Alexander Wagner <alexander.wagner@desy.de> --- 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.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38425 --- Comment #19 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Lucas Gass (lukeg) from comment #12)

(In reply to Roman Dolny from comment #8)

...

There is also a suggestion in Bug 37995 (authority context, but similar to the application here) to avoid hard-coded names/identifiers/uri and introduce system preferences to make it more configurable and maintainable for libraries.

Yes, I don't think these links should be hard coded. If this display needs to be customized maybe it's a good use case for Bug 39860:

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

I don't quite see the reason for the resistance here as it would only affect libraries with 024 in their data and we had a lot of requests about showing this kind of information (especially DOI) from our academics in the past. Passing structured data to XSLT is a pain and while bug 39860 is nice, it's still a barrier for a lot of libraries as it's too close to programming to be comfortable. I don't see how it would hurt to addd the most common $2 directly to the templates to avoid these issues and make it easier for libraries. For the URLs: I don't see the risk of them changing as a blocker, we have also a similar mechanism for OPACAuthorIdentifiersAndInformation and 024 from authority data. Since it's introduction there was neither a rush to add many additional codes nor a change in the URLs. We also added links there, because it improves the usefulness of seeing the identifiers immensely. I don't understand the push against a link since the source determines where it should link to rather clearly and it's an added benefit for the user. All the requests we had for DOI asked for a linked version. The info can also be easily hidden if we add individual CSS classes for each, would that be a good compromise? That said, I'd suggest some changes: 1) Patch currently doesn't apply and needs a rebase. 2) Check for existing 024 will add label if 024 exists in any case. + <xsl:if test="marc:datafield[@tag=024]"> This means the label will display when there is at least one 024, even if the code doesn't match any of the implemented ones. I think it might be easier to implement as individual label + code link pairs instead of a list under a shared label. with classes built from the $2 libraries could then also easily hide or customize entries individually. It would also be a litte more consistent with our current way of display. My local DOI snippet looks something like this: <!-- 024 - DOI --> <xsl:template name="doi"> <xsl:if test="marc:datafield[@tag=024]/marc:subfield[@code='2'][contains(.,'doi')]"> <span class="results_summary doi"> <span class="label">DOI: </span <xsl:for-each select="marc:datafield[@tag=024]/marc:subfield[@code='2'][contains(.,'doi')]"> <a> <xsl:attribute name="href">https://doi.org/<xsl:value-of select="../marc:subfield[@code='a']"/></xsl:attribute> <xsl:attribute name="target">_blank</xsl:attribute> <xsl:value-of select="../marc:subfield[@code='a']" /> </a> <xsl:choose><xsl:when test="position()=last()"><xsl:text></xsl:text></xsl:when><xsl:otherwise><span class="separator"> | </span></xsl:otherwise></xsl:choose> </xsl:for-each> </span> </xsl:if> </xsl:template> I am no longer sure why I used contains ... it's been a while. And the separator should be updated to use the new CSS solution :) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38425 --- Comment #21 from Alexander Wagner <alexander.wagner@desy.de> --- In the last commit I simplified the code, removed the superfluous css and aligned it with the usual display conventions outlined by @cait. Note that this has the additional side effect that it becomes IMHO much clearer which persistent ids are handled and which (persistent) resolver-urls are used. -- You are receiving this mail because: You are watching all bug changes.