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