(L)earning by Doing – »Blockchainifying« Life-long Volunteer

Engagement

Elisabeth Kapsammer

, Birgit Pröll

, Werner Retschitzegger

, Wieland Schwinger

, Philipp Starzer

Markus Weißenbek

, Johannes Schönböck

and Josef Altmann

Johannes Kepler University, Linz, Austria

Upper Austrian University of Applied Sciences, Hagenberg, Austria

Keywords:

Volunteer Management, Blockchain-Technology, Ontology, Knowledge Management.

Abstract:

Volunteering is a vital cornerstone of our society, ranging from social care to disaster relief, being supported

by a plethora of web-based volunteer management systems (VMS). These VMS primarily focus on centralized

task management within non-proﬁt organizations (NPOs), lacking means for volunteers to privately digitize

and exploit their engagement assets, e.g., task accomplishments or earned competences. This may decrease

engagement, since appreciation of volunteer work is the only reward available, and hinders the exploitation of

engagement assets between NPOs and beyond, e.g., the education or labor market.

We put volunteers in the middle of concern by investigating “how can engagement be digitized and exploited

in a life-long way”. First, based on a systematic identiﬁcation of requirements for a trustful digitization

and exploitation of engagement assets, a web-based volunteer ecosystem relying on emerging blockchain

technology is proposed. Second, for representing various kinds of engagement assets, a generic and adaptable

ontology is put forward. Third, for establishing trust across all stakeholders, a prototypical web application is

presented allowing to »blockchainify« life long volunteer engagement. Finally, the prototype applies semantic

web technologies to offer a machine readable form of engagement assets in terms of Linked Data (LD).

1 INTRODUCTION

Omnipresent and Manifold Volunteering. In times

of refugee and health-care crisis, volunteering is a vi-

tal cornerstone of our society, covering a broad part of

our life, from social care and disaster relief to cultural

activities. More than 10% of the world’s population

is already volunteering, topped by 23% in the EU,

and even more than 46% in Austria (UN Volunteers,

2018). Regarding Austria, 2,25 million formal vol-

unteers accomplish more than 400 million voluntary

hours a year, supplemented by more than 2,35 million

“informal” (i.e., NPO-independent) volunteers who

also accomplish 351 million hours, whereby at

least every second informal volunteer is engaged

formally, too (Holzer, 2017). Currently, new forms of

volunteering are emerging (Holzer, 2017), stretching

from (i) Patchwork Volunteers, being engaged in

different NPOs/life phases (e.g., from pathﬁnders to

senior help), over (ii) Engagement Hoppers, getting

active informal, i.e., NPO-independent, and ad-hoc

(e.g., disaster relief), to ﬁnally (iii) Crowd Volunteers

(e.g., open-source projects).

Awareness Deﬁcits about Engagements. These

engagements lay the basis for life-long learning

following the “Learning by Doing” principle. The

potential for experience-based acquisition of infor-

mal competences is a commonly agreed fact of all

volunteering domains (Deloitte, 2016). However, vol-

unteers are often unaware of their accomplishments

and achievements earned across their engagements

(e.g., accomplished tasks or gained competences)

(Livingstone, 2006). This prevents self-exploration

and personality development and hinders exploitation

of engagement assets beyond volunteering, e.g.,

education or labor market, being an invaluable

substitute for certain formal qualiﬁcations (Deloitte,

2016).

Volunteer Management Systems’ Focus Differs.

Current VMS focus either on centralized task man-

agement within NPOs or on coordination of informal

volunteering (Schönböck et al., 2016). Supporting

digital exploitation of engagement assets across

different volunteering forms, e.g., in terms of Linked

Kapsammer, E., Pröll, B., Retschitzegger, W., Schwinger, W., Starzer, P., Weißenbek, M., Schönböck, J. and Altmann, J.

(L)earning by Doing – »Blockchainifying« Life-long Volunteer Engagement.

DOI: 10.5220/0009372500670079

In Proceedings of the 22nd International Conference on Enterprise Information Systems (ICEIS 2020) - Volume 2, pages 67-79

ISBN: 978-989-758-423-7

Data (LD), is not an issue up to now, although

adequate IT-support is of prior importance from an

economic point of view and lies in the very own

interest of all stakeholders, i.e., NPOs, (informal)

help seekers, and volunteers (UN Volunteers, 2018).

Digital Exploitation of Life-long Engagement.

The goal of iVOLUNTEER is to put volunteers in

the middle of concern. According to the metaphor

»I am what I do«, volunteers should be enabled

to digitize engagement assets not only across the

wide spectrum of new volunteering forms, but also

exploit engagement assets beyond volunteering at

the education or labor market. The rational behind

is to strengthen the appreciation of voluntary en-

gagement, being the only reward available in this

domain. This would not only increase a volunteer’s

engagement motivation, but would also leverage the

importance of life-long learning, being beneﬁcial for

all stakeholders. As technological backbone ensuring

“trust” across all stakeholders, engagement assets are

»blockchainiﬁed«, allowing to irrefutably trace back

each single asset wrt. both, its content and its actual

existence. Furthermore, LD is utilized to exploit

engagement assets beyond the the iVOLUNTEER

ecosystem.

Structure of the Paper. After investigating related

work in Sec. 2, we lay out the requirements empha-

sizing the process of trustful engagement digitization

and exploitation based upon which we derive a con-

ceptual architecture for our digital volunteer ecosys-

tem in Sec. 3. Serving as a pivotal building block

for digitizing assets, Sec. 4 presents a generic and

adaptable ontology of engagement assets. Sect. 5

discusses the prototypical implementation, which is

based on (i) a permissioned blockchain and on (ii)

semantic web technologies to provide trustful and

machine interpretable data on a volunteer’s engage-

ment. In Sec. 6, a comparative evaluation of the

iVOLUNTEER prototype is conducted. Finally, Sec. 7

reports on lessons learned and critically reﬂects our

current system.

2 RELATED WORK

Related work is ﬁrst discussed from the broad per-

spective of managing personal data across differ-

ent application areas including volunteering, before

sticking to more closely-related approaches in the

area of digital badges for formal and informal learn-

ing. Finally, we investigate on the application of LD

and semantic web technologies in VMS.

Human-centric Personal Data Management. Cur-

rent management of personal data across domains

like social media, HRM or education is characterized

by organisation-centric data management (Allard

et al., 2017; Abiteboul et al., 2015; Markoulli et al.,

2017; Guidi et al., 2018), which is also prevalent

in the volunteering domain. Available systems

are designed as black-boxes, which can not be

exploited across the NPO’s borders in a trustworthy

and conﬁdent way, as encountered in the course

of our in-depth evaluation of 18 VMS on basis

of a reference model comprising more than 100

evaluation criteria in (Schönböck et al., 2016). Not

least since the emergence of the BC-paradigm (Kap-

sammer et al., 2018), recent research efforts focus on

re-empowering users to manage their personal data,

often referred to as human-centric data management

(Abiteboul et al., 2015), putting forward approaches

for decentralized social networks (Guidi et al., 2018;

Chao and Palanisamy, 2019), personal information

management (Zyskind et al., 2015; Sjöberg et al.,

2016) or digital badges (Araújo et al., 2017; Facey-

Shaw et al., 2017).Especially the area of digital

badges is closely related to the intentions followed by

iVOLUNTEER as digital badges are symbols that are

deﬁned and managed by an issuer, being recognized

inside a community (Araújo et al., 2017).

Digital Badges in Formal & Informal Learning.

Digital badges gain increasing interest in the area

of formal and informal learning for promoting

learner engagement, participation, motivation and

achievement (Facey-Shaw et al., 2017). Related

approaches for BC-based personal data management

in terms of digital badges can be found in the areas of

formal and informal learning, namely UZHBC (Uni-

versity of ZüricH BlockChain) (Gresch et al., 2019),

SPROOF (Brunner et al., 2018), BCE (Blockchain

for Education (Gräther et al., 2018), Blockcerts (MIT

Media Lab, 2019) and EICS (Education-Industry

Cooperative System) (Liu et al., 2018). Although they

use various kinds of mechanisms for representing

assets, little focus has been given up to now on

supporting a ﬂexible and ontological representation

of assets throughout their evolution as discussed in

detail in Sec. 6.

Linked Data and Semantic Web Technologies in

VMS. To the best of our knowledge, none of the

previously evaluated VMS (Schönböck et al., 2016)

describes their data in terms of LD to publish

machine readable data from different sources that

may be connected and queried through the use of

technologies associated such as RDF or SPARQL.

ICEIS 2020 - 22nd International Conference on Enterprise Information Systems

Since iVOLUNTEER focuses on the digitization of

a volunteer’s life-long engagements, acquired com-

petencies build a major pillar. Thus, we investi-

gated on competency proﬁle models in the areas of

HRM/eRecruitment and eLearning (cf., e.g., (Mi-

randa et al., 2017) for an overview). First of all, sev-

eral approaches employ simple semi-structured for-

malisms like the IEEE standard CEO/RCD (IEEE,

2007), or the HR-XML standard (HR Open Stan-

dards, 2017), aiming to act as a competency inter-

change format and not primarily as a basis for ma-

chine interpretable data. One step forward is the Sim-

ple Reusable Competency Map (Rifón, 2011) using

a directed acyclic graph to express different relation-

ship types like composition, equivalence or prerequi-

site. Dedicated ontology-based models like InLoc (In-

tegrating Learning Outcomes and Competences) (ICT

Standardisation Work Programme, 2013) provide a

basis for semantic reasoning, however, conceptualiza-

tions for the area of volunteering are lacking.

3 iVOLUNTEER AT A GLANCE

In order to give insight into our web-based digital vol-

unteer ecosystem iVOLUNTEER, a set of requirements

is identiﬁed, providing the rationale behind the con-

ceptual architecture of iVOLUNTEER presented fur-

ther on. Thereby, we followed the design science re-

search methodology (Hevner et al., 2004; vom Brocke

and Maedche, 2019), including an extensive require-

ments engineering phase together with our demon-

strators in the project (red cross and ﬁre brigade).

Based on that, we built a ﬁrst prototype, which is con-

tinuously evaluated and reﬁned, as is common in agile

project management settings.

3.1 Requirements

Requirements mainly stem from our goal of digiti-

zation of engagement assets, comprising the need

for overcoming scatteredness and diversity and the

demand for maintaining their evolution. In addition,

aiming at volunteer’s self exploitation of engagement

assets rises the need for achieving sovereignty and, at

the same time, calls for establishment of trust for any

stakeholder who gets assets transferred by a volunteer.

Overcoming Scatteredness & Diversity. Not least

because of the new forms of volunteering (Holzer,

2017), engagements of volunteers are manifold over

time, leading to the following requirements:

[REQ1.1] Engagement assets earned through various

volunteering work are scattered across data silos of

proprietary VMS at different NPOs, representing par-

tial views, only. Therefore, a global view on these

engagement assets is demanded, allowing to gain a

comprehensive basis for further exploitation.

[REQ1.2] Engagement assets are naturally diverse in

various aspects. Their level of detail may range from

simple engagement conﬁrmations, over detailed task

accomplishments to comprehensive achievements.

Furthermore, the evidence for asset earnings may

range from simple textual justiﬁcations to formal,

NPO-speciﬁc rules. To cope with these diversities

when establishing a global view, generic represen-

tation mechanisms are needed, e.g., LD, together

with means for conﬁguration and extensibility, to

incorporate the assets’ peculiarities.

Maintaining Evolution. As (L)earning-by-doing is

an evolutionary process, engagement assets need to

co-evolve, leading to the following requirements:

[REQ2.1] Engagement assets should not only be is-

sued once by NPOs or informal help seekers, but

must be maintained to reﬂect evolution history. Thus,

updates of already existing assets (e.g., increasing

a competences’ proﬁciency level), their withdrawal

(e.g., due to a missing refreshment training), or dep-

recation in case the assets’ status is no longer main-

tained by the issuer (e.g., if a volunteer resigns en-

gagement for the issuer) should be supported.

[REQ2.2] Engagement assets should be traceable

across their whole life-span comprising different

states and evolution of structure with respect to the

time, they became available, but also indicating the

assets’ validity start and possible end time.

Achieving Sovereignty. To counteract the prevalent

trend of centralized personal data storage in volun-

teering or HRM (Allard et al., 2017; Abiteboul et al.,

2015), volunteers should be empowered to achieve

sovereignty over their assets, leading to the following

requirements:

[REQ3.1] Engagement assets should be privately

storable by volunteers at an arbitrary location (e.g.,

local NAS) and it should be deﬁnable which assets to

store (e.g., tasks history, or certain awards).

[REQ3.2] Engagement assets, which are already

stored should be selectively transferable by volun-

teers to other stakeholders in our digital ecosystem,

like NPO’s, help seekers, or job recruiters, based

on common semantic web standards. Thus a proper

transfer format based on LD should be realized. This

is a prerequisite not only to obtain personally satisfy-

ing volunteering tasks compatible with competences,

but also for being able to claim, e.g., the possession

of a certain competence for job applications. Addi-

(L)earning by Doing – »Blockchainifying« Life-long Volunteer Engagement

tionally, in case the volunteer revokes the transfer

from an NPO, further maintenance of these assets by

the NPO (e.g., update of a competence’s proﬁciency

level) must be prohibited.

Establishing Trust. To empower volunteers with

sovereignty over their assets, establishing trust into

them across all stakeholders is crucial for their suc-

cessful exploitation. This is aggravated by the fact,

that sovereignty over the transfer of assets to certain

receivers entails their uncertainty about the actual ex-

istence of assets, since being claimed by the volunteer

themselves, leading to the following requirements:

[REQ4.1] Engagement assets of a volunteer should

be described through LD in a way providing a proper

basis for the receiver to gain trust in their content.

For example, evidence about their justiﬁcation, con-

text of emergence, topicality, issuer, and evolution

should be provided to further strengthen plausibility

of their emergence. However, it naturally lays in the

eyes of the beholders and their perspectives to trust

in the content of an asset, not least since the level of

trust heavily depends on the reputation of the issuer,

i.e., a well-known NPO might be more trustful than

an unknown informal help seeker.

[REQ4.2] Engagement assets should be transferable

by the volunteer such that trust in their actual exis-

tence, despite their transfers by the volunteers them-

selves, can be irrefutably established for receivers.

Thus, immutability of the asset’s complete evolution

and authenticity of its issuer must be guaranteed.

3.2 Conceptual Architecture

Based on the requirements, Fig. 1 shows the con-

ceptual architecture of our ecosystem iVOLUNTEER,

depicting four different usage scenarios [A-D].

Decentralized System Components. Since

iVOLUNTEER adheres to the principle of subsidiarity

and data sovereignty, which puts the volunteer in

the middle of concern, we rely on decentralized

system components. To deal with the isolated data

silos of current VMS, four independent components

are employed, comprising a PrivateAssetRepository

establishing a global view on assets [REQ1.1] within

the sole sovereignty of a volunteer [REQ3.1-3.2],

VolunteeringHubs to incorporate NPOs and informal

help seekers providing their partial views, Asset-

TransferHubs for the exchange of assets, and an

iVOLUNTEER Blockchain to establish trust across the

ecosystem.

VolunteeringHubs & PrivateAssetRepositories.

VolunteeringHubs cover VMS functionality like task

management or volunteer matchmaking and allow

for an experience-based acquisition of engagement

assets (cf. (Schönböck et al., 2018; Kapsammer

et al., 2017) for details) or generation thereof (e.g.,

competence derivation based on pre-deﬁned rules). In

contrast to existing VMS, volunteers that engage on

a VolunteeringHub (cf. Fig. 1 [A.1]), can download

[A.2] their issued [A.3] engagement assets into the

PrivateAssetRepository to establish a global view

from the VolunteeringHubs’ local views [REQ1.1 and

3.1] based on a generic engagement asset ontology

[REQ1.2] (cf. Sec. 4). To exploit engagement assets

for obtaining suitable and personally satisfying tasks,

volunteers can selectively provide assets to other

VolunteeringHubs (i.e., publish [B.1] / unpublish

[B.2]) [REQ3.2], whereby their existence can be

veriﬁed [B.3] [REQ4.2]. If an engagement asset

is unpublished from a VolunteeringHub, deprecat-

ing [B.4] those assets prevent future maintenance

through that hub. Data which is explicitly published

on volunteering hubs may also be provided in form

of LD to provide a machine readable format.

AssetTransferHubs. In order to connect existing

VMS, which do not need classical VMS functionality

of VolunteeringHubs to our ecosystem as well,

AssetTransferHubs may be employed. These allow to

incorporate engagement assets, which were acquired

outside of our ecosystem and were digitized within

external VMS. Appropriate interfaces for asset import

[C.1] (basing on LD - cf. Sec. 5) are provided to-

gether with means for the »blockchainiﬁcation« [C.2]

of these external assets (cf. Sec. 5), again enabling

in a subsequent step their download [C.3] by volun-

teers. AssetTransferHubs also allow to connect third

parties like educational or recruitment institutions,

by enabling volunteers to publish/unpublish ([D.1]

and [D.2]) assets at these hubs solely for veriﬁcation

purposes through registered third parties [D.3] and

[D.4]. Overall, AssetTransferHubs are in fact a

form of "lightweight" VolunteeringHubs allowing the

trustful exchange of already existing assets, coming

either from outside or being transferred to parties

beyond the volunteering domain.

iVOLUNTEERBlockchain. To establish a layer

of trust [REQ4.1-4.2] and to support later ex-

ploitation, engagement assets, no matter if gen-

erated at a VolunteeringHub or imported at an

AssetTransferHub are »blockchainiﬁed«. Due to

cost reduction and performance improvements com-

pared to public blockchains, a private, permissioned

ICEIS 2020 - 22nd International Conference on Enterprise Information Systems

Figure 1: Conceptual Architecture of iVOLUNTEER - Usage Scenarios.

iVOLUNTEERBlockchain is used to record all en-

gagement assets [A.3] (for privacy reasons encoded

as hash-values), allowing to irrefutably trace back

each single asset (cf. Sec. 5) An asset’s existence,

immutability and authenticity can be veriﬁed [B.3]

by both, VolunteeringHubs and AssetTransferHubs

[REQ4.2]. Thus, the iVOLUNTEERBlockchain forms

the integral backbone of trust for the global view, be-

ing maintained by the volunteers themselves.

As pivotal building block for digitizing and ex-

ploiting assets as outlined above, a conceptual model

for engagement assets is presented in the next section.

4 ENGAGEMENT ASSET

ONTOLOGY

The following ontology formalizes volunteering con-

cepts and relationships in between. It serves as (i) de-

sign rationale for PrivateAssetRepositories, (ii) tem-

plate for VolunteeringHubs to manage assets, (iii) ex-

change format for AssetTransferHubs to connect to

third parties and (iv) data structure being hashed and

»blockchainyﬁed« in the iVOLUNTEERBlockchain.

The ontology is depicted in Fig. 2 as UML class di-

agram, colors additionally grouping closely related

concepts. Next, we reason about the ontology’s

generic core and its means for adaptability followed

by a discussion of asset earnings and their types.

4.1 Generic Core and Adaptability

Genericity as Basis for Diversity. Based on the

methaphor »I am what I do«, a basis for deriving

the common core concepts has been found in the

area of linguistic research, notably in the prominent

work of Vendler about the aspectual classiﬁcation

of verbs (Vendler, 1957), as well as by considering

well-known upper ontologies like SUMO (Niles and

Pease, 2001) or DOLCE (Gangemi et al., 2002).

Following (Vendler, 1957), the core of generic con-

cepts of our ontology builds upon the bold-framed

classes shown in the middle of Fig. 2, expressing the

fact, that Engagement in Activities running through

certain States may lead to Accomplishments and

various Achievements, justiﬁed by some Evidence.

Although our engagement asset ontology focuses

on volunteering, special attention has been paid to

provide a core of generic concepts being applicable to

a much broader range of application areas. Proposing

a generic core for describing engagement and its

justiﬁed recognition by others contributes also to the

research efforts for integrating formal and informal

learning (Livingstone, 2006), especially emphasizing

transferable competencies and the open badges

initiative (Facey-Shaw et al., 2017).

Adaptability - United in Diversity. Building upon

this generic core, several adaptability means are pro-

vided for uniting these assets while preserving their

diversity. Adaptability is not only supported at a tech-

nological level, e.g., by using a graph-based NoSQL

storage system (cf. Sec. 5), but especially considered

at the conceptual level. Thus core concepts of our on-

tology are complemented with a type hierarchy (Type)

to support conﬁgurability and extensibility. This en-

ables white-box reuse, i.e., subtyping to extend the

pre-deﬁned type taxonomies, thereby coping with pe-

culiarities of assets issued by, e.g., different NPOs.

Black-box reuse is supported through explicit exten-

sion points, allowing to enhance and conﬁgure the on-

tology by specifying, e.g., further properties for types

(Property) or conﬁguring the state transition of ac-

(L)earning by Doing – »Blockchainifying« Life-long Volunteer Engagement

{complete, distinct}

Lecture

{incomplete, distinct}

◀plays

{incomplete, disjoint}

{complete,

disjoint}

{incomplete, disjoint}

ACHIEVEMENT

Externally

EarnedAsset

OriginOfAsset

◀belongsTo

»I AM« (Achievement)

»What I DO« (Accomplishment)

{complete, disjoint}

engagesIn▶

leadsTo▶

offers▶

0..1

evolves

Blockchain

Entry

- hash

- combinedID

- signature

- timestamp

- deprecated

combinedId :=

hash(hubID + assetID)

signature := sign(hubID +

timestamp, privateKey)

hashedInto▶

KindOfAchievement

/self-issues▶

- assetID

- timestamp

- validStartTime

- validEndTime

pre

State

publishedAt▶

{abstract}

iVolunteer

SystemComponent

PrivateAsset

Repository

VolunteeringHub /

AssetTransferHub

{singleton}

iVolunteer

Blockchain

{abstract}

iVolunteer

Role

iVolunteer

User

NPO /

HelpSeeker

Engagement

AssetIssuer

Volunteer

0..1

plays▶

{incomplete, overlapping}

0..1

registeredAt▶

issues▶

owns▶

0..1

issuedAt▶

offeredAt▶

logs▶

◀basedOn

{singleton}

iVolunteerPortal

EVIDENCE

1..*

justifiedBy▶

AssetType

{abstract}

ActivityType

STATE

1..*

0..1

manifestsIn▶

runsThrough▶

Education

Task

{incomplete, disjoint}

Engagement

{abstract}

StateType

1..*

pre

State

post

State

BC-Manifestation

Configuration

0..1

Transition

Configuration

has▶

0..1

pre

State

post

State

hasLifeCycle▶

{abstract}

EvidenceType

Textual

Algorithmic

{incomplete,

disjoint}

has▶

Confidence

Level

0..1

relieability

definedBy▶

{incomplete, disjoint}

Certificate

Statistics

Monetary

Incentive

Personal

Appreciation

Reward

Questionaire

Feedback

Freetext

{incomplete,

disjoint}

{incomplete,

disjoint}

KindOf

Appreciation

{abstract}

Competence

Status

Visibility

{complete,

disjoint}

0..1

explicatedBy▶

Grade

Position

Personal

Social

Action

Method

{incomplete, disjoint}

Proficiency

Level

Knowledge

Ability

Skill

definedBy▶

{incomplete,

disjoint}

KindOfStatus

Assigned

Delegated

Canceled

Finished

Applied

Tendency

Variation

Relative

Standing

{incomplete,

disjoint}

Kudos

Voucher

Bonus

{incomplete,

disjoint}

Diploma

Badge

Trophy

1..*

0..1

Ordinal

Remote

OnSite

Individual

Team

Physical

Virtual

Locality

Virtuality

{incomplete,

overlapping}

Individuality

KindOfCoreCompetence

Structuredness

Descriptive

Measure

KindOf

Justification

{abstract}

Internally

EarnedAsset

subscribes▶

registers▶

basedOn▶

Award

Property

{abstract}

Type

extendedBy ▶

{abstract}

AchievementType

has▶

Honor

StateType

Training

activityProvider

activityPerformer

{abstract}

EngagementAsset

- generateHash()

{incomplete,

overlapping}

◀stores

post

State

AchievementType

{abstract}

AccomplishmentType

has▶

FormOf

Explication

ACCOMPLISHMENT

AccomplishmentType

ActivityType

iVolunteer

User

Roles

iVolunteer

System

Components

iVolunteer

Engagement

Assets

iVolunteer

ACTIVITY

Figure 2: Engagement Asset Ontology.

tivity types (TransitionConfiguration). Finally, the

concepts of our ontology can be selectively instan-

tiated, thus ensuring, although being more compre-

hensive, also compatibility with the wide-spread open

badge initiative (Facey-Shaw et al., 2017).

4.2 Asset Earning

Trust in Asset Content. The scenario of asset

earning is explicitly reﬂected by our ontology

(cf. upper part of Fig. 2), being a cornerstone for

achieving trust in an asset’s content [REQ4.1].

Thereby, EngagementAssets are primarily earned

as a result of accomplished activities forming

InternallyEarnedAssets. Activities are of-

fered by ActivityProviders (e.g., NPOs or help

seekers) at certain VolunteeringHubs for which

ActivityPerformers, e.g., volunteers, may engage.

These assets are justiﬁed by an appropriate Evidence

(e.g., textual or rule-based, eventually based on other

assets) together with an optional ConfidenceLevel

and are provided by the EngagementAssetIssuer

(e.g., NPO, help seeker, volunteer colleague, or a

VolunteeringHub using an asset generation rule like a

competency derivation; cf. Fig 5).

Trust in Asset Existence and Sovereignty. For

every InternallyEarnedAsset a new Blockchain-

Entry is generated within the iVolunteerBlockchain

[REQ4.2]. Assets can be downloaded by the vol-

unteer into the PrivateAssetRepository [REQ1.1]

and [REQ3.1-3.2] and further on published at

other VolunteeringHubs for getting adequately en-

gaged again or transferred to third parties via

AssetTransferHubs for further exploitation by means

of, e.g., a job application process. A registry of all

of the created system components (blockchain and

hubs) as well as the registration of users together

with their PrivateAssetRepositories is maintained

by the iVolunteerPortal. This component not only

provides a lookup mechanism for all registered users,

informing them, e.g., about new asset earning possi-

bilities, but also to build-up cross-component func-

tionality, like the provision of NPO-independent core

competence ontologies or asset generation rules for

all VolunteeringHubs.

ICEIS 2020 - 22nd International Conference on Enterprise Information Systems

Evolution of Assets. In order to cope with the evo-

lutionary nature of engagement assets [REQ2.1-2.2]

(e.g., increase of a competence’s proﬁciency level)

the pre- and post-states of EngagementAssets are

connected by a reﬂexive association. Consequently,

EngagementAssets are considered to be immutable,

meaning that every time an evolution takes place, a

new EngagementAsset is created and connected to

its predecessor. This design decision resembles the

functionality of temporal databases (Böhlen et al.,

2017), thereby establishing the pre-requisite for a

life-long digitization and historical exploitation of

volunteer engagement.

Externally Earned Assets. Besides internally earned

assets, we consider also ExternallyEarnedAssets,

where volunteers themselves act as self-issuer of as-

sets earned outside of the iVOLUNTEER ecosystem,

e.g., a driver’s licence or some education diploma.

This is not only a means to overcome the “cold start

problem” for newly registered volunteers, but also for

potential external VMS or third-parties like educa-

tional institutions, not yet connected to our ecosys-

tem through AssetTransferHubs. Externally earned

assets may also be published to a VolunteeringHub,

who may decide on an “approval” by issuing an ac-

cording InternallyEarnedAsset.

4.3 Asset Types

In the following, our generic core concepts of

Activity, State, Accomplishment, and Achievement

are further discussed and augmented with type

taxonomies, reﬂecting common concepts of the

volunteering domain (cf. lower part of Fig. 2).

ActivityType & StateType Taxonomy. The ratio-

nale behind the ActivityType taxonomy was to ex-

plicitly distinguish between assets earned through for-

mal, i.e., educational learning activities in terms of

Training and informal ones, i.e., carrying out volun-

teering Tasks, which may lead to the acquisition of

formal and informal Competences (cf. below). Tasks

are further categorized along exemplary criteria most

relevant for volunteering work, covering aspects like

locality, virtuality, and team-orientation.

Basing on a large body of literature focusing

on the conceptualization of activities (Goschnick

et al., 2010) and their inter-dependencies in terms

of workﬂows (Heidari et al., 2013; Zur Muehlen

and Indulska, 2010), the life-cycle of activity types

is represented in terms of StateTypes, connecting

pre- and post-states using a reﬂexive association and

according exemplary sub-classes covering typical

states of volunteering tasks.

Accomplishment & AchievementType Taxonomy.

Accomplishments are manifestations of certain ac-

tivity states which could serve as assets (e.g., for

computing statistics about a volunteer’s willingness

to apply for tasks or just about the number of accom-

plished tasks), thereby representing the »Do-part«

of the »I am what I do«-metaphor, thus having

no associated type taxonomy. Complementary,

for representing the »I am-part«, a comprehensive

AchievementType taxonomy is provided to cover a

broad range of diverse engagement assets usually

being a consequence of accomplishments. In the

simplest case, Statistics may be drawn based

on other assets, like means of descriptive statistics

as Tendency of, e.g, increasing engagement or

RelativeStanding wrt. other volunteers. All further

kinds of achievements (Feedback and Reward) bear

more or less subjectivism in mind, some times also

paired with domain-speciﬁcity. Feedback may nat-

urally range from simple “likes” or Kudos (Matteis,

2015) to Freetext or be more structured based on

Ordinal ratings or Questionnaires. In contrast to the

general concept of feedback, Rewards which can be

optionally explicated by Certificates, e.g., Badges

(Facey-Shaw et al., 2017) or Trophies, are more

concrete. According to their focus they can be further

specialized into MonetaryIncentive, e.g., Voucher or

Bonus, being the exception in volunteering, and more

predominant PersonalAppreciation. Depending on

its visibility to others, one may further split into a rise

in one’s Status, covering mechanisms like Grade,

Position, Award, or Honor and the acquisition of

Competences.

Competence Type Taxonomy. Competences repre-

sent another cornerstone of our ontology, since be-

ing highly valuable for volunteers and also wrt. the

overall aim of supporting life-long, formal and infor-

mal learning. Our ontology is ﬁrst of all inspired by

the European Qualiﬁcations Framework

as well as

by existing work in the area of competence ontolo-

gies, and eRecruitement (Miranda et al., 2017; Rezgui

et al., 2012). Adhering to this work, we distinguish

Knowledge, Ability, and Skill to cover qualiﬁcations

at different ProficiencyLevels in education, training,

and especially practical tasks. According to the kind

of competence which can be acquired, especially in an

informal context like volunteering, we adhere to the

prominent categorization of Erpenbeck into Personal,

Social, Action, and Method competences (Erpenbeck,

http://www.cedefop.europa.eu/de/events-and-

projects/projects/european-qualiﬁcations-framework-eqf

(L)earning by Doing – »Blockchainifying« Life-long Volunteer Engagement



-�











--------------------------------------------,

 

 



 

















 

  1

 







O·o











 





















 � FABRIC

 

 











 

 

 

   







 E







 



 





  

































Figure 3: iVOLUNTEER Architecture.

2010) providing a ﬁrst, generic frame for integrating

distinct kinds of (domain-speciﬁc) competencies ac-

quirable, e.g., at certain NPOs. To avoid the “cold

start problem”, i.e., all possible competencies have to

be deﬁned when ﬁrst using iVOLUNTEER, the DISCO

project

provides a dictionary with more than 100.000

competency deﬁnitions.

5 PROOF-OF-CONCEPT

PROTOTYPE

This section presents the iVOLUNTEER proof-of-

concept prototype based on the requirements and the

conceptual architecture outlined in Sec. 3 as well as

the engagement asset ontology presented in Sec. 4.

The architecture of the iVOLUNTEER-prototype

builds upon the inter-working of three layers (cf.

Fig. 3), namely Trust Layer, Service Layer and

Client Layer, ensuring a decoupled and decentralized

architecture. This allows independent components

whereby communication between them bases on the

REST paradigm (Fielding, 2000).

Trust Layer. The Trust Layer comprises the

iVOLUNTEER-Blockchain (BC), immutably stor-

ing obfuscated replicas of EngagementAssets, i.e.,

BlockchainEntries. As a technological basis, the

modular, extensible and open source platform Hyper-

ledger Fabric (HLF) has been used, allowing to op-

erate a permissioned BC (Androulaki et al., 2018).

HLF is chosen since (i) as a third generation BC, it

provides for a general-purpose, distributed applica-

tion development platform, characterized by a high

level of conﬁgurability, especially regarding consen-

sus and storage mechanisms, (ii) it has been already

applied in real world settings by major companies,

http://disco-tools.eu

iVol:Achievement

iVol:Emergency

DriverExamination

iVol:VehicleInstruction

iVol:EmergencyDrivers

LicenseEvidence

iVol:Evidence

iVol:Volunteer

iVol:MaxMuster

iVol:Engagement

AssetIssuer

iVol:FireBrigade

iVol:Engagement iVol:State

iVol:Vehicle

InstructionCompleted

iVol:Activity

iVol:Vehicle

Instruction

iVol:Accomplishment

iVol:Emergency

DriversLicense

iVol:basedOn

rdf:type

iVol:belongsTo

rdf:type

iVol:issued

rdf:type

iVol:manifestsIn

iVol:engagesIn

rdf:type

iVol:runsThrough

iVol:offers

iVol:activity

rdf:type rdf:type

rdf:type

iVol:justifiedBy

iVol:issued

iVol:belongsTo

Figure 4: Exemplary RDF Graph of Engagement Assets.

and (iii) its support and maintenance is guaranteed

by IBM. The rationale behind using a private, per-

missioned BC is to minimize transaction costs and re-

sponse time and to avoid potential limitations of trans-

action size, which may occur in public BCs. The HLF

implementation of the iVOLUNTEER-Blockchain en-

compasses the Veriﬁer and Trustiﬁer component, pro-

viding REST endpoints for reading from and writ-

ing to the BC (i.e., create, deprecate, and verify),

triggering their respective smart contract implemen-

tations, which will be described in the following.

To protect the privacy of volunteers,

their EngagementAssets are hashed (stored as

BlockchainEntry.hash, cf. Fig. 2), being further

used as unique ID throughout the BC, enabling fast

retrieval by comparison with the calculated hash of

an asset and at the same time allowing to verify the

existence of the asset (cf. verify method of Veriﬁer).

To further guarantee and verify the issuer’s authen-

ticity, asymmetric cryptography is employed by

signing each entry (cf. BlockchainEntry.signature),

calculated beforehand by the issuer of each asset

through digitally signing the concatenation of their

respective public key and a timestamp with the

private key of the issuer using DSA. Including the

timestamp leads to different signatures each time an

entry is created, thus precluding the signature’s reuse.

In order to allow for veriﬁcation beyond simple

existence, veriﬁcation of an asset’s history is needed,

requiring a linkage between the individual evolution

steps belonging together. This linkage is main-

tained through the BlockchainEntry.combinedID,

calculated as a hash of the issuer’s ID and the

EngagementAsset.assetID, thus mitigating pos-

sibilities to query information about the issuer.

The combination of BlockchainEntry.hash and

BlockchainEntry.combinedID allows for the ver-

iﬁcation of an asset’s (i) topicality, (ii) temporal

dependencies, by further exploiting the provided

timestamp, (iii) completeness of its past evolution,

by being able to query all entries for an asset and

ﬁnally, (iv) future maintenance, using the dedicated

property BlockchainEntry.depricate indicating the

termination of an asset’s evolution.

ICEIS 2020 - 22nd International Conference on Enterprise Information Systems

Figure 5: iVOLUNTEER Web Application.

Service Layer. The Service Layer allows for (i) vol-

unteer engagement through VolunteeringHubs and (ii)

incorporates external VMS and external stakeholders

by providing AssetTransferHubs.

For VolunteeringHubs, the Java Spring Boot

based web server implementation of the central Vol-

unteeringHubService component focuses on conﬁg-

uration and management of activities, assets, en-

gagements and their evolutions. For life-cycle def-

inition of engagements, the open source workﬂow

engine Activiti

is utilized, allowing for graphical

deﬁnition and customization thereof using the Ac-

tiviti designer available as Eclipse plug-in. For

each VolunteeringHub, a VolunteeringHubDatabase

based on the graph-based NoSQL system neo4j

stores the local views on EngagementAssets earned

by volunteers on a certain hub. The rationale be-

hind using Neo4j respectively a graph database is

the storage of LD, which they are primed for (Lu

and Holubová, 2019). Fig. 4 shows an exemplary

RDF graph (A-Box) typed to our conceptual ontol-

ogy (T-Box) representing the earning of a so-called

EmergencyDriversLicense Achievement by a volun-

teer on the volunteering hub of the Red Cross. Addi-

tionally, it also shows the preconditions necessary to

gain this achievement, e.g., the successful completion

of a vehicle instruction as well as passing an emer-

gency driver examination. Changes in the A-Box may

be downloaded to a volunteer’s PrivateAssetReposi-

tory (see below) to provide a global view by employ-

ing a REST endpoint. Additionally, the evolution of

the RDF graph is also stored in the blockchain (cf.

create and deprecate REST endpoints in Fig. 3).

The AssetTransferHubs, implemented again as

https://spring.io/projects/spring-boot

https://www.activiti.org/

https://neo4j.com

Java Spring Boot web server application, allows

for integration of external VMS and third party

applications through their import/export REST

endpoints, thus, enabling usage of externally earned

assets within iVOLUNTEER and vice versa. For

importing data, a light-weight approach is currently

followed, meaning that the provided data needs to

correspond to the JSON-LD format allowing to link

the internal RDF graph to the newly generated graph

from the external JSON-LD data without any need

for mappings. For exporting data, the according RDF

graph is serialized in terms of JSON-LD to provide

a machine readable format. Last, the PortalService

enables registration/deregistration of volunteers and

VolunteeringHubs, establishing the global Registry of

the iVolunteerPortal.

Client Layer. Finally, the Client Layer comprises ac-

cess to the functionalities provided by iVOLUNTEER

for its users being it volunteers, NPOs, help seekers

or other third parties. Foremost, it provides volun-

teers the VolunteerClientApp, enabling them to com-

municate with the hubs, thereby providing means for

engaging in volunteering activities as well as trans-

ferring their assets from the hubs to their PrivateAs-

setRepository (i.e., download assets to PrivateAsse-

tRepository) and vice versa (i.e., publish assets to a

hub). Fig. 5 shows screenshots of the current pro-

totype visualizing a volunteer’s earned engagement

assets stored in the PrivateAssetRepository and a re-

cruiter’s view on the AssetTransferHub.

6 COMPARATIVE EVALUATION

In the following, related approaches for BC-based

personal data management in terms of digital badges

(L)earning by Doing – »Blockchainifying« Life-long Volunteer Engagement

in the areas of formal and informal learning are

investigated, namely UZHBC (University of ZüricH

BlockChain) (Gresch et al., 2019), SPROOF (Brun-

ner et al., 2018), BCE (Blockchain for Education

(Gräther et al., 2018), Blockcerts (MIT Media Lab,

2019) and EICS (Education-Industry Cooperative

System) (Liu et al., 2018). These approaches are

of speciﬁc interest as they are (i) using different

kinds of mechanisms for representing their assets,

ranging from unstructured, schema-less to structured,

schema-based ones, (ii) tackling evolution aspects to

a certain extent, (iii) going at least partly beyond sim-

ple issuing and veriﬁcation of assets and ﬁnally, (iv)

providing for a mixture of both, permissionless and

permissioned BC implementations. Structured along

a set of criteria being derived from our requirements

(cf. Sec. 3), the evaluation results are summarized in

Table 1 and brieﬂy discussed on a per-requirement

basis [REQ1-REQ4] in the following, also especially

emphasizing on the commonalities and differences to

iVOLUNTEER.

Overcoming Scatteredness and Diversity. Regard-

ing our ﬁrst category of requirements, scatteredness

and diversity is not explicitly focused on by the

evaluated approaches, i.e., establishing a global view

on assets (i.e., digital badges) [REQ1.1] stemming

from various sources as targeted by iVOLUNTEER

is not an issue. The mechanisms for representing

diverse assets [REQ1.2] are manifold, ranging from

simply processing PDF-documents (UZHBC), to

schema-less asset descriptions (SPROOF) and differ-

ent schema-based ones, being partly based on Mozilla

Open Badges (BCE and Blockcerts). Neither of them

provides an engagement asset model, and thus a tax-

onomy of assets, with a conﬁgurable and extensible

type hierarchy as provided by iVOLUNTEER.

Maintaining Evolution. Maintenance of asset

evolution [REQ2.1] is supported in different, often

quite restricted forms. In particular, three sys-

tems support withdrawal of already issued assets,

i.e., revising a previously stated claim (SPROOF,

Blockcerts and ECIS), updates thereof are only

supported by EICS, whereas deprecating assets is

unique to iVOLUNTEER. Regarding traceability of

evolutions [REQ2.2], all approaches allow to capture

an assets’ availability time, and, with the exception

of UZHBC, also its validity time. Tracing back the

evolution states of assets is supported by ECIS and

iVOLUNTEER, only. Speciﬁcally, iVOLUNTEER also

addresses different schema versions during asset

evolution.

Achieving Sovereignty. To achieve sovereignty,

all systems except ECIS employ external private

storage for assets [REQ3.1], using the BC, as in

iVOLUNTEER, for storing their hash values. External

storage technologies used are manifold, ranging from

distributed (P2P-)ﬁle systems to speciﬁc groupware,

whereas iVOLUNTEER bases on the, in the meantime

well established, NoSQL paradigm, allowing for

convenient storage of different asset versions result-

ing from both, structural- and state-based evolution.

Finally, although all systems allow for a selective

transfer of received assets, none of them provide

means to revoke this transfer (in contrast to the

revokation of an asset), as available in iVOLUNTEER

[REQ3.2], thus preventing an assets further maintain-

ability.

Establishing Trust. Regarding trust in an as-

sets’ content [REQ4.1], support is restricted in al-

most all systems to the provision of textual evidence

and URIs to external justiﬁcations only. Similar to

iVOLUNTEER, BCE envisions to provide algorithmic

evidence by means of chain code but misses a struc-

tured representation of the emergence of assets based

on certain accomplishments and/or achievements.

For establishing trust in an assets’ existence

[REQ4.2], the majority bases on the public BCs

Bitcoin (Blockcerts) and Ethereum (UZHBC,

SPROOF, BCE), only EICS employs, analogous to

iVOLUNTEER, the permissioned BC HLF. BC-entries

can be issued in all systems, except SPROOF, by

privileged users, only, whereas receiving assets is

destined to registered users in UZHBC, SPROOF

and iVOLUNTEER. Authenticity of the asset issuer

can be veriﬁed by all systems applying asymmetric

cryptography, except UZHBC - which, due to its

schemaless representation, also lacks ability to verify

validity. Beyond, only EICS and iVOLUNTEER

provide means for establishing trust in the topicality

of an asset throughout its evolution. With respect to

completeness of an asset, SPROOF allows to verify

asset bundles, whereas iVOLUNTEER allows to verify

completeness of an assets’ evolution states.

7 LESSONS LEARNED AND

FUTURE WORK

In the following, lessons learned from the employ-

ment of BCs while opening up to LD in our digital

ecosystems as well as future work are discussed,

thereby explicitly considering issues being also

valuable to domains beyond volunteering.

ICEIS 2020 - 22nd International Conference on Enterprise Information Systems

Table 1: Comparison of Related Approaches.

Approaches UZHBC SPROOF BCE Blockcerts EICS

Criteria

[Gresch et al., 2019] [Brunner et al., 2018] [Gräther et al., 2018] blockcerts.org, 2019 [Liu et al., 2018]

[REQ1.1]

    



schemaless

implicit schema explicit schema explicit schema explicit schema explicit schema

PDF n.a. Open Badges based Open Badges based propriatary

inspired by existing

ontologies & standards

incl. Open Badges

Taxonomy  

   

Configurability      

Extensibility

 

~ ~

 

Updateable

    



Withdrawable 

    

Deprecatable      

State Evolution

     

Schema Evolution 

    

Availability Time      

Validity Time

     

External    

 

Technology

file system

IPFS

(P2P filesystem)

BSCW

(groupware)

mobile wallet app n.a. NoSQL (Neo4j)

Selectivity      

Revokability

    

revoke maintainability

Issuer

privileged users

everybody privileged users privileged users privileged users privileged users

Receipient

everybody

everybody registered users registered users registered users registered users

Evidence

textual textual textual + URI textual + URI textual textual + algorithmic

Ethereum Ethereum Ethereum Bitcoin

HLF HLF

public

public public public private private

Authenticity      

Validity      

Topicality

    



Completeness 

Asset Bundle

  

State Evolution

although Open Badges allows, per definition, for extensibility, it is not fully exploited by these approaches

iVolunteer

BC Platform

Representation

Asset[REQ1.2]

[REQ3.2]

[REQ4.1]

[REQ4.2]

Establishing

Trust

Traceability

Maintaining

Evolution

[REQ2.1]

[REQ2.2]

[REQ3.1]

Achieving

Sovereignty

Trust in

AssetContent

Trust in

Asset

Existence

Overcoming

Scatteredness

& Diversity

Global View

Maintainability

Transfer

Private Store

BC as Battering Ram to Break Walled Silos.

Today’s application landscape in social media and

HRM, which bases on data silos and walled gardens,

could be turned upside down by empowering users to

get back control over their data and employing BC as

a means for establishing trust. Although we tried to

take a ﬁrst step in this direction with iVOLUNTEER,

further research is needed to investigate on possible

use cases, technological requirements and borders of

applicability for different application domains.

BC as Backbone for Transparent Asset Gener-

ation. To provide trust in the content of an asset

and its evolution, a transparent asset generation and

evolution process needs to be provided by the BC. In

particular, a library of asset generation rules realized

as smart contracts should be provided, allowing

NPOs to reﬂect their “individual culture of appreci-

ation”, like rules for award or competency earning,

in a transparent way through the BC. This could also

lead to the emergence of cross-NPO asset generation

rules, e.g., the ﬁre brigade considers qualiﬁcations

earned at the red cross as pre-requisite for certain

tasks, and at the very end to some standardized pro-

cedures across different informal learning domains,

resulting in a “homogenization” of assets and their

evolution.

BC as Mechanism for Ensuring Assets’ Existence.

Although a BC can ensure the existence of assets, it

can not entail trust in the actual content of an asset

nor prevent fake assets. Despite of comprehensively

representing an asset’s context of emergence through

LD, there is no doubt that the issuer’s reputation

is the crucial impact factor. Due to openess of our

ecosystem where every registered user is allowed

to act in the role of a volunteer or help seeker and

since it is uncertain if consensus mechanisms of

BCs may always prohibit fake assets, it always lays

in the eye of the beholder to assess the plausibility

of the provided assets. These are without a doubt

some of the most crucial vulnerabilities of our

system, although the special culture prevalent in

the volunteering domain may reduce these risks

to some extent. These are without a doubt some

of the most crucial vulnerabilities of our system,

although the special culture prevalent in the volun-

teering domain may reduce these risks to some extent.

BC as Means for Joint Trust Establishment. One

crucial issue when employing a private, permissioned

BC like HLF is to decide about the distribution

and replication of system components to establish

the required amount of trust. Therefore, the BC

network’s components, the committing peers, as

well as the ordering service have to be hosted

across different trustworthy organizations, preferably

with different intentions like the national ministry of

social affairs or trustworthy NGOs like the Red Cross.

LD as Enabler for Digitizing & Exploiting Fur-

ther Assets. Leveraging our digital ecosystem further

beyond the volunteering domain, it would be valu-

able to allow e.g., educational institutions (providing,

e.g., qualiﬁcation certiﬁcates), companies (providing,

e.g., job references) or governments (providing, e.g.,

a driving license) to issue assets. Besides these possi-

bilities for digitization, exploitation could be further

(L)earning by Doing – »Blockchainifying« Life-long Volunteer Engagement

enhanced by providing functionality for recruiters to

upload job proﬁles and carry out matchmaking.

LD as Common Ground to Share Assets with

Third Parties. Especially sharing engagement as-

sets outside of the iVOLUNTEER ecosystem requires a

mechanism of information manifestation, wrapping a

volunteer’s engagement assets in a machine-readable

format, without any loss of semantics. LD serves

as valuable cornerstone for volunteers to exploit their

engagement assets not only within iVOLUNTEER but

also for external parties like job recruiters.

LD as a basis for ”full integration” of External As-

sets. Importing externally earned assets is currently,

as already mentioned, supported by a light-weight,

i.e., link-based approach, only. Although this allows

the creation of a volunteer’s global view on all earned

assets, the potential typing to a different T-Box hin-

ders further internal processing, e.g., to employ this

data for semantic matchmaking when looking for suit-

able new tasks. Thus, it would be beneﬁcial to pro-

vide some kind of ”full integration” of external assets

by migrating the external data to our engagement as-

set ontology, which would enable their further inter-

nal processing.

REFERENCES

Abiteboul, S., André, B., and Kaplan, D. (2015). Managing

your digital life with a personal information manage-

ment system. CACM, 58(5):32–35.

Allard, T., Bouadi, T., Duguépéroux, J., and Sans, V.

(2017). From self-data to self-preferences: Towards

preference elicitation in personal information man-

agement systems. In Proc of PAP’17, pages 10–16.

Androulaki, E., Barger, A., Bortnikov, V., Cachin, C.,

Christidis, K., De Caro, A., Enyeart, D., Ferris, C.,

Laventman, G., Manevich, Y., et al. (2018). Hyper-

ledger Fabric: A Distributed Operating System for

Permissioned Blockchains. In Proc. of EuroSys’18,

pages 1–15.

Araújo, I., Santos, C., Pedro, L., and Batista, J. (2017). Dig-

ital badges on education: past, present and future. In

Proc. of EUSN’19, pages 27–35.

Böhlen, M. H., Dignös, A., Gamper, J., and Jensen, C. S.

(2017). Temporal data management–an overview. In

Proc. of eBISS’17, pages 51–83.

Brunner, C., Knirsch, F., and Engel, D. (2018). SPROOF:

A platform for issuing and verifying documents in a

public blockchain. Technical report, FH Salzburg.

Chao, L. and Palanisamy, B. (2019). Incentivized

blockchain-based social media platforms: A case

study of steemit. In Proc. of WebSci’19, page 10.

Deloitte (2016). Building leadership skills through volun-

teerism. www2.deloitte.com/content/dam/Deloitte/us/

Documents/us-deloitte-impact-survey.pdf. [accessed:

2019-09-24].

Erpenbeck, J. (2010). Conspiracies and competences. In

Changing Cultures in Higher Education, pages 299–

312. Springer.

Facey-Shaw, L., Specht, M., Van Rosmalen, P., Brner, D.,

and Bartley-Bryan, J. (2017). Educational Functions

and Design of Badge Systems: A Conceptual Litera-

ture Review. IEEE TLT, 11(4):536–544.

Fielding, R. T. (2000). Architectural Styles and the Design

of Network-based Software Architectures. PhD thesis,

University of California, Irvine.

Gangemi, A., Guarino, N., Masolo, C., Oltramari, A., and

Schneider, L. (2002). Sweetening ontologies with

DOLCE. In Proc. of EKAW’02, pages 166–181.

Goschnick, S., Sonenberg, L., and Balbo, S. (2010). A com-

posite task meta-model as a reference model. In Proc.

of INTERACT’10, pages 26–38.

Gräther, W., Kolvenbach, S., Ruland, R., Schütte, J., Torres,

C., and Wendland, F. (2018). Blockchain for educa-

tion: lifelong learning passport. In Proc of ERCIM

Blockchain Workshop’18.

Gresch, J., Rodrigues, B., Scheid, E., Kanhere, S. S., and

Stiller, B. (2019). The Proposal of a Blockchain-

Based Architecture for Transparent Certiﬁcate Han-

dling. In Proc. of BIS-WS’18, pages 185–196.

Guidi, B., Conti, M., Passarella, A., and Ricci, L. (2018).

Managing social contents in decentralized online so-

cial networks: A survey. Online Social Networks and

Media, 7:12–29.

Heidari, F., Loucopoulos, P., Brazier, F., and Barjis, J.

(2013). A meta-meta-model for seven business pro-

cess modeling languages. In Proc. of CBI’13, pages

216–221.

Hevner, A. R., March, S. T., Park, J., and Ram, S. (2004).

Design science in information systems research. MIS

quarterly, pages 75–105.

Holzer, M. (2017). VOLUNTEERING IN AUS-

TRIA. http://www.freiwilligenweb.at/sites/default/

ﬁles/Volunteering\%20in\%20Austria\_1.pdf. [ac-

cessed: 2019-09-24].

HR Open Standards (2017). https://hropenstandards.org/

download-the-standards/. [accessed on 2019-09-24].

ICT Standardisation Work Programme (2013). Integrating

Learning Outcomes and Competences. http://www.

cetis.org.uk/inloc/Home. [accessed on 2019-09-24].

IEEE (2007). IEEE Standard for Learning Technology-Data

Model for Reusable Competency Deﬁnitions. IEEE

Std 1484.20.1-2007, 1484:1–2007.

Kapsammer, E. et al. (2017). iVOLUNTEER: A Digital

Ecosystem for Life-Long Volunteering. In Proc. of

iiWAS’17, pages 366–372. ACM.

Kapsammer, E., Pröll, B., Retschitzegger, W., Schwinger,

W., Weißenbek, M., and Schönböck, J. (2018). The

blockchain muddle: A bird’s-eye view on blockchain

surveys. In In Proc. of iiWAS’18, pages 370–374.

Liu, Q., Guan, Q., Yang, X., Zhu, H., Green, G., and Yin,

S. (2018). Education-Industry Cooperative System

Based on Blockchain. In Proc. of HotICN’18, pages

207–211.

Livingstone, D. (2006). Informal Learning: Conceptual

Distinctions and Preleminary Findings. The Informal

Education Reader, 249:203–227.

ICEIS 2020 - 22nd International Conference on Enterprise Information Systems

Lu, J. and Holubová, I. (2019). Multi-model databases: A

new journey to handle the variety of data. ACM Com-

put. Surv., 52(3):55:1–55:38.

Markoulli, M. P., Lee, C. I., Byington, E., and Felps, W. A.

(2017). Mapping human resource management: Re-

viewing the ﬁeld and charting future directions. Hu-

man Resource Management Review, 27(3):367 – 396.

Matteis, L. (2015). Kudos: A peer-to-peer dis-

cussion system based on social voting.

http://citeseerx.ist.psu.edu/viewdoc/download?doi=

10.1.1.700.9643\&rep=rep1\&type=pdf. [accessed:

2019-09-24].

Miranda, S., Orciuoli, F., Loia, V., and Sampson, D. (2017).

An ontology-based model for competence manage-

ment. DKE, 107:51–66.

MIT Media Lab (2019). Blockcerts: The open standard for

blockchain credentials. https://www.blockcerts.org.

[accessed: 2019-09-24].

Niles, I. and Pease, A. (2001). Towards a standard upper

ontology. In Proc. of FOIS’01, pages 2–9.

Rezgui, K., Mhiri, H., and Ghedira, K. (2012). Competency

models: A review of initiatives. In Proc. of ICALT’12,

pages 141–142.

Rifón, L. A. (2011). Standardising competency deﬁnitions

for engineering education. In IEEE Global Engineer-

ing Education Conference (EDUCON), pages 52–58.

Schönböck, J., Altmann, J., Kapsammer, E., Kimmerstor-

fer, E., Pröll, B., Retschitzegger, W., and Schwinger,

W. (2018). A Semantic MatchMaking Framework

for Volunteering MarketPlaces. In Proc. of World-

CIST’18, pages 701–711.

Schönböck, J., Raab, M., Altmann, J., Kapsammer,

E., Kusel, A., Pröll, B., Retschitzegger, W., and

Schwinger, W. (2016). A survey on volunteer man-

agement systems. In Proc. of HICSS’16, pages 767–

776.

Sjöberg, M., Chen, H.-H., Floréen, P., Koskela, M.,

Kuikkaniemi, K., Lehtiniemi, T., and Peltonen, J.

(2016). Digital me: Controlling and making sense of

my digital footprint. In Proc. of WS on Symbiotic In-

teraction, pages 155–167.

UN Volunteers (2018). State of

the World’s Volunteerism Report.

https://www.unv.org/sites/default/ﬁles/UNV_SWVR_

2018_English_WEB.pdf. [accessed: 2019-09-24].

Vendler, Z. (1957). Verbs and Times. Philosophical Review,

66(2):143–160.

vom Brocke, J. and Maedche, A. (2019). The DSR grid: six

core dimensions for effectively planning and commu-

nicating design science research projects. Electronic

Markets.

Zur Muehlen, M. and Indulska, M. (2010). Modeling

languages for business processes and business rules:

A representational analysis. Information systems,

35(4):379–390.

Zyskind, G., Nathan, O., and Pentland, A. (2015). De-

centralizing privacy: Using blockchain to protect per-

sonal data. In Proc. of SPW’15, pages 180–184.

(L)earning by Doing – »Blockchainifying« Life-long Volunteer Engagement