fairdo-org · fdo-secretariat · Sep 15, 2026 · Jul 29, 2026 · Jul 29, 2026 · Jul 29, 2026
diff --git a/.github/workflows/pr-preview-build.yml b/.github/workflows/pr-preview-build.yml
@@ -84,7 +84,7 @@ jobs:
           mkdir -p site
           if [ "${ACTION}" != "closed" ]; then
             # Move built site contents into the artifact staging directory,
-            # excluding git/github metadata that should not be deployed.
+            # excluding git/github metadata that SHOULD not be deployed.
             shopt -s dotglob
             for item in *; do
               case "$item" in

diff --git a/.gitignore b/.gitignore
@@ -44,8 +44,8 @@
 .idea/**/libraries
 
 # Gradle and Maven with auto-import
-# When using Gradle or Maven with auto-import, you should exclude module files,
-# since they will be recreated, and may cause churn.  Uncomment if using
+# When using Gradle or Maven with auto-import, you SHOULD exclude module files,
+# since they will be recreated, and MAY cause churn.  Uncomment if using
 # auto-import.
 # .idea/artifacts
 # .idea/compiler.xml
@@ -539,7 +539,7 @@ $RECYCLE.BIN/
 .AppleDouble
 .LSOverride
 
-# Icon must end with two \r
+# Icon MUST end with two \r
 Icon
 
 # Thumbnails
@@ -560,4 +560,3 @@ Icon
 Network Trash Folder
 Temporary Items
 .apdisk
-
diff --git a/README.md b/README.md
@@ -35,11 +35,11 @@ coherent rendered document.
 
 This specification is developed under the governance of the **FDO Forum**.
 
-- The document may evolve over time
-- Not all sections may be complete at all times
+- The document MAY evolve over time
+- Not all sections MAY be complete at all times
 - Changes are discussed and reviewed through the repository’s issue and pull request process
 
-Unless explicitly stated otherwise, the content in this repository should be considered **work in progress**.
+Unless explicitly stated otherwise, the content in this repository SHOULD be considered **work in progress**.
 
 ## Repository Structure
 
@@ -73,7 +73,7 @@ Typical contributions include:
 Please read the policy on how to contribute:
   https://github.com/fairdo-org/fdo-architecture-spec/blob/main/Contribution-Specification-Development-Policy-v1.0.pdf
 
-Contributions should follow the architectural scope and terminology defined by the FDO Forum.
+Contributions SHOULD follow the architectural scope and terminology defined by the FDO Forum.
 
 ## Governance
 

diff --git a/img/FDO-basic-concept.svg b/img/FDO-basic-concept.svg
diff --git a/index.html b/index.html
@@ -2,7 +2,8 @@
 <html lang="en">
   <head>
     <meta charset="utf-8" />
-    <title>FAIR Digital Objects Architecture Specification DRAFT</title>
+    <meta name="color-scheme" content="light dark">
+    <title>FAIR Digital Objects Architecture Specification</title>
     <script
       src="https://www.w3.org/Tools/respec/respec-w3c"
       class="remove"
@@ -98,11 +99,16 @@
             company: "Senckenberg, SDCT"
           }
         ],
-        github: "https://github.com/fairdo-org/fdo-architecture-spec/",
+        github: {
+          repoURL: "https://github.com/fairdo-org/fdo-architecture-spec",
+          pulls: "https://github.com/fairdo-org/fdo-architecture-spec/pulls",
+          commitHistoryURL: "https://github.com/fairdo-org/fdo-architecture-spec/commits/main/",
+        },
+        canonicalURI: "edDraft",
+        doJSONLD: true,
+        license: "cc-by",
         shortName: "FDO_Architecture_Spec",
         latestVersion: null,
-        edDraftURI: "https://github.com/fairdo-org/fdo-architecture-spec",
-        commitHistoryURL: "https://github.com/fairdo-org/fdo-architecture-spec/commits/main/",
         localBiblio: {
           "FAIR": {
             title: "The FAIR Guiding Principles for scientific data management and stewardship",
@@ -133,21 +139,14 @@
             date: "2023",
             href: "https://zenodo.org/records/7825650"
           },
-          "FDO-Operations": {
-            title: "A Comparative Analysis of Modelling Approaches for the Association of FAIR Digital Object Operations",
-            authors: ["S. Bingert", "J. Böhm", "et al."],
-            publisher: "Data Science Journal",
-            date: "2025",
-            doi: "10.5334/dsj-2025-022"
-          },
           "ECMA262": {
             title: "ECMAScript® 2026 Language Specification",
             authors: ["ECMA International", "TC39"],
             publisher: "ECMA International",
             date: "2026-06-30",
             href: "https://262.ecma-international.org/17.0/index.html#sec-regexp-regular-expression-objects"
           },
-          "FDO-Operations-2025":{
+          "FDO-Operations":{
             title: "A Comparative Analysis of Modeling Approaches for the Association of FAIR Digital Objects Operations",
             authors:[
                     "Nicolas Blumenröhr",
@@ -167,7 +166,14 @@
             authors: ["J. Böhm", "M. Inckmann", "et al."],
             date: "2026",
             href: "https://fairdo-org.github.io/handle_fdo_specification/"
-          }
+          },
+          "RDA-DTR-WG": {
+            title: "RDA Data Type Registries Working Group Output",
+            authors: ["Larry Lannom", "Daan Broder", "Giridhar Manepalli", "Tobias Weigel"],
+            date: "2015-04-30",
+            doi: "10.15497/A5BCD108-ECC4-41BE-91A7-20112FF77458",
+            url: "https://zenodo.org/records/1406127"
+          },
         },
         lint: { "no-unused-dfns": false }
       };
@@ -186,7 +192,7 @@
     <section id="abstract">
       <p>
         This document specifies the architecture of FAIR Digital Objects (FDOs) as a unified,
-        technology-independent framework for representing and managing digital and physical resources
+        technology-independent framework for representing and managing digital and physical <a>resources</a>
         in a machine-actionable manner. FDOs are persistent bundles of information identified by
         globally unique, persistent, and resolvable identifiers (PIDs) that resolve to structured
         FDO Records defined by explicit profiles and registered attributes.
@@ -209,10 +215,9 @@
     <section class="informative" data-include="sections/00_introduction/00-Intro.html"></section>
     <section class="informative" data-include="sections/00_introduction/01-How-To-Read-This-Document.html"></section>
     <section class="informative" data-include="sections/00_introduction/02-High-Level-Overview.html"></section>
-    <section class="informative" data-include="sections/00_introduction/03-Terminology.html"></section>
 
     <section data-dfn-for="building-blocks" class="normative">
-      <h2>FDO Building Blocks</h2>
+      <h2><dfn data-lt="FDO type system">FDO Building Blocks</dfn></h2>
       <section data-include="sections/01_fdo-building-block/01-PID.html" id="pid"></section>
       <section data-include="sections/01_fdo-building-block/02-Granularity.html" id="granularity"></section>
       <section data-include="sections/01_fdo-building-block/03-FDO-Records.html" id="records"></section>
@@ -250,11 +255,14 @@ <h2>Implementation Template</h2>
     </section>
 
     <section id="conformance" data-include="sections/04-Conformance.html"></section>
-    <section id="tof" class="appendix"></section>
-    <section id="index" class="appendix"></section>
+
     <section id="appendix" class="appendix">
       <h2>Appendix</h2>
-      <section data-include="sections/05_appendix/01_AttributeDefs.html" id="appendixAttrDefsUsed"></section>
+      <section id="list-of-tables" class="appendix"></section>
+      <section id="tof" class="appendix"></section>
+      <section id="index" class="appendix"></section>
+      <section class="informative appendix" data-include="sections/05_appendix/01-Terminology.html" id="terminology"></section>
+      <section data-include="sections/05_appendix/02_AttributeDefs.html" id="appendixAttrDefsUsed"></section>
     </section>
   </body>
 </html>
diff --git a/sections/00_introduction/00-Intro.html b/sections/00_introduction/00-Intro.html
@@ -3,24 +3,24 @@ <h3 id="intro">Introduction</h3>
     The concept of FAIR Digital Objects (<a>FDOs</a>) emerged from discussions in a) the Research Data Alliance where Working
     and Interest Groups discussed – drawing upon a seminal paper by Kahn and Wilensky [[Kahn-Wilensky]] – worked on
     all aspects around Digital Objects as replacement for the file-oriented approach which is still being used and
-    creating so many inefficiencies and b) the FAIR community where machine actionability is a key issue [[Jacobsen2020]].
+    creating so many inefficiencies and b) the FAIR community where <a>machine actionability</a> is a key issue [[Jacobsen2020]].
 </p>
 <p>
-    A <dfn data-lt="FDO|FDOs">FAIR Digital Object (FDO)</dfn> is a <strong>harmonized and persistent bundle</strong>
-    of information that represents (i.e., identifies, encapsulates, and describes) a (digital or physical) resource
+    An <dfn data-abbr="FDO">FAIR Digital Object</dfn> (<a>FDO</a>) is a <strong>harmonized and persistent bundle</strong>
+    of information that represents (i.e., identifies, encapsulates, and describes) a (digital or physical) <a>resource</a>
     which can be of any type (data, metadata, semantic assertions, configurations, AI models, etc.).
     <a>FDOs</a> implement the <dfn>FAIR principles</dfn> [[FAIR]] and comply by-default with these principles:
 </p>
 <ul>
     <li>
-        Each resource (which is represented as an <a>FDO</a>) is identified by a globally unique, resolvable, and persistent
+        Each <a>resource</a> (which is represented as an <a>FDO</a>) is identified by a globally unique, resolvable, and persistent
         identifier (a <a>PID</a>).
     </li>
     <li>
-        A <a>PID</a> resolves into a structured, machine-actionable metadata record that describes the identified resource.
+        A <a>PID</a> resolves into a structured, machine-actionable metadata record that describes the identified <a>resource</a>.
     </li>
     <li>
-        The record contains external reference(s) to the data <a>bit-sequence</a> of the resource and additional metadata
+        The record contains external reference(s) to the data <a>bit-sequence</a> of the <a>resource</a> and additional metadata
         <a>bit-sequence(s)</a>, if appropriate.
     </li>
     <li>
@@ -33,9 +33,9 @@ <h3 id="intro">Introduction</h3>
     ecosystem of data, which includes well-documented AI models and their training corpus.
     Societies and business will increasingly depend on proper AI models, requesting a reliable and trustworthy data basis.
     <a>FDOs</a> are passive units of information that posess the ability to be associated with executable operations.
-    This does not only enable encapsulation but can also be used to support autonomously acting agents.
+    This does not only enable <a>encapsulation</a> but can also be used to support autonomously acting agents.
     Due to these properties, <a>FDOs</a> are a common harmonization layer for the many dataspaces that have been
     developed and which currently are emerging in science and industry.
-    <a>FDO</a> inform the three layers of dataspaces: creating trust amongst partners, comparing rights on resources
+    <a>FDO</a> inform the three layers of dataspaces: creating trust amongst partners, comparing rights on <a>resources</a>
     with user claims, and finally exchanging the data.
-</p>
+</p>
diff --git a/sections/00_introduction/02-High-Level-Overview.html b/sections/00_introduction/02-High-Level-Overview.html
@@ -2,8 +2,7 @@ <h3>
     Overview
 </h3>
 <p>
-    The vision of the
-    <a>FDO</a> concept is to enable machine actionability and facilitate highly automated processing of data.
+    The vision of the <a>FDO</a> concept is to enable <a>machine actionability</a> and facilitate highly automated processing of data.
     If an <a>FDO</a> client finds a <a>PID</a> that identifies an
     <a>FDO</a>, it is able to automatically interpret and process the
     <a>FDO</a>, regardless of the technology used to implement it.
@@ -18,7 +17,7 @@ <h3>
     <a>FDOs</a> in themselves to prevent unwanted dependencies from specific technologies and enable a common exchange format between implementations.
     In <a href="#generic-fdo-processing">Section 6</a> we describe how a client finds, accesses, and interprets
     <a>FDOs</a> to get to the data represented by it.
-    We expect that implementations of <a>FDOs</a> will vary and may not realize all of the building blocks.
+    We expect that implementations of <a>FDOs</a> will vary and MAY not realize all the building blocks.
     Thus, we specify in <a
         href="#implementation-profile">Section 7</a> how implementations adopt this document to facilitate interoperability between implementations.
 </p>
@@ -30,33 +29,33 @@ <h3>
     <figcaption>
         This diagram indicates schematically the basic building blocks of an <a>FDO</a>.
         The <a>attribute definition</a> (left) and
-        the profile (right) are also
+        the <a>profile</a> (right) are also
         <a>FDOs</a> where the records consist of tuples, which is not shown in this diagram for
         readability.
     </figcaption>
 </figure>
 
 <ul>
     <li>
-        <strong>Resource</strong>: Each
+        <strong><a>resource</a></strong>: Each
         <a>FDO</a> is a<strong>standardised and persistent bundle</strong> of information that
-        represents (i.e., identifies, encapsulates, and describes) a resource.
-        The resource could be digital, in which case the
-        resource would usually be a data <a>bit-sequence</a>.
-        But it is also possible that this resource is physical, in which
+        represents (i.e., identifies, encapsulates, and describes) a <a>resource</a>.
+        The <a>resource</a> could be digital, in which case the
+        <a>resource</a> would usually be a data <a>bit-sequence</a>.
+        But it is also possible that this <a>resource</a> is physical, in which
         case there is no data <a>bit-sequence</a> attached to the <a>FDO</a>.
-        The resource is the heart of the <a>FDO</a> and all other
-        components are there to make the resource and its metadata machine actionable.
+        The <a>resource</a> is the heart of the <a>FDO</a> and all other
+        components are there to make the <a>resource</a> and its metadata machine actionable.
     </li>
     <li>
         <strong>Persistent identifier (PID)</strong>: Each <a>FDO</a> is identified by a globally unique and persistent
         identifier.
-        A <a>PID system</a> must resolve the <a>PID</a> to an <a>FDO record</a>.
+        A <a>PID system</a> MUST resolve the <a>PID</a> to an <a>FDO record</a>.
     </li>
     <li>
         <strong><a>FDO Record</a></strong>: The
         <a>FDO record</a> is a predictable and machine actionable information structure that
-        contains <a>attributes</a> of the resource which the <a>FDO</a> represents.
+        contains <a>attributes</a> of the <a>resource</a> which the <a>FDO</a> represents.
         The <a>FDO record</a> is that piece of information a <a>FDO</a>
         client first encounters after <a>PID</a> resolution.
     </li>
@@ -74,17 +73,17 @@ <h3>
                 filled into the metadata field).
             </li>
         </ol>
-        <a>FDO <a>attributes</a></a> are properties of the resource the <a>FDO</a> represents, hence they are metadata.
+        <a>FDO <a>attributes</a></a> are properties of the <a>resource</a> the <a>FDO</a> represents, hence they are metadata.
         We distinguish three types of <a>FDO <a>attributes</a></a>/<a>attribute definitions</a>:
         <ol>
             <li>
                 This document specifies <strong>mandatory
-                <a>FDO <a>attributes</a></a></strong> that must be used to ensure predictability and machine actionability of any
+                <a>FDO <a>attributes</a></a></strong> that MUST be used to ensure predictability and <a>machine actionability</a> of any
                 <a>FDO</a>.:
                 <ul>
                     <li><a>FDO type</a> <em><a>0.FDO/Type</a></em></li>
-                    <li><a>FDO profile</a> <em>(0. <a>FDO</a>/Profile)</em></li>
-                    <li><a>FDO data</a> <em>(0. <a>FDO</a>/Data)</em></li>
+                    <li><a>FDO profile</a> <em><a>0.FDO/Profile</a></em></li>
+                    <li>FDO data <em><a>0.FDO/Data</a></em></li>
                 </ul>
             </li>
             <li>
@@ -112,7 +111,7 @@ <h3>
                 a semantic description of the <a>attribute</a> (e.g., “Person who wrote the document”),
             </li>
             <li>
-                a cardinality (e.g., this <a>attribute</a> can be used at most one time in an <a>FDO record</a>), and
+                a <a>cardinality</a>  (e.g., this <a>attribute</a> can be used at most one time in an <a>FDO record</a>), and
             </li>
             <li>
                 syntactic rules for the value that instantiates this
@@ -130,10 +129,9 @@ <h3>
     </li>
     <li>
         <strong><a>FDO Profile</a></strong>: The <a>FDO profile</a> specifies the set of
-        <a>FDO <a>Attribute Definitions</a></a> that must or can
-        (depending on the cardinality of the <a>attribute definitions</a>) be instantiated to create
-        <a>FDO records</a> by a certain
-        repository, community, or implementation.
+        <a>FDO <a>Attribute Definitions</a></a> that MUST or can
+        (depending on the <a>cardinality</a> of the <a>attribute definitions</a>) be instantiated to create
+        <a>FDO records</a> by a certain repository, community, or implementation.
         The <a>FDO profile</a> makes the content of an <a>FDO record</a> predictable for an
         <a>FDO</a> client: Each <a>FDO record</a> needs to have a reference to the <a>FDO profile</a> it complies with.
         By inspecting the
@@ -143,15 +141,12 @@ <h3>
     <li>
         <strong><a>FDO Type</a></strong>: Each <a>FDO</a> has to specify an
         <a>FDO type</a> which essentially provides any client with a hint
-        how the resource can be processed.
+        how the <a>resource</a> can be processed.
     </li>
     <li>
-        <strong>Registries</strong>: <a>Attribute Definitions</a> and profiles must be stored in open registries.
+        <strong>Registries</strong>: <a>Attribute Definitions</a> and <a>profiles</a> MUST be stored in <dfn data-lt="DTR|data type registry">open registries</dfn>.
         This gives the possibility of a reverse lookup.
-        The mandatory and optional <a>attribute definitions</a> are stored in registries maintained by the
-        <a>FDO</a> Forum.
+        The mandatory and optional <a>attribute definitions</a> are stored in registries maintained by the <a>FDO Forum</a>.
         Communities of practice maintain their own community-defined <a>attribute definitions</a> in open registries.
     </li>
 </ul>
-
-