Tag Archives: metadata

Thinking about Research Data Asset Registers

Posted on by
Reply

[Reposted from https://libraryblogs.is.ed.ac.uk/blog/2013/12/12/thinking-about-research-data-asset-registers/]

In my last blog post, I looked at the four quadrants of research data curation systems.  This categorised systems that manage or describe research data assets by whether their primary role is to store metadata or data, and whether the information is for private or public use.  Four systems were then put into these quadrants.

quadrants3

The University of Edinburgh already has two active services from this diagram: PURE, our Current Research Information System and DataShare, our open data repository.

This blog post will start to unpack some of the requirements for a Data Asset Register.

The first aspect to cover is its name.  What should it be called?  Traditionally systems like this, which only hold metadata records that either just describe, or describe and point to other resources, are known as registers, catalogues, directories, indexes, or inventories.

The University already has a ‘Data Catalogue’, maintained by the Data Library.  However this list has a different purpose, to hold details of external data.  Oxford University, instead of opting for a name such as this, have instead opted to call their service by the verb ‘find’ – DataFinder.  Whilst there may be some brand or service name applied to the system we create at the University of Edinburgh, for now its working title is ‘Data Asset Register’ as one of its main functions will be to allow data creators to ‘register’ their data assets by describing them, and if the data is published online to link to the data.

But what should the Data Asset Register provide?  The following diagram shows some early thoughts:

dar-thoughts

The diagram splits this up into three broad areas:

  • Description – what the asset register should describe
  • Functions – the functions needed to allow data asset description
  • Services – the value-added services that will add benefit to people who register their data

Description

The core purpose of the system is to describe data.  This is split into two categories: being able to describe single items or data assets, and describing collections of data assets.  Many data assets are created on their own, for example a population health longitudinal study.  As such, this should be described on its own.  In contrast, some data are created in large sets, where it isn’t necessarily useful to describe every part of that set on its own.  In this case, the collection as a whole can be described. A good example of this is the Research Data Australia service from the Australian National Data Service.

We’ll need to decide how to describe the data.  A likely initial candidate will be the DataCite Metadata Schema, but we may find this needs to be extended to cover extra elements relevant to the University or the discipline of the data asset being described.  There will also be requirements coming from a possible UK research data registry, development of which is being led by the Digital Curation Centre.

Functions

In order to enable data asset description, a register will need certain functions.  So far three have been identified:

  1. CRUD: Create / Read / Update / Delete are the basic functions required when manipulating data.  The system should allow records of research data to be created, read later, updated, and if needed, deleted.
  2. User Interface (UI): In order to enable CRUD functionality, a user interface will be required.  To be useful, this will need to provide search and display functionality, for example using faceted search and browse.
  3. Log: Some funders have requirements to keep data for certain lengths of time, or for periods of time that must be reset each time a data set is accessed.  For this reason each access of a data asset must be logged by the system.  An example is from the EPSRC:

“Research organisations will ensure that EPSRC-funded research data is securely preserved for a minimum of 10-years from the date that any researcher ‘privileged access’ period expires or, if others have accessed the data, from last date on which access to the data was requested by a third party;”

It may also be that the Data Asset Register can be a front-end for our Data Vault too – more about that in another blog post!

Services

Extra value-added services are required in order to make the Data Asset Register useful to people.  Our initial thoughts about these services include the following:

  • Identify: The ability to assign identifiers to data assets.  Some of these identifiers will need to be persistent.
    • DOI: DataCite DOIs allow DOIs to be assigned to data assets, in the same way that DOIs are assigned to journal articles.  This allows them to be persistently identified over time even if they move between systems, but also allow them to be cited using a well-known identifier.
    • TinyURL: A short URL such as those provided by TinyURL or bitly are useful to give easy web identifiers to objects.  For example it might be nice to be able to issue URLs such as http://data.ed.ac.uk/abcd.
    • Other: Are there any other identifier systems that we should consider using?
  • Discover: It is important that the data records held in the Data Asset Register are searchable and can be indexed by external services.  This may be by national, international, or discipline-based data aggregators, or by normal web search engines.
  • Share: Whilst often the data assets will be described online but kept offline by the researcher, they may wish to share the data.  The Data Asset Register may need to facilitate this in a number of ways:
    • Deposit:  If the data is held in the Data Vault, along with a description in the Data Asset Register, then using a deposit protocol such as SWORD it would be possible to deposit the data into the institutional data repository, or into an external repository.  The Data Asset Register can then record the identifier for the hosted data set.
    • Redirect:  Where the data is hosted online elsewhere, the Data Asset Register could automatically redirect users.  For example visiting http://data.ed.ac.uk/abcd could redirect a visitor directly to the repository, rather than showing them just the data asset record description.  If the data is not shared openly, then contact details can be provided of the data owner.
    • RCUK: Some funders, such as the RCUK members (Research Councils UK) require funded journal papers to include “a statement on how the underlying research materials – such as data, samples or models – can be accessed”.  The data asset register could facilitate this by automatically writing statements such as “Details about accessing the data referenced in this paper may be found at http://data.ed.ac.uk/abcd”

It is very early days in our thinking about what features a Data Asset Register should offer, and like many components of a modern research data management infrastructure, there are very few existing examples to look at.  Our thoughts will be refined over the coming months so that we can start looking at implementation options.  Is there an existing system that can do all of this for us, or is it better to build something new, either alone or with collaborators?

Images available from http://dx.doi.org/10.6084/m9.figshare.873617

Stuart Lewis, Head of Research and Learning Services, Library & University Collections.

The four quadrants of research data curation systems

Posted on by
1

[Reposted from https://libraryblogs.is.ed.ac.uk/blog/2013/12/06/the-four-quadrants-of-research-data-curation-systems/]

The University of Edinburgh, like many other universities, is currently undertaking extensive work to build infrastructure that supports and enables good practice in the area of Research Data Management.  This infrastructure ranges from large-scale research storage facilities to data management planning tools.

One aspect of Research Data Management highlighted in the University’s RDM Roadmap is ‘Data stewardship: tools and services to aid in the description, deposit, and continuity of access to completed research data outputs.’

To help describe how these systems fit together yet how they differ from each other, I use a model with two axes to differentiate what they hold, and who can access them.  The first axis is used to differentiate between systems that hold only metadata from those that hold files (typically with some level of metadata), while the second differentiates between private systems and public systems.

quadrants1

Research information and data management and associated systems aren’t a new phenomenon. We have been offering services in these areas for some time.  To demonstrate this, we have two existing systems that provide services in two of the areas:

  •  PURE is our Current Research Information System (CRIS).  It is a private system for the University to record the research outputs it generates.  It therefore falls into the metadata / private quadrant. (It can hold files, and has a public interface, but this is primarily for Open Access publications rather than research data).
  • DataShare is our open research data repository.  It holds and curates data (and associated metadata) for public consumption on behalf of the data creators.  It therefore falls into the data / public quadrant.

quadrants2

What about the other two quadrants?  Are there systems or infrastructure needed to fill these?  Is there a case where we need a public store of metadata about research data, or a private store of finished data sets?

The rest of this blog post will argue that there is a need for these, and will describe two pieces of infrastructure that could fill them.  Further blog posts will be written that start to unpick the requirements of these systems in more depth.

Public Metadata: Not only is it good practice for a research institution to know what research data it is creating, some research funders require us to do so.  In addition the University’s RDM policy requires

“Any data which is retained elsewhere, for example in an international data service or domain repository should be registered with the University.”

The following is an extract from the EPSRC’s expectations for research data management:

 “Research organisations will ensure that appropriately structured metadata describing the research data they hold is published (normally within 12 months of the data being generated) and made freely accessible on the internet; in each case the metadata must be sufficient to allow others to understand what research data exists, why, when and how it was generated, and how to access it. Where the research data referred to in the metadata is a digital object it is expected that the metadata will include use of a robust digital object identifier (For example as available through the DataCite organisation – http://datacite.org/).”

This need can be fulfilled by the creation of a Data Asset Register.

Private Data: Whilst some data will be suitable for public sharing, for various reasons some will not, or will need to have access controlled by the data creator.  Therefore there is a need for a safe place for keeping data that will be kept secure, both in terms of access and change.  Once lodged/archived there, files should only be accessible by the data creator or data manager, and it should not be possible to change files, but only to create newer versions or to remove/delete them.

This need can be fulfilled by the creation of a Data Vault.

quadrants3

Systems however do not live in isolation, and become more powerful, more useful, and more likely to be used if they are able to integrate with each other.  With the ever-growing number of ‘systems’ provided by a large research-intensive university, the last thing that a research data management programme wants to do is to introduce further systems that need to be fed with duplicate information.  This means that some or all of the components will need to be integrated together.

There are three obvious integrations between these systems, as shown below:

quadrants4

First, because PURE is the master system for holding data and relationships about research outputs (THIS grant, funded THAT piece of equipment, which was used to create THIS data set, that was described in THESE journal articles), records of data sets need to exist within it.  However if some or all of these are being created in the Data Asset Register, then they will need to be pushed into PURE.  Equally if some data are being registered directly in PURE, it will be useful to pull this out of PURE and into the Data Asset Register.

Secondly, because the Data Asset Register may become the main user interface for entering details of data sets, it could also be the main administrative user interface for uploading files into the Data Vault.  If that is the case, then the Data Asset Register and the Vault will need to be integrated.

Finally, for instances where metadata is held in the Data Asset Register, corresponding files are held in the Data Vault, and the data owner decides to make the data openly available, then the Data Asset Register should be able to deposit these as a new item in the Data Repository.

The next challenge will be to describe the requirements for the Data Vault and Data Asset Register.  We have some early thoughts about this, and will share these in future blog.

Images available from http://dx.doi.org/10.6084/m9.figshare.873617

Related blog posts:

 

Stuart Lewis, Head of Research and Learning Services, Library & University Collections.