Thanks Mark, The application of ORCID is one hook that definitely gets the attention of top management here. Good luck with pursuing further implementation! I look forward to it.
Regards hg *Hilton Gibson* Ubuntu Linux Systems Administrator Stellenbosch University Library http://staff.lib.sun.ac.za/~hgibson/docs/cv/cv.html On 17 June 2015 at 16:40, Mark H. Wood <mw...@iupui.edu> wrote: > 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 > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Dspace-general mailing list > Dspace-general@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-general > >
------------------------------------------------------------------------------
_______________________________________________ Dspace-general mailing list Dspace-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-general
