Not yet on 1.6, we also are wondering how to extend the metadata record in
DSpace to accommodate author affiliations, as well as links to corresponding
item records.
Should we have, for example, in one record,
dc.contributor.author: Tam, PKH
dc.contributor.author: Lui, VCH
dc.identifier.authority.scopus: Tam, PKH=7202539421
dc.identifier.authority.researcherid: Tam, PKH=C-4405-2009
dc.identifier.authority.scholaruniverse: Tam,
KT=8B0ED4A67F000001019A50FD81A9004B
dc.identifier.authority.scopus.authorid: Lui, VCH=7004231344
dc.identifier.authority.researcherid: Lui, VCH=C-4359-2009
.
.
dc.identifier.scopus.ead: 779508865221
dc.identifier.pmid: 12631670
dc.identifier.doi: 10.1136/bmj.328.7455.1566
dc.identifier.issn: 0959-535X
It's so clunky. Should we load the one DC element of dc.author.contibutor
with subfields for these corresponding remote records?
Or, should we load the dc.identifier.authority fields to a separate Dspace
Author record? The HKU IR has author records, but not in DC format.
Ex., http://hub.hku.hk/rp/rp00060
Therefore when OAI harvesting is done on items, this data will not be
included. Because it is not included, OAI Service Providers harvesting our
item data, will then have the author name disambiguation problem de novo.
Or, maybe something like Univ of Nagoya does,
http://ir.nul.nagoya-u.ac.jp/dspace/handle/2237/6408
[click on "author link"]
Or, ??
David Palmer
Scholarly Communications Team Leader
The University of Hong Kong Libraries
Pokfulam Road
Hong Kong
tel. +852 2859 7004
------------------------------------------------------------------------------
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
