[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

--- Comment #33 from Jonathan Druart <jonathan.druart+koha at gmail.com> ---
(In reply to Katrin Fischer from comment #26)

Thanks for your time, Katrin!

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

We are going to lose flexibility, but I agree we should follow the standard.

> 1) Missing POD for _get_marc_authors
> 
> Could it be a little confusing having _get_marc_authors and get_marc_authors?

Added POD.

> 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)

Adjusted the POD!

> 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?

Hum, yes? I don't know! Any ideas why it's missing here?

> 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

Done, thanks for the suggestion.

> 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

Hugo, do you know "loop"?

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

I have added here.

> 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)

Done, but I am not sure I agree with this :)
Won't we get request from lot of people to add theirs?

> 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.

Can you be more specific please? There is a class on the div already
(author_identifier).
With the new patches, do you think we should have:
  <span class="orcid">ORCID</span>
?

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