Bug 38425 - Add links to full texts based on identifiers
Summary: Add links to full texts based on identifiers
Status: Needs Signoff
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low enhancement
Assignee: Alexander Wagner
QA Contact: Testopia
URL:
Keywords:
: 39852 (view as bug list)
Depends on:
Blocks:
 
Reported: 2024-11-12 14:00 UTC by Alexander Wagner
Modified: 2025-05-08 16:11 UTC (History)
4 users (show)

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


Attachments
Bug 38425: Add external links based on PIDs in 024 (11.90 KB, patch)
2024-11-12 16:39 UTC, Alexander Wagner
Details | Diff | Splinter Review
Unimarc 017 (96.63 KB, image/png)
2025-05-05 08:56 UTC, Igor A. Sychev
Details
Bug 38425: Add external links based on PIDs in 024 (11.90 KB, patch)
2025-05-06 13:55 UTC, Alexander Wagner
Details | Diff | Splinter Review
Bug 38425: Add external links based on PIDs (UNIMARC) (10.93 KB, patch)
2025-05-06 13:55 UTC, Alexander Wagner
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Wagner 2024-11-12 14:00:18 UTC
Marc21 allows to add persistent identifiers to `024 7?` by means of subfields `$2` and `$a`. E.g. one could give the DOI of an eBook as 

```
024 7_ $2doi $a 10.000/123.456.789
```

For `$2` the LoC refers to the list of standard identifiers, that is actually quite long:

https://www.loc.gov/standards/sourcelist/standard-identifier.html

Currently, it seems Koha creates a link only if there is a URL in `856 4_` which requires duplication of data. Especially of scientific libraries it would be helpful if ids pointing to "well known" services that assign PIDs would also trigger such a display to point the users to the full texts.

The most relevant in this context seem to be:

- DOI
- PMID 
- PMC
- arXiv
- handle
- urn

In other contexts OpenLibrary was also mentioned.
Comment 1 Alexander Wagner 2024-11-12 16:39:08 UTC
Created attachment 174425 [details] [review]
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
Comment 2 Igor A. Sychev 2025-05-05 04:36:04 UTC
Good idea. 
Please add it also for UNIMARC. 
017 in UNIMARC.
Comment 3 Alexander Wagner 2025-05-05 07:18:34 UTC
@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?
Comment 4 Igor A. Sychev 2025-05-05 08:56:15 UTC
Created attachment 181900 [details]
Unimarc 017

Very similar, see attachment.
Comment 5 Alexander Wagner 2025-05-06 13:55:19 UTC
Created attachment 181974 [details] [review]
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
Comment 6 Alexander Wagner 2025-05-06 13:55:21 UTC
Created attachment 181975 [details] [review]
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
Comment 7 Lucas Gass (lukeg) 2025-05-08 14:44:34 UTC
*** Bug 39852 has been marked as a duplicate of this bug. ***
Comment 8 Roman Dolny 2025-05-08 16:00:55 UTC
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.
Comment 9 Alexander Wagner 2025-05-08 16:11:31 UTC
I agree that a procedure that basically uses a hash of the form

{ id -> resolver }

would be more convenient. This is how I did it in our old system.

However I am not (yet) aware of how to do this in Koha given the XSLT required. I'd need a helping hand here and happily recode. IOW how do I access a system pref, that should actually also be a structured variable, from XSLT? Is there some sample where something along those lines is already done?

Wrt Bug 37995 I think we could even share the same hash for id -> resolver for both authorities and bibliographics. IMHO the orcid resolver would live happily along the doi resolver eg. and they wouldn't hurt each other.