Explain Yourself: A Semantic Annotation Framework to Facilitate

Tagging of Semantic Information in Health Smart Homes

Bastian Wollschlaeger

, Elke Eichenberg and Klaus Kabitzsch

Chair of Technical Information Systems, Technische Universität Dresden, 01062 Dresden, Germany

Keywords:

Ambient Assisted Living, Digital Personalized Health, Health Smart Home, Interoperability, Taxonomy,

Telehealth, Telemedicine.

Abstract:

Health Smart Homes (HSH) are a key concept in future personalized health care. However, with an abundance

of heterogeneous assistance components available, the design process of HSHs is becoming increasingly com-

plex and needs to rely on computer-based support. As a key prerequisite, formal models of information se-

mantics are required for component selection and early-on interoperability assessment. This paper proposes a

ﬂexible and extensible framework of semantic annotations that copes with the interdisciplinary nature of HSH

and can be used to incorporate a formal model of semantics at component interfaces. The framework consists

of a taxonomy of semantic annotations (tags) and their relationships and is developed using a well-established

taxonomy creation method. The tags address several independent aspects of semantics, increasing the expres-

siveness of information semantics. With this valuable new level of detail for information, component models

can be semantically enriched, in turn enabling computer-based design algorithms to carry out the complex

design tasks in the future.

1 INTRODUCTION

Health Smart Homes (HSH) are a key concept for re-

alizing personalized health care in order to cope with

future challenges for health care systems (Maeder and

Williams, 2017). However, with an abundance of

heterogeneous assistance components available, the

design process for HSH is becoming increasingly

complex and requires computer-based support (Haux

et al., 2016; Welge et al., 2015). In order to allow al-

gorithms to identify meaningful design suggestions,

formal functional models for HSH components are

required to select appropriate and compatible compo-

nents (Wollschlaeger et al., 2019). However, achiev-

ing interoperability is a complex problem (Vermesan

et al., 2014), resulting in high follow-up costs when

neglected in the design phase. As an example, NIST

reported annual costs of $ 15.8 billion for the U.S.

building industry (Gallaher et al., 2004). To detect

potential interoperability issues as early as possible,

it is necessary to include the semantics of information

exchanged by components in their functional mod-

els, enabling a conceptual interoperability assessment

at design time by comparing the resulting semantic

https://orcid.org/0000-0002-1101-0680

data types. While syntactical interoperability can be

achieved by middleware approaches and standardiz-

ing the data types of programming languages or the

payloads of communication technologies, semantic

information describing the actual meaning of data is

often neglected. This semantics of information in the

context of automated design processes for HSH will

be this paper’s object of investigation with the aim

to provide a modeling framework for semantic data

types. In this context, semantic data types are classes

of equal meaning of information. Subsequently, main

requirements for the framework will be discussed.

Despite the importance of semantic data types in

achieving semantic interoperability in both the de-

sign and operation phase of HSH, the semantics of

data is nowadays often not formally speciﬁed, so no

automated processing of their meaning is possible.

Even if some approaches offer a vocabulary of seman-

tic types that enable a basic annotation of semantics

(VDI 3813-2, 2011), these vocabularies are usually of

low expressiveness. The automated processing of se-

mantic information is limited to a comparison of data

type names only. Therefore, it is still an open prob-

lem to provide a high model expressiveness, leading

to REQUIREMENT I) explicability.

During the design process, semantic data types are

Wollschlaeger, B., Eichenberg, E. and Kabitzsch, K.

Explain Yourself: A Semantic Annotation Framework to Facilitate Tagging of Semantic Information in Health Smart Homes.

DOI: 10.5220/0008968901330144

In Proceedings of the 13th International Joint Conference on Biomedical Engineering Systems and Technologies (BIOSTEC 2020) - Volume 5: HEALTHINF, pages 133-144

ISBN: 978-989-758-398-8; ISSN: 2184-4305

133

relevant in two different levels of detail: ﬁrstly, they

are used to model an abstract system speciﬁcation

without usually taking into account aspects of data

representation. Secondly, they are used for detailed

modeling of the required and provided data for spe-

ciﬁc components. These different levels of abstrac-

tion render it difﬁcult to assess how well a speciﬁc

component ﬁts to the abstract speciﬁcation. In addi-

tion, the level of abstraction is ﬁxed for existing ap-

proaches, i. e. it is not possible to use the same vo-

cabulary for abstract speciﬁcation and detailed com-

ponent modeling. This leads to the open problem of

supporting different levels of details within the same

approach; resulting in REQUIREMENT II) comprehen-

siveness.

As the interdisciplinary domain of HSH is highly

diverse and dynamic, a modeling framework for an-

notating semantics to data types needs to be ﬂexi-

ble and extensible. Existing vocabularies of semantic

types are usually not extensible, but rather ﬁxed and

limited. Therefore, the open problem to be able to

account for future changes in the dynamic domain of

HSH leads to REQUIREMENT III) extensibility.

In order to meet the requirements outlined above,

the modeling framework developed by this paper will

use the concept of semantic annotations (shortly re-

ferred to as tags) in multiple dimensions encompass-

ing different aspects of semantics. All in all, this pa-

per proposes the following main contributions:

1. Proposal of an ontology structure for semantic an-

notation frameworks meeting requirements I) to

III).

2. Description of a systematic and reproducible

method that can be used to develop semantic an-

notation frameworks for different domains.

3. Development of an exemplary semantic annota-

tion framework for room automation aspects of

HSH that is extensible to further aspects of HSH.

This paper is structured as follows: The next sec-

tion discusses related work for HSH and semantic an-

notations of data. Section 3 extends a conceptual core

framework of HSH to provide context for semantic

annotations in assistance systems. Section 4 describes

the development of the proposed semantic annotation

framework for room automation aspects of HSH, in-

cluding a possible extension of the developed frame-

work to cover further aspects of HSH. The framework

is validated in Section 5 by discussing its potential use

in a variety of application areas. Finally, the paper is

summarized by Section 6, which also provides further

research areas.

2 STATE OF THE ART

2.1 Engineering of Health Smart Homes

The concept of HSH addresses the living environ-

ment of patients and aims at both improving the qual-

ity of life and increasing the safety of the occupants.

To achieve this, HSH builds upon smart home tech-

nology to combine technical equipment with health

care applications (Rialle et al., 2002; Maeder and

Williams, 2017). Consequently, HSH are the nexus of

domains such as smart home, ambient assisted living

and room automation technologies (Wollschlaeger

and Kabitzsch, 2019).

A conceptual core framework from

(Wollschlaeger and Kabitzsch, 2019), which is

depicted in Figure 1 in UML-notation, shows the

main entities and their relationships for HSH. The left

side is constituted by the entities of the requirements

view and deﬁnes the demands (User Requirements)

of the HSH Occupant. On the right side, the entities

of the components view model the HSH Assistance

System and its respective Assistance Components.

Thus, the HSH’s capabilities in providing assistance

for the occupant are deﬁned. The concept Assistance

Function mediates the demands and the capabilities

by providing a shared vocabulary for both the user

requirements’ functional intentions and the assistance

system’s functionality.

Figure 1: Core concepts of the conceptual framework for

HSH, from (Wollschlaeger and Kabitzsch, 2019).

In order to achieve the high level of customiza-

tion required for assistance systems in HSH (Maeder

and Williams, 2017), computer-based support is nec-

essary. (Wollschlaeger and Kabitzsch, 2020) formally

deﬁnes the HSH engineering task as well as an ap-

proach for automated engineering of HSH. This ap-

proach is motivated by a prototype of an automated

engineering approach in the adjacent domain of room

automation (Dibowski et al., 2010). Functional mod-

els for components aimed to facilitate the design pro-

cess have been investigated in different levels of de-

tail (Dibowski and Kabitzsch, 2011), (Wollschlaeger

et al., 2019). Key vocabulary for functionality was the

German room automation standard VDI 3813 (VDI

3813-2, 2011), which introduces standard functional-

ity and information types available in room automa-

HEALTHINF 2020 - 13th International Conference on Health Informatics

134

tion systems on an abstract and technology-neutral

level. As representation for functionality, it deﬁnes

function blocks and the information required and pro-

vided by them. However, the semantic data types used

in the prototypes were limited to a ﬁxed set.

2.2 Semantic Data Types and Tags

A previous literature analysis revealed that currently

there is no comprehensive standard that can be used

as a common knowledge base for functionalities and

data types in the whole HSH domain (Wollschlaeger

and Kabitzsch, 2019). However, when only consid-

ering the room automation aspects of HSH, the func-

tional standard VDI 3813 can be regarded as such a

common understanding of functionality and informa-

tion types. It deﬁnes a set of 46 semantic types, which

each are semantically labeled with one mnemonic

name consisting of two components hinting at the

type of information represented and its meaning(e. g.

A_SUN representing the angle of the sun’s position).

Thus, a coarse structure for attributing semantics to

the information is available; yet, the two components

are often not clearly delimitated and further details are

only mentioned as unstructured explanation text. The

validity of interoperability assessment based solely on

the data type names is therefore limited.

As a different approach, system information mod-

els provide means to formalize speciﬁc technical sys-

tem conﬁgurations. There are plenty of approaches

for building automation systems (Butzin et al., 2017)

and smart homes (Grassi et al., 2013), such as Do-

moML (Sommaruga et al., 2011), the SSN-Ontology

(Compton et al., 2012), DogOnt (Bonino and Corno,

2008), ThinkHome Ontology (Koﬂer et al., 2012),

AAL-Onto (Welge et al., 2015), or SAREF (Daniele

et al., 2015). They focus on the detailed modeling of

environment and context, but mostly not on health-

related aspects. Though these approaches provide

generic high-level views of HSH, they do not model

sufﬁcient information to attribute semantics to infor-

mation for design purposes.

Similarly, abstract reference models such as the

UniversAAL platform (Tazari et al., 2012) provide a

conceptual framework for systems in general, but re-

main too coarse on the aspect of data type semantics.

The ISO/IEEE 11073 standards family (ISO/IEEE

11073-10101a, 2015) offers a detailed nomenclature

for health information, yet remains largely focused

on communication in a hospital setting. Middleware

platforms aim at translating data between different en-

tities with possibly heterogeneous data models. The

ESKAPE platform (Pomp et al., 2017) lifts this trans-

lation the level of data to the level of information by

offering means for semantic data integration. It en-

ables the integration of custom semantic models into

a dynamic semantic knowledge graph, thus enabling

querying of information agnostic of the speciﬁc data

formats. However, the platform provides no guid-

ance on which data should be semantically modeled

and how the creation of the custom semantic models

should be conducted, resulting in potentially incom-

plete and incompatible semantic models.

Another class of approaches for modeling the se-

mantics of data are semantic tagging approaches. The

most prominent example from the ﬁeld of building au-

tomation is Project Haystack

, which aims at mod-

eling the semantics of building automation compo-

nents. To this end, more than 200 semantic annota-

tions (tags) are available as a list or as an ontology

(Charpenay et al., 2015). This enables to create a sys-

tem model that is organized along the hierarchies of

site, equipment and (data) point. The ﬂexibility and

community-based approach of Haystack has inspired

further work in the domain of IoT, e. g. the extended

data model BACnet XD by the BACnet group (Butzin

et al., 2017), the KNX Information Model by the KNX

Association (Pelesic et al., 2016), or for integration of

IoT and building systems (Schachinger et al., 2017).

In order to improve the applicability of tagged sys-

tem models, BRICK (Balaji et al., 2016) introduced

a metadata schema for buildings aimed at enabling

applications such as model-predictive control or fault

detection and diagnosis. BRICK offers an ontology of

entities (Point, Equipment, Location, Measurement)

and their relationships in order to model building au-

tomation systems and components.

These approaches aim at facilitating building an-

alytics by adding semantic information to models of

building systems. While capturing the systems’ struc-

ture and metadata, they are focused on the operation

phase and do not intend to use the semantic informa-

tion in the design phase. In contrast to the available

coarse granularity of data semantics, design tasks re-

quire a higher level of expressiveness such as shown

by (Wollschlaeger et al., 2019) for interoperability as-

sessments.

2.3 Taxonomies, Ontologies and

Taxonomy Creation Methods

A taxonomy is an hierarchical categorization sys-

tem consisting of dimensions, which each can

have different values (characteristics). Borrowing

from(Nickerson et al., 2013), a taxonomy T can be

deﬁned as

http://project-haystack.org/

Explain Yourself: A Semantic Annotation Framework to Facilitate Tagging of Semantic Information in Health Smart Homes

135

T = {D

, i = 1, . . . , n

| D

= {C

i j

, j = 1, . . . , k

; k

≥ 2}}

(1)

with D

being the dimensions and C

i j

their char-

acteristics. Ontologies extend the concept of tax-

onomies from an hierarchical categorization towards

a network of information and logical relationships.

Due to the relationships between the concepts, the

strict hierarchical structure of a taxonomy is not suf-

ﬁcient for representing it. Instead, a knowledge graph

is required.

Taxonomies and ontologies are often used for

structuring concepts in a speciﬁc domain of interest.

A reproducible method for developing these struc-

tures promotes re-use of the categorizations. In the

ﬁeld of Information Systems Research, however, sev-

eral analyses pointed out that most taxonomies are

developed in an ad hoc and thus non-reproducible

manner (Nickerson et al., 2013; Lösser et al., 2019).

In order to increase the rigor in taxonomy develop-

ment and to provide guidance for researchers dur-

ing the taxonomy design process, (Nickerson et al.,

2013) proposed a generic high-level method for tax-

onomy development. Their proposed method uses

meta-characteristics as a conceptual kernel and allows

for an iterative taxonomy design process offering both

a bottom-up (inductive) and a top-down (deductive)

approach (cf. Figure 2).

Figure 2: Method for Taxonomy Creation according to

(Nickerson et al., 2013).

With the ﬂexibility of choosing both inductive as

well as deductive approaches, this taxonomy develop-

ment method ﬁts for creating the semantic annotation

framework. This is due to the fact that on the one

hand, some semantic data types have been deﬁned in

the domain (favoring the inductive approach) and on

the other hand, a vast conceptual knowledge is avail-

able (facilitating the deductive approach). The itera-

tive nature of the method allows for a combination of

both approaches to reach the best trade-off between

structuring and adhering to the existing types.

3 SEMANTIC DATA MODELS IN

HSH CONTEXT

In order to put semantic data types into context, a con-

ceptual framework of the assistance system aspects of

HSH will be used. Based upon the conceptual core

framework from (Wollschlaeger and Kabitzsch, 2019)

(cf. Figure 1) and the UniversAAL reference model

(Tazari et al., 2012), the concepts and relationships

of the assistance systems are depicted in Figure 3 in

UML notation.

Figure 3: Conceptual Model of Assistance Systems in HSH

context.

The classes on the left model Assistance

Component as structures for equipment, which

contains a software application, modeled by

Device Application. The software applica-

tion provides a certain functionality modeled by

Assistance Function. The classes on the right

side – Communication Relation and Semantic

Data Type – are used to model the interconnections

of assistance components in the assistance system.

More speciﬁcally, the assistance components are

communicating with each other in order to fulﬁll

their functionality. A communication relation models

one of the information exchanges for a set of “linked”

assistance components. Each communication relation

is used to exchange a speciﬁc type of information

between the assistance components’ software ap-

plications, modeled by its data type. On the other

hand, these software applications need to provide

information about their software interface. More

speciﬁcally, they need to model required data types

on the input side as well as provided data types on

the output side.

The key concept of interoperability can now be

investigated: the software applications exchanging in-

formation in the context of a speciﬁc communication

relation need to adhere to its semantic data type. More

speciﬁcally, the data types of the provided and the re-

quired side need to be compatible with each other.

HEALTHINF 2020 - 13th International Conference on Health Informatics

136

The types are said to be compatible if the provided

types are equal to or a subclass of the required types.

4 SEMANTIC ANNOTATION

FRAMEWORK

The following section shows the development of the

semantic annotation framework in more detail. First,

the overall structure of the framework is discussed.

Then, the taxonomy creation method of (Nickerson

et al., 2013) is applied and descriptions of the differ-

ent iterations and the decisions made in the taxonomy

creation process are provided. When describing the

taxonomy creation, we will use the numbers of the

different steps according to Figure 2 for reference.

4.1 Structuring Semantic Data

Annotations

The main idea for structuring the semantic annotation

framework is based on describing semantics along

several different information dimensions. This is mo-

tivated by different approaches of semantic system

modeling for building analytics, such as the Seman-

tic Sensor Network Ontology, the semantic tagging

approach Project Haystack, and the BRICK metadata

schema (cf. Section 2.2). Those approaches provide

detailed system models by taking entities and their

relationships into account. We aim to translate such

expressiveness to the semantic information modeling

by providing different aspects of semantics. Such a

composite semantic model allows for expressing in-

formation and relations in much more detail than se-

mantic models consisting of only one semantic label.

Figure 4: Model of the Semantic Annotation Framework.

Following the structuring approach outlined

above, Figure 4 depicts a model of the proposed

framework. A Semantic Data Type is composed

of several different Semantic Aspects, which each

are annotated with Semantic Tags. When consid-

ering the semantic annotation framework as a taxon-

omy, the aspects are taxonomy dimensions with the

different annotations making up the characteristics of

these dimensions. Since taxonomies are structurally

less complex than ontological knowledge graphs, we

start with a development process geared for taxon-

omy creation (Nickerson et al., 2013) and evaluate

the taxonomy’s expressiveness at each iteration in or-

der to decide whether an extension (e. g. by using the

parentTag relation in Figure 4) towards an ontology

structure is beneﬁcial.

4.2 Meta-characteristics and Ending

Condition

At the beginning of the taxonomy creation pro-

cess, the Nickerson method requires to deﬁne meta-

characteristics and ending conditions for this process.

Meta-characteristics are used as the basis for choosing

the dimensions in the taxonomy. As the process itself

is iterative, the ending conditions are required to de-

termine, at which point the taxonomy creation process

may terminate, i. e. the resulting taxonomy fulﬁlls the

intended goal (Nickerson et al., 2013).

For step 1, we choose meta-characteristics that re-

fer to the orthogonal aspects of i) which entity is de-

scribed, ii) in which context, and iii) using which real-

ization. The last meta-characteristic is closely related

to syntactic aspects of how information is encoded;

however, since it models semantic aspects, it will only

entail realization aspects on an abstract level. We de-

ﬁne the meta-characteristics as follows (cf. Table 1):

Table 1: The meta-characteristics (MC) chosen in step 1 of

the taxonomy creation process.

ID NAME EXPLANATION

MC1 Entity What is the information

referring to?

MC2 Context In which context is the

information generated

and used?

MC3 Realization How is the information

encoded?

Several possible pre-deﬁned ending conditions for

step 2 are deﬁned by Nickerson, divided into objective

and subjective ending conditions (Nickerson et al.,

2013). The conditions depicted in Table 2 were se-

lected for the development process.

4.3 First Iteration

The ﬁrst iteration starts with the decision, if the

top-down (conceptual-to-empirical) or bottom-up

(empirical-to-conceptual) approach should be used

(step 3). Since various domain knowledge is available

Explain Yourself: A Semantic Annotation Framework to Facilitate Tagging of Semantic Information in Health Smart Homes

137

Table 2: The ending conditions (ECO / ECS) chosen in step 2 of the taxonomy creation process.

ID NAME EXPLANATION

OBJECTIVE ENDING CONDITIONS

ECO1 Comprehensive

Modeling

Semantic data types of target domain are comprehensively modeled (all objects

have been examined)

ECO2 Objects stable No object was merged or split in the last iteration

ECO3 Important con-

cepts identiﬁed

No new dimensions or characteristics were added in the last iteration

ECO4 Concepts stable No dimensions or characteristics were merged or split in the last iteration

ECO5 Dimension

Uniqueness

Every dimension is unique and not repeated (i. e. there is no duplicate)

ECO6 Characteristic

Uniqueness

Every characteristic is unique within its dimension

SUBJECTIVE ENDING CONDITIONS

ECS1 Conciseness The number of dimensions limited to at most 7± 2

ECS2 Robustness Sufﬁcient differentiation amongst the objects is feasible

ECS3 Comprehen-

siveness

REQUIREMENT II) All objects of interest can be classiﬁed

ECS4 Extensibility REQUIREMENT III) New dimensions / characteristics can be added easily

ECS5 Explicability REQUIREMENT I) The dimensions / characteristics are able to explain the objects

that may serve as a conceptual guideline for struc-

turing semantic models, we chose the conceptual-

to-empirical approach with the data types of the

VDI 3813 as the initial set of objects. At this point,

we have to restrict the objects under investigation to

the room automation aspects of HSH, as further as-

pects such as assistance technology still lack a com-

mon understanding of semantics (Wollschlaeger and

Kabitzsch, 2019). We envisage to broaden the per-

spective towards further aspects of HSH once the con-

ceptual structure has been consolidated. Section 4.6

demonstrates the framework’s extensibility by dis-

cussing health-related HSH examples.

Since this is the ﬁrst iteration, step 4c conceptu-

alizes new dimensions and characteristics based on

the conceptual kernel of meta-characteristics. In or-

der to achieve an easily extensible taxonomy, we fol-

low the approach of the SSN-Ontology (Compton

et al., 2012) and deduct the two new dimensions FEA-

TURE OF INTEREST and PHYSICAL QUALITY from

MC1 Entity. Their characteristics can be determined

by investigating potential entities and properties in

a room. Entities involve equipment (climatisation,

contact, damper, drive, fan, lamella, lamp, sunblind,

valve, vav

), and physical entities (air, light, occu-

pant, sun, water), distinguishing if the entity can be

directly controlled by technical means (equipment) or

not (physical entity). On the other hand, each en-

tity possesses different properties, constituting a list

of PHYSICAL QUALITIES.

Variable Air Volume, a type of ventilation system

The second meta-characteristic MC2 Context is

used to infer two further dimensions LOCATION and

VARIABLE TYPE to model the information origin and

usage, respectively. The LOCATION dimension con-

tains characteristics describing the location type of

the information’s origin, namely indoor, outdoor, bms

(building management system), and equipment (if the

information is used in the technical systems only).

The VARIABLE TYPE dimension models the in-

tended usage of the contained information. Since the

processes in room automation may be modeled as

control loops, the VARIABLE TYPE dimension uses

characteristics classifying data based on its usage in a

standard control loop. Figure 5 depicts the different

characteristics that were identiﬁed using the interna-

tional electrotechnical vocabulary for control theory

(IEC 60050-351, 2013). The types of variables can

be differentiated into operating values (command and

setpoint), computed values (i. e. controller output) and

measured values (state and value).

Finally, meta-characteristic MC3 Realization al-

lows to infer abstract realization characteristics. The

dimension TRIGGER TYPE models that information

can be created by a manual human action (e. g. choos-

ing temperature set point or the push of a button) or by

algorithms in an automatic way (e. g. the blind posi-

tion following the movement of the sun). This distinc-

tion often carries further semantic information with

respect to prioritizing the commands, as most often

the command issued by humans can override auto-

matically generated commands.

In addition, the dimension REFERENCE TYPE

HEALTHINF 2020 - 13th International Conference on Health Informatics

138

models if a value is to be interpreted as an absolute

or a relative value. In case of relative values, a base

value is required in order to compute the actual value

to work with. This distinction is important for e. g.

setting the temperature set point, as most room con-

trol units only provide means to adjust the set point

within ±5K, while others allow a speciﬁc tempera-

ture as set point.

Finally, the dimension REPRESENTATION allows

to specify the general type of information encoding in

terms of the scale of measurement. It distinguishes

amongst binary, quantiﬁed, continuous, nominal, and

ordinal values. Nominal and ordinal values repre-

sent enumeration types with ordinal values addition-

ally featuring a partial order.

Having identiﬁed the initial set of dimensions and

characteristics, step 5c examines existing semantic

data types as empirical objects for these dimensions

and characteristics. The 46 types of the VDI 3813

were annotated semantically. If multiple semantic an-

notations for each dimension were possible, they were

assigned simultaneously. However, this strongly indi-

cates that the semantic type in question is ambiguous,

i. e. deﬁned too vaguely as it can have multiple mean-

ings, preventing this type to be used in an interoper-

ability assessment.

With the results of the ﬁrst iteration, the result-

ing vocabulary (step 6c) consists of the seven dimen-

sions and 53 characteristics. Different from Nicker-

sons original method, we put major emphasis on RE-

QUIREMENT III) extensibility (e. g. new equipment,

new considered physical entities, new forms of rep-

resentation, .. . ), so we do not eliminate dimensions

and characteristics that are not yet used, as long as

Figure 5: The different Variable Types (bold in boxes) in

a closed-loop control system. The functionalities are dis-

played as function blocks according to (VDI 3813-2, 2011).

they are potentially useful. As an example, the di-

mensions TRIGGER TYPE, REFERENCE TYPE and

REPRESENTATION are usually not speciﬁed at the ab-

stract level of the VDI 3813, but they can be used to

further model the semantics of speciﬁc component in-

terfaces (cf. (Wollschlaeger et al., 2019)). For this

reason, we did not eliminate these dimensions, but

keep them as extension points for more detailed mod-

eling. By allowing information dimensions to be un-

speciﬁed, subclass-relationships amongst the seman-

tic types can be inferred quite easily. This enables to

model semantic types with different levels of abstrac-

tion, e. g. more abstract types for system speciﬁcation

and speciﬁc types for functional component modeling

(cf. REQUIREMENT II) comprehensiveness).

After the ﬁrst iteration, step 7 tests if the ending

conditions have been met. From the objective ending

conditions, ECO3 is not met since new dimensions

and characteristics were added. As not all ending con-

ditions have been met, at least one more iteration is

needed.

4.4 Second Iteration

At the beginning of the second iteration in step 3, a de-

cision for the top-down or bottom-up approach needs

to be made. Since we identiﬁed several ambiguous

data types in iteration 1, we use the bottom-up ap-

proach in this iteration to investigate new and more

speciﬁc data types.

In step 4e, we identiﬁed missing data types that

will be added to the set of empirical objects. In to-

tal, 29 new data types have been identiﬁed, includ-

ing three new data types that were missing until now

(frost state, rain alarm, wind alarm). The further 26

data types resulted from introducing new, more spe-

ciﬁc data types for the ambiguities of D_ACT (con-

taining both date and time), L-types (describing lamp

activation or level), S-types (addressing sunblind or

lamella), as well as V_SET and V_STA (modeling ei-

ther drive position, fan rotation, or air ﬂow). The for-

mer ambiguous data types were kept as “abstract data

types” and for compatibility with the standard.

In order to semantically annotate the new data

types, we adapted the vocabulary in step 5e. More

speciﬁcally, we added new characteristics for entities

(calendar, controller, hvac, room, shading), qualities

(frost, humidity, intrusion, pressure), and representa-

tion (complex). In addition, we renamed entity vav to

ventilation and restructured some of the qualities (az-

imuth to angle.azimuth, elevation to angle.elevation,

maintenance to maintenance.position, protection to

protection.position, mode_ventilation to mode) in or-

der to better grasp the real-world relationships. There

Explain Yourself: A Semantic Annotation Framework to Facilitate Tagging of Semantic Information in Health Smart Homes

139

was no need to adapt the dimensions themselves.

At the end of iteration 2 (step 6e), the semantic

annotation framework consists of 63 annotations in

seven categories. It was successfully used to model

75 semantic data types.

After the second iteration, step 7 tests if the end-

ing conditions have been met. In order to test the

robustness (ECS2) of the taxonomy, we modeled the

dimensions, characteristics and also data types in an

OWL ontology in order to use the reasoner for con-

sistency checks and subsumption analysis. We mod-

eled the data types as deﬁned classes requiring an-

notations according to their respective characteristics.

As an example, we can deﬁne the room brightness

H_ROOM as a data type that contains information

about the FEATURE OF INTEREST light and its PHYS-

ICAL QUALITY illuminance, referring to an informa-

tion about an indoor (LOCATION) value (VARIABLE

TYPE). Usually, this value is represented as an ab-

solute value (REFERENCE TYPE). In E L

notation

(Baader et al., 2005), this yields:

H_ROOM ≡DataType

u (∃ hasFeatureOfInterest.Light)

u (∃ hasQuality.Illuminance)

u (∃ hasLocation.Indoor)

u (∃ hasVariableType.Value)

u (∃ hasReferenceType.Absolute).

(2)

The reasoner conﬁrmed the overall consistency

of the ontology and inferred a subsumption hier-

archy of types. Most of the hierarchical relations

were correct, but the following issues could be iden-

tiﬁed: First, the shading data types have no connec-

tion to each other; however, e. g. S_AUTO should

be a super type of S_AUTO_SBL (sunblind) and

S_AUTO_LML (lamella). Secondly, T_SUPPLY is

inferred to be a subclass of V_STA, which may con-

tain positions, ﬂows, or rotations, but not tempera-

tures. This is due to the too lax deﬁnition of V_STA.

From the objective ending conditions, ECO3 is

not met, since new dimensions and characteristics

were added. ECO2 is also not met since some data

types were split. As not all ending conditions have

been met, at least one more iteration is needed.

4.5 Third Iteration

Again, the type of approach has to be deﬁned in step

3 for this third iteration. In the previous iteration, two

issues were identiﬁed by using reasoning: On the one

hand, some relationships were missing (e. g. that the

data types for shading are related) and on the other

hand, some deﬁnitions were too broad, encompass-

ing non-related types (e. g. V_STA wrongly subsum-

ing T_SUPPLY). Since these main issues refer to the

semantic deﬁnition of existing data types, we choose

the top-down approach to adjust the characteristics.

In step 4c, we chose to adapt the generic room

model, which was used to specify the dimensions

FEATURE OF INTEREST and PHYSICAL QUALITY in

the ﬁrst iteration, in order to add the missing relation-

ships. Therefore, we speciﬁed that both characteris-

tics sunblind and lamella are sub-classes of the shad-

ing system and that the climatisation and ventilation

characteristics are sub-classes of the hvac system.

Since the characteristics in one dimension of the

taxonomy are only lists, we included these hierarchi-

cal relations in the semantic annotation framework

ontology, but did not change the taxonomic structure.

At this point, the transition from taxonomy towards

ontology seems beneﬁcial.

In step 5c, we modiﬁed the annotations for those

types that were deﬁned too broadly. As an exam-

ple, the type V_STA had neither annotations from

the FEATURE OF INTEREST and PHYSICAL QUAL-

ITY dimensions in order to include its possible infor-

mation types (drive position, fan rotation, air ﬂow).

We deﬁned multiple annotations in previously empty

dimensions to include all sub-types while excluding

other non-related types. This was done for the types

V_STA and V_SET, D_ACT (to include the two pos-

sible properties date and time) and the L-Types (in-

clude two possible properties activation and level).

As we did not change the dimensions or charac-

teristics in this iteration, we do not need to revise the

taxonomy in step 6c. We added relationships between

the characteristics so that a reasoner can automatically

infer additional relations between the data types. By

doing so, we go beyond a taxonomic structure, which

is not able to capture relationships amongst the char-

acteristics. Instead, this renders the semantic frame-

work to an ontology that is largely based on the de-

veloped taxonomic structure.

At the end of the procedure, step 7 again checks

the ending conditions. Since we made no changes in

the semantic annotation vocabulary and only added

relationships in the ontology, the objective ending

conditions are met this time. By using the additional

relationships, the annotation framework could be in-

creased in robustness. All other subjective ending

conditions are also met, so that the taxonomy creation

process can be concluded.

The ﬁnal and valid taxonomy for semantic data

types of the room automation aspects contains the di-

mensions and characteristics shown in Table 3.

HEALTHINF 2020 - 13th International Conference on Health Informatics

140

Table 3: The ﬁnal semantic annotation framework for the room automation aspects of HSH.

Dimensions Characteristics

FEATURE OF

INTEREST

air calendar climatisation contact controller damper

drive fan hvac lamella lamp light

occupant room shading sun sunblind valve

ventilation weather

PHYSICAL

QUALITY

activation angle.azimuth angle.elevation date dewpoint ﬂow

frost illuminance intrusion level maint.pos mode

position precipitation presence pressure protect.pos quality

rotation scene temperature time velocity

LOCATION bms equipment indoor outdoor

VARIABLE TYPE command computed setpoint state value

TRIGGER TYPE automatic manual

REFERENCE TYPE absolute relative

REPRESENTATION binary complex continuous nominal ordinal quantiﬁed

4.6 Extension Capability towards

Remaining HSH Aspects

As there are no semantic standards for further as-

pects of HSH yet, we cannot create a holistic semantic

framework for HSH at this moment. However, we can

hint at how such a framework would look like due to

the extensible nature of the developed framework for

room automation.

To include aspects such as health care and as-

sistance systems into the semantic annotation frame-

work, further iterations of the Nickerson method may

extend the characteristics. Once a common under-

standing of further HSH functionality has been es-

tablished, each of these functions can be investigated

with respect to its required and provided information.

These types of information would constitute a new set

of semantic data types that can be annotated with the

framework proposed in this paper.

With health being a major part of the missing HSH

aspects, further characteristics of the occupant need

to be added. This may include the body’s height and

weight as well as vital parameters such as pulse, blood

pressure, body temperature, breathing rate. To incor-

porate e. g. chronic diseases, closely related charac-

teristics like blood sugar level or HbA1c value for di-

abetes type 2 might be added, too.

For dementia patients with wandering behavior, a

“tracking system” might be a useful functionality for

a HSH to prevent the patients getting lost. In this case,

the functionality would involve exchanging informa-

tion about the occupant’s position (for which annota-

tions already exist), which could also be specialized

to include the GPS position components latitude and

longitude. In case of the functionality “dietary as-

sistance”, information related to food are important,

more speciﬁcally its type and the amount consumed.

Similarly, the functionality “medication reminder” is

processing medication information regarding its type

and amount. This is combined with some informa-

tion regarding the day time or speciﬁed as a rate. As

a ﬁnal example, some assistance systems are able to

identify states of emergency based on consumption

data from energy and water meters. This can be in-

corporated by the FEATURES OF INTEREST energy

and water as well as the PHYSICAL QUALITY anno-

tations consumption.current and consumption.total.

By discussing several examples from the

assistance- and health-related aspects of HSH, it

could be shown that the proposed framework is

extensible towards new semantic data types from the

HSH domain. New characteristics will be necessary

to account for speciﬁc aspects of HSH. However, it

can be expected that the structure of the framework’s

dimensions is expressive and robust, so most likely

no changes will be required here.

5 APPLICATION AREAS AND

VALIDATION

In order to validate that the proposed method for cre-

ating a semantic annotation framework has produced

a valid result, this section will discuss the applicabil-

ity of the resulting framework based on several appli-

cation areas. For each application area, we will pro-

vide an example that illustrates how the annotation

framework facilitates such applications.

Firstly, the annotation framework enables a con-

ceptual consistency check of established semantic

types due to its expressive semantic model. As has

been discussed in Section 4.3, we were able to de-

tect ambiguities in the established standard VDI 3813.

Explain Yourself: A Semantic Annotation Framework to Facilitate Tagging of Semantic Information in Health Smart Homes

141

The most important ambiguities were the data types

for lamp control – missing a distinction between

switching (activation) and dimming (level) lamps, the

types for shading control – not specifying whether

sunblind or lamella or both are controlled – and

V_SET and V_STA, which each could represent three

completely different meanings.

Secondly, the structure of the framework allows

for a seamless semantic modeling from abstract spec-

iﬁcation to detailed component models. In context of

automated design approaches for HSH this means that

by applying the proposed framework a consistent ap-

proach in semantic data modeling can be used. De-

pending on the number of dimensions used for seman-

tic speciﬁcation, the information type can be speci-

ﬁed with varying level of abstraction. While informa-

tion types in system speciﬁcations on an abstract level

might only contain core aspects, independent of real-

ization details, a detailed functional model of an as-

sistance component may feature all available dimen-

sions to model the semantic of its exchanged data as

precisely as possible. Since both cases use the same

structure, a relation between more abstract and very

speciﬁc information types can be easily determined.

As an example, a system speciﬁcation might in-

dicate that a functionality temperature controller re-

quires a temperature setpoint on the one hand and the

current temperature on the other hand. Thus, both

data types would be modeled as air (FEATURE OF IN-

TEREST) temperature (PHYSICAL QUALITY) indoor

(LOCATION). Additionally, the temperature setpoint

would be tagged with the setpoint annotation in the

VARIABLE TYPE dimension, while the current tem-

perature would be tagged with the value annotation.

A device implementing such a temperature con-

troller functionality might now additionally provide

semantic annotations for its interface. If the tempera-

ture setpoint is expected to be an offset value, it could

add the relative annotation to the REFERENCE TYPE

dimension. On the other hand, if it expects a speciﬁc

temperature value as setpoint, the annotation absolute

would be more appropriate. This additional level of

detail is vital to be able to detect a mismatch between

the sender of the setpoint and the expected seman-

tic of the data. If the sender is a room control unit

with a rotary switch for determining the setpoint off-

set, it would not be compatible with a temperature

controller expecting an absolute setpoint value.

Thirdly, as was hinted at by the example above,

the proposed framework allows for an improved in-

teroperability assessment by lifting the assessment

from a mere comparison of names to the level of ex-

pressive semantics and subsumption hierarchies. For

the temperature controller example above, instead

of comparing the semantic types T_SETPOINT and

T_SETPOINT, the more detailed versions (air, tem-

perature, indoor, setpoint, relative) and (air, temper-

ature, indoor, setpoint, absolute) can be compared.

Only this detailed comparison enables to spot inter-

operability issues – when comparing the previous se-

mantic names of the data types, issues would not have

been predicted and only noticed after installation, in-

curring high revision costs.

The downside of using a subsumption hierarchy

instead of a name-based interoperability comparison

is the more difﬁcult interoperability assessment com-

pared to string comparisons. The effect of using a

logical reasoner for interoperability assessment still

needs to be investigated more closely; however, a

component-wise interoperability assessment that in-

vestigates each dimension independently for interop-

erability could be implemented as a trade-off. As this

would involve several comparisons of strings, its per-

formance is expected to lie between single string com-

parison and logical reasoning. Since it would work

on a taxonomic structure only, a loss of expressive-

ness would be traded for a better performance. In

the future, the structure of the used semantic annota-

tion framework could be investigated to determine the

most efﬁcient interoperability assessment algorithm:

if the annotations form a taxonomy, the component-

wise algorithm would be preferred, whereas logical

reasoning is required if the framework’s structure can

only be represented as an ontology.

Lastly, the detailed semantic speciﬁcation of the

proposed framework allows for more sophisticated

analyses of semantic data types. This new depth of

understanding the semantics of a data type may be

used in future to make the component model speci-

ﬁcation process more efﬁcient and robust. This pro-

cess consists of component manufacturers specifying

a functional model of their components. Until now,

they need to specify both the component’s function-

ality and the semantics of its interface independently,

resulting in a labor-intensive process with a high er-

ror probability. Furthermore, they are restricted to

a ﬁxed list of semantic data types. If no exactly ﬁt-

ting data type is available, they need to resort to the

best ﬁt, thereby increasing the modeling error. By us-

ing the proposed semantic framework, the vocabulary

of available data types can be expanded strongly. If

none of the pre-speciﬁed data types is ﬁtting, new data

types may be easily created by specifying the different

dimensions as it seems appropriate. Unlike assigning

the semantics to data types based on their names only,

newly created data types are instantly understandable

as the annotation framework provides a high degree

of explicability.

HEALTHINF 2020 - 13th International Conference on Health Informatics

142

On the other hand, the detailed semantic under-

standing of the data types can be used for suggestion

mechanisms. Instead of choosing a data type amongst

a list or manually specifying each dimension sepa-

rately, the knowledge base of functionalities and their

semantic interface can be used to automatically infer

and suggest possible data types based on the already

speciﬁed functionalities. This suggestion mechanism

can also be applied in the other direction, suggesting

possible functionalities based on the already seman-

tically annotated component interface. Such sugges-

tion mechanisms thus connect the previously indepen-

dent aspects in the modeling process.

6 CONCLUSIONS

In this paper, we proposed an extensible semantic

annotation framework that is able to add a signif-

icant level of semantic expressiveness to informa-

tion types exchanged in information systems such

as health smart homes. We applied a well-adopted

method for taxonomy creation to end up with a basic

structure, featuring seven dimensions and 63 charac-

teristics for semantic annotations. Afterwards, it was

extended to an ontology by introducing relationships

between the annotations, which allows the use of au-

tomated reasoning to infer relations between the mod-

eled data types. Since there are currently no common

vocabularies of functionality or semantic data types

for HSH as a whole, all its aspects could not yet be

included in the semantic framework. While it is re-

stricted to room automation aspects of HSH, 75 data

types of the VDI 3813 could be successfully modeled.

Furthermore, the feasibility of extending the seman-

tic framework to encompass missing aspects could be

demonstrated in Section 4.6 by adding new annota-

tions while preserving the general framework struc-

ture. This fulﬁlls REQUIREMENT III) extensibility).

With its aspect-oriented approach and the deﬁ-

nition of different dimensions of semantic annota-

tions, the approach is able to specify semantics in de-

tail and to meet REQUIREMENT I) explicability, sur-

passing the expressiveness capabilities of using mere

data type names to encode semantics. Since multi-

ple dimensions can be taken into account, the frame-

work also allows for a seamless semantic data model-

ing from abstract speciﬁcation to detailed component

modeling, starting from a few dimensions to fully en-

compass all aspects of semantic data as demanded by

REQUIREMENT II) comprehensiveness).

We demonstrated how different applications are

facilitated by the proposed semantic annotation

framework – namely, it enables a consistency check

on established semantic types, it improves the qual-

ity of interoperability assessments, and it lays the

foundation for streamlining the process of specifying

semantic models for automation components by en-

abling auxiliary suggestion functionalities.

As next steps, we intend to put the semantic anno-

tation framework into action by further investigating

the mentioned application areas. Improved interop-

erability assessment and support functions for model

speciﬁcation seem to be the most promising applica-

tions as of now. Furthermore, once a consolidation of

functionality and data types is achieved for the whole

domain of HSH, we plan to extend the framework so

that is encompasses HSH as a whole. In order to in-

tegrate the semantic annotation framework with exist-

ing tagging approaches, ontology matching and merg-

ing approaches might be a viable tool to consolida-

tion of interdisciplinary semantic vocabularies (e. g.

the nomenclature of health informatics provided by

the IEEE 11073).

We consider the increased semantic expressive-

ness offered by the annotation framework as vital for

increasing the degree of automation of the design pro-

cess of HSH and as an enabler for an increased pro-

liferation of assistance technology applications in the

future.

ACKNOWLEDGEMENTS

The work for this paper was funded by the European

Social Fund and the Free State of Saxony (Grant no.

100310385). The authors would also like to offer spe-

cial thanks to Lena Otto and the other members of the

junior research group Care4Saxony for their valuable

feedback on the manuscript.

REFERENCES

Baader, F., Brandt, S., and Lutz, C. (2005). Pushing the EL

envelope. In IJCAI - Int. Joint Conf. on AI, pages 364–

369.

Balaji, B., Bhattacharya, A., Fierro, G., Gao, J., Gluck, J.,

Hong, D., Johansen, A., Koh, J., Ploennigs, J., Agar-

wal, Y., Berges, M., Culler, D., Gupta, R., Kjærgaard,

M. B., Srivastava, M., and Whitehouse, K. (2016).

Brick: Towards a Uniﬁed Metadata Schema For Build-

ings. In Proceedings of the 3rd ACM International

Conference on Systems for Energy-Efﬁcient Built Envi-

ronments, BuildSys ’16, pages 41–50, New York, NY,

USA. ACM.

Bonino, D. and Corno, F. (2008). DogOnt - Ontology Mod-

eling for Intelligent Domotic Environments. In Sheth,

A., Staab, S., Dean, M., Paolucci, M., Maynard, D.,

Finin, T., and Thirunarayan, K., editors, The Semantic

Explain Yourself: A Semantic Annotation Framework to Facilitate Tagging of Semantic Information in Health Smart Homes

143

Web - ISWC 2008, pages 790–803, Berlin, Heidelberg.

Springer Berlin Heidelberg.

Butzin, B., Golatowski, F., and Timmermann, D. (2017).

A survey on information modeling and ontologies in

building automation. In IECON 2017 - 43rd Annual

Conference of the IEEE Industrial Electronics Society,

pages 8615–8621.

Charpenay, V., Käbisch, S., Anicic, D., and Kosch, H.

(2015). An ontology design pattern for IoT device tag-

ging systems. In 2015 5th International Conference on

the Internet of Things (IOT), pages 138–145.

Compton, M., Barnaghi, P., Bermudez, L., García-Castro, R.,

Corcho, O., Cox, S., Graybeal, J., Hauswirth, M., Hen-

son, C., Herzog, A., Huang, V., Janowicz, K., Kelsey,

W. D., Phuoc, D. L., Lefort, L., Leggieri, M., Neuhaus,

H., Nikolov, A., Page, K., Passant, A., Sheth, A., and

Taylor, K. (2012). The SSN ontology of the W3C se-

mantic sensor network incubator group. Journal of Web

Semantics, 17:25 – 32.

Daniele, L., den Hartog, F., and Roes, J. (2015). Study on se-

mantic assets for smart appliances interoperability: D-

S4: Final report. European Commission, Brussels.

Dibowski, H. and Kabitzsch, K. (2011). Ontology-based de-

vice descriptions and device repository for building au-

tomation devices. EURASIP Journal on Embedded Sys-

tems, 2011:3:1–3:17.

Dibowski, H., Ploennigs, J., and Kabitzsch, K. (2010). Auto-

mated design of building automation systems. IEEE

Transactions on Industrial Electronics, 57(11):3606–

3613.

Gallaher, M., O’Connor, A., Dettbarn, J., and Gilday, L.

(2004). Cost Analysis of Inadequate Interoperability

in the U.S. Capital Facilities Industry. techreport, Na-

tional Institute of Standards and Technology.

Grassi, M., Nucci, M., and Piazza, F. (2013). Ontolo-

gies for smart homes and energy management: An

implementation-driven survey. In 2013 Workshop on

Modeling and Simulation of Cyber-Physical Energy

Systems (MSCPES), pages 1–3.

Haux, R., Koch, S., Lovell, N. H., Marschollek, M.,

Nakashima, N., and Wolf, K.-H. (2016). Health-

enabling and ambient assistive technologies: Past,

present, future. Yearb Med Inform, Suppl. 1(Suppl

1):76–91. 27362588[pmid].

IEC 60050-351 (2013). International electrotechnical vocab-

ulary - Part 351: Control technology.

ISO/IEEE 11073-10101a (2015). Health informatics – Point-

of-care medical device communication – Part 10101:

Nomenclature Amendment 1: Additional Deﬁnitions.

Koﬂer, M. J., Reinisch, C., and Kastner, W. (2012). A se-

mantic representation of energy-related information in

future smart homes. Energy and Buildings, 47:169 –

179.

Lösser, B., Oberländer, A. M., and Rau, D. (2019). Taxon-

omy Research in Information Systems: A Systematic

Assessment. In Proceedings of the 27th European Con-

ference on Information Systems (ECIS), Stockholm and

Uppsala, Sweden.

Maeder, A. J. and Williams, P. A. H. (2017). Health smart

homes: New challenges. Studies in health technology

and informatics, 245:166–169.

Nickerson, R. C., Varshney, U., and Muntermann, J. (2013).

A method for taxonomy development and its applica-

tion in information systems. European Journal of In-

formation Systems, 22(3):336–359.

Pelesic, I., Fernbach, A., Granzer, W., and Kastner, W.

(2016). Semantic Integration in Building Automation

A Case Study for KNX , oBIX and Semantic Web Ap-

plications. In Proceedings of the KNX Scientiﬁc Con-

ference.

Pomp, A., Paulus., A., Jeschke., S., and Meisen., T. (2017).

Eskape: Information platform for enabling semantic

data processing. In Proceedings of the 19th Inter-

national Conference on Enterprise Information Sys-

tems - Volume 2: ICEIS,, pages 644–655. INSTICC,

SciTePress.

Rialle, V., Duchene, F., Noury, N., Bajolle, L., and Demon-

geot, J. (2002). Health "Smart" Home: Information

Technology for Patients at Home. Telemedicine Jour-

nal and e-Health, 8(4):395–409. PMID: 12626109.

Schachinger, D., Fernbach, A., and Kastner, W. (2017).

Modeling framework for IoT integration of build-

ing automation systems. at-Automatisierungstechnik,

65(9):630–640.

Sommaruga, L., Formilli, T., and Rizzo, N. (2011). Do-

moML: An Integrating Devices Framework for Ambi-

ent Intelligence Solutions. In Proceedings of the 6th In-

ternational Workshop on Enhanced Web Service Tech-

nologies, WEWST ’11, pages 9–15, New York, NY,

USA. ACM.

Tazari, M.-R., Furfari, F., Fides-Valero, Á., Hanke, S., Höft-

berger, O., Kehagias, D. D., Mosmondor, M., Wichert,

R., and Wolf, P. (2012). The universAAL Reference

Model for AAL. In Handbook of Ambient Assisted Liv-

ing.

VDI 3813-2 (2011). Building automation and control sys-

tems (BACS). Room control functions (RA functions).

Vermesan, O., Friess, P., et al. (2014). Internet of things-

from research and innovation to market deployment,

volume 29. River publishers Aalborg.

Welge, R., Busch, B.-H., Kabitzsch, K., Laurila-Dürsch, J.,

Heusinger, S., Lipprandt, M., Eichelberg, M., Eichen-

berg, E., Engelien, H., Gök, M., Moritz, G., Hein, A.,

and Dutz, T. (2015). AAL-Onto: A Formal Represen-

tation of RAALI Integration Proﬁles. In Wichert, R.

and Klausing, H., editors, Ambient Assisted Living: 7.

AAL-Kongress 2014 Berlin, Germany, January 21-22,

2014, pages 89–102. Springer International Publishing,

Cham.

Wollschlaeger, B., Eichenberg, E., and Kabitzsch, K. (2019).

Switching to a holistic perspective on semantic com-

ponent models in building automation – tapping the

full potential of automated design approaches. IOP

Conference Series: Earth and Environmental Science,

323:012047.

Wollschlaeger, B. and Kabitzsch, K. (2019). Navigating the

Jungle of Assistance Systems: A Comparison of Stan-

dards for Assistance Functionality. In Proceedings of

the 12th International Joint Conference on Biomedi-

cal Engineering Systems and Technologies - Volume 5:

HEALTHINF, pages 359–366. INSTICC, SciTePress.

Wollschlaeger, B. and Kabitzsch, K. (2020). Automated En-

gineering for Health Smart Homes: Find a Way in the

Jungle of Assistance Systems (accepted). Studies in

health technology and informatics.

HEALTHINF 2020 - 13th International Conference on Health Informatics

144