Merge AIRR 2024 meeting ratification changes

[bcorrie]

I don't see anything significant to change in this document, it still stands up fairly well. My main questions would be:

Unique digital object identifiers;
A minimal set of searchable metadata;
Physical availability through a cloud-based Commons provider;
Clear access rules and controls; and
An entry (with metadata) in one or more indices.

This list comes from a fairly obscure NIH document as far as I can tell: https://datascience.nih.gov/sites/default/files/CommonsOverviewFrameWorkandCurrentPilots281015_508.pdf

This isn't really citable (at least that I can find), and in todays context I am not sure this is the list we want. In particular the statement "Physical availability through a cloud-based Commons provider" seems overly specific. Is there something more recent? Something that is citable? I can't even tell when this was produced...

[schristley]

Maybe the NIH Strategic Plan for Data Science is better.

[bcorrie]

I wonder about this statement: "AIRR sequences for which epitopes are known should be deposited in the Immune Epitope Database (IEDB)."

Should the Common Repository Working Group be so strict in recommending one and only one repository. We don't do this for sequences (e.g. sat that they should go in SRA and not ENA), recognizing that there are several under the INSDC umbrella.

This may be what we prefer, but is it realistic for this to be so specific? Playing devils advocate a bit here, but...

[bcorrie]

Does anyone else find it ironic that NIH doesn't use PIDs so that its published public documents can be cited??? 8-)

[lgcowell]

I think the difference is the umbrella. My understanding is that SRA and ENA synchronize/mirror one another, so once you submit to one, your data are in both. That is not (currently) the case for the specificity databases.

IEDB is recognized by NIH. I don’t think the others are, but I might be wrong. Not sure about in Europe.

[schristley]

I wonder about this statement: "AIRR sequences for which epitopes are known should be deposited in the Immune Epitope Database (IEDB)."

Should the Common Repository Working Group be so strict in recommending one and only one repository. We don't do this for sequences (e.g. sat that they should go in SRA and not ENA), recognizing that there are several under the INSDC umbrella.

This may be what we prefer, but is it realistic for this to be so specific? Playing devils advocate a bit here, but...

If you are doing NIH-funded research, then yes because they are now requiring data management plans, and IEDB is an NIH-supported data repository for that domain. If you aren't doing NIH-funded research, then I suppose it falls to just a recommendation.

[bcorrie]

Maybe the NIH Strategic Plan for Data Science is better.

I don't see anything in that about compliance like the wording we have now. I would be tempted to take the digital object compliance sentence and list out, and just leave the FAIR principles part in. I would argue that that covers the point we are trying to make - data should be FAIR. Without a citable list of compliance criteria for FAIR data, I suggest we remove this list.

[bcorrie]

If you are doing NIH-funded research, then yes because they are now requiring data management plans, and IEDB is an NIH-supported data repository for that domain. If you aren't doing NIH-funded research, then I suppose it falls to just a recommendation.

Yes, and if you were doing research in the EU and they had a similar repository, they would need to publish the data there and not in IEDB. I would suggest something like the following wording:

"AIRR sequences for which epitopes are known should be deposited in recognized international resources for such data, such as the Immune Epitope Database (IEDB)."

[bcorrie]

Assuming we come up with a process for "accreditation" for repository compliance - which will be used to control which repositories are added to the ADC registry, we probably want to remove this:

Next Step: The AIRR Community will need to work with repositories to establish an accreditation system for compliance with AIRR-C standards.

And add a recommendation to the Repository section.

[bcorrie]

I am going to also suggest we change the numbering system for our recommendations, so we have Section and Subsections.

Section 1: Statement of Principles - AIRR Data Sharing

We can then have:

Recommendation 1.1: Facilitate deposit, access, and use of data

In this way we can add Recommendations to a Section without having to change renumbering of following recommendations outside of that section.

Let me know if there are any objections.

[lgcowell]

Agreed.

[bussec]

My 2 cents:

• Rec. 9 (FAIR Digital Objects): I also could not find the document that is mentioned here, but I should note that FAIR Digital Objects (FDOs), are a big thing some EU/EOSC circles (they even have their own association - FAIRDO). While the implementations I have seen so far try to solve the same issues as we do, their approach is IMO different from ours (strong focus on packaged objects that just need storage, little API interaction).
• Rec. 10 (Legal compliance): We should write "applicable legal norms" (instead of "local"), as e.g. GDPR applies to you when you are located in the EU or when you are processing data of EU citizens (no matter where you are).
• Rec. 14 (Other related data): Remove the reference to Immport as there is IMO no reason why they should be highlighted here.
• Next steps: Remove the bullet point about the development of "consistent consent documents" as this by now has become as realistic as establishing a colony on Mars (maybe even less...).

[bcorrie]

I believe all of the above are done, with the exception of drafting a recommendation around:

Next Step: The AIRR Community will need to work with repositories to establish an accreditation system for compliance with AIRR-C standards.

• I mention IEDB instead of ImmPort since we mention it in the other recommendation and Receptor points to IEDB as an example. We could take out the example entirely if we want
• I changed the FAIR wording substantially, saying that repositories should adhere to FAIR principles and follow best practices for FAIR Digital Objects and cite a FAIR DO publication.

[bcorrie]

Any other comments on this? If not, my intent will be to merge it after CRWG tomorrow assuming the group approves.

[bussec]

Looks good to me!