Enhancing Data Governance in Data Trustees Through ODRL-Based

End-of-Life Policies

Michael Steinert

1,2 a

and Daniel Tebernum

1 b

Fraunhofer Institute for Software and Systems Engineering ISST, Dortmund, Germany

TU Dortmund University, Dortmund, Germany

Keywords:

ODRL, End-of-Life Data Management, Data Trustees, Data Spaces, Data Governance.

Abstract:

While data sharing drives innovation, ensuring compliance with legal, regulatory, and trust requirements

presents signiﬁcant challenges. Research identiﬁes data trustees as intermediaries between providers and

consumers, facilitating compliant and trusted data sharing. However, an underserved aspect is managing the

end-of-life (EoL) of shared data, where standardized, machine-interpretable mechanisms for detailed EoL poli-

cies are lacking. To address this gap, we propose an extension of the Open Digital Rights Language (ODRL)

to incorporate semantically rich EoL policies. This enables the speciﬁcation of data deletion requirements,

supporting legal and regulatory obligations. Data trustees can use these enhanced policies to coordinate EoL

actions among all parties. The explicit semantics within these policies facilitate clearer accountability and

support the creation of auditable logs by making EoL obligations machine-interpretable and unambiguous.

Our ODRL extension has been evaluated by ODRL and data governance experts, ensuring its robustness and

relevance for practical implementation. This work contributes to the standardization of EoL data management

by analyzing and articulating the detailed requirements for EoL policies in the context of data trustees, and by

proposing a speciﬁc ODRL extension to meet these requirements. For practitioners using ODRL, our exten-

sion provides enhanced, machine-interpretable EoL capabilities, improving compliance and trust.

1 INTRODUCTION

In times of constantly growing data volumes and

ever more complex legal requirements, efﬁcient end-

of-life (EoL) data management is becoming increas-

ingly important. This is particularly relevant with the

widespread adoption of generative AI, which can pro-

duce vast quantities of data, further emphasizing the

need for systematic data deletion strategies. A sys-

tematic approach to data deletion is essential (Teber-

num and Howar, 2023), especially for data trustees

who facilitate trusted and neutral data access between

data providers and data consumers while comply-

ing with legal requirements (Specht-Riemenschneider

and Kerber, 2022). In this process, data trustees must

maintain the trust and interests of all stakeholders.

Acting neutrally does not mean having no interests

of their own; rather, it means balancing the various

stakeholders’ interests (Schinke et al., 2023), a core

aspect emphasized in deﬁning their trusted role (Lind-

https://orcid.org/0009-0008-3888-2092

https://orcid.org/0000-0002-4772-9099

ner and Straub, 2023). To address these interests,

data trustees can operate in a speciﬁc sector (e.g., the

building sector) to meet stakeholder needs and under-

stand data and regulatory requirements (Steinert et al.,

2025). Incorporating EoL considerations offers data

trustees technical advantages (such as improved re-

source and cost optimization, reduced attack surfaces,

higher data quality (Tebernum and Howar, 2025)) and

strengthens stakeholder trust (Steinert and Tebernum,

2025).

To ensure the protection and targeted use of data,

data providers and consumers conclude data pro-

cessing agreements with data trustees to govern data

ﬂows, enforce agreed-upon rules, and manage con-

sent or usage rights (Stachon et al., 2023). These

agreements (also called data contracts) contain com-

prehensive usage guidelines in which prohibitions,

permissions, and duties are deﬁned (Iannella and

Villata, 2018). One way of making such policies

machine-readable and automatically enforceable is to

map them in Resource Description Framework (RDF)

using Open Digital Rights Language (ODRL). Simi-

lar access and usage policy mechanisms are already

Steinert, M. and Tebernum, D.

Enhancing Data Governance in Data Trustees Through ODRL-Based End-of-Life Policies.

DOI: 10.5220/0013669800003985

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 21st International Conference on Web Information Systems and Technologies (WEBIST 2025), pages 27-38

ISBN: 978-989-758-772-6; ISSN: 2184-3252

being used in data spaces (Dam et al., 2023; Ei-

tel et al., 2021), i.e., digital infrastructures that en-

able the secure, controlled, and sovereign exchange

of data between different stakeholders (Otto et al.,

2022). However, while ODRL provides a robust

foundation for general usage policies, including a

basic odrl:delete action, specifying the complex nu-

ances required for veriﬁable and compliant EoL data

management presents a challenge within the standard

ODRL vocabulary. Speciﬁcally, important aspects

such as the explicit rationale behind a deletion re-

quirement (e.g., legal mandate vs. user consent with-

drawal vs. data quality remediation), the mandated

deletion method (e.g., logical deletion vs. crypto-

graphic shredding), requirements for proof of deletion

or the handling of data dependencies are not natively

supported in a standardized, machine-interpretable

way. Representing these EoL speciﬁcs often requires

extensions or remains implicit within policy deﬁni-

tions. This semantic gap hinders interoperability and

the automated traceability of deletion duties and au-

ditable compliance trails, particularly within multi-

stakeholder environments, such as data spaces, facili-

tated by data trustees.

The importance of EoL data management is un-

derscored by external research, such as a survey of

35 data trustee experts, which found that respondents

consider reliable and traceable data deletion to be

a part of data trustees’ activities

. Acknowledging

these ﬁndings and the identiﬁed semantic gap in cur-

rent policy languages, we aim to enhance EoL data

governance for data trustees by addressing the follow-

ing two research questions:

RQ1: What speciﬁc requirements must an EoL

policy vocabulary fulﬁll to enable EoL data manage-

ment by data trustees, particularly within data spaces?

RQ2: How can the ODRL standard be ex-

tended with a semantically rich vocabulary to meet

these EoL requirements and facilitate machine-

interpretable speciﬁcation of deletion policies?

To answer these questions, we ﬁrst analyze and ar-

ticulate the requirements for a uniform, semantically

rich vocabulary for data deletion policies suitable for

data trustees. Subsequently, we propose an ODRL ex-

tension incorporating these requirements, drawing in-

spiration from existing EoL frameworks like the De-

stroyClaims concept (Tebernum and Howar, 2025)

Our contribution focuses on deﬁning the essential

components of this vocabulary to facilitate machine-

interpretable EoL policies. The aim is to establish

a more comprehensive data governance model, en-

abling automated compliance with EoL duties and

https://doi.org/10.5281/zenodo.14992879

https://github.com/DaTebe/destroyclaims

thereby reinforcing trust in data trustees.

The remainder of this paper is structured as fol-

lows: Section 2 provides the theoretical background

on data trustees, data spaces, and the intricacies of

EoL data management. Section 3 delves into the

requirements for an EoL policy vocabulary tailored

for data trustees, directly addressing RQ1, and also

presents our proposed ODRL extension, detailing the

vocabulary and associated mechanisms needed to ful-

ﬁll these requirements, thereby answering RQ2. Sec-

tion 4 describes the methodology and ﬁndings of our

qualitative evaluation, focusing on an expert work-

shop to assess the feasibility and conceptual sound-

ness of our ODRL extension. Section 5 discusses the

implications, potential beneﬁts, and limitations of our

ODRL extension. Finally, Section 6 summarizes our

ﬁndings and outlines directions for future work.

2 THEORETICAL FOUNDATION

This section ﬁrst outlines the core concepts that un-

derpin our work: data trustees and data spaces. Un-

derstanding these concepts is crucial for contextualiz-

ing our proposed ODRL extension for EoL data man-

agement. We also discuss the importance of EoL data

management.

2.1 Data Trustees

Data trustees represent a speciﬁc form of data inter-

mediary designed to act in the best interests of ex-

ternal stakeholders, namely data providers and data

consumers, without pursuing commercial goals con-

cerning the data itself (Specht-Riemenschneider and

Kerber, 2022). Literature distinguishes between a

narrower focus on ﬁduciary data management and a

broader view emphasizing the trustee’s role in facili-

tating trusted data sharing (Reiberg et al., 2023; Lind-

ner and Straub, 2023). Their fundamental role is to

serve as a trusted entity facilitating interactions be-

tween these parties (Schinke et al., 2023), ensuring

neutrality and transparency in their operations (Lind-

ner and Straub, 2023). By fulﬁlling this role, data

trustees ensure that data access and utilization occur

responsibly and compliantly.

Typical responsibilities of a data trustee include

mediating between data supply and demand, support-

ing the technicalities of data exchange, and fostering

trust among participants (Specht-Riemenschneider

et al., 2021). They offer an alternative to platform

models, thereby helping to counteract the forma-

tion of platform monopolies (European Commission,

2022). This contributes to market pluralization and

WEBIST 2025 - 21st International Conference on Web Information Systems and Technologies

enables smaller or specialized actors to participate ef-

fectively in the data economy, which can strengthen

market innovation (Shaharudin et al., 2024). The op-

erations of data trustees are grounded in technical, le-

gal, ethical, and organizational standards that guaran-

tee security and reliability. Functionally, they can ei-

ther hold the data directly or facilitate the direct shar-

ing of data between the parties involved (Lauf et al.,

2023). In either scenario, the objective is to safeguard

the interests and rights of all participants, cultivate

trust within the data ecosystem, and ensure fair and

transparent data sharing (Stachon et al., 2023). Fi-

nally, data trustees should have domain knowledge,

such as in the building sector, which can further en-

hance their ability to meet stakeholder needs and nav-

igate speciﬁc regulatory requirements (Steinert et al.,

2025).

2.2 Data Spaces

The concept emerged partly from the need to manage

increasingly diverse and distributed data sources be-

yond traditional centralized databases (Franklin et al.,

2005). Data space technology offers a technical foun-

dation for implementing the functionalities required

by data trustees, enabling secure and sovereign data

sharing (Otto et al., 2022). CEN and CENELEC, the

European bodies responsible for developing techni-

cal standards, deﬁne a data space as an “interopera-

ble framework, based on common governance prin-

ciples, standards, practices, and enabling services,

that enables trusted data transactions between par-

ticipants” (European Committee for Standardization,

2024). The goal of data spaces is to facilitate the

controlled sharing and cooperative use of data be-

tween different organizations, irrespective of the data

types involved, while ensuring data providers retain

sovereignty over their assets (Otto, 2022). Techni-

cal implementations often follow architectures like

the International Data Spaces Reference Architecture

Model (IDSA RAM) (Otto et al., 2019), which out-

lines components and layers for secure data shar-

ing. Consequently, data spaces empower organiza-

tions and individuals to gain deeper insights from

their data, thereby improving decision-making pro-

cesses and fostering innovation (Bacco et al., 2024).

2.3 The Interplay of Data Trustees and

Data Spaces

Data trustees and data spaces are complementary con-

cepts (Steinert and Altendeitering, 2024). In addition,

the broader category of data intermediaries, which in-

cludes data trustees, is also seen as part of the role

model of data spaces (Gemein et al., 2023). Data

trustees provide the organizational, legal, and trust-

building framework necessary to govern sovereign

data sharing according to agreed rules and policies.

Conversely, data spaces provide the technical infras-

tructure required for secure, efﬁcient, and sovereign

data management and sharing. The data trustee es-

tablishes the governance and trust layer by deﬁning

the rules of engagement (often codiﬁed in ODRL

policies), while the data space provides the technical

means to enforce these rules, manage data ﬂows, and

facilitate secure interaction. This interplay ensures

that data can be protected effectively while being uti-

lized purposefully, beneﬁting all participants and con-

tributing to an innovative and competitive data econ-

omy. Our work enhances this interplay by introducing

EoL data management within data trustees that oper-

ate within or interact with data spaces.

2.4 End-of-Life Data Management

Data deletion, the deliberate and often irreversible ac-

tion of removing or obliterating information, consti-

tutes the ﬁnal stage of the data lifecycle (Tebernum

and Howar, 2023) (also referred to as EoL data man-

agement). It transcends the simplicity implied by

a ’delete’ command, representing a necessary pro-

cess driven by multifaceted requirements and con-

veying signiﬁcant implicit meaning. Despite its in-

creasing importance, research indicates this area re-

mains under-addressed compared to other lifecycle

stages (Tebernum et al., 2021, 2023). Understand-

ing the depth of data deletion is paramount, particu-

larly within trust-based ecosystems facilitated by data

trustees.

Controlled data deletion ensures compliance with

legal and regulatory requirements, such as the

GDPR’s “right to be forgotten” (European Commis-

sion, 2016), mitigating signiﬁcant legal and ﬁnancial

risks. It also improves security by reducing the attack

surface; removing redundant or sensitive data mini-

mizes the potential damage from breaches. Moreover,

it maintains data quality (Wang and Strong, 1996) and

utility, ensuring that decisions are based on current,

relevant, and accurate information, which is impor-

tant, for example, when needing to remove speciﬁc

data points from trained models (Ginart et al., 2019).

Furthermore, it optimizes resource utilization, reduc-

ing storage costs and potentially improving system

performance, aligning with principles of efﬁcient re-

source management and Green IT (Van Bussel and

Smit, 2014). Finally, ethical considerations, organi-

zational policies, or evolving risk assessments may

require data removal.

Enhancing Data Governance in Data Trustees Through ODRL-Based End-of-Life Policies

Given its destructive and irreversible nature, data

deletion demands a systematic and precise approach.

A simple instruction to delete is often insufﬁcient.

Effective deletion requires detailed speciﬁcations, in-

cluding: precise identiﬁcation of the target data (e.g.,

speciﬁc records, ﬁles identiﬁed by hashes, data within

certain systems); explicit documentation of the ratio-

nale for deletion (e.g., compliance, user request, qual-

ity issue); deﬁnition of preconditions (e.g., temporal

constraints, geographical location, completion of re-

lated processes); speciﬁcation of the deletion method

(e.g., logical deletion, cryptographic wiping, physi-

cal destruction); assignment of responsibility; and im-

plementation of safeguards (e.g., simulations, explicit

approvals) to prevent errors.

Crucially, the action of deletion, particularly when

formally speciﬁed and recorded, carries inherent

meaning beyond the mere absence of data. The doc-

umented speciﬁcation itself becomes valuable meta-

data. The stated rationale reveals the intent behind

the deletion (compliance, risk reduction, etc.). The

decision to delete implies a value assessment - the

data is no longer deemed necessary, useful, or its re-

tention poses unacceptable risk according to deﬁned

policies. Speciﬁed conditions provide context about

operational workﬂows or regulatory constraints. The

chosen deletion method reﬂects the perceived sen-

sitivity of the data and the required level of assur-

ance. Furthermore, the existence of a structured, doc-

umented deletion process signiﬁes the organization’s

governance maturity (Tallon et al., 2013) and com-

mitment to the responsibilities of data trustees, pro-

viding an auditable trail that is important for account-

ability.

However, standard policy languages like ODRL,

with basic actions such as odrl:delete, lack the seman-

tic depth required for comprehensive EoL data man-

agement. This gap in expressiveness, particularly in

deﬁning the rich context of deletion for traceable and

auditable processes, motivates the ODRL extension

detailed in this work.

3 PROPOSED ODRL EXTENSION

FOR EOL POLICIES

Building upon the analysis of data trustee needs (Sec-

tion 2) and the identiﬁed semantic limitations of stan-

dard ODRL for EoL management (Section 2.4), this

section details our ODRL extension. Our goal is to

create a semantically rich and machine-interpretable

vocabulary that enables the precise speciﬁcation, au-

tomated processing, and auditing of data deletion

policies by data trustees, particularly within data

spaces.

This ODRL extension addresses RQ1: What spe-

ciﬁc requirements must an EoL policy vocabulary

fulﬁll to enable EoL data management by data

trustees, particularly within data spaces? by fulﬁll-

ing the speciﬁc requirements derived from our anal-

ysis. It then answers RQ2: How can the ODRL

standard be extended with a semantically rich vo-

cabulary to meet these EoL requirements and fa-

cilitate machine-interpretable speciﬁcation of dele-

tion policies? through the proposed eol: vocabulary

and its mechanisms. Speciﬁcally, the ODRL exten-

sion is designed to fulﬁll the following requirements:

• REQ1: Semantic Richness for Rationale: Ex-

plicitly capture the reason for the EoL action (e.g.,

GDPR request, contract end, data quality).

• REQ2: Speciﬁcation of Deletion Method: Al-

low speciﬁcation of the required deletion method

(e.g., logical delete, wipe, physical destruction).

• REQ3: Granular Data Identiﬁcation: Enable

precise identiﬁcation of data assets, potentially

beyond URIs (e.g., via hashes, record IDs).

• REQ4: Clear Temporal and Spatial Speciﬁca-

tion: Support unambiguous temporal and spatial

constraints for deletion actions.

• REQ5: Machine Interpretability and Automa-

tion: Be deﬁned formally (e.g., RDF) for unam-

biguous machine interpretation and automation.

• REQ6: Support for Traceability and Auditing:

Ensure traceability and auditability of EoL actions

(e.g., via logs or conﬁrmations) to enable conﬁr-

mation processes.

• REQ7: Compatibility and Extensibility within

ODRL: Integrate seamlessly with ODRL and fol-

low its design principles as a modular extension.

• REQ8: Contextual Applicability for Data

Trustees: Be suitable for multi-party scenarios

managed by data trustees within data spaces.

• REQ9: Operational Policy Management Fea-

tures: Incorporate attributes for practical policy

management at the rule level, allowing for control

over execution behavior.

To meet these requirements, we propose deﬁning

this ODRL extension using RDF, introducing a new

vocabulary under the namespace eol:.

3.1 The eol: Vocabulary Extension

The eol: vocabulary complements standard ODRL by

adding speciﬁc classes and properties tailored for EoL

data management, addressing the requirements out-

lined above.

WEBIST 2025 - 21st International Conference on Web Information Systems and Technologies

3.1.1 Rule-Level Operational Attributes

(Addressing REQ9)

To provide operational control over individual rules

within a policy, we introduce several properties ap-

plicable directly to instances of odrl:Rule (such as an

odrl:obligation or odrl:permission):

• eol:simulated (xsd:boolean): Indicates if the rule

execution should only be simulated (e.g., for test-

ing or impact analysis) rather than enacted.

• eol:notiﬁcation (xsd:boolean): Speciﬁes if the as-

signee should receive a notiﬁcation before the data

associated with the rule is deleted.

• eol:optIn (xsd:boolean): Indicates whether the

deletion of data as per the rule must be explicitly

accepted (opted-in) by the assignee, rather than

being processed automatically.

• eol:strict (xsd:boolean): Mandates that rule ex-

ecution should only proceed automatically if the

processing system understands all classes, prop-

erties, and values within the rule. This prevents

unintended actions due to partial interpretation.

3.1.2 Specifying WHAT to Delete: The

eol:Locator (Addressing REQ3)

Standard ODRL uses odrl:target to identify the as-

set. However, EoL actions often require more gran-

ular identiﬁcation, especially for distributed data or

speciﬁc data fragments. We introduce:

• eol:Locator (Class): Represents a detailed de-

scription of an asset’s location or identity beyond

a simple URI. Instances of eol:Locator can have

various speciﬁc properties to accommodate differ-

ent types of location or identiﬁcation information

(e.g., content hashes, ﬁle paths, persistent identi-

ﬁers, database UIDs, URLs).

• eol:hasLocator (Property): Links an odrl:Asset

(and therefore also an odrl:AssetCollection, as

it is a subclass) to one or more eol:Locator in-

stances. Its domain is explicitly set to odrl:Asset,

allowing locators for both individual assets and

collections.

• eol:locatorSHA256Hash (Property): This prop-

erty serves as one example of how an asset can be

identiﬁed within an eol:Locator instance, speciﬁ-

cally using its SHA256 content hash (xsd:string).

Other properties could be deﬁned for different

identiﬁcation schemes.

This allows policies to precisely target speciﬁc

data instances or collections for deletion, even if indi-

vidual items lack persistent URIs, using precise iden-

tiﬁers like content hashes or other suitable locator

properties.

3.1.3 Specifying WHY: The eol:Reason

(Addressing REQ1)

Understanding the rationale behind a deletion require-

ment is important for compliance, auditing, and ap-

propriate handling (e.g., notifying stakeholders). We

introduce:

• eol:Reason (Class): Represents the justiﬁcation

for the policy, rule, or action. Instances of

this class would typically be URIs representing

concepts like eol:reason:LegalObligation,

eol:reason:UserConsentWithdrawal,

eol:reason:DataQualityIssue, etc.

• eol:hasReason (Property): Links an odrl:Rule

(or an odrl:Action within it) to an instance of

eol:Reason, providing machine-interpretable con-

text.

3.1.4 Specifying HOW: eol:destructionMethod

and Reﬁnements (Addressing REQ2)

The core odrl:delete action lacks speciﬁcity regard-

ing the deletion method. We leverage ODRL’s

odrl:reﬁnement mechanism within a odrl:Constraint

attached to the rule governing the odrl:delete action.

We introduce:

• eol:destructionMethod (LeftOperand): Deﬁned

as an odrl:LeftOperand, this represents the con-

cept of the required method or level of destruc-

tion. It is used as the odrl:leftOperand in a re-

ﬁnement constraint associated with an action (like

odrl:delete).

• Speciﬁc Destruction Method Identiﬁers (Right-

Operands): The required method is speciﬁed us-

ing an IRI as the odrl:rightOperand in the re-

ﬁnement constraint (typically with odrl:operator

odrl:eq). These IRIs can represent:

– Abstract destruction levels, such as

eol:method:Recycled (implying data might

be restorable), eol:method:Deleted (standard

logical deletion), eol:method:Wiped (data is

overwritten and not practically restorable), or

eol:method:PhysicallyDestroyed (the storage

medium itself is destroyed). These abstract

levels of recoverability are inspired by Cantrell

and Runs Through (2019).

– Concrete algorithms or techniques, for exam-

ple, an IRI representing a speciﬁc wiping al-

gorithm (e.g., a Gutmann method variant) or a

destruction level from standards such as NIST

SP 800-88, ISO/IEC 27040 or DIN 66399.

Enhancing Data Governance in Data Trustees Through ODRL-Based End-of-Life Policies

While the speciﬁc eol: vocabulary elements

detailed above directly address REQ1 (Rationale),

REQ2 (Method), REQ3 (Identiﬁcation), and REQ9

(Operational Attributes), the overall design, based

on RDF and ODRL’s extensibility, inherently sup-

ports other requirements. Standard ODRL temporal

(odrl:dateTime) and spatial (odrl:spatial) constraints

are leveraged to meet REQ4 (Temporal and Spa-

tial Speciﬁcation). The use of RDF ensures REQ5

(Machine Interpretability), which, combined with the

explicit semantics, provides a foundation for REQ6

(Traceability and Auditing). Compatibility (REQ7) is

maintained by adhering to ODRL patterns. How these

elements integrate to support data trustee operations

in multi-party contexts (REQ8) is further detailed in

Section 3.3.

3.2 Illustrative Example EoL Policy

Listing 1 demonstrates how these extensions inte-

grate within an ODRL policy, reﬂecting the struc-

ture from our formal deﬁnition (provided in the Ap-

pendix of this paper) and incorporating terms shown

in the following JSON-LD structure. The policy ref-

erences an ODRL proﬁle (via the odrl:proﬁle), which

deﬁnes or imports the eol: vocabulary terms and

their usage. This ensures that all parties understand

the semantics of the EoL extension used. It shows

an odrl:Agreement where a data trustee assigns an

obligation to a data consumer. The obligation rule

within the policy speciﬁes that its execution will not

be simulated (eol:simulated is false), requires strict

interpretation (eol:strict is true), mandates assignee

opt-in for deletion (eol:optIn is true, meaning it is

not fully automated without acceptance), and trig-

gers a notiﬁcation to the assignee (eol:notiﬁcation

is true). The obligation is to delete (odrl:delete)

an asset (odrl:Asset, which uses eol:hasLocator to

refer to a eol:locatorSHA256Hash, triggered by

user consent withdrawal (eol:hasReason pointing

to eol:reason:UserConsentWithdrawal). This obli-

gation is constrained temporally, active from Jan-

uary 1, 2025, and expiring by December 31, 2026,

and spatially limited to the EU (via an odrl:spatial

isA constraint). Furthermore, the deletion action

is reﬁned to require a speciﬁc destruction method

(eol:destructionMethod equal to a URI representing

the Gutmann method).

3.3 Integration Within Data Trustees

This extended ODRL vocabulary integrates into the

operational workﬂows of data trustees, potentially

within data spaces. While this section outlines how

this integration would function, its concrete imple-

mentation and empirical validation are planned for fu-

ture work. Data trustees use these policies in data con-

tracts to specify EoL duties. Technical components

(e.g., a data space connector enhanced with policy

enforcement capabilities) can parse and act on these

machine-interpretable policies (REQ5). The explicit

semantics, such as eol:hasReason and the speciﬁc

eol:destructionMethod, along with rule-level opera-

tional attributes like eol:simulated or eol:notiﬁcation,

guide implementation (e.g., triggering speciﬁc dele-

tion scripts or workﬂows) and facilitate targeted no-

tiﬁcations or compliance checks (REQ9). Crucially,

this structure enables automated logging and auditing

based on policy terms (e.g., recording when a policy

with a speciﬁc reason and method was executed), en-

hancing traceability and auditing (REQ6). This ap-

proach aligns with ODRL principles (REQ7) and di-

rectly supports the data trustee’s governance role in

managing multi-party data lifecycles (REQ8).

In summary, this proposed ODRL extension, char-

acterized by the eol: vocabulary and driven by the

identiﬁed requirements, provides a concrete mech-

anism to facilitate expressive, machine-interpretable

EoL policies, thereby strengthening data governance

for data trustees.

4 EVALUATION

To assess the feasibility and appropriateness of the

proposed ODRL extension for EoL policies, and to

validate the underlying requirements, a qualitative

evaluation study was conducted. Nine experts par-

ticipated in semi-structured interviews. These experts

were selected to represent a diverse range of relevant

domains: one data scientist, two mobility and smart

city experts, one manufacturing expert, one cloud in-

frastructure expert, and four data space experts. Cru-

cially, all participants had knowledge of and practical

experience with data governance and policy manage-

ment, as well as expertise with ODRL. The interviews

were guided by a framework covering six evalua-

tion criteria: Relevance & Completeness of Require-

ments (addressing RQ1), Suitability of the Solution

Approach, Semantic Clarity & Expressiveness, Tech-

nical Feasibility & Integration, and Potential Impact

& Usefulness (all addressing RQ2). Interview tran-

scripts were analyzed using qualitative content anal-

ysis to identify recurring themes, patterns, and criti-

cal insights regarding the proposed ODRL extension,

following established procedures for deductive con-

tent analysis and systematic qualitative analysis of

text data (McKibben et al., 2022; Puppis, 2019).

WEBIST 2025 - 21st International Conference on Web Information Systems and Technologies

{

// Cont ext de fin i t io n s omi t te d to save s pa ce

" @t yp e ": " Ag re e men t ",

" u id ": " urn : pol i cy: e xam p le0 1 - delete - ob li g a ti o n ",

// Prof ile w ou ld def i ne or im po rt t he eol : v o ca b u la r y t er ms an d their us ag e

" od rl : p r of i l e ": { " @i d ": " htt p: // e x am ple . c om / od rl / pro fi l e / data - t ru ste e " } ,

" dc t :de s c r ipt i o n ": { " @v al ue ": " De le te use r da ta ( co n se n t w ith d raw a l )" } ,

" dct: i ssu e d ": "20 25 -01 -01" ,

// R EQ 7: Co m p a ti b i l it y / REQ5: In t erp r e t a bil i t y / RE Q6 : A ud i ti n g

" obli g ati o n ": [{

" @ id ": " urn : pol i cy: e xam p le0 1 - delete - ob li g a ti o n # obli g ati o n ",

// R EQ 1: WHY - S e man t ic Ri ch n ess for Rat i on a l e

"eol:hasReason" : { " @id ": " e o l :Us e r C o n s e n t Wit h d r a w a l " } ,

// R EQ 9: Op e r at i o na l Poli cy Ma nag e men t Fe at u re s

"eol:simulated" : false ,

"eol:notification" : tr ue ,

"eol:optIn" : tr ue ,

"eol:strict" : tr ue ,

// R EQ 8: Co n te x t ua l Ap p l ica b i l it y ( Da ta T rus tee Con t ex t )

" ass i gn e r ": " ur n : p ar t y : t r ust e e " ,

" ass i gn e e ": " ur n : p art y : c o n sum e r " ,

" tar ge t ": {

" @t yp e ": " Asset ",

" @ id ": " u r n: a s s e t :us e r X Y Z ",

" dct : t it l e ": " Us er XYZ Data Se t ",

"eol:hasLocator" : {

" @t yp e ": "eol:Locator" ,

// Loca tor ca n use va r io us p rop e rti e s ; thi s is one e xam pl e

"eol:locatorSHA256Hash" : " db2 d c5 .. ."

}

" act io n ": {

" @ id ": " odr l : de l e te ",

" refi n eme n t ": [{

// R EQ 2: HOW - Re fin e men t sp ec i f yin g th e De l et i on Me th od

" le ft O p era n d ": "eol:destructionMethod" ,

" ope r at o r ": " odr l :e q ",

" ri gh t O p er a n d ": " htt p: // exa mpl e . com / odrl - eo l / me t ho d / gu tma nn - met h od "

}]

}

// R EQ 4: W HE N & W HE RE - C o ns t r ain t s on t he Ob li ga ti on ’ s a pp l i c abi l i t y

" cons t rai n t ": [

{

" le ft O p era n d ": " od r l :d a t e Ti m e " ,

" ope r at o r ": " od rl : gte q ",

" ri gh t O p er a n d ": "20 25 - 01 -01"

{

" le ft O p era n d ": " od r l:s p a tia l " ,

" ope r at o r ": " odrl :is A ",

" ri gh t O p er a n d ": " ur n : l oc a t i o n:E U "

{

" le ft O p era n d ": " od r l :d a t e Ti m e " ,

" ope r at o r ": " od rl : lte q ",

" ri gh t O p er a n d ": "20 26 - 12 -31" ,

" sko s : no t e ": " Ru le E x p ir a t ion D at e "

}

]

}]

}

Listing 1: Example ODRL Policy with EoL Extensions in JSON-LD.

Enhancing Data Governance in Data Trustees Through ODRL-Based End-of-Life Policies

4.1 Relevance & Completeness of

Requirements (RQ1)

There was a strong consensus among the experts re-

garding the relevance of addressing EoL data man-

agement with more granularity than standard ODRL

provides. The identiﬁed set of nine requirements

(REQ1-REQ9) was generally perceived as compre-

hensive and well-founded for specifying EoL policies

in the context of data trustees.

Semantic Aspects (REQ1, REQ2, REQ3): The

need to specify the rationale (REQ1) for deletion was

acknowledged for context and auditability, although

some experts questioned its direct technical necessity

for policy execution engines. Specifying the dele-

tion method (REQ2) was deemed crucial for compli-

ance and operational clarity, prompting discussions

on the technical capabilities required by the execut-

ing party. The requirement for granular data iden-

tiﬁcation (REQ3) beyond simple URIs, potentially

using hashes or internal identiﬁers via the proposed

eol:Locator, was strongly supported as a necessary

enhancement, although challenges regarding consis-

tency of identiﬁers across systems were noted.

Contextual & Technical Aspects (REQ4,

REQ5, REQ6, REQ7): Leveraging standard ODRL

for temporal and spatial constraints (REQ4) was

considered pragmatic. The fundamental need for

machine interpretability (REQ5) through a formal

RDF structure was undisputed. Supporting traceabil-

ity and auditing (REQ6) was recognized as a critical

goal, though experts highlighted the practical limi-

tations and dependency on the logging mechanisms

and trustworthiness of the executing environment.

Ensuring compatibility with ODRL (REQ7) by using

an extension vocabulary was seen as the correct

approach.

Operational & Ecosystem Aspects (REQ8,

REQ9): The suitability for multi-party scenarios typ-

ical for data trustees (REQ8) was conﬁrmed by the

inherent structure of ODRL for deﬁning roles (assign-

er/assignee). The operational policy management fea-

tures (REQ9), such as those for simulation, notiﬁca-

tion, opt-in, and strict interpretation at the rule level,

were particularly well received and considered highly

valuable for practical policy deployment and control.

Discussions arose regarding the optimal placement of

these attributes (policy vs. rule level) depending on

the desired scope (e.g., EoL as part of a larger usage

policy).

Potential Gaps Identiﬁed: A recurring theme

was the challenge of addressing the EoL of derived

data products (e.g., aggregated datasets, trained AI

models), which was considered important but poten-

tially beyond the scope of this initial vocabulary. The

need for explicit notiﬁcation or conﬁrmation mecha-

nisms upon successful deletion was also suggested by

some participants, a point partially addressed by the

eol:notiﬁcation ﬂag. Furthermore, a clearer deﬁnition

of responsibilities for policy enforcement and veriﬁ-

cation within the ecosystem was deemed necessary.

4.2 Evaluation of the ODRL Extension

(RQ2)

Suitability of Approach: Extending ODRL was

broadly accepted as a suitable and pragmatic ap-

proach, given ODRL’s prevalence in data spaces and

related initiatives. Its ﬂexibility was seen as an ad-

vantage, while its known complexity and lack of stan-

dardized tooling were acknowledged as general chal-

lenges. The proposed eol: vocabulary was found to be

logically structured and consistent with the identiﬁed

requirements.

Semantic Clarity & Expressiveness: The vocab-

ulary was perceived as clear and understandable, par-

ticularly when presented with the policy examples.

Experts conﬁrmed its ability to effectively express the

EoL nuances (reason, method, granular target, oper-

ational controls), representing a signiﬁcant improve-

ment over standard ODRL for this purpose. The lim-

itation regarding derived data was reiterated here.

Technical Feasibility & Integration: While the

vocabulary and its ODRL integration were considered

sound, experts identiﬁed several practical implemen-

tation challenges. These primarily centered on the

need to develop speciﬁc policy engine logic to in-

terpret and act upon the eol: terms, the mapping of

eol:Locator information to diverse target systems, en-

suring target systems support the speciﬁed deletion

methods, and potential limitations in existing APIs

(e.g., for custom attributes). However, the overarch-

ing challenge of policy enforcement - ensuring that

the speciﬁed actions are actually carried out reliably

and veriﬁably in the target environment - was empha-

sized by almost all participants as a hurdle, indepen-

dent of the policy language itself.

Potential Impact & Usefulness: The experts

saw potential value in the proposed ODRL exten-

sion. Beneﬁts highlighted included enhanced com-

pliance support, improved data quality management,

increased transparency in data handling, and foster-

ing trust within data ecosystems, particularly for the

governance role of data trustees. While the potential

to improve current EoL practices was acknowledged,

concerns about widespread, rapid adoption were also

expressed, citing the general inertia of detailed policy

implementation and the reliance on perceived need

WEBIST 2025 - 21st International Conference on Web Information Systems and Technologies

and regulatory pressure.

General Acceptance & Suggestions: Overall

feedback was positive, conﬁrming the need and

general direction of the proposed ODRL extension.

Strengths were seen in the semantic richness and op-

erational control features. The main perceived weak-

ness is the reliance on effective enforcement mecha-

nisms. Suggestions for improvement included con-

sidering more ﬂexible placement of operational at-

tributes and possibly including notiﬁcation mecha-

nisms. The critical role of clear governance frame-

works deﬁning EoL standards and responsibilities

within data ecosystems was repeatedly emphasized.

4.3 Evaluation Summary

The expert interviews broadly conﬁrmed the identi-

ﬁed requirements for enhanced EoL data management

(RQ1) and conﬁrmed the suitability of the proposed

ODRL extension (RQ2) to address these needs. The

eol: vocabulary was found to be semantically ex-

pressive for EoL concepts and operationally valuable.

However, the evaluation emphasized that the success

of such a policy framework depends on addressing

the persistent challenge of policy enforcement and es-

tablishing clear governance structures within the tar-

get data ecosystems. While the proposed eol: vo-

cabulary provides the necessary means to specify de-

tailed EoL policies, ensuring their implementation re-

quires complementary technical and organizational

measures. The results provide valuable input for re-

ﬁning the vocabulary and underscore the importance

of integrating policy deﬁnition with robust enforce-

ment and governance strategies in future work.

5 DISCUSSION

The introduction of the eol: vocabulary as an ODRL

extension for EoL data management by data trustees

presents several practical and theoretical implications.

This section discusses these implications, the bene-

ﬁts, and limitations of the proposed approach, and its

broader signiﬁcance for data governance, building on

the validation from our expert evaluation (Section 4).

Practical Implications: Leveraging ODRL for

EoL Management. A design choice was to ex-

tend ODRL rather than proposing a new policy lan-

guage. This decision carries practical advantages.

Data trustees and participants in data spaces are fa-

miliar with ODRL for deﬁning access and usage poli-

cies (Dam et al., 2023; Eitel et al., 2021). Integrat-

ing EoL speciﬁcations into ODRL avoids the over-

head of developing, learning, implementing, and exe-

cuting a separate language and its associated tooling.

Systems already capable of parsing and interpreting

ODRL (e.g., data space connectors) can potentially

be adapted to handle the eol: extension, lowering the

barrier to adoption. This pragmatic approach directly

supports REQ7 (ODRL Compatibility) and enhances

the likelihood of practical implementation within ex-

isting data governance frameworks. While conceptual

integration into the ODRL model is straightforward,

practical implementation of interpretation engines re-

quires more work. Here, it is necessary that, over

time, practical experience feeds back into research to

identify the most important aspects, so that robust in-

terpretation engines can be developed on this basis.

Towards Holistic Data Lifecycle Governance

with ODRL. ODRL focuses on the phases of data ac-

cess and usage. Our extension incorporates the ﬁnal

phase of the data lifecycle. By enabling the speciﬁca-

tion of why data should be deleted (eol:Reason), how

it should be deleted (eol:destructionMethod), and pre-

cisely what data is targeted (eol:Locator), ODRL be-

comes a more comprehensive language for govern-

ing data throughout its entire lifecycle. This aligns

with the need for holistic data lifecycle management

(Tebernum and Howar, 2023) and moves ODRL to-

wards being a language capable of expressing poli-

cies that span from data creation and sharing through

to its eventual, traceable deletion. While inspired

by concepts seen in frameworks like DestroyClaims

our integration within the ODRL standard facilitates

broader interoperability and standardization potential.

Theoretical Implications: Formalizing EoL as

Policy. Beyond the practical beneﬁts, our work

demonstrates the theoretical feasibility and utility

of modeling EoL actions declaratively as machine-

interpretable policies. Traditionally, data deletion

might be handled through procedural scripts, man-

ual processes, or implicit understandings. Formaliz-

ing EoL duties within ODRL elevates these actions to

the level of explicit governance rules that are suitable

for automated reasoning, traceability, and auditing.

The ability to capture the meaning behind deletion

(as discussed in Section 2.4) via properties such as

eol:Reason adds semantic depth, transforming a sim-

ple delete command into a rich, context-aware gov-

ernance instruction. This formalization is important

for building trustworthy data trustees, where trans-

parency and accountability are paramount.

Addressing the Need for a Uniform EoL Vocab-

ulary and Standardization. The lack of a standard-

ized vocabulary for EoL actions represents a signif-

icant barrier to reliable and veriﬁable data deletion

across organizational boundaries, as highlighted in

https://github.com/DaTebe/destroyclaims

Enhancing Data Governance in Data Trustees Through ODRL-Based End-of-Life Policies

our problem statement. Ambiguity regarding deletion

requirements hinders automated enforcement, partic-

ularly when obligating data consumers to perform

deletion, and complicates compliance auditing. Our

work tackles this by systematically identifying the

necessary semantic components (REQ1-REQ9) and

proposing a concrete vocabulary (eol:) integrated

within ODRL. While proposing a full W3C standard

is beyond the scope of this initial work, the deﬁnition

and validation of these requirements, coupled with the

demonstration of their feasibility using ODRL exten-

sions, represent a novel and necessary contribution. It

lays the crucial groundwork for future standardization

efforts, providing a candidate vocabulary that aims to

foster a common understanding and improve trust and

compliance regarding EoL duties in data spaces.

Facilitating Enforceability and Auditing. A per-

sistent challenge in data sharing is ensuring that data

consumers adhere to usage policies, including dele-

tion duties. While our ODRL extension cannot guar-

antee technical enforcement on a consumer’s system

(which remains dependent on their implementation

and willingness to comply), it facilitates enforceabil-

ity and auditability. The machine-interpretable nature

(REQ5) allows consumer systems to automatically

recognize and process deletion duties. Explicit re-

quirements for deletion methods (REQ2) and reasons

(REQ1) clarify expectations. Crucially, the structured

policy enables better auditing (REQ6). Data trustees

can log the issuance of EoL policies, and mechanisms

could be envisioned (potentially linked to data space

components like clearing houses) to track acknowl-

edgments or require conﬁrmations of deletion from

consumers, based on the policy rules. This provides a

veriﬁable trail, enhancing accountability even if direct

technical enforcement is limited.

Supporting Legal Compliance and Risk

Management. The proposed ODRL extension

ensures compliance with various legal and regulatory

frameworks, including the GDPR and CCPA. The

ability to specify the legal basis for deletion (e.g.,

eol:UserConsentWithdrawal, eol:LegalObligation)

and the required deletion standard aligns with data

protection principles. Furthermore, the rule-level

operational attributes introduce risk management

features. eol:simulated allows for impact analysis be-

fore actual deletion, mitigating the risk of accidental

data loss. eol:strict prevents automated execution if

the policy semantics are not fully understood by the

processing system, reducing the chance of incorrect

actions. eol:optIn ensures assignee consent for

deletion when required, and eol:notiﬁcation provides

transparency. However, it is important to recognize

that while these features help manage risk, they do

not eliminate operational risk entirely; robust backup

and recovery strategies, along with careful policy

authoring and review processes, remain essential.

Limitations and Future Directions. Despite the

positive feedback on our evaluation, we acknowledge

the limitations of our approach. First, the challenge of

technical enforcement on consumer systems remains.

While our ODRL extension improves the clarity and

auditability of the deletion duty, veriﬁable deletion

still relies on consumer cooperation and additional

technical mechanisms. Second, handling cases across

multiple jurisdictions presents governance challenges

that the eol: vocabulary cannot solve alone. Third,

extending ODRL is pragmatic but adds complexity to

the standard. This requires careful consideration of

tooling support and potential interactions with other

ODRL proﬁles. Fourth, the eol: vocabulary may

require reﬁnement to address more complex scenar-

ios, such as intricate data dependencies, the need for

speciﬁc proof-of-deletion artifacts, and partial data

anonymization as an alternative to deletion. Finally,

the success of our ODRL extension depends on com-

munity adoption and integration into data spaces. Fur-

ther dissemination, the development of best practices,

and pilot implementations are necessary next steps.

6 CONCLUSION

This work addressed the gap in EoL data manage-

ment within data trustee operations, particularly in

the context of data spaces, by answering our research

questions concerning the requirements for (RQ1) and

the implementation of (RQ2) an expressive EoL pol-

icy vocabulary. Our proposed solution extends the

ODRL standard with an eol: vocabulary, enabling the

machine-interpretable speciﬁcation of deletion poli-

cies. The qualitative evaluation via an expert work-

shop (Section 4) provided initial validation, indicat-

ing that the identiﬁed requirements are relevant and

the proposed ODRL extension is perceived as a con-

ceptually sound, technically feasible, and potentially

impactful approach.

Building on this, we have shown that effective

EoL data management is essential for data trustees,

yet current policy languages such as ODRL lack

the semantic depth to specify detailed, machine-

interpretable EoL policies. This paper tackled this

issue by ﬁrst identifying the requirements for an

EoL policy vocabulary (RQ1), covering the why (ra-

tionale), how (method), what (data identiﬁcation),

when/where (context), and operational aspects of EoL

policies. We then proposed the eol: vocabulary,

an ODRL extension designed to meet these require-

WEBIST 2025 - 21st International Conference on Web Information Systems and Technologies

ments, thereby enabling the machine-interpretable

speciﬁcation of EoL policies (RQ2). Our qualita-

tive evaluation with experts validated the relevance of

these requirements and the conceptual soundness of

the ODRL extension, underscoring its potential to en-

hance compliance, trust, and overall data governance.

The primary contribution, therefore, is the for-

malization of EoL policy requirements tailored for

data trustees and a practical vocabulary to imple-

ment them. This approach facilitates more holis-

tic data lifecycle governance by rendering EoL poli-

cies explicit, machine-interpretable, and auditable.

While this work improves policy speciﬁcation, en-

suring technical enforcement in distributed systems

and establishing robust ecosystem governance remain

challenges. Future work should focus on reﬁning the

eol: vocabulary for data deletion, exploring mecha-

nisms for veriﬁable EoL execution, and developing

best practices for its integration within data spaces.

As another part of EoL data management involves

not only data deletion but also data retention, future

work could also include the development of a com-

plementary ODRL extension to specify retention poli-

cies. By promoting standardized, expressive policies

for the full scope of EoL data management, encom-

passing both deletion and retention, we aim to further

strengthen data governance and trust in data trustees.

REFERENCES

Bacco, M., Kocian, A., Chessa, S., Crivello, A., and Bar-

socchi, P. (2024). What are data spaces? systematic

survey and future outlook. Data in Brief, 57:110969.

Cantrell, G. and Runs Through, J. (2019). The Five Levels

of Data Destruction: A Paradigm for Introducing Data

Recovery in a Computer Science Course . In 2019

International Conference on Computational Science

and Computational Intelligence (CSCI), pages 133–

138. IEEE Computer Society.

Dam, T., Krimbacher, A., and Neumaier, S. (2023). Policy

patterns for usage control in data spaces.

Eitel, A., Jung, C., Brandst

adter, R., Hosseinzadeh, A.,

Bader, S., K

uhnle, C., Birnstill, P., Brost, G., Gall, M.,

Bruckner, F., Weißenberg, N., and Korth, B. (2021).

Usage control in the international data spaces.

European Commission (2016). Regulation (EU) 2016/679

of the European Parliament and of the Council of 27

april 2016 on the protection of natural persons with

regard to the processing of personal data and on the

free movement of such data, and repealing Directive

95/46/EC (General Data Protection Regulation).

European Commission (2022). European data governance

act.

European Committee for Standardization (2024). Trusted

data transaction.

Franklin, M., Halevy, A., and Maier, D. (2005). From

databases to dataspaces: a new abstraction for infor-

mation management. SIGMOD Rec., 34(4):27–33.

Gemein, O.-G., Hilberg, S. J., L

ahteenoja, V., and

Turpeinen, M. (2023). Reﬂections on the dga and data

intermediaries.

Ginart, A., Guan, M. Y., Valiant, G., and Zou, J. (2019).

Making ai forget you: Data deletion in machine learn-

ing.

Iannella, R. and Villata, S. (2018). ODRL information

model 2.2.

Lauf, F., Scheider, S., Friese, J., Kilz, S., Radic, M., and

Burmann, A. (2023). Exploring design character-

istics of data trustees in healthcare - taxonomy and

archetypes. In Proceedings of the 31st European Con-

ference on Information Systems (ECIS).

Lindner, M. and Straub, S. (2023). Datentreuh

anderschaft

status quo und entwicklungsperspektiven. Whitepa-

per, Begleitforschung Smarte Datenwirtschaft.

McKibben, W. B., Cade, R., Purgason, L. L., and and, E. W.

(2022). How to conduct a deductive content analy-

sis in counseling research. Counseling Outcome Re-

search and Evaluation, 13(2):156–168.

Otto, B. (2022). The evolution of data spaces. In Designing

data spaces: The ecosystem approach to competitive

advantage, pages 3–15. Springer International Pub-

lishing Cham.

Otto, B., Steinbuss, S., Teuscher, A., and Lohmann, S.

(2019). IDS Reference Architecture Model. Technical

report, International Data Spaces Association.

Otto, B., ten Hompel, M., and Wrobel, S., editors (2022).

Designing Data Spaces: The Ecosystem Approach to

Competitive Advantage. Springer Nature.

Puppis, M. (2019). Analyzing Talk and Text I: Qualitative

Content Analysis, pages 367–384. Springer Interna-

tional Publishing, Cham.

Reiberg, A., Appelt, D., Smole

n, A., and Kraemer, P.

(2023). Datentreuh

ander, datenvermittlungsdienste

und gaia-x. Whitepaper, Gaia-X Hub Deutschland.

Schinke, L., Hoppen, M., Atanasyan, A., Gong, X., Heinze,

F., Stollenwerk, K., and Roßmann, J. (2023). Trustful

data sharing in the forest-based sector - opportunities

and challenges for a data trustee. In VLDB Workshops.

Shaharudin, A., van Loenen, B., and Janssen, M. (2024).

Exploring the contributions of open data intermedi-

aries for a sustainable open data ecosystem. Data &

Policy.

Specht-Riemenschneider, L., Blankertz, A., Sierek, P.,

Schneider, R., Knapp, J., and Henne, T. (2021).

Die Datentreuhand: ein Beitrag zur Modellbildung

und rechtlichen Strukturierung zwecks Identiﬁzierung

der Regulierungserfordernisse f

ur Datentreuhand-

modelle. Number 6 Beilage.

Specht-Riemenschneider, L. and Kerber, W. (2022). De-

signing Data Trustees – A Purpose-Based Approach/

Datentreuh

ander – Ein probleml

osungsorientierter

Ansatz. Konrad-Adenauer-Stiftung e. V.

Stachon, M., M

oller, F., Guggenberger, T., Tomczyk, M.,

and Henning, J.-L. (2023). Understanding data trusts.

In Proceedings of the 31st European Conference on

Information Systems (ECIS).

Enhancing Data Governance in Data Trustees Through ODRL-Based End-of-Life Policies

Steinert, M. and Altendeitering, M. (2024). Data trustees:

A whitelisting approach for trusted data sharing. page

86–92. Association for Computing Machinery.

Steinert, M., Schleimer, A. M., Altendeitering, M., and

Hick, D. (2025). Designing data trustees: A proto-

type in the building sector. In Proceedings of the 11th

International Conference on Information Systems Se-

curity and Privacy - Volume 1, pages 157–166.

Steinert, M. and Tebernum, D. (2025). Questionnaire and

survey results: Design and technical requirements for

data trustees.

Tallon, P. P., Ramirez, R. V., and Short, J. E. (2013). The

information artifact in it governance: Toward a theory

of information governance. Journal of Management

Information Systems, 30(3):141–178.

Tebernum, D., Altendeitering, M., and Howar, F. (2021).

Derm: A reference model for data engineering. In

Proceedings of the 10th International Conference on

Data Science, Technology and Applications - DATA,

pages 165–175. INSTICC, SciTePress.

Tebernum, D., Altendeitering, M., and Howar, F. (2023). A

survey-based evaluation of the data engineering ma-

turity in practice. In Data Management Technologies

and Applications, pages 1–23, Cham. Springer Nature

Switzerland.

Tebernum, D. and Howar, F. (2023). Structuring the end

of the data life cycle. In Proceedings of the 12th In-

ternational Conference on Data Science, Technology

and Applications - DATA, pages 207–218. INSTICC,

SciTePress.

Tebernum, D. and Howar, F. (2025). Treating the end of

the data life cycle as a ﬁrst-class citizen in data engi-

neering. In Solutions and Technologies for Respon-

sible Digitalization, pages 237–252, Cham. Springer

Nature Switzerland.

Van Bussel, G. and Smit, N. (2014). Building a Green

Archiving Model: Archival Retention Levels, Infor-

mation Value Chain and Green Computing. In Pro-

ceedings of the 8th European Conference on IS Man-

agement and Evaluation (ECIME 2014), volume I,

pages 271–277. ACPI.

Wang, R. Y. and Strong, D. M. (1996). Beyond accuracy:

what data quality means to data consumers. J. Man-

age. Inf. Syst., 12(4):5–33.

APPENDIX

@pr ef i x odrl: <www . w3 . or g /ns / o drl /2 / > .

@pr ef i x eo l : < www . ex a m p le . com / odr l - e ol #> .

@pr ef i x rd f : < www . w3 . org / 1 9 9 9 / 02 /2 2 -r df - sy nt

a x- n s #> .

@pr ef i x rdfs: <www . w3 . or g / 2 00 0/ 0 1 / r df -s c h e m a

#> .

@pr ef i x skos: <www . w3 . or g / 2 00 4/ 0 2 / s k o s / cor e #

> .

@pr ef i x ow l : < www . w3 . org / 2 00 2/ 0 7/ owl # > .

@pr ef i x xs d : < www . w3 . org /2 0 01 / X ML S ch em a# > .

@pr ef i x dc t : <p url . o r g /dc / te r ms / > .

# P o l i c y - L ev el A tt r i b ut es ( RE Q9 )

eo l :s im u l a te d a rdf : P r o p e r t y , owl : D a t a

ty pe Pr o p e r t y , s k o s : C o n c ep t ;

rdf s :l a b e l " Si mul at e d " @ e n ;

sk os :d ef in it i o n " Ru l e e x e c ut io n is simu l

a ted if tr u e . " @en ;

rd f s: d om a in odr l: R u l e ;

rdf s :r a n g e xs d: b oo le an .

eo l : n o t if ic a tion a rdf :P r o p e r t y , owl : D a t a

ty pe Pr op e r t y , s k o s : C o n c e p t ;

rdf s :l a b e l " Noti fic a tion " @e n ;

sk os :d ef in it i o n " Ass i gn ee is not i fi e d

bef o re d a t a de l e ti o n if t r ue . " @ e n ;

rd f s: d om a in odr l: R u l e ;

rdf s :r a n g e xs d: b oo le an .

eo l :o pt I n a rdf : P r o p e r t y , owl : D a t a

ty pe Pr op e r t y , s k o s : C o n c e p t ;

rdf s :l a b e l " Op t- I n Req ui r ed " @ e n ;

sk os :d ef in it i o n " Ass i gn ee must

ex p l i ci tl y o pt- i n for de l et io n if

true . " @en ;

rd f s: d om a in odr l: R u l e ;

rdf s :r a n g e xs d: b oo le an .

eo l : s tr ic t a rd f: Pr op er ty , owl: D at a

ty pe Pr op e r t y , s k o s : C o n c e p t ;

rdf s :l a b e l " St ri c t " @en ;

sk os :d ef in it i o n " Au tom a t e d ex ec u ti on

only if a ll t erm s a re k nown ." @en ;

rd f s: d om a in odr l: R u l e ;

rdf s :r a n g e xs d: b oo le an .

# WHA T : Gr a nul a r D a t a Ide n t i fi c a ti o n ( R E Q 3 )

eol :L o c a tor a r dfs :C l a ss, o wl : Cl ass,

sk o s : C o n c e p t ;

rdf s :l a b e l " Loc a tor " @en ;

sk os :d ef in it i o n " Rep re s e n ts a det a i l ed d

at a a ss et l o c a t o r ." @en ;

sk o s: no t e " Des c r i be s a sset lo c a tio n s . "

@en .

eol: h a sLoc a t o r a rdf :P ro pe rt y,

ow l: Ob j e c t P ro pe rt y ;

rdf s :l a b e l " h a sL o c a t o r " @ e n ;

sk os :d ef in it i o n " Li nks a n As s et to its

Loc a t o r ." @en ;

rd f s: d om a in od r l: As s e t ;

rdf s :r a n g e eo l :L o c a tor .

# Ex a mp l e loc a t o r pr op e rt y

eol :l o c a to r SH A2 5 6 H a sh a r d f : P r o p e r t y , o w l:D a

ta ty p e P r o p e rt y , s ko s: Co nc ep t ;

rdf s :l a b e l " SH A2 5 6 H a sh Loc a tor " @en ;

sk os :d ef in it i o n " SH A2 5 6 con t en t ha sh of

the A sse t ." @en ;

rd f s: d om a in eol : Lo c a tor ;

rdf s :r a n g e xs d: st r i n g .

# WHY: R a t i on a le ( R E Q1 )

eol : Re a s o n a r df s :C l a ss, owl: C l a ss,

sk o s : C o n c e p t ;

rdf s :l a b e l " Re a son " @en ;

sk os :d ef in it i o n " Jus t if ic a t ion for a

Pol ic y , Rule, or Acti o n . " @ e n ;

sk o s: no t e " Pro v id e s co n te xt , e. g . , for

in f or mi n g a DPO . " @en .

eol: h a sRe a s o n a rdf :P ro pe rt y,

ow l: O b j e c tP ro p e r t y , sk os : C o n c e p t ;

rdf s :l a b e l " h a sRe a son " @en ;

sk os :d ef in it i o n " Li nks a P ol i cy , R u le,

or Act i on to i t s re a son . " @ e n ;

rd f s: d om a in odr l: R u l e ;

rdf s :r a n g e eol :Re a s o n .

# HOW: De l et i on Me tho d ( REQ2 )

eo l: d e s t r uc t i o n M et ho d a rdf :P ro pe rt y,

od rl :L ef t O p e r a nd, sk o s : C o n c ep t ;

rd fs :i sD e f i n e d B y e o l : ;

rdf s :l a b e l " Des tr uc t i o n Me t hod " @ e n ;

sk os :d ef in it i o n " Spe c i f ie s d at a d el e ti on

met h od or des tr uc t i o n lev e l . " @en ;

sk o s: no t e " E .g . , ’ r e cycle d ’, ’ delete d ’,

’ w iped ’ , ’ p h ysi c a lly de stro y e d ’, a n

a l go r it hm like Gutm a nn meth o d . " @ e n .

Listing 2: Formal Deﬁnition of the EoL ODRL Extension

Vocabulary in RDF/Turtle.

WEBIST 2025 - 21st International Conference on Web Information Systems and Technologies