Natural History Museums use various software for managing their collections, and to manage information about their collection objects. A workshop organised in the framework of SYNTHESYS+ task 3.3 (see chapter 5.2) showed that open source software, proprietary software and individually designed databases are used. Participants listed the proprietary software: Adlib, Axiell and Filemaker. Open source software are Specify (Biological and Earth Sciences), DINA, Diversity Workbench, JACQ (herbaria), Arctos and Symbiota.

Several of these programs provide the feature of attaching or linking documents to records of biodiversity specimens. These documents include permits and contracts, e.g. loan contracts. However, to our knowledge no standardised tags are used for such attached or linked documents. As a result, information from different collections cannot simply be compared and is usually only easily understood by staff if properly trained, but not by other users. By comparing permit/contract information from different collections, we mean general information such as the purpose of a document or the total number of a particular type of permit, not the full contents of a permit, which may include confidential information.

Another issue is the terms themselves contained in permits and contracts applicable to biodiversity specimens in a collection. As far as we could determine, there are no workflows in institutions to systematically extract terms from documents that are relevant for the future, e.g., a term such as the duty to provide a copy of every publication on a specimen. Certainly, this would bind considerable resources if done retroactively, but it could be feasible for new material added to a collection. A reason for the lack of such workflows may be that no standard terms exist that can be used for tagging. It is important to note that such tagging of terms for a certain biodiversity specimen must not replace necessary legal counsel prior to initiating actions with it, but the tagging could save time when preparing such actions. In this respect, tagging and compiling terms give a quick overview but do not replace the obligation to read the permits and contracts.

The mission of the Distributed System of Scientific Collections (DiSSCo) is to develop a next-generation research infrastructure for biodiversity data. It is a long-term initiative and infrastructure development process that originated with the Consortium of European Taxonomic Facilities (CETAF).

DiSSCo is to provide the services required for large-scale and transdisciplinary research. Research that in turn is expected to support the continuing development of a wide range of operational applications that address today’s societal challenges. Up-to-date information-intense basic research into biodiversity and its transition into operational infrastructure tools are needed to effectively and reliably inform and support, e.g., biodiversity conservation, ecologically sound nature-based solutions and ecosystem-based services, agri- and aquaculture breeding programs, sustainable management of natural populations in fisheries and forestry, One Health approaches, and much more.

A comprehensive approach to protect and conserve the planet’s biodiversity is the Kunming-Montreal Global Biodiversity Framework adopted on December 19th 2022 (GBF, Conference of the Parties to the Convention on Biological Diversity 2022) at the 15th conference of the parties of the UN Convention on Biological Diversity*1 (CBD, Convention on Biological Diversity with Annexes 1992). The vision of the GBF is for humans to live in harmony with nature (section F of the GBF). It also contributes to the UN Sustainable Development Goals (SDGs, United Nations General Assembly 2015). In support of the monitoring strategy for tracking the GBF’s progress and achievements, powerful information- and communication-technical (ICT) data infrastructures are needed, such as DiSSCo that is further expanded in its applicability to the cross-continental level by its alignment with the Digital Extended Specimen concept (DES; Hardisty et al. 2022).

At least six international data infrastructures provide contents related to biodiversity specimens (compare chapter 4.4.2). They may be interested in making available information on associated permits, contracts and their terms, and hence in the work presented here. These six infrastructures are the Global Genome Biodiversity Network (GGBN), the International Nucleotide Sequence Database Collaboration (INSDC), JACQ (herbaria), the Integrated Digitized Biocollections (iDigBio), the Atlas of Living Australia (ALA, Commonwealth Scientific and Industrial Research Organisation CSIRO 2023), and the Global Biodiversity Information Facility (GBIF).

The Global Genome Biodiversity Network (GGBN) is the only international data infrastructure that already displays some information on permits. The GGBN website includes a searchable catalogue of genomic samples (Global Genome Biodiversity Network et al. 2023) which not only displays species identification, collection/taking event, extraction and available sequences. It also displays loan information and permit information (Fig. 2), based on the GGBN Permit Vocabulary and GGBN Loan Vocabulary.

Figure 2.  

Sections from the GGBN webpage on a seashell sample (Astarte montagui (Dillwyn, 1817) Catalogue Number ABMBS 172-10 of the Centre of Biodiversity Genomics, Canada), showing how the GGBN Permit Vocabulary and GGBN Loan Vocabulary (from the “GGBN data standard v1”) is used by the GGBN data portal.

We considered a wide range of official notifications and private contracts, and already existing compilations of such documents.

The Global Genome Biodiversity Network (GGBN) released the first version of its “GGBN data standard” at the end of 2016 (Droege et al. 2016). This standard comprises 9 different vocabularies:

• for amplification,

• DNA cloning,

• gel imaging,

• loans,

• material samples,

• permits,

• preparation,

• preservation

• and for single reads.

The GGBN vocabulary for permits (Suppl. material 5), but also the vocabulary for loans (Suppl. material 6) served as cornerstones of our work.

For permits the “GGBN data standard” version 1 provides a vocabulary with 30 terms that do not only describe different permit purposes, e.g., Collecting Permit, or Memorandum of Understanding (the GGBN Data Standard uses the word “label” for these terms), but also terms that refer to administrative aspects of the permit, e.g., whether the permit is (publicly) available or not. The data standard then supplements each term (“label”) with a normative URI (uniform resource identifier), a definition, information whether it is “required” and/or “repeatable”, and in the case of administrative aspects with examples for possible options. We considered only 20 terms and definitions that describe the purpose of the permit as a basis for our work (Table 1) and because of limited resources we discarded five of them (human pathogens, genetically modified organisms, intellectual property rights, patents, copyright).

We did not include the “GGBN data standard v1” Loan Vocabulary in our Biodiversity Permit/Loan Typology, as it only describes administrative elements of loans (date, loan identifier, availability of specimen…). In this way it differs from the GGBN Permit Vocabulary, which contains primarily different types of documents (but only a few of their administrative elements). Anyway, loans are covered within the “MTA” Documents Types in this project report.

The Society for the Preservation of Natural History Collections (SPNHC) runs the website “SPNHC wiki” (SPNHC_Wiki_contributors 2022b), including topics on legislation and regulation, among them a webpage on “permitting” that started in 2016 (SPNHC_Wiki_contributors 2022a, main editor Breda Zimkus). The document categories from the SPNHC permitting webpage formed another cornerstone of our work (Suppl. material 7). These document categories are listed in the webpage section “Categories of Legal/Compliance Documentation" and were first generated by GGBN with a number of additions made by participants of a BCoN-funded workshop "Addressing Legal Issues Involved in Digitized Collections: The Nagoya Protocol as a Test Case" (NSF grant DBI #1441785) held at Harvard University in March 2018. (SPNHC_Wiki_contributors 2022a)

Participants of this workshop used compliance with the Nagoya Protocol*1 to investigate how US institutions must respond to the need for increased transparency of their biodiversity collections and the required digital tracking. The group recognized the need for standardised definitions across the entire community, nationally and internationally, and they identified a number of permits not included in the GGBN list during working group discussions. Harvard's Museum of Comparative Zoology applied the discussion generated from the workshop and created a controlled vocabulary of Document Categories and specific Document Types (Zimkus et al. 2021).

Limited resources led to our decision to exclude the following topics from developing these biodiversity permit/contract typologies: Human tissue & pathogens, genetically modified organisms (GMO), biosafety and biosecurity issues (e.g. Belgian Science Policy Office 2023) and intellectual property rights (IPR). These are extensively regulated topics requiring considerable engagement of legal counsel, at the same time they are not core objectives of biological collections participating in our European Union funded SYNTHESYS+ project.

We also decided not to cover certain topics in a high granularity, e.g. country-specific permits and legislation, such as Australian permits. No member of our group had the necessary comprehensive knowledge of Australian biodiversity legislation (Suppl. material 3). Another example for our decision to dismiss high granularity in featuring permit types is the available information on phytosanitary*1 requirements: The Food and Agriculture Organization of the United Nations and International Plant Protection Convention Secretariat 2023 lists approximately 700 different documents on that topic, similarly the USDA APHIS United States of America Department of Agriculture Animal and Plant Health Inspection Service 2023 lists approximately 80 different commodity import and export manuals, plus many other manuals on different related topics.

From the sources mentioned in chapter 4.1 we compiled an initial list of 16 Document Categories, intuitively named according to keywords of documents or with seemingly fitting short names (chapter 6.2). In an iterative process of 22 biweekly to monthly meetings we discussed their meaning and what documents they may contain, we adopted their names, devised definitions for them, reviewed them several times, and in this process reduced their number to a final set of 7 (chapter 6.2). In parallel we did the same for the subordinate Document Types (chapter 6.3 and Suppl. material 1).

Creating our collection of Document Types started in June 2021 with an existing list of documents, and with Document Types from the database “MCZbase” of the Museum of Comparative Zoology (Harvard University, Cambridge, MA, USA) provided by Breda Zimkus. In addition, the documents on this list were compared to similar documents from different jurisdictions stored in the other institutions participating in our project. Furthermore, participants added new documents to the list. In cases where no similar documents were available in our institutions, participants consulted other colleagues or checked either European or USA legal information to see if similar documents exist. In the process of researching and comparing documents, new Document Types were created, the names of existing Document Types were changed, a definition was added to each Document Type, and Document Types were assigned to the superior Document Categories.

In the 9th meeting participants decided to separate the description of documents from the description of terms applying to any work with biodiversity specimens. A second and different set of names and descriptions was started, specifically applying on one hand to general terms and on the other hand to very common specific terms extracted from documents (and some that are specific to collection management, e.g. insufficient digitisation).

For the specific terms for collection objects (No. 51-76 in Suppl. material 2) we additionally included publicly available permits associated to Internationally Recognised Certificates of Compliance from Kenya, Peru and India. They have the following ABS Clearing House*1 Unique Identifiers & reference numbers of the national permit: ABSCH-IRCC-KE-242932-1 & NEMA/AGR/68/2017 (Kenya National Environment Management Authority 2019), ABSCH-IRCC-KE-253235-1 & NEMA/AGR/104/2018 (Kenya National Environment Management Authority 2020b), ABSCH-IRCC-KE-253313-1 & NEMA/AGR/135/2019 (Kenya National Environment Management Authority 2020a), ABSCH-IRCC-PE-249103-1 & 0013PER/SERFOR-2020 (Peru Servicio Nacional Forestal y de Fauna Silvestre 2020a), ABSCH-IRCC-PE-249106-1 & 0016PER/SERFOR-2020 (Peru Servicio Nacional Forestal y de Fauna Silvestre 2020b), ABSCH-IRCC-PE-254865-1 & 00026PER/SERFOR-2021 (Peru Servicio Nacional Forestal y de Fauna Silvestre 2021), ABSCH-IRCC-IN-255561-1 & India/NBA/Appl/9/4124 (India National Biodiversity Authority 2021).

To find out critical points in workflow and Nagoya Protocol*1 compliance with outgoing material requests for DNA studies, and to find out how to overcome insufficient documentation of third party material and ensure good scientific practice with incoming loans, a joint (with SYNTHESYS+ task group T 3.2) questionnaire with 32 questions was sent out to all institutions involved in both tasks on September 4th, 2020. The goal for this survey was to get a first overview on how molecular biological lab data, permit documents, and sampling requests are logged. A distinction between the usage of institutions' own molecular biological collections by internal and external scientists versus using third party molecular biological collections (and receiving third party material for own research) was made. The questions in the questionnaire concerned the handling of these collections of sampled tissue, and the handling of the corresponding permits. This was followed by personal interviews at some institutions. 18 SYNTHESYS+ partners of Networking Activity 3 (NA3) participated and 17 completed this survey: BGM, BGBM, CSIC, HNHM, HUJI, LUOMUS, MfN, MNHN, NHM, NHMW, NRM, SGN, SMNS, UGOT, RBGE, RBGK, UCPH, and ZFMK (see acronym list at the beginning). From the 17 institutions who filled the questionnaire, 8 institutions had a follow up interview.

A joint virtual workshop organised by the COST Action MOBILISE (COST Association AISBL 2018) within its Working Group 3 and by SYNTHESYS+ NA3 on "A Loans and Permits Data Standard for Scientific Collections'' took place on September 29th and 30th 2021. In total 105 people from 27 countries attended the workshop.

In this workshop, input was sought from various collection communities regarding their expertise, experiences, needs and challenges in connection with a data standard for loans and permits, with the long-term goal to develop a data standard that can be jointly used by different communities. In the workshop, the implementation of the standard in infrastructures and portals was discussed from a general point of view of what shall be achieved and how.

The workshop contributed to an ongoing cross-community discussion on how to support the adequate handling of legal and ethical requirements in natural history collections and related digital data infrastructures. In this context, the community consultation on converging Digital Specimens and Extended Specimens (GBIF.org 2021), especially part 8 on meeting legal/regulatory, ethical and sensitive data obligations (Hardisty et al. 2021) provided an excellent approach to the topic.

Digital Specimens and Extended Specimens (Webster 2017, Schindel and Cook 2018, Lendemer et al. 2020a, Lendemer et al. 2020b) have slightly different definitions: The DS “represents the sum of information on the Internet about a natural specimen object. The Digital Specimen acts as a processable digital twin on the Internet for the physical specimen in a natural sciences collection” (Hardisty 2020 of Nov. 17th 2020, see a slightly different definition in Hardisty et al. 2020 of May 18th). It serves as a fundamental element of the European research infrastructure DiSSCo (DiSSCoTech 2020). The “extended specimen” is “a constellation of specimen preparations and data types that, together, capture the broader multidimensional phenotype of an individual, as well as the underlying genotype and biological community context from which they were sampled.” (Webster 2017). Combined into a “Digital Extended Specimen” its definition is “the collective representation on the Internet of all digital assets referring to a physical specimen (which can include physical evidence of related observations), that meets the FAIR principles and that is distinguished and linked using globally unique persistent and resolvable identifiers to create an extensive online network of knowledge regarding life and related natural science objects.” (Hardisty et al. 2022).

As a starting point, four different communities were invited, representing the main collections of natural history collections: biological collections, palaeontological collections, geological collections, and anthropological collections. DiSSCo and GGBN as data providing infrastructures were also present. Breakout sessions took place corresponding to the different disciplines: Biology Earth Sciences and palaeontology, and anthropology . The fourth breakout session dealt with implementation and infrastructures

Questions from the joint questionnaire developed in collaboration with SYNTHESYS+ task 3.2 on MTAs (see Suppl. material 10) was one source of information used to get insight in common practice on the use of molecular collections. Outgoing loans for DNA investigations by external and internal researchers are already documented well across the partners, but associated lab data are mostly not linked properly. Associated MTAs, permits and other legal documents are stored centrally in 11 partner institutions, in six institutions they are stored by individual researchers or staff and one organisation doesn’t store them at all. 10 partners store the documents in both printed and digital form, seven store them digitally only.

For the question what kind of MTA the institutions employ for sending out samples to be used for molecular biological analysis four partners use the CETAF MTAs, seven partners use individual MTAs based on CETAF or GGBN, four partners use individual MTAs, and two partners have either no MTA in place or gave no clear answer.

When requesting material from third party institutions - incoming loans - eight partners store associated MTAs, permits and other legal documents centrally, at seven partners individual researchers or staff are responsible for their storage, five partners store them both in printed and digital form, while seven partners keep them only in digital format. Some organisations mentioned that many documents are not reported to the management at all.

The question if good policies are in place for documenting incoming loan requests for genetic analysis was answered positively by 12 partners, five partners said no without specifying reasons. The majority of respondents agreed that it would be useful to establish organisation-wide policies for incoming loans, though stated that it often would be very difficult to implement these due to a lack of resources.

As a general result of this questionnaire, workflows for handling voucher specimens and extracted DNA, as well as for maintaining related documentation vary widely and are often not institutionalised. The need for standardisation in the handling of documentation is evident for DNA tissue material transferred both by out- and ingoing loans.

This chapter is a summary of the still unpublished detailed report of the joint MOBILISE WG3 and SYNTHESYS+ NA3 -Workshop on a loans and permits data standard for scientific collections (see chapter 4.5).

The workshop explored differences and similarities between the different disciplines of a natural history museum: biology, mineralogy and palaeontology as well as anthropology. The workshop went beyond the scope of SYNTHESYS+ NA3.3 (with a focus on biological collections) to introduce the concept of a loans and permits data standard to the wider community of scientific collections. The main conclusion was that a standardised vocabulary for permits and regulations, in biology for example implementing national ABS legislation arising from the Nagoya Protocol*1, is relevant for all these disciplines and that this cross-disciplinary approach should be continued in the future. We decided to summarise the comprehensive results of the workshop here, but emphasise that non-biological collections are out of the scope of the current project report. The plan for a next step is to widen the scope again by setting up a TDWG Task Group for continuing the present work and transforming it into a TDWG standard for “Permits & Transactions” (working title).

The goals set out for the joint MOBILISE-SYNTHESYS+ workshop were:

• bringing together different collection communities

• discussing the need and possibilities for a data standard to share permit and loan information in different disciplines

• working on a set of minimum information required to provide permit/loan data

• coming to a decision that it makes sense to include all the invited disciplines

• (finding volunteers to form a working group for the data standard and agreeing on next steps, not relevant for this project report)

Within the scope of this workshop were Natural History Museums, Botanic Gardens including seed banks, Culture Collections, Technical Infrastructures and associated networks like GBIF, GGBN, DiSSCo or iDigBio.

Libraries, medical collections, related biological collections (agriculture and forestry collections, veterinary collections, zoos/aquaria, virus collections) were out of scope for this workshop, but could be added at a later point.

Regarding permit management, linking permits to samples or specimen data is straightforward in most cases, although there is no controlled vocabulary for permits. Post-hoc searching for applicable legal, ethical, and confidentiality restrictions for specimens is a time-consuming task that is currently done manually.

To explore the requirements of the different disciplines that are holding natural science collections, typical use cases and policies of each discipline were collated to form a starting point for a controlled vocabulary for the contents of legal documents. In breakout sessions characteristics and legal issues of different collection types were addressed and discussed.

Taking together the results of the surveys about managing and using molecular biological collections and of the consultation in the wider community of natural science collections, we derived four levels of activities (transactions) with increasing complexity: 1. Accessioning and (in-house) documentation, 2. Loans and exchange, 3. Use and 4. Submission and publication. With these four levels, the degree of interconnection and visibility of objects and data increases. Accordingly, there is an increasing need to provide standardised information on legal obligations that is transmitted with each step.

The following aspects were highlighted during the fourth breakout session of the MOBILISE-SYNTHESYS+ workshop with members of the biodiversity informatics community engaged in developing, implementing and maintaining biodiversity data infrastructures:

• The standardisation and harmonisation of legal and contractual information associated with physical specimens, their digital representations, as well as derived and associated data is considered to be much needed and to provide important advantages for future collections-based work.
• Accessibility of legal information is of importance for assessing compliance with, e.g., the Nagoya Protocol*1.
• Legal conditions apply to a wide range of different transactions, both analogue and digital, including e.g. loans, gifts, accessions.
• Digital specimens have an entirely different legal background as the physical museums' objects. Connecting both has more dimensions than just "linking permits". The relation between legal conditions associated with a specimen and its digital twin needs to be explored and clarified.
• The meaning of "open data" can be very differently understood, and thus be prone to misunderstanding and contention among different sectors and among different rights- and stakeholders.
• Liability issues may arise from transcripts of "closed" contractual agreements to a standardised set of terms (cp. the Typology of Legal/Contractual Terms).
• There are often legal and linguistic difficulties in transcribing and translating legal documents
• Time stamps are needed since the legal landscape is dynamic and laws change.
• Quality flags are required, e.g. in the form of "no permit present" in the absence of permit information.
• Persistent linkage to data derived from a specimen, e.g. during a loan event, is needed to ensure that legal information is appropriately propagated.
• Infrastructure providers need to solve long-term archiving.
• The different types and levels of legal structures need to be represented. For example, the Nagoya Protocol*1 applies to countries, which then mint national laws, which form the basis for contracts between e.g. providers and users.

The information and experiences provided by infrastructure providers and users in this breakout group became part of the foundation of the work of the SYNTHESYS+ working group and directly influenced the development of the typologies as well as the implementation model.

We collected more than 40 different permit and contract document types for expanding the GGBN permit/loan vocabulary into this Biodiversity Permit/Contract Typology. We selected a two-tiered system where we grouped similar documents (e.g. collecting permits from different countries) in one Document Type (e.g. the Document Type “Collecting Permit”). Then, similar Document Types (e.g. “Collecting Permit”, “Salvage permit”, “Incidental Take Permit”) were pooled to form one Document Category (e.g. the Document Category “Permits for Collecting & Related/Taking/Possessing”).

Apart from higher clarity, our two-tiered approach offers additional advantages:

• thematic clusters – Document Categories are grouping permit/contract documents corresponding to the main processes related to biodiversity collection objects, all but one of these processes (and document categories respectively) are repeatable, only “Collecting & Related/Taking/Possessing“ represents the first phase of a collection object’s life-cycle and is not repeatable for this specific collection object. At the same time most Document Categories contain either only permits or only contracts, while two categories comprise both (permits and contracts are mixed in the document categories ABS and Transport Documents).

• flexible granularity – For filing permits and contracts, institutions can choose whether they only use the less granular Document Categories and skip the more granular Document Types classification (e.g. for subject matters where they have few and very different documents), or they use both Document Categories and Types (e.g. for subject matters with a large number of different documents), or whether they use only a specific Document Type without associated Document Category (e.g. for subject matters where they have few very similar documents).

• graded specificity – the two-tiered approach of Document Categories and Document Types constitutes two levels of specificity that may help with filing documents. Sometimes it is too time-consuming to determine the correct Document Type for a given document at once, then it may be a compromise solution to allocate the document preliminarily to the (less specific) document category.

The group established a set of seven Document Categories (DC1-DC7) after a process of classification of existing documents. The process started with 16 clusters of documents that we initially proposed for Document Categories (see chapter 4.1) . Only two of these clusters remained unchanged throughout the classification process, i.e. the Access & Benefit Sharing Documents, and the Permits for Research. Seven clusters were combined into two Document Categories (i.e. "Permits to Collect and Take/Possess" and "Transportation Documents"). These seven may be an indication of how numerous related documents are in our natural history collections, and how highly their importance is estimated. Another three clusters got new names during the classification process: The Category "Agreement Document" became "High-Level Arrangements", "Use permission” changed to “Permits for special purposes”, and “Transfer of ownership” to “material transfer agreements, stewardships & ownership-related information”. Two initial clusters for Document Categories were transferred to the more granular Document Types. These are on the one hand "Exemption Permit," which we renamed to "Exemption Certificate" and added to all Document Categories for which it was an option based on our experience. On the other hand, we relocated the "Ethical oversight Document" into the "Permits for research" Category. Moreover, the initial cluster for a Document Category with the name "Institutional Permit" was dissolved and the contents (CITES Certificate for Scientific Exchange, US Endangered Species Act Museum permit, Memorandum of Understanding) were moved to the Document Categories "Transportation Documents" and "High Level Arrangements". Finally, the initial cluster for a Document Category with the name "Ownership Document" was excluded because it contained intellectual property rights, and we did not have the resources and expertise to address this topic. An overview of these changes is provided in Table 2.

We realised that our initial drafts for the Biodiversity Permit/Contract Typology were biased by the high number of documents stored in our biodiversity collections for taking objects from nature and transporting them. In the end we needed only two Document Categories for them, and a total number of seven Document Categories.

The Document Category definitions describe the scope of each Category and which Document Types it includes.

We created and allocated Document Types for each Document Category from the previous chapter (Table 3). Each Document Type is characterised by a definition. The 38 Document Types with their definitions, additional information about what a Document Type could include, and examples (e.g. links to publicly available blank forms) are listed in Suppl. material 1. Document Types serve two purposes: The main purpose was to identify and group documents relevant for future use of collection objects. For example, documents related to access to genetic resources & benefit-sharing*1 based on their utilisation. The second was to create a comprehensive system for filing all documents in the life-cycle of a collection object, e.g. a permission to enter a collecting site by car.

The search for European documents similar to those from the USA quickly became time-consuming, as few are standardised at the European level. Most European documents result from national or even local legislation. As a by-product we compiled a list of permits issued by US or European authorities (completeness was not pursued, Suppl. material 8).

Creating definitions for each Document Type was very labour-intensive because they had to fit all documents we knew that belonged to that Document Type. We intended for them to be short and concise, but at the same time contain enough information so that even non-experts could correctly assign the documents.

Once we began updating core elements of the GGBN Permit Vocabulary and Loan Vocabulary, i.e. names and definitions for a list of different permits and contracts, it soon became clear that uniform names/definitions for similar documents from different jurisdictions do not automatically provide uniform “restriction information” or, more generally, uniform use-terms. Simply because we often could not infer accurate “restriction information” from the name of the permit/contract (“contract” also includes loans of biodiversity collection objects). For instance, two “Prior Informed Consent-PIC” documents for utilising genetic resources*1 issued by different jurisdictions contained different restrictions, and also different duties. Both are the same type of permit, but containing different types of use-terms. It became clear that the lack of a comprehensive international standard for configuring biodiversity-related permits requires a twofold approach in addressing restrictions attached to biodiversity specimens. We had to create not only a Biodiversity Permit/Contract Typology for sorting the multitude of national permits/contracts, but we also had to complement it with another typology, the Typology of Legal/Contractual Terms for Biodiversity Specimens if we want to arrive at harmonised concepts for “restriction information”.

Lawfully handling and using biodiversity collection objects, as well as creating harmonised concepts for delivering “restriction information”, in general rests not on permits and contracts alone, there are additional lawful sources to be considered. A recent example is related to “utilisation of genetic resources”*1, first defined in the international Nagoya Protocol*1 and subsequently incorporated in several countries’ national legal systems. Countries often issue individual permits for “utilisation of genetic resources”*1 (provided the genetic resource*1 was taken from that country). Other countries do not regulate their genetic resources, therefore they do not issue such permits and any “utilisation of their genetic resources”*1 is permitted on the principle that anything is allowed unless it is explicitly forbidden. We identified five lawful sources as part of the backbone of our Typology of Legal/Contractual Terms for Biodiversity Specimens (7.2.1).

Documents related to objects in our collections do not only represent different lawful sources for restrictions on having and using these objects, they may also contain other characteristics than “restriction information”, e.g. a permission. These characteristics are compiled further below (7.2.2). Some documents related to collection objects are no judicial texts at all, but opinions of experts in natural sciences (7.2.3).

Users need a specific set of information to work efficiently with terms attached to biodiversity specimens.

1. First of all, they need to know the contents of a term, or in the event of a standardised vocabulary for terms, the definition/description for every item in the vocabulary.
2. Then, most users want to get information on the legal certainty that comes with a specific term, they want to know how much room for interpretation exists, and here the lawful sources mentioned above may serve as first clues.
3. Third, users want to know whether a term potentially applies to them, or has already been fulfilled in the past.

Our Typology of Legal/Contractual Terms for Biodiversity Specimens includes these three elements - definition, lawful source (chapter 7.3.1) , past/future (chapter 7.3.2). The Typology is intended to provide a preliminary, first lead on legal issues, not to replace the necessary thorough legal counsel prior to handling/using biodiversity specimens. Users wanting to implement this Typology in EDP systems (Electronic Data Processing) might also be interested in a classification that specifies whether an item of the Typology is a permission, prohibition, duty or restriction (or a combination of them) - for this purpose we provide a tabulated version of our Typology (chapter 7.3.3).

DiSSCo is currently developing a specification, that is, a technical standard, for digital representations of curated collection specimens, called open Digital Specimen (openDS; Addink and Hardisty 2020). Digital representations are the sum of information on the Internet about a natural specimen.

The following description of openDS is based on communication with Wouter Addink, Work package lead SYNTHESYS+ WP6 and DiSSCo CSO Deputy Director in charge of Data and Technology, to closely align the description with the most up-to-date understanding of both groups: “openDS is a specification for open Digital Specimens, which includes three components: a data model, ontology and an API. The openDS data model and ontology aim to describe specimens and their related objects, such as the organisation holding it, a contract or permit dealing with it, images of a preserved specimen, field observation media files, notes in field notebooks, in such a way that they can be related and also interlinked with additional data and information derived from and associated with the specimen, such as traits, taxonomic treatments and genetic sequence data. The different groups of objects within the specification are defined by classes with properties, which can be properties pointing to other classes to relate them, or properties with actual content (data or metadata). The first version of openDS contains the classes which are mandatory for basic interoperability with the DiSSCo Technical Framework and cover use cases such as Minimum Information about a Digital Specimen (MIDS) and the Specimen Data Refinery (SDR). These core groups are: Digital Specimen, Multimedia, Agent, Provenance and Other, where Other is used for concepts that don’t properly fit in the other core groups, but are not extensive enough to warrant the creation of another group.”

The openDS specification will standardise data and metadata entries for natural specimens and related objects and, thus, provide a foundation for global data harmonisation and aggregation. Enabling the merging of (meta)data of different types and from many different sources for their combined reuse, it will facilitate joint analyses of large datasets and transdisciplinary information. Community agreement on and acceptance of the specification will form the foundation for an integrated and extensible global data infrastructure providing (meta)data on biodiversity entities preserved and managed by scientific collections.

With this specification, the Distributed System of Scientific Collections (DiSSCo) can be one of the starting points for a globally connected, though distributed and federally governed infrastructure for biodiversity data. It can contribute to the integration of collection- and event-based data from species- to population-level into, for example, the Global Biodiversity Observation System (GBiOS) conceptualised by bioDISCOVERY/Future Earth and GeoBon (Krug et al. 2022), or the Knowledge Centre for Biodiversity (European Commission 2022) of the European Commission. The FAIRness (Wilkinson et al. 2016) of openDS objects and their intrinsic functionality for linking out from discipline-specific platforms beyond the realm of biodiversity and its associated sectors, enables event-based data describing and recording collection objects and field observations to become part of a wide-ranging open and interoperable global data system and network bringing together all kinds of data, information and knowledge.

The foundational architecture for such versatile and highly transdisciplinary next-generation data infrastructures has been laid out in the Digital Object Architecture (DOA; Sharp 2016). The DOA aims to enable “an internet of FAIR data and services” (Wittenburg et al. 2019) and conceptualises a system, which will enable the wide-ranging, dense and flexible interlinking of data entities, based on open FAIR Digital Objects (openFDOs; Schultes and Wittenburg 2019) as its individual data elements. openFDOs are data packets in which “payload” data are wrapped by several layers of operational metadata that transform data of any type into Findable, Accessible, Interoperable and Reusable (FAIR; Wilkinson et al. 2016) entities that can be effectively shared online. Furthermore, as openFDOs data become machine-actionable, this is enabling the automatic updating and extended interlinking of the objects as the basis for building a provenance record and increasing transparency.

When openFDOs and the DOA in addition follow and intrinsically implement within their metadata layers and infrastructure functionality the rights and guidelines associated with Collective benefit, Authority to control, Responsibility and Ethics, together forming the CARE principles (Carroll et al. 2021) of data governance, they will empower data providers and promote data and metadata sharing and reuse in a wide range of contexts.

The metadata layers that are wrapping an openFDO and form the foundation of the power and versatility of the digital objects combine both generally applicable operational information common to all openFDOs, as well as discipline- and data type-specific metadata profiles. The openDS specification provides such a discipline-specific metadata profile for the biodiversity sciences and data of the applied biodiversity fields. It is designed to include sub-schemata to represent metadata specific to physical objects of the biological, anthropological and geological domains. Among the disciplines that are in scope, sub-schemata are present for specimens from anthropology, botany, geology, microbiology, palaeontology and zoology.

In conjunction with the DiSSCo technical infrastructure and its openDS specification, which are focused on providing general functionality for work with the digital representations of collection specimens, a module is under development specifically for the management of loans and visits to collections of physical objects, the European Loans and Visits System (ELViS; Islam and Addink 2023). Supporting the functional focus of this DiSSCo module, here as well (meta)data standardisation and harmonisation will enable the inclusion and handling of all kinds of digital biodiversity records. For example, in ELViS open Digital Specimens can be included that represent physical specimens whose information have been digitised to different extents (cp. MIDS levels; Haston and Chapman 2022). The ability to include objects is independent of their scientific context (e.g. bio-, geo-, anthropological or ethnocultural diversity), object type (e.g. microscope slides, DNA extracts, mounted vertebrates, artist models of organisms), material composition, preparation and preservation (e.g. frozen tissue samples, bones, mineral objects, dried organisms or clay cultural artefacts), as well as their location in the world and their holding organisation.

Building on the openFDO and biodiversity-focused openDS data specifications, event-based transactional models consider that (meta)data are not static, but are constantly created, accessed (retrieved and read), updated and deleted. That is, they are always changing due to the activities of humans and machines that are interacting with them. Event-based transactional models are able to support and incorporate these interactions and their arising information. They do so by digitally representing and implementing the functionality contained in interactions, thereby building capacity for processes. Hence, they digitally represent the dynamic nature of (meta)data.

Forming the core part of the backbone in the next generation of biodiversity data infrastructures, event-based transactional models enable the bidirectional sharing and reuse of physical objects and digital data. For example, in event-focused infrastructures not only collection-holding institutions provide data to users, but annotations and extensions with new insights from users flow back to the data providers. From the recording of individual transaction events as well as their persistent linking to the data object arises an object’s provenance record. This record is created automatically with the help of transactional models. A complete time series of transactional records results in a full chain of custody for the physical object or data entity.

A chain of custody arising from a time series of provenance records that has been accumulating along, e.g., a research workflow can be transformed into an operation-grade chain of custody. This requires extensive resources and efforts to be allocated for development and continued maintenance. If required such an operational chain-of-custody can be further developed into supporting tracking and tracing. However, this would, for example, require extensive and expensive resources for the development and maintenance of such systems. Well-designed checks-and-balance environments will need to accompany them. The implementation of reliable tracking and tracing applications, specifically those that are expected to scale up to the global level are far out of the range of the resources usually available to natural science collections. Among the technical requirements are that any provenance information is associated with sufficient, reliable and information-rich metadata. This includes metadata that might be legally required for the specific use case at hand. It furthermore requires that such provenance systems are complemented by the implementation, maintenance, and auditing of software applications, operating systems and hardware, as well as comprehensive security measures. These resource-intense requirements and the wide range of consequences associated with implementations of tracking and tracing have to be considered, for example, in the contexts of international benefit sharing, supply chain certification, or verification of geographic origin.

Overall, transactional models with the capabilities of announcing and transmitting events and their results across interlinked infrastructure landscapes form the basis for transparency, attribution and accountability.

The event-based transactional model used in DiSSCo, which therefore can also be used in upcoming versions of its ELViS module, is based on the W3C-recommended Provenance Ontology (PROV, Lebo et al. 2013). The functionality of the PROV standard is extended by the W3C-recommended Web Annotation Ontology (OA, Sanderson et al. 2016), which allows an infrastructure to capture and record more detailed information about transactions. The OA standard thus fosters the linking of several transactional events, potentially involving different parts of a physical or digital object, into a series. In this way, a sufficiently information-rich provenance record can be accumulated.

The core elements (Fig. 3) of an event in the PROV standard are a prov:Activity, associated with or performed by a prov:Agent, potentially acting as part of a specific prov:Role, on a prov:Entity, which can be physical or digital. In a series of activity events on one and the same object or entity, the OA standard provides more specificity by adding functionality for identifying which specific part of the object (the oa:Target) was modified in which way (the oa:Body of the annotation).

Figure 3.  

The core elements of the PROV standard and their structure (recreated from Thessen et al. 2019 Appendix A, fig. S1, CC-BY 4.0; based on the PROV Model Primer, Copyright ©2013 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability rules, trademark rules and document use rules apply.)

Certain functionality needs to be implemented, for conditions to take the step from an attached information resource to being functionally incorporated and forming an integral part of (automated) online transactions. All information, first, needs to be reliably and persistently linked to the digital representation of the physical object or digital data. Second, information needs to be made machine-actionable as a prerequisite for implementation and, third, all information will need to be embedded in an information model or architecture that provides the structure and semantics supporting automated functionality, specifically reasoning. These prerequisites are essential for empowering complex online tools such as, for example, DiSSCo and its ELViS module.

Therefore, information on conditions that are specific to certain events, agents, objects and data (e.g. contracts) or inherited from contexts (e.g. national laws and regulations, or collection policies) will need to be stored with or linked to the digital objects as part of their metadata. For this purpose, the openDS specification will need to be extended. A general “slot” for conditions will allow the integration of information about conditions into the openDS specification. To design the data structure for this slot and for identifying the metadata details in this slot, the working group developed, as described in Chapters 6 and 7, a two-level classification. The first level, Document Categories and Types (see Chapter 6) provides an initial, high-level orientation to users, as well as a scaffolding for the structuring of the second level, the Typology of Legal/Contractual Terms for Biodiversity Specimens (see Chapter 7). The Typology of Legal/Contractual Terms directly contributes to the foundation for machine-actionability.

Once information on conditions associated with a collection specimen, e.g. in the form of governmental or contractual documents, has been digitised and integrated into the metadata of the openDS object (Document Categories and Types), the contents of such information and documents, which describe concrete rules for behaviours and activities, need to be identified, extracted and represented as machine-actionable commands (see the Typology of Legal/Contractual Terms for Biodiversity Specimens as a development step towards this goal).

Finally, the basic event-based transactional model built using the PROV and OA ontologies will need to be extended to allow the incorporation of functionality that transforms such document-derived, machine-actionable information on conditions into corresponding, appropriate and well-designed computational commands, steps and routines.

The Typology of Legal/Contractual Terms for Biodiversity Specimens (Chapter 7) has been developed primarily with the goal to document, standardise and harmonise the action-oriented contents stated within and between Document Types, as well as found associated with the diverse contexts in which physical and digital objects are embedded.

At the same time, the standardised Typology with its “catchphrases” and their definitions takes an important step towards a “vocabulary”. A vocabulary provides human-readable labels that can act as codified condition statements (see e.g. the labels of boxes and connections in Fig. 4). These labels are associated with corresponding machine-readable terms, which can act as commands in algorithms and computational routines (see e.g. the code examples below) that underlie and give rise to automated conditional actions.

Figure 4.  

ODRL information model (Diagram copied from "ODRL Information Model 2.2", Figure 1, https://www.w3.org/TR/odrl-model/; Copyright © 2018 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply, see https://www.w3.org/Consortium/Legal/2015/copyright-software-and-document).

Such condition statements specific to the bio-, geo- and anthropodiversity sector, and the computational workflows that implement arising domain-specific computational decisions and consequences, can be integrated into an existing Rights Expression Language (REL) and, thus, take advantage of its already developed functions (i.e. expressions). The vocabulary and functionality of a REL expanded for the natural sciences domain will complement the PROV and OA ontologies that are currently forming the basis of DiSSCo’s technical architecture. In the following, we are exploring the W3C-recommended Open Digital Rights Language (ODRL) ontology for use within the biodiversity sector and more specifically for an ELViS use case.

The ODRL ontology provides a general structure, as well as functions and workflows for transforming predefined condition statements into actions, which can be machine- and human-mediated, as appropriate (Fig. 4). In future work, the integration of biodiversity-relevant condition statements (“contents”) and actions into the already existing information model of the ODRL ontology can be further explored, necessary extensions developed and their limits identified. In this way, conditions can be made functional, resulting in automated events and transactions. In addition, biodiversity-specific condition statements can form the basis for developing, implementing and populating informative user interfaces. These enable human decisions and subsequent manual input. The incorporation of human decisions into workflows might be implemented as, e.g., a click on a “yes” or “no” button by a user after they made a decision that was informed by a machine-generated assessment provided by the user interface, as well as, if available and disclosable, attached documentation materials.

When developing and implementing machine-actionable and automated assessments of legal, including contractual, and other conditions, the following statement from the "ODRL Implementation Best Practices - Draft Community Group Report 10 January 2023" needs to be kept in mind and considered:

"While ODRL can represent elements of a license or regulation for machine consumption, it cannot replace them in court! It is best practice to explicitly point to the license or regulation that a policy models using the dc:terms property provided by the Dublin Core Metadata Initiative."

(Cited from Smith et al. 2023, Section 2.3. © Copyright 2023 the Contributors to the ODRL Implementation Best Practices Specification, published by the ODRL Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.)

Therefore, the final decision on an assessment of conditions associated with a physical specimen, openDS object or dataset always remains with the human user and requires in a final manual step the input of the human agent.

Fig. 5 provides a high-level, abstract view of the integration of ODRL functionality into the PROV-based transactional model employed by DiSSCo. The integration of an element representing “Conditions” (e.g. the terms from the typology) into the basic event-based transactional model (Fig. 4) fundamentally changes the structure of the data model. The model transitions from a two-dimensional triangular structure with bilateral links between all elements into a three-dimensional tetrahedron, in which for each node several bilateral links might be activated in parallel, the information of each of them being required for the event to be performed appropriately and as expected. Represented as a two-dimensional structure, a central junction arises (cp. the centroid of a tetrahedron) with connections to all of the four primary elements of the model, i.e. entity, agent, activity and condition. In this “Decision” hub simultaneous input from all four model elements is needed for the formulation of a valid outcome.

Figure 5.  

Generalised decision model for a single atomized step, that is, a functional event that cannot be further divided. The decision model arises by integrating conditions (e.g. the terms from the typology) into the basic transactional model. The model can be set into the background of a physical or digital infrastructure (e.g. a collection institution or digital platform) that publicly presents open data to the world.

For example, a decision about a loan will only be possible if a user (manually) and/or the model (automatically) considers at the same time the involved elements: the prov:Agents (odrl:Parties; Who are the holding institution and the loaner? Where are they located, also relative to each other?), the prov:Entity (odrl:Asset), that is, the physical object that is requested for loan (e.g. is it currently available and can it be sent out by mail or is it too fragile?), the prov:Activity (odrl:Action; here: a loan event, including an access event, which in addition might be associated with further requested use activities, e.g. a scan by computer tomography/magnetic resonance tomography, removal of tissue for DNA extraction, etc.) and specific Conditions (cp. odrl:Policy) arising from the contexts associated with the object, including its geographic origin and history (e.g. is it a biological type specimen and is there an institutional or collection policy for sending out types?; Where does the object come from and does it thus have legal documents attached, e.g. a MAT, governing access, use and subsequent duties of benefit sharing?).

In the ODRL ontology three categories of concrete conditions are defined, called odrl:Rules that can modify and thus have an impact on a decision, these are odrl:Permission, odrl:Prohibition, and odrl:Duty (for rules) or odrl:Obligation (for policies). Restrictions can be applied to these conditions in the form of odrl:Constraints modifying rules in general and/or odrl:Refinements of agents, activities and entities that enter the joint evaluation and decision process.

The overall structural system for conditions in ODRL is that all conditions are placed in the context of odrl:Policies at the highest level. Thereby, policies present the envelopes for sets of odrl:Rules (i.e. permissions, prohibitions, duties), these rules in turn can be modified by restrictions (i.e. constraints and refinements).

More fine-grained detail for an exploration of and insights into the applicability of the ODRL standard and its functionality to common tasks and use cases within biodiversity contexts is provided by considering the three types of policies defined within ODRL. These three policy categories are namely odrl:Agreement, odrl:Offer and odrl:Set. In a biodiversity context these can correspond to and be used for, for example, contracts between two parties, a licence attached to an odrl:Asset or prov:Entity by a rights-holder, and a governmental law or regulation, respectively.

Within odrl:Actions (cp. prov:Activities), the classes odrl:Use and odrl:Transfer of ownership form the two highest level subclasses. “Use” and “transfer” in general seem to be both pivotal to events and transactions, as well as to the conditions themselves that are associated with activities performed on and with (meta)data and digital representations of physical objects in the biodiversity sector. However, they are not only of interest in connection with ownership, but can interact with a wide range of conditions. Of interest are within the context of biodiversity data infrastructures, for example, the delegation of actions and their associated rules to third parties, or actions that involve multiple, that is more than two, parties each with different rights. This is an area that will need to be explored further, see Chapter 9.4 on next steps and open tasks.

In the previous sections a conceptual approach to the integration of conditions into the next-generation of biodiversity data infrastructures, based e.g. on the Digital Extended Specimen concept (DES; Hardisty et al. 2022) and represented by e.g. DiSSCo’s event-based transactional data model, has been explored and outlined. In this section we provide an example of how these abstract considerations might be transformed into a concrete, code-based implementation. The chosen use case for the example is a loan transaction represented in, mediated by and made machine-actionable by the planned ELViS module of the DiSSCo technical infrastructure.

The use case expressed in human-readable prose can be described as follows: Curator Hortensia (names were chosen in honour of the taxon group used in the example) of Institution 2 requests the loan of a specific physical specimen identified as common earthworm from Institution 1 holding the specimen. Curator Annelie at collection institution 1 prepares the loan and assesses if the specimen can be sent out to curator Hortensia. Once curator Annelie decides that the loan can move forward, she links associated legal/contractual documents with the loan transaction for online access by curator Hortensia. Finally, after the specimen has been sent out, the collection management record of the specimen gets updated with the new location information during the loan period.

Starting out with a minimal loan scenario the code base of the example is introduced and subsequently expanded by stepwise integrating additional information and functionality, so that an increasingly complex and thus more realistic and common loan scenario will be represented by machine-actionable code. The following outline provides an overview over the main stages of developing the loan transaction used in the example:

1. Introduction to the JSON-LD serialisation.

2. Digital representation of the elements involved in and necessary for the loan transaction using PROV.

3. A simple loan transaction without associated conditions, represented by PROV functionality. 3a Including the delegation of the activity from the responsible institution to a curator. 3b Communicating legal documents that are associated with and inform the loan transaction.

4. Updating the CMS or DiSSCo record to reflect the new locality of the physical specimen during the loan period using OA functionality. 4a Attaching information about rights to the annotation of the digital record.

5. Integrating conditions governing the loan transaction using ODRL. 5a Adding global YES/NO conditions governing shipping and handling of the physical specimen. 5b Setting loan decisions that are context-dependent: To which countries and partners can the specimen be shipped?

6. Moving towards an operational framework: exploring the policy life-cycle with inheritance between policies

A compilation of the example code provided for the loan use case can be found in Suppl. material 9.

JSON (JavaScript Object Notation, Wikipedia contributors 2023b) is a widely used, human-readable data exchange format that enables interoperability between independent infrastructure platforms. Its extension for linked data, JSON-LD (JavaScript Object Notation for Linked Data, Wikipedia contributors 2023c) opens up the opportunity of integrating efficiently the latest versions of distributed, independently maintained, often information-rich and standardised information resources, as for example ontologies, data files, database records or open FAIR Digital Objects (openFDOs), into data transactions between federated digital infrastructure systems by linking to these resources. The links should be based on persistent, globally unique and resolvable identifiers (PIDs), or more generally on Internationalised Resource Identifiers (IRIs, Wikipedia contributors 2022b). In the following example Uniform Resource Locators (URLs, Wikipedia contributors 2023d) are used, colloquially known as “web addresses” for locating and retrieving information on networks.

The following JSON-LD implementation of the ELViS loan use case was inspired by the examples and JSON-LD serialisations that have been developed and published for PROV (Provenance ontology), OA (Web Annotation ontology) and JSON-LD itself, which are provided by the World Wide Web Consortium, Inc., Delaware: Dover (W3C) at https://www.w3.org/ . More information, examples, explanations and background can be found at these links for

• PROV: https://openprovenance.org/prov-jsonld/

• OA: https://www.w3.org/TR/annotation-model/#complete-example

• JSON-LD: https://www.w3.org/TR/json-ld11/#data-model

This online validator can provide support for writing JSON-LD serialisation:

• JSON-LD Playground: https://json-ld.org/playground/

Step 1: Introduction to the structure of a JSON-LD serialisation

In the example code developed for the loan use case, the top-level of a JSON-LD serialisation (Fig. 6) is structured into two parts or entries: @context and @graph.

Figure 6.  

EXAMPLE CODE 1: Top-level framework of the example JSON-LD serialisation

In @context a shared digital context is defined for the overall JSON-LD object, in which terms are mapped to full IRIs (Fig. 7). This mapping enables the use of a short-hand notation throughout the object that is better human-readable. Thus, the term “http://example.com/physicalSpecimen1” in the following code can be written as “ex:physicalSpecimen1” and the full namespace address for the PROV term “Entity", that is, "https://www.w3.org/ns/prov#Entity" can be shortened and unambiguously identified by using the short-hand “prov:Entity”.

Figure 7.  

EXAMPLE CODE 2: Top-level framework: @context

In @graph the data structure and data of the actual transaction are described as entries in a list of data structures that are called maps or dictionaries, and which are key : value pairs (https://infra.spec.whatwg.org/#data-structures). These entries are each independent, but interlinked and interacting JSON objects themselves that might be, e.g., openFDOs. The objects require at least an @type property describing them. They describe an expression (i.e. a snippet of code) as a resource, which can be explicitly named by the use of an identifier (@id) or remain anonymous, in which case no identifier is associated with the resource or expression. The following graph in EXAMPLE CODE 3 includes two anonymous objects within @graph, one a prov:Entity, the other a prov:Agent (Fig. 8).

Figure 8.  

EXAMPLE CODE 3: Top-level framework: @graph

In the following, the context defined in @context remains the same, so that the subsequent example code snippets focus only on the development of the expressions in the data structure part under @graph, and the @context part will be omitted.

Step 2: Digital representation of involved objects

At the core of a loan transaction lies a collection specimen that is sent to a different locality for a certain time. To digitally represent this loan transaction, the digital representation of the specimen, its openDS twin, needs to be identified.

In the PROV ontology, the specimen’s representation as an openDS instance takes the role of a prov:Entity, thus, the JSON object is of "@type": "prov:Entity". The expression "@id" : "ex:physicalSpecimen1" links the JSON object to the openDS resource (that is, the digital twin of the physical specimen stored in the DiSSCo technical infrastructure) and, thus, uniquely identifies it (Fig. 9).

Figure 9.  

EXAMPLE CODE 4: Digital representation of the collection specimen

To improve human readability, a prov:label is set for the prov:Entity, informing us that the physical specimen in the focus of the loan transaction of this use case had been identified as a common earthworm Lumbricus terrestris Linnaeus, 1758 (Fig. 9).

A loan transaction has two agents, first, the institution holding the physical specimen, which is preparing the loan. Second, the institution that requested the loan and will receive it once the loan has been approved and sent out.

Both institutions are digitally represented as agents using "@type": "prov:Agent". The PROV standard allows a classification of agents into agent subcategories, we choose the subcategory prov:Organization for the description of the institutional agents and set it using the expression "prov:type" : ["prov:Organization"] . The institutions in this example are uniquely identified by their Research Organization Registry (ROR) identifiers, which are incorporated into the script as the values of @id (Fig. 10).

Figure 10.  

EXAMPLE CODE 5: Adding the legal agents of a loan transaction

We know based on the given human-readable ID to which of the two institutions the specimen belongs. However, this information is not machine-readable and -actionable. Therefore, it is necessary to explicitly link the specimen and Institution 1 that is holding it by employing an object of "@type": "prov:Attribution". The prov:Attribution-object links an prov:Entity to its associated prov:Agent (Fig. 11).

Figure 11.  

EXAMPLE CODE 6: Linking the specimen to its holding institution

Step 3: A simple loan transaction without associated conditions

Now the loan event itself needs to be defined and represented as JSON objects. Two objects are defined to capture the fundamental information of the loan process. These objects are the complementary entities of "@type" : "prov:Activity" and "@type": "prov:Usage".

The object of type prov:Activity defines the outline of the activity, that is, it sets the stage by defining its @type as an activity and minting an @id that uniquely identifies this concrete activity, this loan transaction. Furthermore, this object represents the (planned) duration of the loan (given by start and end time).

Due to the structure of the standard and its JSON-LD implementation, a second object seems to be needed that “qualifies” the activity as being of type prov:Usage. Usage describes an interaction between two resources that are in this case the interaction of a prov:Activity with a prov:Entity, in which the prov:Activity prov:used the prov:Entity (see diagram and examples at https://openprovenance.org/prov-jsonld/#introduction-qualification-pattern as well as https://www.w3.org/TR/2013/REC-prov-o-20130430/#description-qualified-terms). The activity and the entity of prov:Usage are unambiguously identified by 1) the (P)ID of this specific loan transaction as defined in the object of type prov:Activity and 2) the (P)ID of the specimen that is requested and prepared for loan, defined in the object of type prov:Entity, respectively. Both involved objects were defined earlier in the script.

After the loan activity defined as prov:Activity with the "@id" : "ex:loan2023_1" has been linked to the specimen defined as "entity" : "ex:physicalSpecimen1" , it needs to be associated with the two involved agents, ex:institution1_holding and ex:institution2_requesting. The object prov:Association makes it possible to do so. In addition, the prov:Association is further qualified by providing metadata on the plan or template that the loan activity follows ("plan" : "ex:elvis_standard_loan_routine") as well as the role of the two agents, stored as prov:role property.

Finally, after the loan transaction has been recorded and the physical specimen has been sent out to Institution 2, the specimen needs to be associated with the receiving institution for the duration of the loan. Thus, the attribution of the specimen needs to be updated, using again prov:Attribution for this purpose (Fig. 12).

Figure 12.  

EXAMPLE CODE 7: Defining the loan activity of the transaction

Obviously, this is a very rudimentary way of recording the change in association for the specimen during the loan that doesn't differentiate between properties that change (e.g. locality and associated curator) and those properties that remain associated with the original holding institution (e.g. ownership and accession information). Here, expressions need to be found or developed in future work that enable the system (e.g. the DiSSCo technical infrastructure) to update and record only those properties that require updating

Step 3a: Delegation of the activity from the responsible institution to a curator

While loan transactions officially (legally) often are transactions between institutions, in reality, it is collection staff and scientists who act on behalf of institutions. Organisations’ concrete activities are delegated to individual persons. The PROV ontology can represent patterns of delegation.

To represent a delegation, two additional entities are defined for each delegation relationship. First, a prov:Person is defined as prov:Agent in addition to the already defined prov:Organization-agent object. This prov:Person object is uniquely identified by the @id of the involved person (here referred to as ex:curator1 or ex:curator2), which might be, for example, an ORCID. For improved human readability, the name of the person (here Annelie or Hortensia) is added to the JSON object representing the involved person.

The second object defines the delegation itself ("@type": "prov:Delegation") and its unique @id ("@id" : "ex:toCurator1" or "@id" : "ex:toCurator2"). The following line "responsible" : "ex:institution1_holding" (or "responsible" : "ex:institution2_requesting") identifies the delegating organisation, while the next line "delegate" : "ex:curator1" (or "delegate" : "ex:curator2") identifies the person that performs the activity in delegation for the organisation. The last line "activity" : "ex:loan2023_1" identifies the activity that gets delegated, that is, to which the delegation refers. A more realistic implementation might divide this activity further into institution-specific sub-activities, that is, e.g. the sub-activities "ex:preparingLoan" and "ex:receivingLoan" that can inherit the delegation (Fig. 13).

Figure 13.  

EXAMPLE CODE 8: Delegation of the activity

Step 3b: Communicating legal documents that are associated with and inform the loan transaction

In the ELViS use case it is important that documents associated with and governing the loan transaction are transferred from the holding institution to the institution that receives the physical specimen as loan.

Such legal and ethical documents and information can be directly associated with the physical specimen (the prov:Entity, in that case likely as part of a prov:Collection). In addition, certain documents, e.g. defining institutional and collection policies, might be associated with and govern the loan event itself (not the specimen directly). In that case, a set of documents will be assembled in preparation of the loan that is loan-specific.

In general, documents that will be attached to and transferred with the loan will be focused on the physical specimen and the tangible, offline loan process, in accordance with the main perspective of our use case. They might include selected and/or abridged versions of documents or their extracted information contents, whereby all three will be associated with the physical specimen.

Information that governs the loan transaction can be incorporated into the digital representation of the loan event itself, using objects of "@type" : "prov:Communication" . The functionality of prov:Communication makes it possible to represent that one activity informs another activity. In the example, the prov:Communication object has the (P)ID ex:transferLegalInfo.

The activity that is informed by the prov:Communication is the earlier defined loan activity (ex:loan2023_1). The activity that informs the loan event is the informant. To define the informant activity, again a prov:Activity entity is generated (with the (P)ID ex:createdLegalInfoCollection) and further qualified by a prov:Usage object. The prov:Usage expression associates a collection of legal documents and information (a prov:Entity) with the ex:createdLegalInfoCollection activity. The entity representing the collection remains anonymous in the example, that is, without (P)ID. It is defined by a list of two elements that have the IDs ex:assocLegalDoc1 and ex:assocLegalDoc2 (Fig. 14).

Figure 14.  

EXAMPLE CODE 9: Communicating legal information associated with the loan transaction

The information encoded by using PROV, so far represents some basic building blocks of a loan transaction. This digital representation of the loan transaction in the ELViS module of the DiSSCo technical infrastructure can be made accessible to both (or all) partners of the loan transaction. Shared online via the ELViS system, digital representations of loan transactions enhance communication between the involved partners and in this way can support and mediate interactions associated with loans of physical specimens.

Step 4: Updating of the CMS or DiSSCo record to reflect the new locality of the physical specimen during the loan period

Supported by the digitised information available in the online ELViS system, once the decision has been made to send out a physical specimen, it can be of interest to collection managers to update the record of the physical specimen with some or all of the information associated with the loan. Such an update can make sense for the record of the physical specimen in an institution’s local collection management system (CMS) or in the globally accessible openDS twin of the physical specimen stored in the DiSSCo technical infrastructure. We will use the example of updating the locality information associated with the physical specimen to introduce functionality provided by the Web Annotation Ontology (OA).

In the following code examples the @context entity will be added with one line defining the specific namespace that is the focus of this part of the example code. This is to highlight that the examples are now using expressions of additional, more specialised ontologies.

EXAMPLE CODE 10 shows an encoding of an annotation event that modifies the local CMS record or a globally shared openDS twin of the physical specimens with information taken from the loan transaction. In this case, the locality information is updated to reflect the location of the physical specimen during the loan period. If set up in advance by the holding institution, it is assumed that such an annotation event is automatically triggered by the ELViS system at the time the loan is sent out, as well as when it is returned and the physical specimen is reinserted into the collection of its steward institution. In this case, no human involvement is needed, since the transactional model of ELViS will support machine-actionability.

The JSON object of "@type" : "oa:Annotation" is identified by a (P)ID, here represented by ex:update_spec1_location. The keywords body and target are functionality provided by the OA ontology. body identifies the information (e.g. provided by a standardised locality string) that will be inserted into the CMS record or openDS metadata, and thus update the locality information there. The target identifies and links to the CMS record or openDS object that represents the physical specimen and needs updating (Fig. 15).

Figure 15.  

EXAMPLE CODE 10: Annotation of a corresponding CMS record (or openDS twin)

Step 4a: Attaching information about rights to the annotation of the digital record

The OA ontology defines a key - value pair (rights) to capture and store rights information that is associated with an annotation event itself, as well as the information given in the body and/or the target object (here: the CMS record or openDS). EXAMPLE CODE 11 shows how rights information can be integrated at the level of the annotation event as a whole (ex:AnnotationRightsInfo) and at the level of the target object. The expression "rights": "ex:RecordRightsInfo" is only changing and setting the rights for the target context (Fig. 16).

Figure 16.  

EXAMPLE CODE 11: Adding information on rights associated with the CMS record and annotation itself

Step 5: Integrating conditions governing the loan transaction

The digital representation of the loan transaction at this point provides a sufficiently developed context for introducing conditions into the code of the example. Functionality provided by the ODRL ontology is used as an example of how legal information provided by documents can be transformed into and implemented as machine-actionable commands.

Step 5a: Adding global YES/NO conditions governing shipping and handling of the physical specimen

In preparation of a loan transaction the conditions attached to the physical specimen need to be clarified. This involves, for example, an assessment if the specimen can be shipped to a different collection or research institution, and which actions on and with the specimen are allowed by the receiving partner.

Chapter 4.6 provides proposals for standardised legal/contractual terms that can be used to set conditions that might apply in the context of a loan transaction. In future work, these terms can be integrated into the functionality provided by the ODRL ontology (using e.g. the "profile" functionality, see https://www.w3.org/TR/odrl-model/#profile) or other rights expression languages. The W3C recommendation webpage for the "ODRL Information Model 2.2" (https://www.w3.org/TR/2018/REC-odrl-model-20180215) and the "ODRL Implementation Best Practices" webpage (https://w3c.github.io/odrl/bp/) offer an introduction to and guidelines for implementing the ODRL ontology in JSON-LD.

In the following code examples, a globally applicable (that is, no constraints or refinements apply) permission is encoded that allows unconditional shipping to 3rd parties. A second global permission subsequently is added that provides explicit consent to physical analyses of the material specimen.

In EXAMPLE CODE 12 a contractual agreement is digitally represented by using the ODRL policy type odrl:Agreement. This loan contract is unambiguously identified by and has the address of ex:inst1_inst2_loan_contract. The next line of code links to a (future) ODRL profile ("profile": "ex:biodivDomain_profile") that defines legal/contractual (cp. Chapter 4.6.4) - and at that point potentially also social and ethical (see CARE principles) - terms that are specific to the biodiversity domain.

The agreement explicitly provides a permission that allows the shipping of the physical specimen to third parties ("action" : "ex:shipping_to_3rdParty"), for example implementing term 23_YES_3rd party of the Typology of Legal/Contractual Terms. This odrl:Rule has been set by the institution holding the physical specimen (the "assigner" : "institution1_holding"). It governs the rights and conditions associated with the physical specimen ("target" : "ex:physicalSpecimen1"), for which conditions are evaluated for the concrete loan transaction in question. The loan requesting institution is identified by "assignee" : "ex:institution2_requesting".

As before, the informative elements of this policy are defined by links to PID/ID-identified information (which might be formatted and deposited as openDS or openFDOs objects with other specifications) that is stored independently within the Distributed System of Scientific Collections (DiSSCo) or the wider network of a decentral, federated digital object architecture (Fig. 17).

Figure 17.  

EXAMPLE CODE 12: Applying a permission to the loan transaction

The same contractual agreement might further set a second permission ("action" : "ex:physical_analysis") and allow anatomical-morphological analyses on the physical specimen (Fig. 18), compare 10_YES_physical_analysis of the Typology of Legal/Contractual Terms (Annex 2).

Figure 18.  

EXAMPLE CODE 13: Adding a second permission to the loan transaction

EXAMPLE CODE 14 alternatively implements a globally valid prohibition that applies to the physical specimen and prohibits all shipping of the specimen ("action" : "ex:noShipping") implementing 80_NO_shipping of the Typology (Fig. 19).

Figure 19.  

EXAMPLE CODE 14: Applying a globally applicable prohibition to the loan transaction

Step 5b: Representing information for loan decisions that is context-dependent

Often decisions associated with loan transactions are context-dependent. In the following we provide example code for implementing rules representing answers to the question to which countries and partners a physical specimen can be sent out.

The basis again is an explicit permission with its associated information on the target, the assigner and the assignee. The action now implements a different predefined legal/contractual term, that is 24_obligations_3rd_party, with the outcome after a successful evaluation however remaining the same ex:shipping_to_3rdParty.

The permission is modified by a constraint expression that limits the permission for shipping of the physical specimen to third parties located in countries within the European Union. If that constraint is evaluated and the country, in which the receiving institution is located, satisfies the constraint (i.e. it is a member of the EU for this example), then an action appropriate to fulfilling the term 24_obligations_3rd party from Annex 2 can be conducted, i.e. the loan transaction can go through and the physical specimen can be prepared for shipping to this institution.

The second global permission (allowing anatomical-morphological analyses) is not impacted by the constraint to the first permission and remains as before (Fig. 20).

Figure 20.  

EXAMPLE CODE 15: Defining a context-dependent decision - based on country

constraint properties modify specifically prov:Rules, which include prov:Permissions, prov:Prohibitions and prov:Duty's. The refinement property is used to modify (restrict) the scope of prov:Actions, prov:Assets and prov:Party's.

In the following EXAMPLE CODE 16 a refinement is introduced to the assignee of the first permission, which requires loan recipients to be of age (i.e. 18 years or older). To be able to do so, the assignee is defined as "@type": "foaf:Person". In the following line the person is identified with "source" : "ex:curator2" to be curator Hortensia at Institution 2. The refinement checks the age of Hortensia by defining an operation that states that a foaf:Person's age (foaf:age) is required to be greater than the integer number "17", that is, it needs to be "18" or higher. If that equation is true, then the geographic constraint will be evaluated. If both restrictions are positively evaluated, then the action of ex:shipping_to_3rdParty corresponding to the linked resource 24_obligations_3rd party can be performed (Fig. 21).

Figure 21.  

EXAMPLE CODE 16: Defining a context-dependent decision - adding an age restriction

Step 6: Moving towards an operational framework: exploring the policy life-cycle with inheritance between policies

In an operational setting, as for example ELViS and the DiSSCo technical infrastructure, policies and events do not exist in isolation. Hence, their machine-actionable representation as program code will not be called and run in isolation, too.

In the here explored use case of an ELViS loan transaction, the code describing odrl:Policies is populated with links to information that has been captured by PROV-constructs, which in their first function are used to record all activities and lay down a provenance trail over time. At the same time, due to this function they therefore are the go-to resources for linking to the most up-to-date versions of digital objects and (meta)data. These up-to-date versions can then be used to construct conditions in the form of odrl:Policies.

Furthermore, odrl:Policies complement each other, exchange information and function in interaction. Already within the considered loan use case they evolve and introduce a life-cycle perspective. A loan environment can be considered to start with a prov:Agent designing a loan policy in the form of an odrl:Offer and offer prov:Entities (physical collection specimens) on the ELViS platform as available for loan. Another prov:Agent interested in receiving a specimen on loan, can design an odrl:Request (a subtype of odrl:Policy). Generally, this will mean that they fill out a standard request form on the ELViS system with the specifics of their loan request. The loan system will then bring together both the odrl:Offer and the odrl:Request policies and create from them a concrete loan contract, an odrl:Agreement. This newly minted odrl:Agreement policy will inherit its information from the two parental policies (odrl:Offer and odrl:Request). Based on the information and conditions inherited, the ELViS loan system will evaluate if the loan request fulfills the requirements associated with the requested specimen(s). If it does, the contract can be manually accepted by the involved prov:Agents and the loan be realised. In this way, odrl:Offer and odrl:Request policies evolved into an odrl:Agreement contract.

The following code example (EXAMPLE CODE 17) provides an overview over the elements of the policy life-cycle (Fig. 22). Several open questions currently remain regarding the details of inheritance, for example when information and conditions overlap and need to be merged, as well as concerning approaches for identifying and accessing specific properties within the policy objects. Thus, the example code exemplifies a general framework that can be further developed.

Figure 22.  

EXAMPLE CODE 17: The policy life-cycle: an offer (with links to PROV objects) and request (with links to PROV objects) evolve into a contractual agreement as the basis for a machine-actionable assessment, including a final human decision step, in preparation of and leading up to a loan event.

The Kunming-Montreal Global Biodiversity Framework (GBF; Conference of the Parties to the Convention on Biological Diversity 2022) adopted in December 2022 by the parties to the UN Convention on Biological Diversity (CBD) sets global biodiversity conservation into an overarching context of ethical and socio-political principles that provide conditions for human actions and interactions (CBD 2022, Section C). Most of these principles are of direct application and impact to biodiversity data, data infrastructure design and maintenance, as well as knowledge management. For example, biodiversity data and knowledge services are called to consider different value systems (IPBES-Intergovernmental Science-Policy Platform on Biodiversity and Ecosystem Services et al. 2019), be founded on a human rights-based approach (UNSDG-HRWG United Nations Sustainable Development Group Human Rights Working Group 2003), enable free, prior and informed consent and the right to participatory decision-making by indigenous peoples and local communities (IPLCs; United Nations General Assembly 2007), as well as support collaboration of all, providing implementation for a whole-of-government and whole-of-society approach.

IPLCs have already been working for some time on transforming such principles into operational implementations. Members of the communities developed the CARE principles (Carroll et al. 2021) and have started to build systems of concrete flags that can be associated with physical objects, e.g. collection specimens, and data, e.g. genomic data. One such system are the Local Contexts labels, including Traditional Knowledge and Biocultural labels (https://localcontexts.org/).

The approaches that have been developed by and for IPLCs can provide inspiration, since biodiversity data infrastructures and natural science collections are embedded in highly cooperative social contexts that involve a wide range of stakeholders and rights holders, which at least in part have distinct and sometimes divergent interests.

These social structures are characterised by dynamically changing and sometimes complex conditions arising from multi-layered legal, ethical and social contexts, multiple interacting agents in a variety of roles and sets of situation-specific restrictions and decision processes. Examples are annotations of taxon identifications, and updates to a physical object’s associated collection management information by members of the biodiversity sciences and collections communities. In addition, the same physical object might be subject to contracts, policies, regulations and laws at all legislative levels, from civil contracts between two parties to local, national and international legislation, including bilateral and multilateral treaties.

Thus, information on conditions associated with physical specimens and biodiversity data is and increasingly will be multi-faceted, structured and interlinked, dynamic and context-dependent. The modular structure of the openDS specification will enable the integration of one or more classes that store such information. In next steps, the overall structure as well as internal details of these classes will need to be clarified and developed. Together the Biodiversity Permit/Contract Typology and the Typology of Legal/Contractual Terms for Biodiversity Specimens provide a comprehensive and information-rich starting point for structuring data and information on conditions within the openDS specification.

One higher-level split that suggested itself already during this work cycle differentiates between, on one hand, odrl:Set and odrl:Offer policies spanning open a context of "lawful handling" and, on the other hand, odrl:Agreement policies determining concrete "contract conditions" between uniquely identified parties for specific assets (specimens). The first category provides information on conditions derived from applicable laws and regulations. Specifically for existing collection objects, due to resource limitations, it is practically impossible for natural science collections to retrospectively provide sufficient information for all objects. In addition, for a large part of old collection objects, legal conditions are not readily available and cannot be reliably inferred automatically. Furthermore, many common species might not have any legislation associated with them. Entries to the second category storing contractual information might be more realistically provided, at least for contracts covering future activities and transactions, as e.g. loan transactions. Most transactions are associated with contracts that are concrete, well-delimited and state conditions explicitly. Here, the decision is whether all available contractual information should be reflected in the DiSSCo technical infrastructure and e.g. its ELViS module.

Some challenges that the working group encountered and discussed during the development of the Typology of Legal/Contractual Terms for Biodiversity Specimens were associated with use cases in which conditions are linked to past (e.g. collecting from nature) versus future (e.g. loan, use) events, as well as use cases that require the identification of implicit permissions. Implicit conditions can be associated with specimens and/or situations, which are characterised by an absence of existing policies or regulations.

The SYNTHESYS+ working group focused exclusively on legal and contractual conditions associated with physical specimens to build a starting point for continuing development. Participants of the MOBILISE-SYNTHESYS+ workshop in the fall of 2021 pointed out that legal conditions apply to a wide range of both analogue and digital transactions. It is clear that, compared to physical specimens, digital objects, (meta)data and processes exist in entirely different legal backgrounds, which currently are very dynamic and rapidly evolving, cp. e.g. the ongoing discussions and negotiation process on “Digital Sequence Information” within the CBD, and the latest UNCTAD report on transnational data flows (UNCTAD United Nations Conference on Trade and Development 2021). Understanding, differentiating and connecting the interrelated realms of physical and digital objects will be an important objective of upcoming work. It will increasingly require transdisciplinary collaboration with legal experts.

Further work is also needed to investigate the capabilities and limitations of applying ODRL and its extensions for the design and construction of normative statements for data and services required by and commonly occurring within the biodiversity sector. Very likely existing rights expression languages (RELs), with ODRL being one ontology system, will need to be modified, expanded and adapted to the specifics of the biodiversity sector with its own set of widely varied legal, ethical and social contexts.

Kebede et al. 2021 pointed out and discussed several challenges that they encountered while exploring ODRL for use cases arising in connection with data sharing infrastructures in the health and logistics sector. The limitations considered by them concern, e.g., the delegation of compound rights, in which some rights are passed on, while others are restricted or revoked, specifically in situations of unequal power; the handling of newly created entities from existing assets; normative statements pertaining to outcomes (e.g. of "use") versus the process-based approach taken by ODRL; agent granularity and the diversity of their roles; a dynamic user-driven consent management; and transitions within the policy- and rule-lifecycles.

Kebede et al. 2021 suggest eFlint (Binsbergen et al. 2020) as an alternative or complementary approach to ODRL. They describe and highlight eFlint as an action-based policy language. In addition, they point to several more RELs and suggest a review of Hohfeld’s “Fundamental legal conceptions” (Hohfeld 1917), which introduces and informs about the fundamentals of legal decision processes. This provides essential background for investigations and work towards a decision for a fully applicable and functional REL for defining and implementing normative statements and their conditions for data and services.

In conclusion, the investigation of the ODRL ontology, its applicability and limits, as well as explorations of additional existing REL standards and ontologies will need to be continued. Furthermore, a comprehensive structural framework for integrating information about conditions into the openDS specification will need to be developed, considering (known) challenges and a wider range of use cases. For this, the interconnections between and potential inheritance of conditions associated with physical and digital entities will need to be developed.

The goal of all these developments is the integration of conditions into events and transactions that are representing the dynamic and evolving nature of physical and digital biodiversity records as captured in and by biodiversity data infrastructures.