A Comparative Analysis of Modeling Approaches for the Association of FAIR Digital Objects Operations

2.1 Foundations of FDOs and the Core Model

FDOs are persistent entities that bundle information for FAIR processing of a bit sequence including different kinds of metadata. They are referenced by a Persistent Identifier (PID), fulfill FAIR criteria in their core mechanisms, and can be protected against misuse in various dimensions (Smedt, Koureas, and Wittenburg, 2020). In the FDO core model given by (Blumenröhr et al., 2025), each FDO represents a basic structure that allows for different configurations, i.e. configuration types (Lannom, Peters-von Gehlen, et al., 2022), and has the following characteristics:

• A Handle PID will be resolved into an FDO information record that contains the Kernel Information.

• The Kernel Information describes the FDO core metadata attributes, such as its data type, location and additional metadata references.

• The Kernel Information is structured as a set of attributes expressed as a set of key-value pairs, aggregated by a Kernel Information Profile (Weigel et al., 2019) that the information record must conform to.

• For compatibility reasons, only a minimal set of attributes are specified in the Kernel Information Profile as also proposed by the FDO Forum¹ and the Research Data Alliance².

• Each attribute included in the profile must be defined and registered in a public registry according to the specification of PID-Information Types (PITs) (Schwardmann, 2017), making it machine-interpretable.

• It is actionable through a set of operations that are associated with the Kernel Information via a typing mechanism.

This minimal definition of the FDOs follows the original idea of the Internet, which defines a basic package structure for information transfer and allows making use of a communication protocol for FDOs, the Digital Object Interface Protocol (DOIP) (DONA Foundation, 2018). FDOs can represent bit sequences with different kinds of content, such as data, metadata, configurations, semantic assertions, software, etc. As illustrated in Figure 1, due to their conceptual core model, FDOs have the potential to be used as a basic interoperability layer to connect different types of repositories and data spaces (Curry, Scerri, and Tuikka, 2022). For further technical details on FDOs, see the FDO Overview (Anders et al., 2023a), and the FDO Requirement Specifications (Anders et al., 2023b). Note that the term profile is used interchangeably with the term Kernel Information Profile in the subsequent sections.

Figure 1

2.2 Problem Description

Several works on FDO implementations have described the theoretical applicability of FDO operations, e.g. (Blanchi, Gebre, and Wittenburg, 2022; Blumenröhr et al., 2025; Islam, 2023; Lannom, Koureas, and Hardisty, 2020) or have even implemented specialized systems that enable the execution of operations in their FDO ecosystem, e.g. (Blumenröhr and Aversa, 2023; Islam et al., 2023). However, to the best of our knowledge, a set of generic mechanisms for associating these operations with FDOs via a set of rules, i.e., a type system, in compliance with the description of the original concept, has not been worked out yet. This makes it hard to assess and to reproduce these use-case specific operation frameworks.

The authors of this work have developed typing mechanisms to associate FDOs and operations within their organizations, which were extensively discussed in the frame of the FDO Forum. At this point, there exist some reference implementations for these mechanisms as described in the following sections, but no detailed definition of their data models and how these compare to each other. We therefore see this paper as a step forward in assessing these association models and providing a baseline for implementing (inter-)operable FDO ecosystems.

3.1 Typing Mechanisms

The problem with the terms ‘type’ and ‘typing’ is that they are generic, and often have different definitions across disciplines and technologies. This work does not aim to provide an exhaustive description of these terms but it does require a more concrete description in the context of FDOs. It can be said at this point that many of the terms employed relate to ideas from the field of Object-oriented Programming (OOP), of which relations to other principles such as abstraction and encapsulation have already been described by the work of (Blumenröhr et al., 2025; Schultes and Wittenburg, 2019). The next step is to infer mechanisms for associating operations on the basis of abstraction and encapsulation provided by FDOs. It is important to note that we consider the analogy between OOP and FDOs only on an abstract, conceptual level, whilst the implementation details of FDOs are a different aspect. The following terms also found in OOP are therefore defined in the context of FDOs as the following:

• Abstraction and Encapsulation: FDOs pack data and metadata into a single unit by definition, encapsulating internal details. The interface to the FDO is given by attributes that describe possible interactions. The set of attributes is given by its profile. The profile itself is therefore a class. It is an abstraction of all FDOs that satisfy the profile requirements.

• FDO Type: a characterization of an FDO through the set of its typed attributes (e.g. using PITs) that are bundled in a profile and are subject to syntactic and semantic specifications.

• Type System: inspired by the work of (Pierce, 2002), we define this as a set of rules for validating how FDOs are typed and associated with a set of operations by one or more typing mechanisms.

• Typing Mechanism: the exact procedure to determine if and how an operation is associated with a particular FDO via its kernel information elements, i.e., key-value pairs of typed attributes and profile.

The typing mechanisms to associate operations with FDOs are described below. The details and relations of these mechanisms to principles known from OOP are illustrated in Figure 2.

Figure 2

With respect to the association approach, there are two obvious possibilities. The first is to extend the FDO interfaces and to include operations as attributes in the FDO record by changing the profile (operation association to FDO). The other is to leave the interfaces of FDOs unchanged and to describe requirements for the interfaces of the operation representation (FDO association to operation). This can be represented as relations between operations and types (i.e., typed attributed using PITs) in a dedicated type system.

Even though object association to operations is also possible within OOP, operation association to objects of classes is encouraged there as part of the encapsulation. Operations behind Representational State Transfer (REST) services are also usually associated to the objects behind their interfaces. Object association to operation is more commonly used in the context of media types, in which the applicability of an operation is decided by the type of object. The type encapsulates the internal complexity of both the object and the operation. This results in three core mechanisms of typing that we detail in the following.

3.2 Implementation Examples

The examples described in this subsection originate from different projects and organizations the authors are involved in, using different types of data, technologies and service architectures. We concentrate here on the association models and the essential workflow, also considering information exchange between FDO services and the client side. Apart from a minimal necessary description, we do not therefore provide technical details of each implementation and the service components that are used in these projects. We also do not further explain the details of how these operations are ultimately applied to the contents of the FDOs they are associated with. For this, we refer to the references provided in each section. We also want to point out that different complexity levels of these implementations are not necessarily related to the complexity of the individual association model. These will be evaluated in section 4. However, according to the FDO core model, each FDO in these examples is registered at—and is thus resolvable via—the Handle Registry, has a typed information record, and complies to one of the known FDO configuration types.

3.2.1 Record Typing in Interactive Computing Environments

This example considers a simple FDO information record that represents a catalog containing links to various climate model simulations described by domain-specific metadata key-value pairs. FDO-related information is statically implemented in the record. Hence, Figure 3 lays out how the implementation of an association mechanism for operations via record typing works in principle. The diagram shows a workflow illustrating the interaction between an FDO and a client using a computational environment, i.e., a Jupyter Notebook, to retrieve predefined operations (here labeled as operation 1 for opening the catalog and operation 2 for reading the catalog) that are bundled in the information record among other metadata required to execute the operation, such as the content type, the reference to the bit sequence, or other metadata.

Figure 3

Depending on the FDO service, a client can either request the list of associated operations or directly retrieve them from the FDO’s information record. In this example, these operations are a specification of code that is executable on the client side.

From a technical implementation perspective, the information record itself contains a set of operations that are in principle relevant to any object conforming to the content-type it represents. Note that these FDOs cannot dynamically change their operations or substitute them at runtime. The operations are fixed and cannot vary based on different FDO subtypes. The Jupyter Notebook can be found at (Kulüke, 2025).

3.2.2 Profile Typing with Multiple Registries

Within the FDO One project,³ the focus is on providing basic operations for FDOs to build up a functional FDO ecosystem, e.g. CRUD operations (create and delete an FDO, get or update the (meta)data of an FDO) or copying an FDO and moving a distributed FDO from one storage location (data service) to another. For these types of operations, domain-specific attributes and content-types of bit sequences are irrelevant. Rather, the structure of the FDO itself is of importance, for example, whether it represents zero, one, or multiple (meta)data bit sequences and how those are stored. This information is determined by the FDO profile. Hence, the profile typing mechanism is used to associate those operations to FDO profiles. In particular, each FDO profile contains not only a list of mandatory and optional attributes which must be present in an FDO information record, but also a list of operations that can be applied to any FDO complying with this specific FDO profile. Profiles are registered in the profile registry, which is based on a Data Type Registry.⁴

As described in Figure 4, to find operations associated with an FDO, a client may retrieve the profile (either directly or through a software component) and receive a list of PIDs identifying operations that are associated to this FDO. The operations, in turn, are registered in the operation registry together with all necessary execution information⁵. For further reading and technical details of the FDO One testbed implementation, we refer to (fairdo, 2025).

Figure 4

3.2.3 Attribute Typing with Operation FDOs

To realize the attribute typing mechanism, an operation must be represented in a way that allows it to be related to the attributes in the targeted FDO’s information record that represents research data (i.e., labeled here as target FDO). This could be easily provided by representing the operation itself as an FDO as well, which we label here as operation FDO. This follows the concept’s generic approach that each type of bit sequence can be represented as an FDO. The specific implementation of the operation is thus described in this operation FDO information record, detailing its implementation, possible execution mechanism, and the type-association requirements in the form of a typed attribute’s key-value pair.

An example of this modeling approach is illustrated in Figure 5, where a target FDO and two operation FDOs are shown. Each operation FDO represents the implementation of the underlying operation that is either applied to the bit sequence, i.e., operation 1 for schema validation, or to the kernel metadata, i.e., operation 2 for license evaluation. The information record of the operation FDO contains at least one key-value pair where the key expresses the requiredInput and the value references the PIT that indicates applicability of the operation to all FDOs that contain a typed attribute of this PIT in their information record. Depending on these requirements, only the corresponding key of the referenced PIT, or the key and a specific value in the form of a tuple (cf. operation 1) may be specified. This construction enables a dynamic typing mechanism, in which operations are ‘aware’ of the traits an FDO must have for their applicability to discover them at runtime. With respect to the infrastructure, additional services that know how to interpret and validate these type-based relations and subsequently execute the implemented operation, which is not detailed in this work, will be required. For further reading and technical details of this example, we refer to (Blumenröhr, 2025).

Figure 5

4.1 Modeling the Association Mechanisms as Graphs

To compare the association models not only qualitatively but also quantitatively, the three association approaches need to be put into a mathematical framework. For a distinct representation of all involved components, we model the association approaches first as Entity-Relationship (ER) Models, based on the work of (Chen, 1976), and then as directed graphs. This seems natural because associations between FDOs and operations are all based on references pointing from one entity to another entity. Those entities might be FDOs, operations, profiles (in the case of profile typing), or attribute definitions according to PITs (in the case of attribute typing). Instances of attribute definitions, i.e., typed attributes, are represented using the Attribute class in the ER model. The components of the ER model are then converted into mathematical graph components such that entities and their attributes (of the Attribute class) are represented as vertices, while relationships are represented as edges. Relationships such as ‘FDO f contains attribute a in its information record’ and ‘attribute a points to operation o’ directly translate into edges, while the entities named above, including instances of attribute definitions, translate into vertices in a graph. In this way, the ER model semantically specifies the components and structure of each association model generically, whilst the corresponding graph details the actual complexity to assess the number of elementary operations. This addresses especially the direct relationships between attribute instances and other components via edges, which can only be modeled implicitly in the ER diagram. This is further detailed in Definition 2 and visualized by Figure 6.

Figure 6

For the rest of this section, we index our association models with $i\in \{1,2,3\}$, such that $i=1$ refers to record typing, $i=2$ to profile typing, and $i=3$ to attribute typing. In the following, we examine each association model separately under the assumption that the whole FDO ecosystem purely relies on a single association approach.

Definition 1 (Components). Let F be the set of all FDOs representing data, O the set of all operations, P the set of all FDO profiles, and $A_i^{\mathit{\text{def}}}$ the set of all attribute definitions (referring to PID-Information Types), in the whole FDO ecosystem. Attribute definitions are instantiated by typed attributes, from now on denoted only as attributes, (e.g., in FDO, operation, or profile information records) which are given by the set A_i. We denote the numbers of those quantities by $|F|,$ $|O|$, $|P|$, $|A_i^{\mathit{\text{def}}}|$ and $|A_i|$, respectively. The set $C_i=F\cup O\cup P\cup A_i^{\mathit{\text{def}}}$ contains all components of the i-th association model.

Attribute definitions determine a key for an attribute together with a set of restrictions on the value of the attribute. Each attribute $a=(a_1,a_2)\in A_i$ is represented by a tuple that consists of a key a₁ and a value a₂. Two attributes $a=(a_1,a_2)$, $b=(b_1,b_2)\in A_i$ are considered to be the same element (i.e., $a=b$) if and only if they have the same key-value-pair (i.e., $a_1=b_1$ and $a_2=b_2$) and they are part of the same information record.

All components of the FDO ecosystem are uniquely identified by PIDs. Some components, such as the set of profiles and the set of attribute definitions or attributes, depend on the examined association approach. For example, attribute definitions might have different required keys and restrictions on the values depending on the model. In addition, the content of the profiles might differ according to the implementation and the chosen model. Hence, the set of attributes and the set of profiles are indexed by $i\in \{1,2,3\}$. The FDOs and operations are considered to be the same sets in all models (strictly speaking, we assume that there are bijective mappings ${\mathcal{M}}_{\mathit{\text{ij}}}:F_i\to F_j$ and ${\mathcal{M}}_{\mathit{\text{ij}}}^{’}:O_i\to O_j$ between FDOs from different models and operations from different models, for $i\ne j$).

Definition 2 (Entity Relationship and Graph Models). We define a simple ER and graph model for the three association approaches. The ER model is the basis specifying the elements of the set $C_i$ as entities and their relationships, and the elements of the set $A_i$ as attributes of these entities. Furthermore, for $i\in \{1,2,3\}$, we denote $G_i=(V_i,E_i)$ as the graph G_i, which consists of vertices $v_i\in V_i$ that are connected by edges $e_i=\{x_i,y_i\}\in E_i$ with $x_i,y_i\in V_i$.

• $i=1$: For record typing, each FDO is directly associated with an operation via an attribute within the information record. Hence,

  $V_1=F\cup A_1\cup O,$
  $E_1=\{\{f,a\}:\text{FDO}f\in F\text{has the attribute}a\in A_1\}$
  $\cup \{\{a,o\}:\text{attribute}a\in A_1\text{references operation}o\in O\}.$

• $i=2$: In terms of profile typing, each FDO references a profile via an attribute in the information record. In turn, an attribute in the profile information record references an FDO operation. Therefore,

  $V_2=F\cup A_2\cup P\cup O,$
  $\begin{array}{cc}\hfill E_2=& \{\{f,a\}:\text{FDO}f\in F\text{has the attribute}a\in A_2\}\hfill \\ & \cup \{\{a,p\}:\text{attribute}a\in A_2\text{references profile}p\in P\}\hfill \\ & \cup \{\{p,a\}:\text{profile}p\in P\text{has the attribute}a\in A_2\}\hfill \\ & \cup \{\{a,o\}:\text{attribute}a\in A_2\text{references operation}o\in O\}.\hfill \end{array}$

• $i=3$: For attribute typing, each operation FDO implicitly references a set of attributes within an FDO information record via their attribute definition and using attributes in the operation FDO. Hence,

  $V_3=F\cup A_3\cup A_3^{\mathit{\text{def}}}\cup O,$
  $\begin{array}{cc}\hfill E_3=& \{\{o,a\}:\text{operation}o\in O\text{has the attribute}a\in A_3\}\hfill \\ & \cup \{\{a,a^{\mathit{\text{def}}}\}:\text{attribute}a\in A_3\text{references attribute}{a}^{\mathit{\text{def}}}\in A_3^{\mathit{\text{def}}}\}\hfill \\ & \cup \{\{a^{’},a^{\mathit{\text{def}}}\}:\text{attribute}{a}^{’}\in A_3\text{references attribute}{a}^{\mathit{\text{def}}}\in A_3^{\mathit{\text{def}}}\}\hfill \\ & \cup \{\{a^{’},f\}:\text{attribute}{a}^{’}\in A_3\text{is contained in FDO}f\in F\}.\hfill \end{array}$

References point from the originating entity to the referenced entity. Note that references from attributes to attribute definitions in $i=3$ arise from the instantiation itself. Consequently, the edges $\{x,y\}\in E_i$ are naturally ordered and may be modeled as directed edges (see Figures 6d-f where references are explicitly displayed as directed edges). However, for any directed edge from $x\in V_i$ to $y\in V_i$, there will never be another directed edge from y to x due to model definition. Hence, there is no need to differentiate between the orientation of edges, so we will work with simple graphs and adopt the notation as in Definition 2.

Figure 6 visualizes Definition 2. The ER models (labels a, b, c) constitute the generic constellation of the different typing mechanism models. The three graphs (labels d, e, f) derived from these ER models, respectively, illustrate an exemplary excerpt of a potential FDO ecosystem. They all contain the same FDOs $f_1,\mathrm{\dots },f_4$, the same operations $o_1,\mathrm{\dots },o_5$ and represent the same set of associations: f₁ is associated with $o_1,o_2$ and o₃, while f₂ and f₃ are both associated with o₃, and f₄ is associated with o₅.

For record typing, each FDO might have several attributes for operation association, which contain the same key (i.e., $a_1=b_1=c_1=d_1=e_1=f_1$). The attributes directly reference an operation via their value. In this example, attributes c, d, and e all have the same value (i.e., $c_2=d_2=e_2$) because they refer to the same operation. Each path connecting an FDO on the left side with an operation on the right side represents one FDO-operation-association.

In terms of profile typing, each FDO has exactly one attribute containing the profile reference. Those attributes have the same keys (i.e., $a_1=b_1=c_1=d_1$). If two FDOs have the same profile, their attributes point to the same profile in the graph (i.e., $b_2=c_2$). Each profile contains exactly one attribute ($e_1=f_1=g_1$) to specify a list of operations as its value. Similarly to record typing, each path from left to right represents one FDO-operation-association.

For attribute typing, each target FDO may contain multiple attributes. Similarly, each operation FDO may contain multiple attributes, with keys being all tantamount (i.e., $h_1=i_1=j_1=k_1=l_1=m_1=n_1$). The attributes in the operation FDO information record reference attribute definitions that are instantiated by attributes in the target FDO information record (i.e., in this example, we have $h_2=a_1$, $i_2=b_1$, $j_2=d_1$, and so on). Note that this model is a simplification of attribute typing because we just consider the case that attributes in the operation record match with attributes in the FDO information record if the attribute in the FDO information record is present (i.e., has the desired key). We do not consider possible restrictions on the allowed values of attributes in the FDO information record and the resulting impact on granularity.

4.2 Evaluation of Quality Indicators and Metrics

We examine quantitative quality indicators (simplicity, efficiency, flexibility) and qualitative aspects (granularity, required client knowledge and versatility). For the quantitative quality indicators, we define simple mathematical measures that are separately evaluated for each model under the assumption that the whole FDO ecosystem relies purely on a single association approach.

Throughout this work, we use big $\mathcal{O}$ notation to assess computational complexity of the conceptual models. Note that we generally make no assumptions about the data structure used in an implementation in which the information concerning the assessments would be stored.

4.3 Comparison of Measures

We now compare the measures to evaluate the strengths and weaknesses of the different association models, starting with the quantitative measures. The overview of all measures is provided in Table 1.

• Simplicity: Both the number of components and the number of attributes that are part of the association mechanism are measures for the simplicity of the model. If few attributes are involved, the information records (of FDOs, profiles, and operations) can be kept comparatively short. If additionally few components are involved, the models are easier to understand for potential users. Regarding components, we have ${\mathcal{C}}_1<{\mathcal{C}}_2$ and ${\mathcal{C}}_1\le {\mathcal{C}}_3$, while for ${\mathcal{C}}_2$ and ${\mathcal{C}}_3$ the following cases are possible:

  ${\mathcal{C}}_2\{\begin{array}{cc}<{\mathcal{C}}_3\hfill & \text{if}|P^{’}|+2<|A_3^{\mathit{\text{def}}}|\hfill \\ ={\mathcal{C}}_3\hfill & \text{if}|P^{’}|+2=|A_3^{\mathit{\text{def}}}|\hfill \\ >{\mathcal{C}}_3\hfill & \text{if}|P^{’}|+2>|A_3^{\mathit{\text{def}}}|\hfill \end{array}$

  In addition, there does not appear to be any general order of ${\mathcal{A}}_1,{\mathcal{A}}_2$ and ${\mathcal{A}}_3$, for which we get the following estimates:

  ${\mathcal{A}}_1={\displaystyle \sum _{f\in F_{O^{’}}}}|O_f|\le {\displaystyle \sum _{f\in F_{O^{’}}}}|O_{F^{’}}|=|F_{O^{’}}||O_{F^{’}}|$
  ${\mathcal{A}}_2=|F_{O^{’}}|+|P_{F^{’}{O}^{’}}|\stackrel{|F_{O^{’}}|\ge 1}{=}|F_{O^{’}}|\left(1+{\displaystyle \frac{|P_{F^{’}{O}^{’}}|}{|F_{O^{’}}|}}\right)\{\begin{array}{cc}<2|F_{O^{’}}|\hfill & \text{if}|P_{F^{’}{O}^{’}}|<|F_{O^{’}}|\hfill \\ \ge 2|F_{O^{’}}|\hfill & \text{if}|P_{F^{’}{O}^{’}}|\ge |F_{O^{’}}|\hfill \end{array}$
  ${\mathcal{A}}_3={\displaystyle \sum _{j=1}^{|F_{O^{’}}|}}{b}_j+{\displaystyle \sum _{j=1}^{|O_{F^{’}}|}}{d}_j\le |F_{O^{’}}||A_F|+|O_{F^{’}}||A_O|\stackrel{|F_{O^{’}}|=|O_{F^{’}}|}{=}|F_{O^{’}}|\left(|A_F|+|A_O|\right)$

  With that, we get ${\mathcal{A}}_2\le {\mathcal{A}}_1$ if $|O_{F^{’}}|\ge 2$, which should be the most common case and assumes that the number of profiles is relatively small compared to the number of FDOs. We also get ${\mathcal{A}}_1<{\mathcal{A}}_2$ if $|O_{F^{’}}|<2$, which implies $|O_{F^{’}}|=1$ (since $|O_{F^{’}}|>0$). This means that each FDO is associated to exactly one operation.

  From ${\mathcal{A}}_1<{\mathcal{A}}_3$, we get $|O_{F^{’}}|<|A_F|+|A_O|$, which means that there are more attributes associated with FDOs and operations than there are operations associated to FDOs. Additionally, given $|F_{O^{’}}|\le |P_{F^{’}{O}^{’}}|$ and $|A_F|+|A_O|=2$, we have ${\mathcal{A}}_3\le |F_{O^{’}}|(|A_F|+|A_O|)=$$2|F_{O^{’}}|\le {\mathcal{A}}_2$. This is the case when each operation relies on few attributes for association.

• Efficiency: All measures ${\mathcal{Q}}_i$, ${\mathcal{R}}_i$ and ${\mathcal{S}}_i$ quantify the effort for a client to find certain FDO-operation-associations within the FDO ecosystem. To compare those measures, we note that all upper bounds are sharp upper bounds.

  ${\mathcal{Q}}_i$ quantifies the effort to decide whether a certain FDO is associated to an operation. This is obviously smallest for record typing. For ${\mathcal{Q}}_2$ and ${\mathcal{Q}}_3$, the following cases are possible:

  ${\mathcal{Q}}_2\{\begin{array}{cc}\lesssim {\mathcal{Q}}_3\hfill & \text{few operations are associated with}f\text{’s profile for}i=2\hfill \\ \gtrsim {\mathcal{Q}}_3\hfill & \text{otherwise}\hfill \end{array}$

  Considering ${\mathcal{R}}_i$, it is obvious that ${\mathcal{R}}_1$ is smallest. For the other two association models, the following two cases are possible:

  ${\mathcal{R}}_2\{\begin{array}{cc}\lesssim {\mathcal{R}}_3\hfill & \text{if (very) few operations are associated with}F\hfill \\ \gtrsim {\mathcal{R}}_3\hfill & \text{otherwise}\hfill \end{array}$

  For example, ${\mathcal{R}}_2\lesssim {\mathcal{R}}_3$ occurs when all $f\in F$ have the same profile. For ${\mathcal{S}}_i$, we observe that ${\mathcal{S}}_1$ is smallest, while ${\mathcal{S}}_2$ also scales with the number of operations related to the given profile and ${\mathcal{S}}_3$ scales with the number of attributes in all operations, which is considerably larger.

  Overall, this shows that record typing is the best approach in terms of efficiency. Profile typing and attribute typing are less efficient in terms of measures ${\mathcal{Q}}_i$ and ${\mathcal{R}}_i$. However, the measure ${\mathcal{S}}_3$ reveals the high costs of attribute typing in comparison to the other models, because one has to iterate over all attributes of all operations in the FDO ecosystem to find all operations associated to one FDO.

• Flexibility: Assuming that the number of FDOs associated to the new operation is much larger than the number of profiles (for $i=2$) associated to this operation, it trivially follows that ${\mathcal{T}}_1\gtrsim {\mathcal{T}}_2>{\mathcal{T}}_3=0$. For ${\mathcal{U}}_i$, obviously ${\mathcal{U}}_1>{\mathcal{U}}_2={\mathcal{U}}_3=0$. Hence, in terms of required updates, attribute typing is most efficient, followed by profile typing. In comparison, record typing is relatively inefficient.

Finally, we will comment on qualitative aspects, that is, granularity and client knowledge, as well as versatility.

• Granularity and client knowledge: For record typing, each FDO can be associated with any operation as desired by the client. This is the most granular approach, as any combination of FDOs and operations is possible. However, for each newly defined FDO, the client who has introduced the FDO information record has to think of which operations to include into the information record. This requires both domain knowledge regarding the content information in the FDO, and knowledge about the association mechanism. The price for higher granularity is therefore that for each new FDO a careful individual inspection might be required to make an informed decision on operation association.

  Attribute typing has a slightly smaller granularity as not every FDO can be seamlessly associated to any operation. In turn, the association mechanism works out automatically, which means that clients just need to include all information they have available into the information record, without deciding for specific operations or attributes. However, in case a client has a specific operation in mind that was not automatically associated to the FDO but which one wants to be associated, one still needs to figure out which additional attributes to include into the FDO information record.

  Profile typing is the least granular approach. As each operation is associated to a whole class of FDOs, there is a need for many different profiles to be made available to the client to reach a granularity that is comparable with the other models. The advantage of profile typing is that the client just has to make an informed choice as to which profile to use, and then will be instructed which attributes are required in the information record due to the profile definition. Hence, one does not have to think at all about associating their FDO to any operations.

• Versatility: In contrast to its high granularity, the overall versatility of record typing is considered to be the lowest, as each FDO-operation association must be explicitly declared to increase the possible processing options for an FDO.

  Profile typing has much greater versatility compared to record typing because a profile is typically reused several times to create a set of FDOs, and all of these FDOs automatically have the possible processing options defined by the operations associated with that profile.

  Compared to attribute typing, the versatility of profile typing is potentially lower because attribute definitions that constitute an association condition are typically reused across profiles and may occur in multiple target FDOs. These FDOs then automatically have the possible processing options defined by these operations. In this way, an operation can still be associated with any FDO whose profile contains the required set of attributes, and the association is not missed simply because the association between the operation and the profile was not explicitly made. In addition, an operation associated via profile typing may assume the presence of specific, not necessarily mandatory, attribute definitions in the profile. This could result in incompatibilities when executing the operation in case these attribute definitions were not instantiated for a particular FDO. With attribute typing, this cannot happen since the instantiation of all required attribute definitions is assured as part of the association process.

4.4 Interoperability of Association Models

In contrast to the other quality indicators, we do not define specific metrics to quantify different levels of interoperability, which is out of scope for this work. Instead, we describe the implications for interoperability of FDOs and their operations by the compatibility of the introduced association models.

Interoperability of FDO operations refers to the ability to perform consistent, standardized operations on FDOs across different systems and platforms, ensuring that actions such as accessing, processing, or transforming the objects can be executed reliably and requested uniformly by a client, regardless of the environment. From our point of view, different association models should therefore be consistent and compatible with respect to a standardized FDO type system that utilizes one or more typing mechanisms.

This ensures that when an FDO is accessed or manipulated across different platforms, its type definitions and associated operations are consistently interpreted and executed. The type system provides a common language for using the standardized structure of FDOs based on one or more typing mechanisms, enabling seamless interaction between systems. Regardless of which typing mechanisms are implemented within a service, it is critical that all clients accessing an FDO obtain the same set of associated operations independent from the underlying model.

Profiles are essential for this as they provide a minimal, standardized metadata structure for all FDOs. Because all association models for FDO Operations are expected to work with either a profile, profile attributes (also operations that are specified in the record), or a combination of both, they maintain a basic level of compatibility. Different association models using either record, profile or attribute typing can therefore be applied to the same FDO since the type system serves as a common language that allows different models to ‘understand’ which operations are valid. This also means that regardless of whether a simple or complex association model is used, the kernel metadata ensures that at least a core set of operations can be applied universally.

4.5 Implementation Considerations

Based on the results of our comparative evaluation and considering the approach of modeling the different association models using directed graphs, we conclude that implementations such as described in section 3.2.1–3.2.3 would highly profit from storing the interconnected components and the rules of each association model in proper graph data structures. This way, the assessment of the information about associations as described by the metrics is done once at ingestion time and stored as vertices and nodes according to the model, yielding the structure as illustrated in Figure 6. The repetitive procedures described by the quality indicators and quantified by their metrics are then facilitated. For example, assessment about which operations are associated with a given FDO and vice versa can be performed with simple graph queries. More complex procedures, such as is the case for attribute typing (cf. ${\mathcal{S}}_3$), could be also compensated this way by caching and integrating rules for inferring information. This could take place on the level of the object entities, as well as on the level of the services which store additional information about some components, for example the profiles.