New Extension: Research Product Types

[allysonlister]

Name: Research Products for Standards
(not an official extension name, as some investigating still needs to be done to understand exactly how to progress with this item.

Note that policies, metrics and benchmarks are not strictly standards, and therefore may need splitting out into a separate extension ticket - please let me know if you'd like me to do this. I thought that we should start by describing them in a single ticket to triage which need new research product types and which can be adequately served within existing types.

Acronym or suggested repo name: RP-STDS

Proponent(s): Allyson Lister @allysonlister (https://github.com/allysonlister), Milo Thurston @knirirr (https://github.com/knirirr)

Brief motivation:

Background

FAIRsharing describes a number of different research objects:

• databases (comprised of repositories and knowledgebases)
• standards (comprised of terminology artifacts, models/formats, reporting guidelines, identifier schemata, principles*)
• policies (research data management policies from funders, institutions, journals etc)
• FAIR assistance components (metrics*, benchmarks*)

( * ): components marked with an ( * ) are in development

Please note that FAIRsharing stores records describing these resources (and not the resources themselves), which means we have looked to Silvio and OpenCitations as a template. Doing so, we hope that many of our records can already be described using existing SKG IF structures; the Appendix at the bottom of this ticket lists those as it would be great to get feedback that we're thinking along the correct lines. However, as they are not the focus of this ticket, I've moved them to the bottom.

New Research Product Types

This leaves the following record types in FAIRsharing with no equivalent research product type. While some might be shoehorned into 'literature', the rest are simply not available within any existing product types and would fall into “Other”. However, these research products need better visibility within the SKG than can be provided with 'other' as it is not just FAIRsharing that would ultimately be interested in talking about them. An extension(s) that would cover these resources should be developed.

Standards types in FAIRsharing as defined here

• reporting guidelines: e.g. MIAME. we could provide our categorisation within "literature". However, are literature object suitable to reporting guidelines? They are often represented as publications, but their purpose is not simply to disseminate research results as most publications are.
• principles: these will be a type of record very similar to reporting guidelines, and likely should be treated similarly. These record types with include all principles, e.g. FAIR, FAIR4RS, CARE, TRUST etc. Top-level principle records representing the entirety of a set of principles will have child principles that break the set down into constituent atomic concepts. These will be generated in FAIRsharing in the next month or two.
• terminology artifacts: e.g. GO. including ontologies, controlled vocabularies, thesauri etc.
• models/formats: e.g. KML.
• identifier schemata: e.g. DOI.

In future, once stable, we may also wish to include our new metrics and benchmarks record types, which will align with the OSTrails FAIR assessment track.

Policies in FAIRsharing as defined here

• data/digital object sharing/management policies: e.g. EPSRC Funder policy on data sharing. This is the same question as for reporting guidelines. Such policies are often represented as documents or web pages, but their defining features are NOT as literature, but rather as dissemination of recommendations and requirements by the owning organisation.

Appendix: already-matched types/classifications

We plan to use existing data source classifications for the following types of content within FAIRsharing:

Database types in FAIRsharing as defined here

• repository: any of the data source classifications except aggregator, depending on the particular resource
• knowledgebases: aggregator
• repository/knowledgebase: a mixture of the above two, not sure how to represent such a mixture in SKG-IF though?

Created at the same time as #4

[paolomanghi]

My two cents:

Databases are special classes of services, they are not research products; they will be covered by the "service" extension. Note that a database is not a downloadable dataset. There is a clear distinction between ProtDB (and its APIs) and a dump (generated at time T) of ProtDB records that can be downloaded from the web.

Policies and standards are not necessarily research products, but rather "research support products", this note falls under a broader problem, which today is not clearly addressed by the research product classification. Products of research are intended to be the result of research and to introduce innovation, while many classes of products today find themselves in a "grey area". For example, presentations, deliverables, maps, technical documentation, reports, supplementary material, and why not, guidelines and policies. I would be positive in adding a category of research products, to publications, datasets, software, otherRP, and "support products" (or find a better name), which includes all such resource types that are more intended to support the research process (its reproducibility, its validation, etc.) than being an outcome of it.

FAIR assistant metrics and components are very specialised classes of objects, probably today available only via FAIRSharing. Again, these may fall as resource type of the class "support products" (or find a better name).

Following this approach, we can have all these changes at the level of the CORE data model, rather than pushing them as extensions.

[allysonlister]

Databases - agree with your definition, and if will be covered by services, I'm happy with that.

policies and standards -

I would be positive in adding a category of research products, to publications, datasets, software, otherRP, and "support products" (or find a better name), which includes all such resource types that are more intended to support the research process (its reproducibility, its validation, etc.) than being an outcome of it.

I'm not sure I follow what you're suggesting here. I agree that classifying them as research support products makes sense, but not sure how you're suggesting implementing it, though that may be my lack of expertise regarding the SKG framework.

metrics and benchmarks: happy to put them in the same bin as research support products. NOte that there will be other metric and benchmarks (eg for DMP evaluation) that may fall within this.

Thanks!

[paolomanghi]

Apoligies, I was too introspective... Here is a list of meta-types with examples of resource types...

Research products:

• publications: articles, thesis, book, book chapter, patents, etc.
• research data: datasets, collections, proteins, etc.
• research software: code
• support products: presentations, lectures, guidelines, policies, supplementary material, technica documentation, etc,
• other research products: AI models, maps, images, workflows, etc.

[paolomanghi]

if we approve it, I think in the long term we can have it in the core model, it's generic enough and very reasonable

[allysonlister]

thanks that helps. So you're suggesting that FAIR benchmark/metrics and all standards types would fall under support products.

As that is quite a broad group, how do people further describe the type of support products? Is there a way to tag a support product with the specific type of product it is (eg reporting guideline, policy or format)? Otherwise an object that was a conference presentation would be hard to distinguish from a FAIR benchmark or an astronomy metadata format...?

Thanks!

[allysonlister]

(as, in some ways, research software could be argued to be support product as much as eg a format. Both are instrumental in getting the data to the form it is when it is added to the graph). I realise that software may be used to generate or analyse data, but not all software is used in that way - it may be visualisation software, or simply the research output in itself.

And, sometimes the standard is the research output, eg the output of a collaborative process to create a community format. So we are kind of in a murky situation too :)

[paolomanghi]

Fully agree, Allyson, there could be multiple characterizations (types) for the same resource. A software product could be both a "support product" and a "research product", although in general the latter type could become of the former type, not vice versa. The same may happen for a "standard" product.

So, the solution I proposed treats all of them as products but assigns them to a single class, based on two assumptions: software that is not the result of research is NOT modeled in the SKG; and standards, be them research outcomes or not, all fall under the same class of "support products".