Registry Type

Each registry within FAIRsharing has a number of types.

The Registry type field in the General Information tab of a FAIRsharing record.

Setting Registry Type

Please choose the appropriate value from the list of options. Full descriptions of these registry type options are available on this page.

Changing Registry Type

Sometimes you accidentally set a record to the incorrect type, and need to change your record from one type to another. For example, you create a database record as 'knowledgebases and repositories' but you intended to classify it as 'knowledgebase' only. Even after saving your record, you can still change this field.

Standards

Standards records are divided into five subtypes. In order to be approved by the FAIRsharing team, the standards must be created by or have a strong backing from a community. This is commonly a grassroots or community-led standard, but may also be from a formal standards development organisation (SDO).

Please choose the standard type appropriate for your resource. If your resource does not fit into any of these categories, then please get in touch:

  • Model and Format records describe resources that provide a common structure for all data of a given experimental type. They are structured representations of information from a conceptual model or schema, which enables (syntactic) interoperability among systems. These formats are often created using base formats such as XML, CSV or RDF.

  • Terminology artefacts are controlled vocabularies or ontologies that describe the meaning, or semantics, of data and metadata. They provide a method of annotating data in a way that is useful for humans and comprehensible by computers, and allow for better collation and searching of the data.

  • Reporting guidelines provide a checklist for the minimal descriptive content required to evaluate, interpret and disseminate an experiment. Defining a common set of metadata to guide researchers in reporting scientific context is important for data repositories, journals and funders. Often reporting guidelines do not have a literal checklist, but are rather presented as a document stating required and optional attributes.

  • Identifier schemas (e.g. URLs, pURLs, DOIs) describe publicly-available identifiers from a central registry. For more information on this type, see the subsection below.

  • Metrics are criteria to assess some aspect of a digital resource, for example - but not limited to - its discoverability. As an example, the FAIR Metrics (of which FM-I2 is one) are a set of machine-actionable criteria that allow the assessment of the level of FAIRness of a resource.

A note on Identifier Schema records

Identifier schema records are intended to describe those publicly-available, persistent, and unique identifiers used and shared across multiple resources. The examples below provide some context for understanding what is in scope for these record types:

  1. Resolvable, globally unique, and persistent. DOI, Handle, and ARK are schemata for resolvable PIDs that are used in cross-community, multi-disciplinary ways, and are used and assigned across multiple projects.

  2. Globally unique, and persistent. Non-resolvable, but persistent and unique identifiers shared across resources and communities such as Reaction InChi, CAS registration numbers and EC numbers. Although they don't "click and resolve" without help, they are consistently used through a number of communities and therefore are in scope. Another example is the IVOA identifier, which is intended for a large, single-domain community of virtual observatories that use this identifier system for linking and identifying data.

  3. Persistent, single-repository identifiers. Identifiers only ever minted for a single repository, e.g. UniProt IDs, that may or may not be of a structure that is also globally unique. Although often shared as cross-references and links back to the originating resource, they are not intended to be created for anything other than that resource's contents.

Databases

Database records are divided into three subtypes. Please choose the record type appropriate to your resource. If your resource does not fit into any of these categories, then please get in touch. Please choose from the following types:

  • Repositories allow the submission, storage of and access to data (datasets, software, materials and other digital objects) and include (multi)disciplinary, generalist, project, data type and institutional repositories

  • Knowledgebases synthesise data from a number of sources including published literature, databases and other types of data sources. They often have a manual curation component. They can be considered secondary databases as they store data derived from primary sources.

  • Knowledgebases and Repositories are databases that have features of both knowledgebases and repositories.

While "Database" is used as the name of this registry, in this regard please note that we have a very generous definition of "data". Anything that stores digital objects (e.g. software repositories, digital representations of physical collections) and that meets the conditions outlined below, may be described in FAIRsharing.

What databases are in our remit?

It is important to note that FAIRsharing database records are intended to describe resources that store datasets; we do not accept submissions describing the datasets themselves. FAIRsharing is a registry of linked information on content standards, databases, and data policies in a variety of research areas, and as such does not describe data sets or allow data upload. More information as to what constitutes a suitable resource for incorporation into FAIRsharing can be found on our website.

What should I with my dataset instead?

At FAIRsharing, one of our roles is to help you find the right database to upload your data. Try browsing our complete subject hierarchy or searching our database records to find an appropriate database for your data type. Alternatively, you could look at our collection of Generalist Repositories or browse all subject-agnostic records, which may provide you with a location to store data from a wider range of research areas. If you are submitting to a particular journal, you can also search for that journal or its publisher; if they are registered with us, then their FAIRsharing data policy record may contain a list of recommended databases and/or standards.

Is my database suitable?

Here are the criteria for acceptance as a FAIRsharing database record:

  • The resource should be an organised collection of data (see our definition of "data" earlier in this section) and datasets rather than just an individual dataset.

  • The resource is findable. Users can access the database via an active website and can also browse and/or search the database. In contrast, datasets are generally downloadable but not searchable, and therefore are not appropriate for FAIRsharing.

  • The resource is accessible. Irrespective of licence type, the resource is available to users via a dedicated website (even if a log in or payment is required).

Policies

FAIRsharing stores descriptions of data policies from a number of sources outlined below. The common feature of all of them is that the data policy should describe how each source recommends the storage and/or formatting of data.

  • Journal: A journal data policy describes those formats and/or databases that are recommended for use for authors submitting a manuscript to that journal. Such resources may be described either explicitly or in a more general way.

  • Society: Particular societies (e.g. standards development organisations) often provide data policies so that researchers wishing to align with society best practices have a concrete data policy they can implement.

  • Funder: Funders often have strict requirements about the type of databases or standards that they wish their grantees to use.

  • Project: Particular projects may have a data policy that describes those resources that must be used by project members. Please note that this policy type should only be used for large-scale projects.

  • Institution: This is a relatively new policy type for FAIRsharing. Please use this to describe your institution's (e.g. a university's) data policy for its employees and, sometimes, collaborators.

  • Journal Publisher: Sometimes the publisher of a stable of journals has overarching data policies that apply to all journals.

Irrespective of the type of policy you are describing, it is important that you provide accurate and complete metadata to describe the policy itself. Of particular interest are the relationships you can add to your policy record with us; these provide direct links from your policy record to the database and standards records that your policy recommends. Also, data policies can be nested, allowing one data policy to extend another data policy(ies). This is useful in many situations, such as when a journal publisher has an overall data policy, and then individual journals from that publisher have their own specific extension of that policy.

Further information below shows how FAIRsharing is working to align with a number of different policy metadata standardisation efforts. This means that registering your policy with us provides prospective users with human- and machine-readable metadata describing the characteristics of your policy.

Collections

Collections are containers that allow you to create branded "slices" of FAIRsharing records that are specific to your needs. Please note that new collections must be of clear relevance and utility to a particular research community in order to be approved by the FAIRsharing curation team.

The infographic below provides a few examples of the ways in which our user community highlights their resources of interest using our collections. The examples in the image are IVOA, the RDA COVID-19 WG Resources, CDISC, and a crosswalk of metadata schemas and guidelines.

A few examples of the ways collections can help your organisation or community.

Another example of a collection in use by a community is INCF. Read more in our guest blog post, where INCF Director of Science and Training Mathew Abrams describes how the INCF makes use of FAIRsharing as part of the formal procedure it has in place for the evaluation and endorsement of community standards:

FAIRassist

FAIRsharing provides a registry that stores records relating to FAIR assistance and evaluation, initially developed as part of the OSTrails project. The types of records within this registry are defined here, as well as how those record types align with community-developed frameworks and standards.

FAIRsharing registers principles, metrics and benchmarks within the FAIRassist registry: the three conceptual components of the OSTrails FAIR Interoperability Framework (FAIR IF). Please note that OSTrails refers to principles as Dimensions, in keeping with the alignment with dqv:Dimension. FAIRsharing uses the 'principles' label instead, although within OSTrails dimensions and principles are the same thing; this is because the FAIRsharing community is comfortable with the idea of principles (e.g. the FAIR principles), while 'dimensions' may be unfamiliar.

Alignment with the OSTrails FAIR Assessment Interoperability Framework

As is the case with all of our metadata, the properties chosen for our Metrics and Benchmarks as listed in this section have been created in response to the needs of our user community. Where we have explicit alignment of the community resources below, such alignment is provided in the tables associated with each field.

Metrics

Metrics in OSTrails are an extension of dqv:Metric.

dqv:Metric
FAIRsharing
Comments

dcterms:identifier

FAIRsharing DOI

A unique identifier of the metric being described, which in this instance should be the FAIRsharing DOI as the underlying Homepage could change.

dcterms:title

vivo:abbreviation

dcterms:description

dcat:keyword

Note that we recommend using keywords sparingly, as it is much better to make use of the dcat:theme field and provide IRIs for our subject or domain tags.

dcat:landingPage

URL to a longer description of the Metric in (primarily) human readable format. This would include information about maintenance and curatorial staff, as requested in the original discussion document

dcat:version

tbc

ftr:status

sio:has-implementation (sio:SIO_000234) ftr:Test

tbc

dqv:inDimension

'measures principle' relationship

a FAIRsharing relationship to the relevant Principle record

ftr:hasBenchmark

inverse of 'has associated metric'

a FAIRsharing relationship from a Benchmark to a Metric, but visible from both directions

dcterms:creator

creator metadata in the record history

Has an optional organisation linked to the user account

dcat:contactPoint

Contact Information and also any Maintainer information

The maintainer account has an optional organisation, linked to the user account

Last updated

Was this helpful?