Ease compliance obligations regading the Nagoya Protocol (in the EU)

[bressco]

Problem

The Convention on biological diversity (CBD) and the Nagoya Protocol
specifying certain aspects of it establish, amongst other, access- and
benefit sharing obligations. The EU implemented related compliance
obligations in Regulation (EU) No 511/2014 (ABS Regulation).

Those compliance obligations apply to all users of genetic ressources
or traditional knowledge associated with such ressources inside the
EU. These obligations are documentation and due diligence. These
obligations can create additional work and could easily be missed, as
they are potentially seen as a burden. This could lead to liability of
the users or their institution, as laid down in Art. 11 ABS Regulation
and the relevant national law.¹

Genetic material is "any material of plant, animal, microbial or other
origin containing functional units of heredity", Art. 2 CBD.

Digital Sequence Information (DSI) and similiar informations are not
adressed by the ABS Regulation (yet), at least in the view of the
Commission.² However, discussion regarding DSI is ongoing between
the parties of the CBD.

Proposed solution

Including certain information would simplify fulfilling due diligence
and information obligations for users of the resources and could
improve compliance. Below possibly relevant types and profiles are
listed, currently without a concrete proposal for naming etc. Maybe
the information could already be included without creating new
properties.

Also, the information could used to automate certain aspects of
the obligations, e.g. checking whether a IRCC is valid.

Possibly relevant Types

SDO

• Gene

Possibly relevant Profiles

Bioschemas

• Gene, but
  possibly just sequence information to which the ABS Regulation does
  not apply
• Sample

Information in the metadata relevant for the ABS Regulation that
should be at least ...

• recommended:
  • location of origin. Needed to determine whether the nagayo
    protocol potentially applies. Allows to check the
    ABSCH for further information.
  • date of access to the ressource
  • description of the ressource
  • source of the ressource, from which it was obtained
  • presense or abscence of rights and obligations to access and
    benefit-sharing
  • access permits, where applicable
  • mutually agreed terms, where applicable
• optional:
  • Internationally recognized certificate of compliance (IRCC):
    Used to demonstrate due diligence regarding the resource.
    Should be complemented by information on the content of
    potential mutually agreed terms relevant for subsequent users.
    Either the document could be referenced (via the ABSCH) or those
    terms could be represented in e.g. ODRL.
    If an IRCC is given, it replaces most of the recommended
    information regarding the obligation to due diligence. However,
    the information should still be documented.
  • Registered collection the resource was obtained from. The ABS
    Regulation considers due diligence having been applied when a
    resource is obtained from certain collections. The information
    named before needs still to be documented and shared, however.

---

Footnotes

1. E.g. G zur Umsetzung der Verpflichtungen nach dem [...] und zur Durchführung
   der Verordnung (EU) Nr. 511/2014 v. 25.11.2015 (BGBl. I 2092; FNA
   188-108), ÄndVO v. 19.6.2020 (BGBl. I 1328, 1332). ↩

2. OJ C 313, 27.8.2016, p. 10. ↩

[bressco]

The ABS Regulation has some potential edge cases, mostly relating to other international treaties such as the plant treaty. For more information see https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52021XC0112(02), Sections 2.3 and 5.2. Those could require the inclusion of more relevant metadata.

[ljgarcia]

Hi @gtsueng @nsjuty could you please add this topic to your discussions on BioSample?
@bressco is there a suggestion in terms of properties to cover this topic? Any approach that you have seen structuring this kind of data?

[ljgarcia]

@bressco Going through the initial thread with some questions, using a gene as an example, sorry if I am misunderstanding something:

recommended:

• location of origin. Needed to determine whether the nagayo protocol potentially applies. Allows to check the ABSCH for further information. --would this location be for the actual specimen? If I am not mistaken, Gene in Bioschemas is a gene in a database, a composite, not an actual gene. Could work for the actual sample
• date of access to the ressource --would this be the date when someone (person or machine) access, for instance, a gene databank? If yes, then it would not go at the gene level but at the level of an action representing the access by someone in particular to that resource
• description of the ressource --the resource would be, for instance gene databank, that goes at the resource level, and we have it, for instance description of a database
• source of the ressource, from which it was obtained --maybe provenance for sample submission (but for composite genes)

If my comments, make no sense, maybe we are misunderstanding, please Slack

[gtsueng]

I don't think it makes sense to apply it to the Gene schema based on the definition provided: "any material of plant, animal, microbial or other origin containing functional units of heredity", since the Gene IS the functional unit of heredity. Based on the definition it sounds like it should apply to anything containing genes, but it's not clear to me that it applies to genes themselves.

It might make sense to apply it to Sample, but I don't see why the requisite information for compliance needs its own fields and couldn't just be included via the locationOfOrigin, conditionsOfAccess, and ethics properties already defined for the Sample type.

[bressco]

Coming back to our exchange at BHDE 2025 some examples for the various fields:

Field	Example	Notes	Properties of BioSample (Type)
place of access to the resource	Geocoordinates OR Countrycode	Could be sdo:PostalAddress	locationCreated
date of access to the resource	(some date)	Art. 4 (3) ABS regulation. When the resource is retrieved/first used	dateCreated
description of the resource	Galeopsis segetum	CETAF proposes a taxonomic description. Can also be used to check against the plant treaty	taxonomicRange (?)
source of the resource	https://ror.org/02tyer376	RoR or other IDs, if applicable	custodian (?)
users of resouce	[https://ror.org/02tyer376, ... ]	Could be a list, as subsequent users should be included.	?
presense or absense of rights and obligations	false XOR (ODRL representation OR Link to e.g. PDF)		?
access permits, where applicable	false XOR (ODRL representation OR Link to e.g. PDF)		?
mutually agreed terms	false XOR (ODRL representation OR Link to e.g. PDF)		?
IRCC	None XOR ABSCH-IRCC-PA-281633-1	Unique ID of IRCC. Example taken from 1	?
Registered Collection the resource was obtained from	None XOR https://ror.org/02tyer376	RoR? Registered Collections currently only in PDF 2	?
Best Practice followed	CETAF Code of Conduct and best practice ...	Until now only one best practice recognized, see 3	?

Based on the comment of @gtsueng i am not quite sure what the difference between a type and a profile is. Especially when there are a type and a profile which are named nearly the same, but have almost completely different contents. If i understand it correctly, a profile adds mainly a marginality on top of a type / existing properties. So even if the information could be integrated in already existing fields (and it should, if possible), the profile should be harmonized and the required information (as per the ABS regulation) should be moved at least to the recommended group of properties.

ethics does not sound like a property for contractual terms. To ease compliance i think it would be best to use (or introduce) a property that can contain machine-interpretable legal terms.
Also, for conditionsOfAccess it has to be kept in mind that e.g. a collection could add conditions on top of those of the provider country.

Regarding registered collections: Maybe those do not need to be included in the metadata, but could be the source of the sample. If a source is a registered collection could be checked via an API or something similiar, as that status can change.

Footnotes

1. https://absch.cbd.int/en/database/IRCC/ABSCH-IRCC-PA-281633-1 ↩

2. https://circabc.europa.eu/ui/group/3f466d71-92a7-49eb-9c63-6cb0fadf29dc/library/929bd3de-3a8a-4a70-9835-9ce7b74b4fba/details?download=true.
   Field maybe not needed, as registered collections could be checked
   against the source of the resource. ↩

3. https://circabc.europa.eu/ui/group/3f466d71-92a7-49eb-9c63-6cb0fadf29dc/library/794aecbb-d925-414c-89a3-3db389239271/details?download=true ↩

[bressco]

@ljgarcia Maybe someone at DSMZ has an idea on how to structure the data. DSMZ is one of the three registered collections regarding the Nagoya Protocol in Europe. They also include some information on it in one of their projects, but that does not seems to be exhaustive.