Use cases and guidelines for data embargo

[Philipp Conzett]

At DataverseNO, we’re considering making use of the Dataverse support for data embargos. Currently, we don’t have clear guidelines for embargo, apart from this general statement in the DataverseNO Accession Policy:

Datasets must be deposited for open, public access, which means that anyone may download and reuse all or part of a Dataset in accordance with the license indicated by the Depositor. Depositors may define an Embargo Period. The individual collections may have their own terms for maximum Embargo Period.

So far, I’ve identified two main uses cases for embargo:
a) Embargo until related publication is published
b) Embargo to align with data usage agreement or other agreement between data producers

In both uses cases, I’m not sure how straightforward it is to identify an exact date for when the embargo period ends. As for use case a: Although a publisher at some point might indicate the date of publication of an accepted manuscript, it’s not unusual that this date may be postponed. As for use case b: Sometimes the period within which project partners / data producers agree that the data shall only be used within the consortium is expressed in relative terms, e.g., five years after project end, which is also prone to be extended. Thus, in both cases, it turns out to be difficult to specify a specific end of embargo period.

That’s why I wonder what kind of uses cases and guidelines other Dataverse-based repositories have for data embargo and if/how they practice the embargo feature in Dataverse.

Thank you!
Philipp

[Dieuwertje Bloemen]

Hi Philipp,

We've been working with them for a while and have noticed that there is one major issue: file embargoes can't be shifted once they've been set and published as embargoed. As we've noticed that these embargo dates can be moved back quite often (especially for PhD projects), or sometimes even be moved forward, we have provided our users with the following advise:

"Be careful with file embargoes, though. Once an embargo is set on a file level, you can’t change it anymore, the file will go live on the date you chose. So, if you’re not too sure about the embargo date, a better option is to use the restrict option on your file level instead. This way, you can move the embargo date and all you’ll have to do is manually unrestrict the files once the date passes."

Because we have a metadata field indicating the overall access level of a dataset, that is where they can provide the information that the dataset is embargoed and until what date. We can then also do a regular check to see if passed embargoes have in fact been lifted based on this metadata.

Kind regards,

Dieuwertje

[James Myers]

FWIW: Embargoes on released files can be changed by superusers. The reasoning behind making it a privileged operation is that the embargo duration is something that could/would be reviewed to see if it conforms with policy and that allowing the creator to change it later would be a way around those policies. There was discussion early on about designs that could instead allow specifying a relative date, e.g. 6 months after a paper is published, but there was no consensus on how to scope that.

 

-- Jim

--
You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-commu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/58604087-584c-46c4-9c45-832cbdb6533bn%40googlegroups.com.

[Dieuwertje Bloemen]

Hi Jim,

I think it's right to have it set up that way, as it's in line with overall best practices for embargoes. As far as I know, they shouldn't ever be postponed. It's just that the practice has shown us otherwise. It is therefore that we suggest that option of restricting and manually releasing instead.

Kind regards,

Dieuwertje