Blockchainifying« Life-long Volunteer Engagement - SciTePress

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

Elisabeth Kapsammer1, Birgit Pröll1, Werner Retschitzegger1, Wieland Schwinger1, Philipp Starzer1,Markus Weißenbek1, Johannes Schönböck2 and Josef Altmann2

1Johannes Kepler University, Linz, Austria2Upper 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 supportedby a plethora of web-based volunteer management systems (VMS). These VMS primarily focus on centralizedtask management within non-profit organizations (NPOs), lacking means for volunteers to privately digitizeand exploit their engagement assets, e.g., task accomplishments or earned competences. This may decreaseengagement, since appreciation of volunteer work is the only reward available, and hinders the exploitation ofengagement 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 exploitedin a life-long way”. First, based on a systematic identification of requirements for a trustful digitizationand exploitation of engagement assets, a web-based volunteer ecosystem relying on emerging blockchaintechnology is proposed. Second, for representing various kinds of engagement assets, a generic and adaptableontology is put forward. Third, for establishing trust across all stakeholders, a prototypical web application ispresented allowing to »blockchainify« life long volunteer engagement. Finally, the prototype applies semanticweb technologies to offer a machine readable form of engagement assets in terms of Linked Data (LD).

1 INTRODUCTION

Omnipresent and Manifold Volunteering. In timesof refugee and health-care crisis, volunteering is a vi-tal cornerstone of our society, covering a broad part ofour life, from social care and disaster relief to culturalactivities. More than 10% of the world’s populationis 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 voluntaryhours a year, supplemented by more than 2,35 million“informal” (i.e., NPO-independent) volunteers whoalso accomplish 351 million hours, whereby atleast every second informal volunteer is engagedformally, too (Holzer, 2017). Currently, new forms ofvolunteering are emerging (Holzer, 2017), stretchingfrom (i) Patchwork Volunteers, being engaged indifferent NPOs/life phases (e.g., from pathfinders tosenior help), over (ii) Engagement Hoppers, gettingactive informal, i.e., NPO-independent, and ad-hoc(e.g., disaster relief), to finally (iii) Crowd Volunteers(e.g., open-source projects).

Awareness Deficits about Engagements. Theseengagements lay the basis for life-long learningfollowing the “Learning by Doing” principle. Thepotential for experience-based acquisition of infor-mal competences is a commonly agreed fact of allvolunteering domains (Deloitte, 2016). However, vol-unteers are often unaware of their accomplishmentsand achievements earned across their engagements(e.g., accomplished tasks or gained competences)(Livingstone, 2006). This prevents self-explorationand personality development and hinders exploitationof engagement assets beyond volunteering, e.g.,education or labor market, being an invaluablesubstitute for certain formal qualifications (Deloitte,2016).

Volunteer Management Systems’ Focus Differs.Current VMS focus either on centralized task man-agement within NPOs or on coordination of informalvolunteering (Schönböck et al., 2016). Supportingdigital exploitation of engagement assets acrossdifferent 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/0009372500670079In Proceedings of the 22nd International Conference on Enterprise Information Systems (ICEIS 2020) - Volume 2, pages 67-79ISBN: 978-989-758-423-7Copyright c© 2020 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

67

Data (LD), is not an issue up to now, althoughadequate IT-support is of prior importance from aneconomic point of view and lies in the very owninterest 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 inthe middle of concern. According to the metaphor»I am what I do«, volunteers should be enabledto digitize engagement assets not only across thewide spectrum of new volunteering forms, but alsoexploit engagement assets beyond volunteering atthe education or labor market. The rational behindis to strengthen the appreciation of voluntary en-gagement, being the only reward available in thisdomain. This would not only increase a volunteer’sengagement motivation, but would also leverage theimportance of life-long learning, being beneficial forall stakeholders. As technological backbone ensuring“trust” across all stakeholders, engagement assets are»blockchainified«, allowing to irrefutably trace backeach single asset wrt. both, its content and its actualexistence. Furthermore, LD is utilized to exploitengagement assets beyond the the iVOLUNTEERecosystem.

Structure of the Paper. After investigating relatedwork in Sec. 2, we lay out the requirements empha-sizing the process of trustful engagement digitizationand exploitation based upon which we derive a con-ceptual architecture for our digital volunteer ecosys-tem in Sec. 3. Serving as a pivotal building blockfor digitizing assets, Sec. 4 presents a generic andadaptable ontology of engagement assets. Sect. 5discusses the prototypical implementation, which isbased on (i) a permissioned blockchain and on (ii)semantic web technologies to provide trustful andmachine interpretable data on a volunteer’s engage-ment. In Sec. 6, a comparative evaluation of theiVOLUNTEER prototype is conducted. Finally, Sec. 7reports on lessons learned and critically reflects ourcurrent system.

2 RELATED WORK

Related work is first discussed from the broad per-spective of managing personal data across differ-ent application areas including volunteering, beforesticking to more closely-related approaches in thearea of digital badges for formal and informal learn-ing. Finally, we investigate on the application of LDand semantic web technologies in VMS.

Human-centric Personal Data Management. Cur-rent management of personal data across domainslike social media, HRM or education is characterizedby organisation-centric data management (Allardet al., 2017; Abiteboul et al., 2015; Markoulli et al.,2017; Guidi et al., 2018), which is also prevalentin the volunteering domain. Available systemsare designed as black-boxes, which can not beexploited across the NPO’s borders in a trustworthyand confident way, as encountered in the courseof our in-depth evaluation of 18 VMS on basisof a reference model comprising more than 100evaluation criteria in (Schönböck et al., 2016). Notleast since the emergence of the BC-paradigm (Kap-sammer et al., 2018), recent research efforts focus onre-empowering users to manage their personal data,often referred to as human-centric data management(Abiteboul et al., 2015), putting forward approachesfor decentralized social networks (Guidi et al., 2018;Chao and Palanisamy, 2019), personal informationmanagement (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 digitalbadges is closely related to the intentions followed byiVOLUNTEER as digital badges are symbols that aredefined and managed by an issuer, being recognizedinside a community (Araújo et al., 2017).

Digital Badges in Formal & Informal Learning.Digital badges gain increasing interest in the areaof formal and informal learning for promotinglearner engagement, participation, motivation andachievement (Facey-Shaw et al., 2017). Relatedapproaches for BC-based personal data managementin terms of digital badges can be found in the areas offormal and informal learning, namely UZHBC (Uni-versity of ZüricH BlockChain) (Gresch et al., 2019),SPROOF (Brunner et al., 2018), BCE (Blockchainfor Education (Gräther et al., 2018), Blockcerts (MITMedia Lab, 2019) and EICS (Education-IndustryCooperative System) (Liu et al., 2018). Although theyuse various kinds of mechanisms for representingassets, little focus has been given up to now onsupporting a flexible and ontological representationof assets throughout their evolution as discussed indetail in Sec. 6.

Linked Data and Semantic Web Technologies inVMS. To the best of our knowledge, none of thepreviously evaluated VMS (Schönböck et al., 2016)describes their data in terms of LD to publishmachine readable data from different sources thatmay be connected and queried through the use oftechnologies associated such as RDF or SPARQL.

ICEIS 2020 - 22nd International Conference on Enterprise Information Systems

68

Since iVOLUNTEER focuses on the digitization ofa volunteer’s life-long engagements, acquired com-petencies build a major pillar. Thus, we investi-gated on competency profile models in the areas ofHRM/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) usinga 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) (ICTStandardisation Work Programme, 2013) provide abasis 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 requirementsis identified, 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 Brockeand Maedche, 2019), including an extensive require-ments engineering phase together with our demon-strators in the project (red cross and fire brigade).Based on that, we built a first prototype, which is con-tinuously evaluated and refined, as is common in agileproject management settings.

3.1 Requirements

Requirements mainly stem from our goal of digiti-zation of engagement assets, comprising the needfor overcoming scatteredness and diversity and thedemand for maintaining their evolution. In addition,aiming at volunteer’s self exploitation of engagementassets rises the need for achieving sovereignty and, atthe same time, calls for establishment of trust for anystakeholder who gets assets transferred by a volunteer.

Overcoming Scatteredness & Diversity. Not leastbecause of the new forms of volunteering (Holzer,2017), engagements of volunteers are manifold overtime, leading to the following requirements:[REQ1.1] Engagement assets earned through variousvolunteering work are scattered across data silos of

proprietary VMS at different NPOs, representing par-tial views, only. Therefore, a global view on theseengagement assets is demanded, allowing to gain acomprehensive basis for further exploitation.[REQ1.2] Engagement assets are naturally diverse invarious aspects. Their level of detail may range fromsimple engagement confirmations, over detailed taskaccomplishments to comprehensive achievements.Furthermore, the evidence for asset earnings mayrange from simple textual justifications to formal,NPO-specific rules. To cope with these diversitieswhen establishing a global view, generic represen-tation mechanisms are needed, e.g., LD, togetherwith means for configuration and extensibility, toincorporate the assets’ peculiarities.

Maintaining Evolution. As (L)earning-by-doing isan evolutionary process, engagement assets need toco-evolve, leading to the following requirements:[REQ2.1] Engagement assets should not only be is-sued once by NPOs or informal help seekers, butmust be maintained to reflect evolution history. Thus,updates of already existing assets (e.g., increasinga competences’ proficiency 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 traceableacross their whole life-span comprising differentstates and evolution of structure with respect to thetime, they became available, but also indicating theassets’ validity start and possible end time.

Achieving Sovereignty. To counteract the prevalenttrend of centralized personal data storage in volun-teering or HRM (Allard et al., 2017; Abiteboul et al.,2015), volunteers should be empowered to achievesovereignty over their assets, leading to the followingrequirements:[REQ3.1] Engagement assets should be privatelystorable by volunteers at an arbitrary location (e.g.,local NAS) and it should be definable which assets tostore (e.g., tasks history, or certain awards).[REQ3.2] Engagement assets, which are alreadystored should be selectively transferable by volun-teers to other stakeholders in our digital ecosystem,like NPO’s, help seekers, or job recruiters, basedon common semantic web standards. Thus a propertransfer format based on LD should be realized. Thisis a prerequisite not only to obtain personally satisfy-ing volunteering tasks compatible with competences,but also for being able to claim, e.g., the possessionof a certain competence for job applications. Addi-

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

69

tionally, in case the volunteer revokes the transferfrom an NPO, further maintenance of these assets bythe NPO (e.g., update of a competence’s proficiencylevel) must be prohibited.

Establishing Trust. To empower volunteers withsovereignty over their assets, establishing trust intothem across all stakeholders is crucial for their suc-cessful exploitation. This is aggravated by the fact,that sovereignty over the transfer of assets to certainreceivers entails their uncertainty about the actual ex-istence of assets, since being claimed by the volunteerthemselves, leading to the following requirements:[REQ4.1] Engagement assets of a volunteer shouldbe described through LD in a way providing a properbasis for the receiver to gain trust in their content.For example, evidence about their justification, con-text of emergence, topicality, issuer, and evolutionshould be provided to further strengthen plausibilityof their emergence. However, it naturally lays in theeyes of the beholders and their perspectives to trustin the content of an asset, not least since the level oftrust heavily depends on the reputation of the issuer,i.e., a well-known NPO might be more trustful thanan unknown informal help seeker.[REQ4.2] Engagement assets should be transferableby 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 evolutionand 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. SinceiVOLUNTEER adheres to the principle of subsidiarityand data sovereignty, which puts the volunteer inthe middle of concern, we rely on decentralizedsystem components. To deal with the isolated datasilos of current VMS, four independent componentsare employed, comprising a PrivateAssetRepositoryestablishing a global view on assets [REQ1.1] withinthe sole sovereignty of a volunteer [REQ3.1-3.2],VolunteeringHubs to incorporate NPOs and informalhelp seekers providing their partial views, Asset-TransferHubs for the exchange of assets, and aniVOLUNTEER Blockchain to establish trust across theecosystem.

VolunteeringHubs & PrivateAssetRepositories.VolunteeringHubs cover VMS functionality like taskmanagement or volunteer matchmaking and allowfor an experience-based acquisition of engagementassets (cf. (Schönböck et al., 2018; Kapsammeret al., 2017) for details) or generation thereof (e.g.,competence derivation based on pre-defined rules). Incontrast to existing VMS, volunteers that engage ona VolunteeringHub (cf. Fig. 1 [A.1]), can download[A.2] their issued [A.3] engagement assets into thePrivateAssetRepository to establish a global viewfrom the VolunteeringHubs’ local views [REQ1.1 and3.1] based on a generic engagement asset ontology[REQ1.2] (cf. Sec. 4). To exploit engagement assetsfor obtaining suitable and personally satisfying tasks,volunteers can selectively provide assets to otherVolunteeringHubs (i.e., publish [B.1] / unpublish[B.2]) [REQ3.2], whereby their existence can beverified [B.3] [REQ4.2]. If an engagement assetis unpublished from a VolunteeringHub, deprecat-ing [B.4] those assets prevent future maintenancethrough that hub. Data which is explicitly publishedon volunteering hubs may also be provided in formof LD to provide a machine readable format.

AssetTransferHubs. In order to connect existingVMS, which do not need classical VMS functionalityof VolunteeringHubs to our ecosystem as well,AssetTransferHubs may be employed. These allow toincorporate engagement assets, which were acquiredoutside of our ecosystem and were digitized withinexternal VMS. Appropriate interfaces for asset import[C.1] (basing on LD - cf. Sec. 5) are provided to-gether with means for the »blockchainification« [C.2]of these external assets (cf. Sec. 5), again enablingin a subsequent step their download [C.3] by volun-teers. AssetTransferHubs also allow to connect thirdparties like educational or recruitment institutions,by enabling volunteers to publish/unpublish ([D.1]and [D.2]) assets at these hubs solely for verificationpurposes through registered third parties [D.3] and[D.4]. Overall, AssetTransferHubs are in fact aform of "lightweight" VolunteeringHubs allowing thetrustful exchange of already existing assets, comingeither from outside or being transferred to partiesbeyond the volunteering domain.

iVOLUNTEERBlockchain. To establish a layerof trust [REQ4.1-4.2] and to support later ex-ploitation, engagement assets, no matter if gen-erated at a VolunteeringHub or imported at anAssetTransferHub are »blockchainified«. Due tocost reduction and performance improvements com-pared to public blockchains, a private, permissioned


70

A B

C D

Figure 1: Conceptual Architecture of iVOLUNTEER - Usage Scenarios.

iVOLUNTEERBlockchain is used to record all en-gagement assets [A.3] (for privacy reasons encodedas hash-values), allowing to irrefutably trace backeach single asset (cf. Sec. 5) An asset’s existence,immutability and authenticity can be verified [B.3]by both, VolunteeringHubs and AssetTransferHubs[REQ4.2]. Thus, the iVOLUNTEERBlockchain formsthe 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 modelfor engagement assets is presented in the next section.

4 ENGAGEMENT ASSETONTOLOGY

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 tothird parties and (iv) data structure being hashed and»blockchainyfied« in the iVOLUNTEERBlockchain.The ontology is depicted in Fig. 2 as UML class di-agram, colors additionally grouping closely relatedconcepts. Next, we reason about the ontology’sgeneric core and its means for adaptability followedby a discussion of asset earnings and their types.

4.1 Generic Core and Adaptability

Genericity as Basis for Diversity. Based on themethaphor »I am what I do«, a basis for derivingthe common core concepts has been found in thearea of linguistic research, notably in the prominent

work of Vendler about the aspectual classificationof verbs (Vendler, 1957), as well as by consideringwell-known upper ontologies like SUMO (Niles andPease, 2001) or DOLCE (Gangemi et al., 2002).Following (Vendler, 1957), the core of generic con-cepts of our ontology builds upon the bold-framedclasses shown in the middle of Fig. 2, expressing thefact, that Engagement in Activities running throughcertain States may lead to Accomplishments andvarious Achievements, justified by some Evidence.Although our engagement asset ontology focuseson volunteering, special attention has been paid toprovide a core of generic concepts being applicable toa much broader range of application areas. Proposinga generic core for describing engagement and itsjustified recognition by others contributes also to theresearch efforts for integrating formal and informallearning (Livingstone, 2006), especially emphasizingtransferable competencies and the open badgesinitiative (Facey-Shaw et al., 2017).

Adaptability - United in Diversity. Building uponthis generic core, several adaptability means are pro-vided for uniting these assets while preserving theirdiversity. Adaptability is not only supported at a tech-nological level, e.g., by using a graph-based NoSQLstorage system (cf. Sec. 5), but especially consideredat the conceptual level. Thus core concepts of our on-tology are complemented with a type hierarchy (Type)to support configurability and extensibility. This en-ables white-box reuse, i.e., subtyping to extend thepre-defined 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 configure the on-tology by specifying, e.g., further properties for types(Property) or configuring the state transition of ac-


71

{complete, distinct}

Lecture

{incomplete, distinct}

◀plays

{incomplete, disjoint}

{complete, disjoint}


**

ACHIEVEMENT

ExternallyEarnedAsset

OriginOfAsset

1

*◀belongsTo

»I AM« (Achievement)»What I DO« (Accomplishment) {complete, disjoint}

**

engagesIn▶

leadsTo▶

offers▶

*

*

*

0..1evolves

*

BlockchainEntry

- hash- combinedID- signature- timestamp- deprecatedcombinedId :=

hash(hubID + assetID)signature := sign(hubID + timestamp, privateKey)

1

1

hashedInto▶

KindOfAchievement

*

1

/self-issues▶

- assetID- timestamp- validStartTime- validEndTime

preState

*

1

publ

ishe

dAt▶

{abstract}iVolunteer

SystemComponent

PrivateAssetRepository

VolunteeringHub /AssetTransferHub

{singleton}iVolunteerBlockchain

{abstract}iVolunteer

Role

iVolunteerUser

NPO /HelpSeeker

EngagementAssetIssuerVolunteer

0..1 *

plays▶

{incomplete, overlapping}

0..1

0..1registeredAt▶

1

*issues▶

*

*

1

*

1 1owns▶

*1

*

0..1

issu

edA

t▶

offe

redA

t▶

logs▶

** ◀basedOn

{singleton}iVolunteerPortal

EVIDENCE1..*1justifiedBy▶

AssetType

{abstract}ActivityType

STATE1..*

1

0..1

0..1

manifestsIn▶ runsThrough▶

Education Task


Engagement

{abstract}StateType

1..*1 *

preState

*postState

1

*

1

*BC-ManifestationConfiguration

0..1

1

TransitionConfiguration

has▶

0..1

0..1

preState

postState

hasLifeCycle▶

{abstract}EvidenceType

TextualAlgorithmic


11

*has▶

ConfidenceLevel

0..1

1

relieabilitydefinedB

y▶


CertificateStatistics

MonetaryIncentive

PersonalAppreciation

Reward

Questionaire

Feedback

Freetext

{incomplete,disjoint}


KindOfAppreciation

{abstract}CompetenceStatus

Visibility {complete, disjoint}

1 0..1explicatedBy▶

Grade Position Personal Social Action Method

{incomplete, disjoint} ProficiencyLevel

KnowledgeAbilitySkill

*1 *

*1 1definedBy▶{incomplete,

disjoint}KindOfStatus

AssignedDelegated

Canceled

Finished

Applied

Tendency

Variation

RelativeStanding


Kudos

VoucherBonus


DiplomaBadgeTrophy

1..*

0..1Ordinal

RemoteOnSite

IndividualTeam

Physical

Virtual

Locality

Virtuality

{incomplete, overlapping}Individuality

KindOfCoreCompetence

Stru

ctur

edne

ss

Des

crip

tive

Mea

sure

Kin

dOf

Just

ifica

tion{abstract}

InternallyEarnedAsset

*

1

subscribes▶

1

*registers▶

*

*

basedOn▶

Award

Property{abstract}Type 1 *

extendedBy ▶

{abstract}AchievementType

1

*has▶

Honor

StateType

Training

activityProvider

activityPerform

er

{abstract}EngagementAsset

- generateHash()

{incomplete, overlapping}

◀st

ores

postState*

*

AchievementType{abstract}

AccomplishmentType

1

*has▶

has▶

For

mO

fE

xplic

atio

n

ACCOMPLISHMENT

AccomplishmentType

ActivityType

iVolunteerUserRoles

iVolunteerSystem

Components

iVolunteerEngagement

Assets

iVolunteer

ACTIVITY

1

Figure 2: Engagement Asset Ontology.

tivity types (TransitionConfiguration). Finally, theconcepts of our ontology can be selectively instan-tiated, thus ensuring, although being more compre-hensive, also compatibility with the wide-spread openbadge initiative (Facey-Shaw et al., 2017).

4.2 Asset Earning

Trust in Asset Content. The scenario of assetearning is explicitly reflected by our ontology(cf. upper part of Fig. 2), being a cornerstone forachieving trust in an asset’s content [REQ4.1].Thereby, EngagementAssets are primarily earnedas a result of accomplished activities formingInternallyEarnedAssets. Activities are of-fered by ActivityProviders (e.g., NPOs or helpseekers) at certain VolunteeringHubs for whichActivityPerformers, e.g., volunteers, may engage.These assets are justified by an appropriate Evidence(e.g., textual or rule-based, eventually based on otherassets) together with an optional ConfidenceLeveland are provided by the EngagementAssetIssuer(e.g., NPO, help seeker, volunteer colleague, or a

VolunteeringHub using an asset generation rule like acompetency derivation; cf. Fig 5).

Trust in Asset Existence and Sovereignty. Forevery 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 atother VolunteeringHubs for getting adequately en-gaged again or transferred to third parties viaAssetTransferHubs for further exploitation by meansof, e.g., a job application process. A registry of allof the created system components (blockchain andhubs) as well as the registration of users togetherwith their PrivateAssetRepositories is maintainedby the iVolunteerPortal. This component not onlyprovides 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 corecompetence ontologies or asset generation rules forall VolunteeringHubs.


72

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 proficiency level)the pre- and post-states of EngagementAssets areconnected by a reflexive association. Consequently,EngagementAssets are considered to be immutable,meaning that every time an evolution takes place, anew EngagementAsset is created and connected toits predecessor. This design decision resembles thefunctionality of temporal databases (Böhlen et al.,2017), thereby establishing the pre-requisite for alife-long digitization and historical exploitation ofvolunteer engagement.

Externally Earned Assets. Besides internally earnedassets, 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 startproblem” for newly registered volunteers, but also forpotential external VMS or third-parties like educa-tional institutions, not yet connected to our ecosys-tem through AssetTransferHubs. Externally earnedassets 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 ofActivity, State, Accomplishment, and Achievementare further discussed and augmented with typetaxonomies, reflecting common concepts of thevolunteering 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 ofTraining and informal ones, i.e., carrying out volun-teering Tasks, which may lead to the acquisition offormal and informal Competences (cf. below). Tasksare further categorized along exemplary criteria mostrelevant for volunteering work, covering aspects likelocality, virtuality, and team-orientation.

Basing on a large body of literature focusingon the conceptualization of activities (Goschnicket al., 2010) and their inter-dependencies in termsof workflows (Heidari et al., 2013; Zur Muehlenand Indulska, 2010), the life-cycle of activity typesis represented in terms of StateTypes, connectingpre- and post-states using a reflexive association andaccording 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., forcomputing statistics about a volunteer’s willingnessto 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 havingno associated type taxonomy. Complementary,for representing the »I am-part«, a comprehensiveAchievementType taxonomy is provided to cover abroad range of diverse engagement assets usuallybeing a consequence of accomplishments. In thesimplest case, Statistics may be drawn basedon other assets, like means of descriptive statisticsas Tendency of, e.g, increasing engagement orRelativeStanding wrt. other volunteers. All furtherkinds of achievements (Feedback and Reward) bearmore or less subjectivism in mind, some times alsopaired with domain-specificity. Feedback may nat-urally range from simple “likes” or Kudos (Matteis,2015) to Freetext or be more structured based onOrdinal ratings or Questionnaires. In contrast to thegeneral concept of feedback, Rewards which can beoptionally explicated by Certificates, e.g., Badges(Facey-Shaw et al., 2017) or Trophies, are moreconcrete. According to their focus they can be furtherspecialized into MonetaryIncentive, e.g., Voucher orBonus, being the exception in volunteering, and morepredominant PersonalAppreciation. Depending onits visibility to others, one may further split into a risein one’s Status, covering mechanisms like Grade,Position, Award, or Honor and the acquisition ofCompetences.

Competence Type Taxonomy. Competences repre-sent another cornerstone of our ontology, since be-ing highly valuable for volunteers and also wrt. theoverall aim of supporting life-long, formal and infor-mal learning. Our ontology is first of all inspired bythe European Qualifications Framework1 as well asby existing work in the area of competence ontolo-gies, and eRecruitement (Miranda et al., 2017; Rezguiet al., 2012). Adhering to this work, we distinguishKnowledge, Ability, and Skill to cover qualificationsat different ProficiencyLevels in education, training,and especially practical tasks. According to the kindof competence which can be acquired, especially in aninformal context like volunteering, we adhere to theprominent categorization of Erpenbeck into Personal,Social, Action, and Method competences (Erpenbeck,

1http://www.cedefop.europa.eu/de/events-and-projects/projects/european-qualifications-framework-eqf


73

a:: w

j -�zw...I

u

a:: w

w u

> a:: w V)

a:: w

j

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

»iVoLUNTEER« VolunteerClient

register/ subscribe/ publish/ unre ister unsubsribe unpublish download

»iVoLUNTEER« Portal [] . t 1»iVoLUNTEER« VolunteeringHub[Jreg1s er

PortalService ,a

O·oRegistry CY

create

unregister VolunteeringHubService ,-

VolunteeringHub (?"0 Database b··

issue verify

verify ._ "- ._ HYPERLEDGER

.. �-: FABRIC »iVoLUNTEER« Blockchain Server

Trustifier Verifier

»iVOLUNTEER« Blockchain

I

..

»EXTERNAL« []

»EXTERNAL« [] Volunteer

Management S stem MS t: t:

O 0 a. a.>< E a,

publish/ � � un ublish download� �

»iVOLUNTEER« [] ·- a,

AssetTransferHub

issue verify

� < C

Cw � z -

...J

I

I

I

I

I I

I

I

I

I I

I

I

I

I I

Figure 3: iVOLUNTEER Architecture.

2010) providing a first, generic frame for integratingdistinct kinds of (domain-specific) competencies ac-quirable, e.g., at certain NPOs. To avoid the “coldstart problem”, i.e., all possible competencies have tobe defined when first using iVOLUNTEER, the DISCOproject2 provides a dictionary with more than 100.000competency definitions.

5 PROOF-OF-CONCEPTPROTOTYPE

This section presents the iVOLUNTEER proof-of-concept prototype based on the requirements and theconceptual architecture outlined in Sec. 3 as well asthe engagement asset ontology presented in Sec. 4.The architecture of the iVOLUNTEER-prototypebuilds upon the inter-working of three layers (cf.Fig. 3), namely Trust Layer, Service Layer andClient Layer, ensuring a decoupled and decentralizedarchitecture. This allows independent componentswhereby communication between them bases on theREST paradigm (Fielding, 2000).

Trust Layer. The Trust Layer comprises theiVOLUNTEER-Blockchain (BC), immutably stor-ing obfuscated replicas of EngagementAssets, i.e.,BlockchainEntries. As a technological basis, themodular, 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, itprovides for a general-purpose, distributed applica-tion development platform, characterized by a highlevel of configurability, especially regarding consen-sus and storage mechanisms, (ii) it has been alreadyapplied in real world settings by major companies,

2http://disco-tools.eu

iVol:Achievement

iVol:EmergencyDriverExaminationiVol:VehicleInstruction

iVol:EmergencyDriversLicenseEvidenceiVol:Evidence

iVol:Volunteer

iVol:MaxMuster

iVol:EngagementAssetIssuer

iVol:FireBrigade

iVol:Engagement iVol:State

iVol:VehicleInstructionCompleted

iVol:Activity

iVol:VehicleInstruction

iVol:Accomplishment

iVol:EmergencyDriversLicense

iVol:basedOniVol:basedOn

rdf:type

rdf:type

iVol:belongsTo

iVol:belongsTo

rdf:type

iVol:issued

iVol:issued

rdf:type

iVol:manifestsIn

iVol:engagesIn

rdf:typeiVol:runsThrough

iVol:offersiVol:activity

rdf:type rdf:typerdf:type rdf:type

iVol:justifiedBy

iVol:issued

iVol:belongsTo

Figure 4: Exemplary RDF Graph of Engagement Assets.

and (iii) its support and maintenance is guaranteedby 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 HLFimplementation of the iVOLUNTEER-Blockchain en-compasses the Verifier and Trustifier 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 asBlockchainEntry.hash, cf. Fig. 2), being furtherused as unique ID throughout the BC, enabling fastretrieval by comparison with the calculated hash ofan asset and at the same time allowing to verify theexistence of the asset (cf. verify method of Verifier).To further guarantee and verify the issuer’s authen-ticity, asymmetric cryptography is employed bysigning each entry (cf. BlockchainEntry.signature),calculated beforehand by the issuer of each assetthrough digitally signing the concatenation of theirrespective public key and a timestamp with theprivate key of the issuer using DSA. Including thetimestamp leads to different signatures each time anentry is created, thus precluding the signature’s reuse.

In order to allow for verification beyond simpleexistence, verification of an asset’s history is needed,requiring a linkage between the individual evolutionsteps belonging together. This linkage is main-tained through the BlockchainEntry.combinedID,calculated as a hash of the issuer’s ID and theEngagementAsset.assetID, thus mitigating pos-sibilities to query information about the issuer.The combination of BlockchainEntry.hash andBlockchainEntry.combinedID allows for the ver-ification of an asset’s (i) topicality, (ii) temporaldependencies, by further exploiting the providedtimestamp, (iii) completeness of its past evolution,by being able to query all entries for an asset andfinally, (iv) future maintenance, using the dedicatedproperty BlockchainEntry.depricate indicating thetermination of an asset’s evolution.


74

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 stakeholdersby providing AssetTransferHubs.

For VolunteeringHubs, the Java Spring Boot3-based web server implementation of the central Vol-unteeringHubService component focuses on config-uration and management of activities, assets, en-gagements and their evolutions. For life-cycle def-inition of engagements, the open source workflowengine Activiti4 is utilized, allowing for graphicaldefinition and customization thereof using the Ac-tiviti designer available as Eclipse plug-in. Foreach VolunteeringHub, a VolunteeringHubDatabasebased on the graph-based NoSQL system neo4j5

stores the local views on EngagementAssets earnedby volunteers on a certain hub. The rationale be-hind using Neo4j respectively a graph database isthe storage of LD, which they are primed for (Luand Holubová, 2019). Fig. 4 shows an exemplaryRDF graph (A-Box) typed to our conceptual ontol-ogy (T-Box) representing the earning of a so-calledEmergencyDriversLicense Achievement by a volun-teer on the volunteering hub of the Red Cross. Addi-tionally, it also shows the preconditions necessary togain this achievement, e.g., the successful completionof a vehicle instruction as well as passing an emer-gency driver examination. Changes in the A-Box maybe downloaded to a volunteer’s PrivateAssetReposi-tory (see below) to provide a global view by employ-ing a REST endpoint. Additionally, the evolution ofthe RDF graph is also stored in the blockchain (cf.create and deprecate REST endpoints in Fig. 3).

The AssetTransferHubs, implemented again as

3https://spring.io/projects/spring-boot4https://www.activiti.org/5https://neo4j.com

Java Spring Boot web server application, allowsfor integration of external VMS and third partyapplications through their import/export RESTendpoints, thus, enabling usage of externally earnedassets within iVOLUNTEER and vice versa. Forimporting data, a light-weight approach is currentlyfollowed, meaning that the provided data needs tocorrespond to the JSON-LD format allowing to linkthe internal RDF graph to the newly generated graphfrom the external JSON-LD data without any needfor mappings. For exporting data, the according RDFgraph is serialized in terms of JSON-LD to providea machine readable format. Last, the PortalServiceenables registration/deregistration of volunteers andVolunteeringHubs, establishing the global Registry ofthe iVolunteerPortal.

Client Layer. Finally, the Client Layer comprises ac-cess to the functionalities provided by iVOLUNTEERfor its users being it volunteers, NPOs, help seekersor other third parties. Foremost, it provides volun-teers the VolunteerClientApp, enabling them to com-municate with the hubs, thereby providing means forengaging 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 ahub). Fig. 5 shows screenshots of the current pro-totype visualizing a volunteer’s earned engagementassets stored in the PrivateAssetRepository and a re-cruiter’s view on the AssetTransferHub.

6 COMPARATIVE EVALUATION

In the following, related approaches for BC-basedpersonal data management in terms of digital badges


75

in the areas of formal and informal learning areinvestigated, namely UZHBC (University of ZüricHBlockChain) (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 CooperativeSystem) (Liu et al., 2018). These approaches areof specific interest as they are (i) using differentkinds of mechanisms for representing their assets,ranging from unstructured, schema-less to structured,schema-based ones, (ii) tackling evolution aspects toa certain extent, (iii) going at least partly beyond sim-ple issuing and verification of assets and finally, (iv)providing for a mixture of both, permissionless andpermissioned BC implementations. Structured alonga set of criteria being derived from our requirements(cf. Sec. 3), the evaluation results are summarized inTable 1 and briefly discussed on a per-requirementbasis [REQ1-REQ4] in the following, also especiallyemphasizing on the commonalities and differences toiVOLUNTEER.

Overcoming Scatteredness and Diversity. Regard-ing our first category of requirements, scatterednessand diversity is not explicitly focused on by theevaluated approaches, i.e., establishing a global viewon assets (i.e., digital badges) [REQ1.1] stemmingfrom various sources as targeted by iVOLUNTEERis not an issue. The mechanisms for representingdiverse assets [REQ1.2] are manifold, ranging fromsimply processing PDF-documents (UZHBC), toschema-less asset descriptions (SPROOF) and differ-ent schema-based ones, being partly based on MozillaOpen Badges (BCE and Blockcerts). Neither of themprovides an engagement asset model, and thus a tax-onomy of assets, with a configurable and extensibletype hierarchy as provided by iVOLUNTEER.

Maintaining Evolution. Maintenance of assetevolution [REQ2.1] is supported in different, oftenquite 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 onlysupported by EICS, whereas deprecating assets isunique to iVOLUNTEER. Regarding traceability ofevolutions [REQ2.2], all approaches allow to capturean assets’ availability time, and, with the exceptionof UZHBC, also its validity time. Tracing back theevolution states of assets is supported by ECIS andiVOLUNTEER, only. Specifically, iVOLUNTEER alsoaddresses different schema versions during assetevolution.

Achieving Sovereignty. To achieve sovereignty,all systems except ECIS employ external privatestorage for assets [REQ3.1], using the BC, as iniVOLUNTEER, for storing their hash values. Externalstorage technologies used are manifold, ranging fromdistributed (P2P-)file systems to specific groupware,whereas iVOLUNTEER bases on the, in the meantimewell established, NoSQL paradigm, allowing forconvenient storage of different asset versions result-ing from both, structural- and state-based evolution.Finally, although all systems allow for a selectivetransfer of received assets, none of them providemeans to revoke this transfer (in contrast to therevokation 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 evidenceand URIs to external justifications only. Similar toiVOLUNTEER, BCE envisions to provide algorithmicevidence by means of chain code but misses a struc-tured representation of the emergence of assets basedon certain accomplishments and/or achievements.

For establishing trust in an assets’ existence[REQ4.2], the majority bases on the public BCsBitcoin (Blockcerts) and Ethereum (UZHBC,SPROOF, BCE), only EICS employs, analogous toiVOLUNTEER, the permissioned BC HLF. BC-entriescan be issued in all systems, except SPROOF, byprivileged users, only, whereas receiving assets isdestined to registered users in UZHBC, SPROOFand iVOLUNTEER. Authenticity of the asset issuercan be verified by all systems applying asymmetriccryptography, except UZHBC - which, due to itsschemaless representation, also lacks ability to verifyvalidity. Beyond, only EICS and iVOLUNTEERprovide means for establishing trust in the topicalityof an asset throughout its evolution. With respect tocompleteness of an asset, SPROOF allows to verifyasset bundles, whereas iVOLUNTEER allows to verifycompleteness of an assets’ evolution states.

7 LESSONS LEARNED ANDFUTURE WORK

In the following, lessons learned from the employ-ment of BCs while opening up to LD in our digitalecosystems as well as future work are discussed,thereby explicitly considering issues being alsovaluable to domains beyond volunteering.


76

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 maintainabilityIssuer privileged users everybody privileged users privileged users privileged users privileged users

Receipient everybody everybody registered users registered users registered users registered usersEvidence textual textual textual + URI textual + URI textual textual + algorithmic

Ethereum Ethereum Ethereum Bitcoin HLF HLFpublic 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

RepresentationAsset[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 andHRM, which bases on data silos and walled gardens,could be turned upside down by empowering users toget back control over their data and employing BC asa means for establishing trust. Although we tried totake a first step in this direction with iVOLUNTEER,further research is needed to investigate on possibleuse cases, technological requirements and borders ofapplicability for different application domains.

BC as Backbone for Transparent Asset Gener-ation. To provide trust in the content of an assetand its evolution, a transparent asset generation andevolution process needs to be provided by the BC. Inparticular, a library of asset generation rules realizedas smart contracts should be provided, allowingNPOs to reflect their “individual culture of appreci-ation”, like rules for award or competency earning,in a transparent way through the BC. This could alsolead to the emergence of cross-NPO asset generationrules, e.g., the fire brigade considers qualificationsearned at the red cross as pre-requisite for certaintasks, and at the very end to some standardized pro-cedures across different informal learning domains,resulting in a “homogenization” of assets and theirevolution.

BC as Mechanism for Ensuring Assets’ Existence.Although a BC can ensure the existence of assets, itcan not entail trust in the actual content of an assetnor prevent fake assets. Despite of comprehensivelyrepresenting an asset’s context of emergence throughLD, there is no doubt that the issuer’s reputation

is the crucial impact factor. Due to openess of ourecosystem where every registered user is allowedto act in the role of a volunteer or help seeker andsince it is uncertain if consensus mechanisms ofBCs may always prohibit fake assets, it always laysin the eye of the beholder to assess the plausibilityof the provided assets. These are without a doubtsome of the most crucial vulnerabilities of oursystem, although the special culture prevalent inthe volunteering domain may reduce these risksto some extent. These are without a doubt someof 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. Onecrucial issue when employing a private, permissionedBC like HLF is to decide about the distributionand replication of system components to establishthe required amount of trust. Therefore, the BCnetwork’s components, the committing peers, aswell as the ordering service have to be hostedacross different trustworthy organizations, preferablywith different intentions like the national ministry ofsocial affairs or trustworthy NGOs like the Red Cross.

LD as Enabler for Digitizing & Exploiting Fur-ther Assets. Leveraging our digital ecosystem furtherbeyond the volunteering domain, it would be valu-able to allow e.g., educational institutions (providing,e.g., qualification certificates), 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


77

enhanced by providing functionality for recruiters toupload job profiles and carry out matchmaking.LD as Common Ground to Share Assets withThird Parties. Especially sharing engagement as-sets outside of the iVOLUNTEER ecosystem requires amechanism of information manifestation, wrapping avolunteer’s engagement assets in a machine-readableformat, without any loss of semantics. LD servesas valuable cornerstone for volunteers to exploit theirengagement assets not only within iVOLUNTEER butalso 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 allowsthe creation of a volunteer’s global view on all earnedassets, the potential typing to a different T-Box hin-ders further internal processing, e.g., to employ thisdata for semantic matchmaking when looking for suit-able new tasks. Thus, it would be beneficial to pro-vide some kind of ”full integration” of external assetsby 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). Managingyour 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: Towardspreference 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 forPermissioned 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. InProc. 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. InProc. of eBISS’17, pages 51–83.

Brunner, C., Knirsch, F., and Engel, D. (2018). SPROOF:A platform for issuing and verifying documents in apublic blockchain. Technical report, FH Salzburg.

Chao, L. and Palanisamy, B. (2019). Incentivizedblockchain-based social media platforms: A casestudy 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. InChanging Cultures in Higher Education, pages 299–312. Springer.

Facey-Shaw, L., Specht, M., Van Rosmalen, P., Brner, D.,and Bartley-Bryan, J. (2017). Educational Functionsand Design of Badge Systems: A Conceptual Litera-ture Review. IEEE TLT, 11(4):536–544.

Fielding, R. T. (2000). Architectural Styles and the Designof Network-based Software Architectures. PhD thesis,University of California, Irvine.

Gangemi, A., Guarino, N., Masolo, C., Oltramari, A., andSchneider, L. (2002). Sweetening ontologies withDOLCE. 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 ERCIMBlockchain Workshop’18.

Gresch, J., Rodrigues, B., Scheid, E., Kanhere, S. S., andStiller, B. (2019). The Proposal of a Blockchain-Based Architecture for Transparent Certificate 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 andMedia, 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, pages216–221.

Hevner, A. R., March, S. T., Park, J., and Ram, S. (2004).Design science in information systems research. MISquarterly, pages 75–105.

Holzer, M. (2017). VOLUNTEERING IN AUS-TRIA. http://www.freiwilligenweb.at/sites/default/files/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). IntegratingLearning Outcomes and Competences. http://www.cetis.org.uk/inloc/Home. [accessed on 2019-09-24].

IEEE (2007). IEEE Standard for Learning Technology-DataModel for Reusable Competency Definitions. IEEEStd 1484.20.1-2007, 1484:1–2007.

Kapsammer, E. et al. (2017). iVOLUNTEER: A DigitalEcosystem for Life-Long Volunteering. In Proc. ofiiWAS’17, pages 366–372. ACM.

Kapsammer, E., Pröll, B., Retschitzegger, W., Schwinger,W., Weißenbek, M., and Schönböck, J. (2018). Theblockchain muddle: A bird’s-eye view on blockchainsurveys. 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 SystemBased on Blockchain. In Proc. of HotICN’18, pages207–211.

Livingstone, D. (2006). Informal Learning: ConceptualDistinctions and Preleminary Findings. The InformalEducation Reader, 249:203–227.


78

Lu, J. and Holubová, I. (2019). Multi-model databases: Anew 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 field 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 forblockchain credentials. https://www.blockcerts.org.[accessed: 2019-09-24].

Niles, I. and Pease, A. (2001). Towards a standard upperontology. In Proc. of FOIS’01, pages 2–9.

Rezgui, K., Mhiri, H., and Ghedira, K. (2012). Competencymodels: A review of initiatives. In Proc. of ICALT’12,pages 141–142.

Rifón, L. A. (2011). Standardising competency definitionsfor 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 Frameworkfor 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., andSchwinger, 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 ofmy digital footprint. In Proc. of WS on Symbiotic In-teraction, pages 155–167.

UN Volunteers (2018). State ofthe World’s Volunteerism Report.https://www.unv.org/sites/default/files/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: sixcore dimensions for effectively planning and commu-nicating design science research projects. ElectronicMarkets.

Zur Muehlen, M. and Indulska, M. (2010). Modelinglanguages 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.


79