[Koha-bugs] [Bug 29897] Display author identifiers for researchers

[bugzilla-daemon at bugs.koha-community.org]

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

Katrin Fischer <katrin.fischer at bsz-bw.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Signed Off                  |Failed QA

--- Comment #26 from Katrin Fischer <katrin.fischer at bsz-bw.de> ---
I'd really love to have this feature, but going through the code sadly found a
bigger issue with the specification :(

I am making this 0) now, although I caught it last at the bottom of the source
tree:

0) Linkage $6

In your code you assume that $6 is a URL, but that will NEVER be the case
according to MARC standard.

$6 is a very specialized field that will never contain a URL. Linkage here
means 'linking MARC fields within the record'. For example it is used to link
an original script tag with the corresponding tag in transliteration. See:
https://www.loc.gov/marc/authority/ecadcntf.html

So I don't think we can push this as is. :(

If at all, a link would probably be in $1, but that's a quite new field and
quite unlikely. I think our best bet for a universally working feature right
now is to buidl the URLs to the corresponding portals using the cataloged IDs
form $a ourselves.

This also means, that we should limit our efforts on a short list of $2 codes
for now. The 4 you have in there would be fine with me. We could add others
later. 

We should also limit $2 display to the ones we have implemented and checked,
some are just not useful to patrons.


1) Missing POD for _get_marc_authors

Could it be a little confusing having _get_marc_authors and get_marc_authors?

2) On get_marc_contributurs, you write:

(700..712 for MARC21)

but:

+    if ( $marcflavour eq "UNIMARC" ) {
+        $mintag = "700";
+        $maxtag = "712";
+        $fields_filter = '7..';
+    } else { # marc21/normarc
+        $mintag = "700";
+        $maxtag = "720";
+        $fields_filter = '7..';
+    }

Overall using a range instead of a list seems a little risky, but works for
MARC21. It looks like a lot of fields, but actually it's only: 700, 710, 711
and 720. 
(https://www.loc.gov/marc/bibliographic/bd70x75x.html)


3) Missing 110, 111

If we get 710 and 711 we should probably include 110 and 111 in
get_marc_authors as well. As it was 'wrong' before, should we file a separate
bug report to extend this method?

4) Pref description

I am struggling a bit with the description.

[Display|Don't display] author identifiers for research publications.

It makes it sound, like it was limited to research publications, while the
limit is actually the 024 existing or not.

Adding information that this requires authorities and 024 would be good I
think. Maybe:


[Display|Don't display] identifiers for authors and contributors to the detail
pages in the OPAC. This feature requires authorities with 024


5) Selection of $2

+  [% CASE 'orcid' %]ORCID:
+  [% CASE 'scopus' %]ScopusID:
+  [% CASE 'loop' %]loop:
+  [% CASE 'rid' %]Publons:

a) Should these be surrounded by <span>?
b) $2 are usually taken from the official LOC list:
https://www.loc.gov/standards/sourcelist/standard-identifier.html

orcid = ORCID OK
scopus = ScopusID OK
loop = doesn't exist in official list. I am fine with it if that is a custom
one, but maybe worth checking?
rid = ResearcherID, linking to:
http://www.researcherid.com/#rid-for-researchers, stating:
ResearcherID profiles moved to Publons on 15 April 2019 - so probably OK

viaf might be a good candidate (for another bug).

The fallback worries me: 
[% CASE %][% identifier.source | html %]:

I think we should stick with a hardcoded list as not all $2 codes and
identifiers are useful to patrons (and they might get into the catalog, if you
use a central authority file)

c) I'd also suggest to add a class with the $2 to the <li> element, this way
each entry could be hidden and customized easily.

-- 
You are receiving this mail because:
You are watching all bug changes.