Bug 38425 - Add links to full texts based on identifiers
Summary: Add links to full texts based on identifiers
Status: In Discussion
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:
Depends on:
Blocks:
 
Reported: 2024-11-12 14:00 UTC by Alexander Wagner
Modified: 2026-03-06 13:49 UTC (History)
6 users (show)

See Also:
GIT URL:
Initiative type: ---
Sponsorship status: ---
Comma delimited list of Sponsors:
Crowdfunding goal: 0
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
Bug 38425: Add external links based on PIDs (UNIMARC) (11.12 KB, patch)
2025-09-05 15:50 UTC, Ludovic
Details | Diff | Splinter Review
Bug 38425: Add external links based on PIDs (37.32 KB, patch)
2026-03-06 13:46 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.
Comment 10 Ludovic 2025-09-05 15:50:13 UTC
Created attachment 186234 [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
Signed-off-by: Ludovic <ludovic.julien@inlibro.com>
Comment 11 Ludovic 2025-09-05 15:53:05 UTC
Thanks to Alexander for the clear and well-structured patch. Glad to help test it and contribute
to moving this improvement forward, making access to full texts via persistent identifiers easier for everyone.
Comment 12 Lucas Gass (lukeg) 2026-02-13 02:19:25 UTC
(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
Comment 13 Alexander Wagner 2026-02-13 13:27:13 UTC
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.
Comment 14 Lucas Gass (lukeg) 2026-02-13 16:27:52 UTC
Also, we no longer need the CSS part of this patch. See Bug 30148.
Comment 15 Esther Melander 2026-02-13 16:38:19 UTC
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.
Comment 16 Lucas Gass (lukeg) 2026-02-13 16:42:22 UTC
(In reply to Esther Melander from comment #15)
> 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.

I think this certainly warrants more discussion. Setting status as such.
Comment 17 Alexander Wagner 2026-02-16 09:22:41 UTC
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.
Comment 18 Marcel de Rooy 2026-02-16 12:38:53 UTC
Authority records also have 024s where such URIs could be in $1 (or $a?)
See also bug 22972 about putting those in biblio recs too.
Comment 19 Katrin Fischer 2026-02-23 10:00:00 UTC
(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 :)
Comment 20 Alexander Wagner 2026-03-06 13:46:12 UTC
Created attachment 194730 [details] [review]
Bug 38425: Add external links based on PIDs

Render some (common) persistent identifiers from field 024 (Marc21) or
field 017 (UNIMARC) as links to external resources. To this end evaluate
`$2` and the appropriate resolver URL.  Currently implemented values for
`$2`: arXiv, doi, inspire, openlibrary, pmc, pmid, handle.

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.1103/grxd-71sk
   - $2 doi $a 10.3204/PUBDB-2025-05454
   - $2 pmid $a 29942120
   - $2 pmc $a PMC6005330
   - $2 arxiv $a arxiv:2411.05889
   - $2 inspire $a 2835154
   - $2 openlibrary $a OL27448W
   - $2 hdl $a 2128/34598
   (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. Depending on the PIDs in
   the record lines for each type get added, if a PID does not exist no
   line is added, values in 024/017 that are not handled are ignored and
   do not trigger any output. Each line gives the type of the PID in
   front and separated list of all ids of this type expressed as
   clickable links in line with the usual display of Koha. E.g.
   ```
     DOI: 10.1103/grxd-71sk | 10.3204/PUBDB-2025-05454
     PMID: 29942120
   ```
7. Check OPAC detail display of the record. It will show a similar list
   of ids clickable and resolving to the appropriate exteral system.

Technical notes:
- The whole section of links crated is encapsulated in
    `<span class="results_summary resource_list_doi">`
- Each line of a given PID group (e.g. doi) is encapsulated in
    `<span class="results_summary resource_list_doi">`
  where the last term gives the type of the id in question
- The individual elements of the generated `<ul>` are expressed as
    `<li class="resource_doi">`

to allow for styling (incl. supression) via CSS.

Sponsored-by: Deutsches Elektronen-Synchrotron DESY, Library
Signed-off-by: Alexander Wagner <alexander.wagner@desy.de>
Comment 21 Alexander Wagner 2026-03-06 13:49:17 UTC
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.