Skip to main content


We are in the process of rolling out a soft launch of the RDA website, which includes a new member platform. Existing RDA members PLEASE REACTIVATE YOUR ACCOUNT using this link: Visitors may encounter functionality issues with group pages, navigation, missing content, broken links, etc. As you explore the new site, please provide your feedback using the UserSnap tool on the bottom right corner of each page. Thank you for your understanding and support as we work through all issues as quickly as possible. Stay updated about upcoming features and functionalities:


Makx –
Many thanks for summarising the ‘state of play’. As one of the few who has been commenting (and enjoying the discussions) I support your request for others to comment – only by having broad agreement can we ensure our proposals will receive wider community support.
Keith G Jeffery Consultants
Prof Keith G Jeffery
E: ***@***.***
T: +44 7768 446088
S: keithgjeffery
The contents of this email are sent in confidence for the use of the
intended recipient only. If you are not one of the intended
recipients do not take action on it or show it to anyone else, but
return this email to the sender and delete your copy of it.
– Show quoted text -From: mail=***@***.*** On Behalf Of makxdekkers
Sent: 15 July 2019 21:02
To: ***@***.***
Subject: [fair_maturity] Status of discussions 2019-07-15
Dear WG,
Based on the discussion at the last online meeting on 18 June, we revised some of the indicators that were presented at the meeting, in several cases duplicating indicators for metadata and data as was suggested. The new indicators have been published in the related GitHub issues at Please review them and provide any feedback you may have, preferably as a comment in the GitHub issue.
On several issues, further discussion has taken place. Below is an overview of proposals that are being discussed.
‘Rich metadata’ (
On this issue, two broad opinions have been expressed:
One is to follow the recommendations of the RDA Metadata Interest Group ( to request the provision of metadata for a set of 17 elements in order for data to be FAIR:
* Unique Identifier (for later use including citation)
* Location (URL)
* Description
* Keywords (terms)
* Temporal coordinates
* Spatial coordinates
* Originator (organisation(s) / person(s))
* Project
* Facility / equipment
* Quality
* Availability (licence, persistence)
* Provenance
* Citations
* Related publications (white or grey)
* Related software
* Schema
* Medium / format
The other opinion was expressed as “We need “a thick cloud” of metadata, but we cannot pre-determine what that cloud is composed of (and shouldn’t try!)” This second view would leave the evaluation of the metadata to the evaluator, taking into account the community-specific metadata standard or application profile that is being used.
We are interested to hear more opinions on this issue. Please go to to participate in this discussion.
Indicators for I2: (meta)data use vocabularies that follow FAIR principles (
It is still being discussed to what extent vocabularies need to be FAIR. The latest contribution introduces the notion of ‘primitive’ FAIRness for vocabularies, i.e. at least resolving to a machine-understandable representation, as a useful test instead of testing for compliance with all FAIR principles, although it would still be the long-term objective for all vocabularies to become fully FAIR.
Indicators for R1.1: (meta)data are released with a clear and accessible data usage licence (
Two new indicators have been proposed:
* Provision of licence information in the appropriate element in the metadata standard used
* Licence information NOT provided in the appropriate element
* Licence information provided in the appropriate element
* Provision of machine-understandable licence information
* NO machine-understandable licence information (e.g. the human-readable title of a licence)
* Machine-understandable licence information (e.g. as provided by Creative Commons at
Indicators for R1.2: (meta)data are associated with detailed provenance (
Two new indicators have been proposed:
* Provenance information based on community-specific guidelines relevant for the resource
* NOT based on community-specific guidelines
* Based on community-specific guidelines
* Mapping of object-specific or domain-specific provenance information to a cross-domain language
* NO mapping to general purpose provenance language
* Mapping to general purpose provenance language (e.g. PROV-O)
Indicators for R1.3: (meta)data meet domain-relevant community standards (
Two new indicators have been proposed:
* (Meta)data follows a community standard
* (Meta)data NOT following community standard (e.g. based on a template or schema)
* (Meta)data following community standard (e.g. based on a template or schema)
* Community standard is encoded in machine-understandable language
* No machine-understandable encoding
* Machine-understandable encoding (e.g. XML schema, JSON schema, SHACL etc.)
We would appreciate more opinions from the members of the Working Group, preferably on GitHub at
Kind regards, Makx Dekkers