Release for the deliverable 2.6

.editorconfig

@@ -8,9 +8,6 @@ trim_trailing_whitespace = true
 insert_final_newline = true
 max_line_length = off
 
-[*.rst]
-indent_size = 4
-
 [*.bat]
 indent_style = tab
 end_of_line = crlf

.github/workflows/code-style.yml

@@ -44,3 +44,41 @@ jobs:
         run: |
           flake8 docs --count --select=E9,F63,F7,F82 --show-source --statistics
           flake8 docs --count --max-complexity=12 --max-line-length=130 --statistics
+
+  file-naming:
+    name: File Naming Convention
+    runs-on: ubuntu-latest
+    steps:
+      - name: Check out repository
+        uses: actions/checkout@v6
+
+      - name: Check docs file naming
+        run: |
+          echo "Checking documentation filenames…"
+
+          invalid_files=$(find docs \
+            -type f \( \
+              -name "*.rst" \
+              -o -name "*.png" \
+              -o -name "*.jpg" \
+              -o -name "*.jpeg" \
+              -o -name "*.svg" \
+              -o -name "*.gif" \
+              -o -name "*.tiff" \
+            \) \
+            | grep -Ev '^docs/_(static|templates)/' \
+            | grep -E '[A-Z_]' || true)
+
+          if [ -n "$invalid_files" ]; then
+            echo "❌ Invalid documentation filenames found:"
+            echo "$invalid_files"
+            echo ""
+            echo "Rules:"
+            echo "  - lowercase only"
+            echo "  - use '-' as separator"
+            echo "  - no underscores '_'"
+            echo "  - exception: docs/_static/** and docs/_templates/**"
+            exit 1
+          fi
+
+          echo "✅ Documentation filenames look good."

CONTRIBUTING.md

@@ -16,6 +16,18 @@ If you find a bug in the documentation, please [open an issue](https://github.co
 
 The documentation is hosted on Read-the-Docs and using standard Sphinx documentation. The documentation is written in reStructuredText (`.rst`) format. It can be compiled locally using Sphinx and viewed in a web browser.
 
+### File Naming Convention
+
+While it may not be clear at first, naming of documentation files is important for clarity and organization. It is also directly reflected in the URLs of the hosted documentation. Please follow these conventions when naming documentation files:
+
+- Use lowercase letters.
+- Use hyphens (`-`) to separate words. Do not use underscores (`_`).
+- Avoid using special characters or spaces.
+- Use descriptive names that reflect the content of the file.
+- Do not change names of existing files unless absolutely necessary, as this may break links.
+
+Adhering to these conventions will help maintain a consistent and organized documentation structure.
+
 ### Writing Style
 
 When contributing to the documentation, please follow the following writing style:
@@ -43,10 +55,11 @@ First, install the required dependencies (preferably in a virtual environment):
 ```bash
 python -m venv venv
 source venv/bin/activate
-
 pip install -r requirements.txt
 ```
 
+**Note**: To activate the env on Windows, run in cmd: `venv\Scripts\activate.bat`.
+
 Then, you can build the documentation using the following command:
 
 ```bash

CONTRIBUTORS.yml

@@ -5,6 +5,20 @@ Marek Suchánek:
   orcid: 0000-0001-7525-9218
   affiliation: CTU in Prague
 
+Jana Martínková:
+  first_name: Jana
+  last_name: Martínková
+  github: jmartinkova
+  orcid: 0000-0001-8575-6533
+  affiliation: CTU in Prague
+
+Vojtěch Knaisl:
+  first_name: Vojtěch
+  last_name: Knaisl
+  github: vknaisl
+  orcid: 0000-0003-0103-8468
+  affiliation: Codevence Solutions
+
 Daniel Garijo:
   first_name: Daniel
   last_name: Garijo
@@ -39,3 +53,69 @@ Allyson Lister:
   github: allysonlister
   orcid: 0000-0002-7702-4495
   affiliation: University of Oxford
+
+Raul Palma:
+  first_name: Raul
+  last_name: Palma
+  github: rapw3k
+  orcid: 0000-0003-4289-4922
+  affiliation: Poznan Supercomputing and Networking Center
+
+Katja Moilanen:
+  first_name: Katja
+  last_name: Moilanen
+  github: katja-moilanen
+  orcid: 0000-0002-7668-5427
+  affiliation: TAU-FSD/CESSDA
+
+Andrea Mannocci:
+  first_name: Andrea
+  last_name: Mannocci
+  github: andremann
+  orcid: 0000-0002-5193-7851
+  affiliation: CNR-ISTI
+
+Paolo Manghi:
+  first_name: Paolo
+  last_name: Manghi
+  github: paolomanghi
+  orcid: 0000-0001-7291-3210
+  affiliation: CNR-ISTI
+
+Miriam Baglioni:
+  first_name: Miriam
+  last_name: baglioni
+  github: mirima2
+  orcid: 0000-0002-2273-9004
+  affiliation: CNR-ISTI
+
+Pablo Alarcón-Moreno:
+  first_name: Pablo
+  last_name: Alarcón-Moreno
+  github: pabloalarconm
+  orcid: 0000-0001-5974-589X
+  affiliation: Universidad Politécnica de Madrid
+
+Renaud Duyme:
+  first_name: Renaud
+  last_name: Duyme
+  github: rduyme
+  affiliation: ESFR
+
+Andres Tabima:
+  first_name: Andres
+  last_name: Tabima
+  github: andresTabiTuwien
+  orcid: 0009-0002-4848-5089
+  affiliation: TU Wien
+
+Menzo Windhower:
+  first_name: Menzo
+  last_name: Windhowe
+  orcid: 0000-0002-2204-4018
+  affiliation: KNAW
+
+Daan Broader:
+  first_name: Daan
+  last_name: Broader
+  affiliation: KNAW

README.md

@@ -6,7 +6,7 @@
 
 ## Usage
 
-This repository contains the source files for the OSTrails documentation. The documentation is hosted on Read-the-Docs and can be accessed [here](https://docs.ostrails.eu/en/latest/).
+This repository contains the source files for the OSTrails documentation. The documentation is hosted on Read-the-Docs and can be accessed (only for this branch) [here](https://ostrails-docs--22.org.readthedocs.build/en/22/commons/resources.html).
 
 ## Contributing
 

docs/architecture/intro.rst

@@ -11,7 +11,7 @@ A key objective of this architecture is to prevent vendor lock-in, ensuring tool
 
 The architecture also supports both current well-known and potential future patterns of interactions between components, fostering innovative use cases that enhance automation and machine-actionability of digital object information exchange. For example, while it is yet uncommon for data repositories to update DMPs, the architecture anticipates and accommodates such potential pathways.
 
-.. figure:: OSTrails-architecture.png
+.. figure:: ostrails-reference-architecture.png
 
     OSTrails Architecture
 

docs/architecture/skg_if.rst → docs/architecture/skg-if.rst

@@ -2,7 +2,8 @@ Architecture: SKG IF
 ====================
 
 .. page-authors::
-    Tomasz Miksa
+    Andrea Mannocci
+    Paolo Manghi
 
 
 This page introduces the Scientific/Scholarly Knowledge Graph Interoperability Framework (SKG-IF). It outlines its motivation, relation to key elements, and applications in OSTrails.

docs/commons/dmp/application-profile.rst

@@ -0,0 +1,72 @@
+OSTrails Application Profile for maDMPs
+=======================================
+
+.. page-authors::
+    Tomasz Miksa
+    Marek Suchánek
+    Jana Martínková
+
+
+The **OSTrails Application Profile (AP) for machine-actionable Data Management Plans (maDMPs)** is a tailored extension of the :doc:`RDA DMP Common Standard (DCS) for maDMPs <dmp-common-standard>`.
+
+It is designed to enhance interoperability while addressing requirements from national and thematic pilots, often reflecting specific funder and community templates. The profile provides a list of additional terms that can be used to express information contained in DMPs in a machine-actionable way.
+
+Upon successful review, some of the fields from the AP will be incorporated into the RDA DCS. This process is still ongoing and requires broader community consensus and RDA involvement.
+
+The work presented on this page reflects the **working draft as of January 2026**.
+
+Purpose and scope
+-----------------
+
+The OSTrails AP enhances interoperability by introducing **additional entities, fields, constraints, and usage patterns** that are not covered by the minimal core defined in the DMP Common Standard.
+
+It is designed to:
+
+- Support **information requirements imposed by funding agencies**
+- Reflect **national, institutional, and thematic practices** around DMPs
+- Enable reliable machine-to-machine interactions in the European research data management ecosystem
+
+Technically, the application profile is specified in accordance with the extension mechanisms foreseen by the DMP Common Standard and forms a core artefact of the DMP Commons as a formal description of the maDMP data structure.
+
+Iterative and community-driven development
+------------------------------------------
+
+The OSTrails Application Profile is developed **iteratively**.
+
+Rather than defining a fixed, one-time specification, the profile continuously evolves by consolidating requirements gathered from multiple perspectives and real-world implementations. This approach allows the AP to respond to emerging needs while maintaining internal consistency and interoperability.
+
+The application profile is intentionally designed as an artefact that is **by-design ready for future evolution**, both within the OSTrails project and beyond it.
+
+At present, the OSTrails AP is in an **early stage of development**, and its structure and content are expected to mature through successive iterations.
+
+Sources of requirements and inputs
+----------------------------------
+
+The OSTrails Application Profile is informed by a wide range of inputs, including:
+
+- **Funding agency DMP templates** and policy requirements
+- **European and EOSC-level guidelines** and interoperability recommendations
+- **National and regional DMP practices** identified through pilots
+- **Institutional requirements**, including those of research-performing   and research-supporting organisations
+- **Thematic and domain-specific guidelines** from research communities
+- **Feedback from national and thematic pilots within OSTrails**
+- **Practical implementation experience** from DMP platforms and services
+- **Gaps and ambiguities identified in the DMP Common Standard** when applied in operational settings
+
+These inputs are analysed, consolidated, and progressively incorporated into the application profile. Some of the exemplary efforts are documented in the :doc:`maDMP mappings <mappings/index>`.
+
+Relationship to the DMP Common Standard
+---------------------------------------
+
+The OSTrails Application Profile is a **formal extension** of the :doc:`RDA DMP Common Standard (DCS) for maDMPs <dmp-common-standard>`.
+
+This means that the profile may introduce:
+
+- new entities,
+- additional fields or attributes,
+- more specific constraints on existing elements,
+- clarified usage patterns for machine-actionable exchange.
+
+At the same time, **compatibility is a core design principle**. Every maDMP that conforms to the OSTrails Application Profile is also compliant with the broader and in a sense simpler DMP Common Standard.
+
+This ensures that DMPs expressed using the OSTrails AP remain interoperable with services that only support the core RDA model, while enabling richer interactions where the application profile is implemented.

docs/commons/dmp/dmp-common-standard.rst

@@ -0,0 +1,72 @@
+RDA DMP Common Standard for maDMPs
+==================================
+
+.. page-authors::
+    Tomasz Miksa
+    Marek Suchánek
+
+
+The **RDA DMP Common Standard for machine-actionable Data Management Plans (maDMPs)** defines a minimal, interoperable data model for representing information contained in Data Management Plans in a machine-actionable way.
+
+The standard provides a shared vocabulary and structure for core DMP concepts that are common across domains, funders, and infrastructures. It is designed to enable consistent interpretation and exchange of DMP information between systems, while remaining independent of specific implementations, workflows, or regional policies.
+
+Version and usage
+-----------------
+
+The DMP Commons currently build on **version 1.2** of the RDA DMP Common Standard:
+
+    - **RDA DMP Common Standard**: https://github.com/RDA-DMP-Common/RDA-DMP-Common-Standard/tree/v1.2
+
+This version serves as the **foundational layer** for the DMP Commons and is used as the base model for higher-level specifications: :doc:`OSTrails Application Profile <application-profile>` and then :doc:`API specification <madmp-api-specification>`. All extensions and constraints introduced by the DMP Commons are defined as additions on top of this common core, ensuring compatibility with the RDA standard.
+
+Scope and role within the DMP Commons
+-------------------------------------
+
+Within the DMP Commons, the RDA DMP Common Standard:
+
+- Defines the **minimum set of concepts** needed to describe a DMP in a machine-actionable way
+- Establishes a **shared semantic baseline** across tools and services
+- Enables interoperability without constraining internal data models or system architectures
+
+The standard intentionally avoids domain-specific requirements or policy-driven constraints. Such specializations are addressed at higher layers (e.g. application profiles), allowing the common standard to remain stable and broadly applicable.
+
+.. figure:: dmp-common-standard-diagram.png
+    :alt: RDA DMP Common Standard for maDMPs v1.2
+    :target: https://github.com/RDA-DMP-Common/RDA-DMP-Common-Standard/tree/v1.2
+
+    RDA DMP Common Standard for maDMPs v1.2
+
+Community governance and maintenance
+------------------------------------
+
+The RDA DMP Common Standard is developed and maintained by the community under the Research Data Alliance (RDA). Issues, discussions, and proposals related **directly to the standard itself** are handled within its established community processes.
+
+Relevant resources include:
+
+    - **Specification repository**: https://github.com/RDA-DMP-Common/RDA-DMP-Common-Standard
+    - **Issue tracker and discussions**: https://github.com/RDA-DMP-Common/RDA-DMP-Common-Standard/issues
+    - **RDA Working Group page**: https://www.rd-alliance.org/groups/dmp-common-standards-wg
+
+These channels are the authoritative venues for proposing changes, reporting issues, and discussing the evolution of the standard.
+
+Contribution and future evolution
+----------------------------------
+
+In OSTrails and DMP Commons, we actively **collaborate with and contribute to the evolution of the RDA DMP Common Standard**.
+
+This collaboration is driven by practical experience gained through building the :doc:`OSTrails Application Profile <application-profile>` and also API on top of the standard, as well as by identifying gaps or ambiguities that affect interoperability beyond specific infrastructures or regional contexts.
+
+Proposed improvements are intentionally **not limited to OSTrails, EOSC, or Europe-specific needs**, but aim to strengthen the standard for the broader international community and future versions of the specification.
+
+As the RDA DMP Common Standard evolves, the DMP Commons will track and align with new versions, ensuring continuity while supporting incremental adoption.
+
+References
+----------
+
+.. bibliography::
+    :list: bullet
+    :filter: False
+    :keyprefix: dmp-common-standard-
+    :labelprefix: dmp-common-standard-
+
+    Miksa_RDA_DMP_Common

docs/commons/dmp/dmp-commons.rst

@@ -0,0 +1,49 @@
+DMP Commons
+===========
+
+.. page-authors::
+    Marek Suchánek
+    Jana Martínková
+    Tomasz Miksa
+
+
+The **DMP Commons** provide a shared, reusable, and interoperable foundation for working with **machine-actionable Data Management Plans (maDMPs)** across tools and services to support the adoption of the **DMP Interoperability Framework**. They define how DMP information is structured, constrained, and exchanged, without prescribing how individual systems are internally designed or implemented. DMP Commons are primarily aimed at software developers building services that create or consume machine-actionable DMPs (maDMPs). This includes:
+
+- DMP platform providers,
+- Other services that integrate with these platforms, as outlined in our *Architecture and Pathways*.
+
+In addition, DMP Commons are relevant for data stewards and other stakeholders who need to structure information about Research Data Management (RDM).
+
+The Commons are built as a **layered framework** consisting of a common data model, an OSTrails (i.e. Europe/EOSC) -specific application profile, and a standard API. Together, these layers enable consistent interpretation of DMP content and predictable interactions between services, regardless of their internal architectures. This approach allows platforms to evolve independently while remaining interoperable at the boundaries. In addition, we provide `maDMP mappings <mappings/index>`_ to support the development of application profiles and to align DMP information with external standards and domain models.
+
+.. figure:: dmp-commons.png
+    :alt: DMP Commons Layers
+    :align: center
+    :scale: 60%
+
+    DMP Commons Layers
+
+
+As illustrated above, the DMP Commons consist of three main components:
+
+- :doc:`RDA DMP Common Standard for maDMPs <dmp-common-standard>`: The foundational data model defining core DMP concepts and structures in a machine-actionable way.
+- :doc:`OSTrails Application Profile for maDMPs <application-profile>`: A Europe/EOSC-specific extension of the common standard that introduces additional entities, fields, and constraints to address regional interoperability needs.
+- :doc:`OSTrails maDMP API Specification <madmp-api-specification>`: A standardised interface for programmatically interacting with maDMPs across platforms, built on top of the common standard and compatible with the application profile.
+
+The primary users of the DMP Commons are **software developers, system architects, and service operators** who design or operate DMP platforms and related research data management services. Researchers are not expected to interact with the Commons directly; instead, they benefit indirectly through increased automation, reduced duplication of effort, and better reuse of DMP information across systems.
+
+The DMP Commons are **community-driven and evolutionary** in a sense that they are designed to continuously evolve based on community feedback and emerging needs. They build heavily on work carried out in the Research Data Alliance (RDA), including the RDA DMP Common Standard recommendation, and in turn actively contribute back to those communities. The framework is designed to support gradual adoption, while enabling full interoperability when all components are implemented.
+
+----
+
+For the time being, the Commons consist of the following resources:
+
+.. toctree::
+    :caption: DMP Commons Resources
+    :maxdepth: 1
+    :titlesonly:
+
+    DMP Common Standard for maDMPs <dmp-common-standard>
+    OSTrails Application Profile for maDMPs <application-profile>
+    OSTrails maDMP API Specification <madmp-api-specification>
+    maDMP mappings <mappings/index>