Address original PRC questions about the Implementation Requirement

[mbrush]

Original 2025-07-17 question from feedback spreadsheet: How would implementing the checklist concretely look in Beacon, who is responsible for creating data aligned with it, and what are the key considerations for practical implementation in a working system before October? (Perhaps Michael and Beacon leads can chime in here?)

Initial PRC response: One straightforward way to implement the checklist in Beacon is to add all relevant checklist properties as filtering terms in the Beacon search API, allowing queries based on those fields within each Beacon instance.

My remaining questions/concerns: Can you review again the current "implementations" of the product - and more generally, what it means to "implement" a minimal checklist. This is my biggest remaining concern, given the PSC requirement for "Showing evidence of at least two interoperable implementations".

Above you describe what an implementation in Beacon would look like - but has this or something similar since been done? Or have concrete plans been made to implement it in this way/system (or some other way/system)?

Alternatively, if we agree that this level of implementation is not feasible or needed to meet the PSC requirement - clarify how you have meet the requirement. Is it simply the mappings to fields in PCGG, IHEC, and INSC/ENA model? The question/response in row 22 of the feedback spreadsheet is relevant to this topic as well.

[dbujold]

Hi @mbrush , what we don't yet have is a strict recommendation for the checklist implementation in any given project. The strategy has been to agree at the semantic level about which properties make sense to include to properly annotate experiments, in their own data models. That's why we're now providing an implementations section in this GitHub, to indicate the way projects have been doing their mappings. It is available here: https://github.com/ga4gh/experiments-metadata/tree/main/mappings

Each projects has its own needs and restrictions, and given that this product is a checklist and not a schema, there is a little bit more freedom in what is expected as an implementation here.

Also, the focus of the product was on discoverability of data, rather than syntactical interoperability, although we do recognize the importance of the latter. This is why future steps in the development of this product will include a schema, that projects can adopt.

Lastly, we are definitely encouraging, for many fields, the use of ontologies. To make this possible, we've even done some work with ontologies maintainers to add missing terms, such as for platforms/instruments in OBI.

As for Beacon, the plan has been discussed with them to look at a potential integration, after the first version of this product has been approved.

[dbujold]

Also it's worth mentioning that a Driver Project, the Pan-Canadian Genome Library, has directly used the checklist for the definition of its data model. Good mappings to longer exisiting bodies (ENA, IHEC), have also been provided. Those two projects have actually been strong contributors to the definition of the checklist, so we consider they actually implement the properties. Others are coming ahead (RDA, CRDC), it's already in their proposed schemas, that is still in the works.

[dbujold]

Hi @mbrush , we've added some precisions at the top of the mappings markdown, synthesizing the above explanation. Let us know what you think!