On Wed, Jun 17, 2015 at 03:56:35PM +0200, Hilton Gibson wrote: > Hi Mark > > Thanks for the reply. > > Now I am bamboozled. > The directive to apply ORCID came from our Vice-Rector Research. > He would like to have reports extracted from our repository about campus > researcher output. > He would also like the same campus researchers to submit primarily to the > repository any current research works.
This sounds to me like a very common desire, and one that DSpace should support. > Now what role does a campus researcher (author/advisor) in this case have > on DSpace, which I am sure is a common case with most academic research > repositories? > user, Eperson or ORCID? The user (a real-world person) is represented in DSpace by an EPerson object. Today the EPerson exists only to hold credentials for authenticating identity at logon, and to support subscription to update emails when new content arrives in a subscribed Collection. Authors (and other contributors to an Item) are (poorly) represented by strings in the Item metadata, and not connected with EPersons. ORCIDs are today not provided for at all in DSpace, but there is much interest in rectifying that. To address your question: if a researcher wishes to submit works for inclusion in the repository, or to subscribe to new-accession notices, or both, then the researcher must create a user account (an EPerson) in your DSpace. If a researcher wishes his deposits known by his ORCID, stock DSpace has no place for that information, but you can define a metadata field for ORCIDs and extend the submission forms as needed. DSpace lets you make a place to keep ORCIDs, but released versions go no further. I took a quick look and, while I am definitely not a metadata expert, it seems to me that neither QDC nor DCTerms defines a field for *author* identifiers, so a hypothetical identifier.ORCID field should be defined elsewhere. There may be a namespace which already defines such a field, which DSpace (or your instance) could adopt and, if so, that is probably the best approach. There may be things you can do with DSpace's authority control support that will make it easier to ensure the quality of these metadata and ease their (correct) entry. I haven't yet looked at authority control at all, so can't say more. There's another aspect to all this: now that EPerson has metadata support, it would be easy to just extend the 'eperson' metadata namespace with eperson.identifier.ORCID. Making use of this field would require substantially more work, though. It would need additions to the user profile UI pages, and some logic to offer the option to pre-fill a submission field from the user's profile (and from other user profiles, if several local users are authors of a single Item). Still more work would be needed to support lookup of (or by!) ORCIDs assigned to non-local authors. > It seems we created more ambiguity/complexity with ORCID, rather than > simplifying and removing author ambiguity. To take advantage of the growing interest in ORCID to simplify and disambiguate is work yet to be done. I want to mention that, if your repository is like many others, the author information may be...messy. There's no mandatory control on author name strings, and people tend to write the same person's name in different ways at different times. I suspect that a rigorous examination and cleanup of author names will be a necessary step in implementing unique identifiers for authors at every site that chooses to do such an implementation. It is something that can be begun now and which will be beneficial now. You may also have sources of authority that you can begin using now to prevent acceptance of any *more* names that will have to be cleaned up. I'm considering how to build tools which can help in doing this cleanup. I would like to exhort all early adopters of ORCID in DSpace to talk early and often about their work, so that we can develop common conventions for basic things like how ORCIDs are stored, for works and for authors. Meanwhile, I think @mire has been working on ORCID support. I also believe that Dryad is pursuing ORCID integration. There should be little trouble in assembling an interest group to make these things happen. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu
signature.asc
Description: Digital signature
------------------------------------------------------------------------------
_______________________________________________ Dspace-general mailing list Dspace-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-general
