BiRD Repository Policies

The following policies cover the submission of data to BiRD, the reuse of data held in BiRD, or general use of research data at Birkbeck. If you have any questions about these policies, contact researchdata@bbkac.uk

• Depositor Agreement
• Collection Policy
• Citation Guide
• DOI Guidance
• Retention Policy
• Notice and Action Procedure
• Withdrawal Policy
• Preservation Statement

Depositor Agreement

1. I have responsibility for what I am uploading
2. I am allowed to deposit the data, and The College is allowed to share it.
3. I give permission for The College to distribute my data.
4. I will specify correct restrictions and embargos.
5. The Dataset does not contain personal identifiable material without permission of the participants, or that hasn’t been anonymised.
6. The Dataset is not subject to copyright restrictions, third party restrictions, and has been considered from an ethical standpoint. It also does not break any laws. If it contains student data, then I have permission to deposit for them.
7. I have provided sufficient metadata.

1. The College will store the data in an appropriate location.
2. The College will clearly display important metadata.
3. The College will maintain provision whereby irregularities with the data and breaches of rights can be reported to The College and investigated.
4. The College can change the format of the dataset if necessary.

Collection Policy

1. Data must be considered final, or in a state to be published. It cannot be added to, or altered after deposit, only accessed.
2. Data must be created as part of research undertaken at Birkbeck College (BBK), by staff employed (wholly or partly) by the college, or its postgraduate, masters and undergraduate students. Data produced by visiting researchers not employed by the College or data created using our facilities can also be considered to be in remit if the data is not going to be stored elsewhere.
   1. This may include collaborative projects with other institutions (the data owning institution should be established before commencement of the project and this should be defined in the collaboration agreement set up for the project).
   2. Student data must be vetted by their Supervisor before upload to the repository.
3. Data should support a publication, or support subsequent publications. With the following exceptions:
   1. Data considered to be of value to research, and likely to be reused. This includes information about negative findings or a lack of reproducibility which it may be challenging to publish but which has value to the research base.
   2. There is an obligation to share the data as part of the project funding.
4. Data must have relevant documentation accompanying to allow for the data to be understood and reused by someone within the same subject area.
   1. All variables must be identifiable; this may mean data dictionary is necessary.
   2. A README file should be included, identifying each file in the upload.
   3. If required, a supplementary metadata file should be included with the other files.
5. Metadata must meet the minimum standard defined by the repository. Uploads will be unsuccessful without this.

It is the responsibility of the depositor to ensure that the data is deposited in a way as to allow its reuse in the future. This means that the depositor must make an effort to use open and accessible file formats. Please consult with the RDM support in the library for more information or advice. In the case of physical Data, a metadata only record can be created. This must comply with the same criteria set out above for Digital Data, with the exception of the Data files themselves.

1. Personal, sensitive, or confidential information is present in the data.
   1. It can also be the case that due to data being combined, participants may be identifiable in the future.
   2. The repository administrators will not necessarily check each data for this. It is the responsibility of the PI/depositor to ensure that no identifiers, personal, or commercially sensitive information is deposited.
2. Documentation is not sufficient, as described above in the Acceptance Criteria.
3. Data is not accompanied by the software needed to make it understandable.
   1. This does not apply to proprietary software which can be purchased, but is referring to software created in the course of the research project.
4. If a proprietary file format is deposited, an open format may be requested to accompany this original.
5. Data is considered too large to be managed by the Library (advice can be given on where best to storage such files). In this case, the metadata record should still be held by the repository.
6. The data could have a better home in a subject or funder repository. In this case, the metadata record should still be held by the repository.

Citation Format

Creator (PublicationYear): Title. Birkbeck Data Repository. doi: 10.18743/data/00001

DOI Guidance

1. A record must be created the Birkbeck College Research Data Repository.
   1. This does not mean that the date itself is deposited on the Repository. A metadata only record is sufficient is the data cannot be deposited.
2. The minimum metadata, as described in our Metadata Schema must be provided (it is impossible to complete the deposit workflow without this stage).
3. If the deposit is not for digital data, a location for the physical item must be recorded.
4. Metadata must be made available under the CC0 license.

Retention Policy

Datasets will be reviewed against this checklist 10 years after being published, 10 years after last download/access, or in line with a funders minimum retention period (if more than 10 years).

1. Dataset still complies with the acceptance criteria from our Collection Policy (4), and does not fall under any part of the rejection criteria.
2. Archived file types still accessible
   1. If no longer accessible, can they be converted to accessible open formats?
   2. If the file types cannot be converted, or opened in the library, we will speak with an expert in the field to establish if the format is still used.
3. Data accessed/viewed/cited in the past 10 years.
   1. Check against internal EPrints reporting
   2. Check Google Analytics
   3. Check Datacite
   4. Check Altmetrics/other alternative metrics as appropriate.
4. Is the data restricted in any way by license or access control?
5. Check the Retention Information in the record metadata.

We should attempt to retain data for as long as is possible, as we cannot predict it’s future importance to research and the College. If a dataset fails on one or more of the items in the above checklist this should not be seen as an automatic decision to remove it. If a dataset fails, repository administrators should take a further look to see if there is a way to improve the dataset, or make it more accessible, before removing.

If the dataset is to be withdrawn, it should be done in compliance with our Withdrawal Policy.

Notice and Action Procedure

If you have discovered material which is unlawful, breaches copyright (yours or a third party), or any other law (this might include, but is not limited to patent, trademark, confidentiality, or data protection issues) you are entitled to make a complaint.

Formal complaints should be made in writing as described in paragraph 12 of the Colleges Research Misconduct Procedure.

A formal complaint should include:

• Your contact details.
• Full details of the material involved in the complaint (Author, titles, etc.)
• Repository address where the material was found.
• Confirmation that you are the intellectual property rights owner, or are authorized to act for the rights owner, if the complaint involves IP issues.
• Evidence of how your rights have been infringed and what action you wish us to take.

Upon receipt of a complaint, the College will follow the procedure described in the Research Misconduct Procedure. The College reserves the right to access independent legal advice (for example, around questions of IP) as part of its investigation.

The College will aim to resolve the issue swiftly and amicably and to the satisfaction of both parties, with the following possible outcomes:

1. The Dataset is replaced in the repository unchanged.
2. The Dataset is replaced in the repository with changes.
3. The data and documentation portions of the Dataset are removed, with only the metadata describing the item remaining openly available. Some parts of the metadata may be changed to reflect the update status of the item.

If we are unable to agree a resolution through the research misconduct procedure, the Dataset will remain unavailable through the Repository until a time when a resolution has been reached.

In this case the metadata will remain available in a reduce form, with a message displayed explaining the reason why the data and documentation have been removed. Any portion of a Dataset which is withdrawn from the Repository will be removed in accordance with our Withdrawal Policy.

Withdrawal Policy

If it is decided that a dataset should be removed from the repository, whither due to a request by the original depositor, author or PI, or if it is deemed to require removal due to a conflict with another policy, the following checklist will be followed.

There are two types of withdrawal listed, Hard Withdrawal and Soft Withdrawal. Hard means that the Data and Metadata are permanently deleted, with no backups. Soft means that it is made inaccessible to the public, but retained internally.

In addition, it should be noted that when a record has to be deleted from the repository, the metadata will remain in some form. This is due to the agreement with Datacite for the generation of DOIs. The remaining metadata may be reduced, but must still have certain details allowing for the identification of the resource which has been removed. However the data itself will no longer be available publically.

Also, while ever effort will be made by the College to delete data from their servers, it is possible that due to the nature of data storage, some might remain. Any data that remains will, by its nature, be inaccessible to ourselves and anyone else, so it is extremely unlikely that it could be accessed.

Once it has been decided that a dataset should be permanently removed, the following procedure will be followed the repository administrator:

1. The Data will be removed from the repository record.
2. The Documentation will be removed from the repository record.
3. The Metadata will be updated to explain:
   1. Why the record has been removed
   2. Where it can be found (if accessible elsewhere).
   3. Who can be contacted regarding the removal.
4. The Datacite record will be updated to reflect the items change in status.

This process will leave the Data and Documentation inaccessible, without violating our agreement with Datacite.

When it is decided that data should be made inaccessible, the following procedure will be followed the repository administrator:

1. The Data visibility is updated to “Repository staff only”.
2. The Documentation visibility is updated to “Repository staff only”.
3. The Metadata will be updated to explain:
   1. Why the Data and Metadata has been made inaccessible
   2. Where it can be found (if accessible elsewhere).
   3. Who can be contacted regarding the removal.
4. The Datacite record will be updated to reflect the items change in status.

This process will leave the Data and Documentation inaccessible, without violating our agreement with Datacite.

Preservation Statement

Items places in the Birkbeck Data Repository may, over time, become less accessible as common formats and applications change. This is a real issue in digital archives, and does not have a simple answer at present.

Files deposited in the archive must already comply with our Collection Policy, which places the responsibility for depositing accessible formats on depositor. While the library can provide guidance and advice on the best formats to use, we will not attempt to convert, update, or emulate deposits to enable future access.