Skip to content

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

Open
Open
Ease compliance obligations regading the Nagoya Protocol (in the EU)#713

Description

@bressco
bressco
opened on Nov 13, 2025

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.1

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.2 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

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. ↩

Activity

  1. bressco commented on Nov 27, 2025

    @bressco
    bressco
    on Nov 27, 2025
    Author

    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.

  2. ljgarcia commented on Dec 3, 2025

    @ljgarcia
    ljgarcia
    on Dec 3, 2025
    Contributor

    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?

  3. ljgarcia commented on Dec 3, 2025

    @ljgarcia
    ljgarcia
    on Dec 3, 2025
    Contributor

    @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

  4. gtsueng commented on Dec 3, 2025

    @gtsueng
    gtsueng
    on Dec 3, 2025
    Contributor

    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.

  5. bressco commented on Jan 2, 2026

    @bressco
    bressco
    on Jan 2, 2026
    Author

    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 ↩

  6. bressco commented on Jan 2, 2026

    @bressco
    bressco
    on Jan 2, 2026
    Author

    @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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions