SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez nos Conditions d’utilisation et notre Politique de confidentialité.
SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez notre Politique de confidentialité et nos Conditions d’utilisation pour en savoir plus.
These are the key issues we’ve been having at Cambridge, I would love to find out what everyone is doing at their respective institutions. Open discussion welcomed throughout, I’ll present briefly on the issues we’re having around each theme and then would invite you suggestions/experiences/bugbears.
Taking care of DOIs doesn’t end with minting them
Maintaining persistency: How much do you allow researchers to change after a DOI is minted? We currently allow typos to be corrected and mistakes in the data files prior to the associated journal article being published. Discussions with the BL suggest that it is ok to change the data files as long as the landing page remains the same but does this violate the principle of having a DOI? Do you issue guidance to researchers?
Withdrawal: Occasionally we have had to withdraw items for various reasons, including researchers panicking about being scooped, how much information are you inserting into your withdrawn record pages? How do you manage your withdrawal notices?
Placeholders: currently (pre-Symplectic) we are allowing researchers to make minimal changes to the metadata and allowing them to upload a placeholder file. This doesn’t seem in the spirit of DOIs but was a way to get researchers DOIs earlier in the research lifecycle. As we integrate our CRIS with our repository we are planning on reserving the DOI for placeholder submissions but these will not resolve until the researcher confirms it is the final record. The increase in placeholder submissions is positive in many ways as it shows researchers are thinking about their data earlier in the submission process (often even before choosing a journal) but this does make it harder to manage them. Are you seeing the same patterns? How do you manage them?
Peer-review access: We are getting increasing number of requests from researchers to have their data embargoed but accesible to peer-reviewers. This is currently not possible within Dspace but it is something we would like to offer in the future (poss through the Jisc Shared Services solutions). Can you do this within your systems set up? If not, how are you managing this? Can this be a way to encourage researchers to make their data open sooner?
Embargoes: Metadata or data only? Cambridge is currently data files only and this can cause some discomfit to researchers about the metadata being visible.
MRC Epid pilot – internal, do not want to encourage. Allowing a unit their own series of DOIs which they can manage (technical difficulties of setting up access), what assurances do you seek from research units before allowing this? Have you been approached with similar requests? Would you do this? What are your views on the risks involved with DOIs which relate to objects outside of the repository?
Policy: currently just types of research outputs, modifications and take down policies. Do you have one? What is in it? How do you use it? According to Actor-Network Theory policies are actors in and of themselves so do you see risks/benefits associated with them?
These are the main issues we have at Cambridge at the moment but I would be interested to hear if you are having other issues
Managing DOIs across lifecycles
Office of Scholarly Communication
Managing DOIs across lifecycles
Wednesday 30th November,
Jisc Research Data Network, St Andrews
• DOI lifecycle
• Publishing lifecycle
• Workflow issues
• Other issues?
OSCThe DOI ‘lifecycle’
How persistent are the objects