Towards a Data Model of End-User Programming of Applications

Marko Palviainen

, Jarkko Kuusijärvi

, Timo Tuomisto

and Eila Ovaska

Digital Systems and Services, VTT Technical Research Centre of Finland, P.O. Box 1000, FI-02044, Espoo, Finland

Digital Systems and Services, VTT Technical Research Centre of Finland, P.O. Box 1100, FI-90571, Oulu, Finland

Digital Systems and Services, VTT Technical Research Centre of Finland, P.O. Box 1300, FI-33101, Tampere, Finland

Keywords: Data Model, Tiles4Data Data Model, End-User Programming, Post-Processing of Data.

Abstract: End-user programming produces applications that can produce and/or consume data. An end-user can be a

software enthusiast or non-programmer. In this paper end-users are understood to be non-programmers that

are interested in creating applications for their personal needs and daily tasks. An interesting research

question is how the input and output data of end-users’ applications should be represented? What kind of a

data model is needed for this data? And how this input and output data can be utilised? Firstly, the data

model should be designed for end-users so that the data model is easy to comprehend and utilise by non-

programmers. Secondly, the data model should be suitable for SW professionals that make functionalities

available for end-user programming. Thirdly, the data model should be designed so that it is possible to

provide reusable processing components for input/output data represented via this model. This paper

discusses these three research questions and outlines a data model, called the Tiles4Data data model that is

designed for the above requirements.

1 INTRODUCTION

There is a strong trend towards integration of the

capabilities and data of separate software systems.

The Internet of Things (IoT) (Fielding, 2000)

technologies enable creation of interoperable

devices, applications, and digital services being

capable of interacting across vendor and industry

domain boundaries. In addition, there will be more

and more smart spaces that enable users to share

information, to monitor their environment and to

control it. In United States and Europe the public

sector is continuously opening computer-readable

data (for example, geographical data, weather data,

and environmental data) to be used freely for

commercial and non-commercial use (Auer et al,

2007; Poikola et al, 2011). Furthermore, open

source, OpenStreetMap, Wikipedia, and social

media communities provide open data.

There are (at least) two perspectives to data, i.e.,

who produces it and who consumes it. In addition,

three common needs relate to the use of data; the

users want to i) see what is in the data (i.e., need

visualisations for the data), ii) share data for other

users and iii) monitor the interesting changes/trends

in the data. A software system can be designed for

these needs but at the implementation phase it is

almost impossible to identify all the needs of various

users and the needs that will possibly arise in the

future. Thus, there is a strong need for End-User

Programming (EUP) that enables the users to tailor

the software systems for their needs and daily tasks.

In our vision, the end-users will be involved in the

integration of capabilities and data: a) The

capabilities and data of the existing software systems

are opened for end-user programming by using IoT

and smart space technologies. b) The opened data is

represented via a uniform data model supporting the

interoperability of data and interoperability of

configurable components processing the data. There

will be two kinds of data: professional data and end-

user data. Professional data are represented via data

models that software professionals can use and

comprehend. The end-user data are data that: a) are

understandable and interesting for end-users and b)

are represented via data models that are designed for

end-users.

As a contribution, this paper outlines the

Tiles4Data data model for EUP that: a) Is based on

the basic concepts such as number, time and location

that the end-users use in their everyday life, b)

provides a simple set of data primitives and data

composites and means for SW professionals to open

data for EUP and c) finally enables the easy use of

data for non-programmers. This paper focuses on

data relating to the EUP of cross-smart space

applications (see details from Palviainen et al, 2012,

272

Palviainen M., Kuusijärvi J., Tuomisto T. and Ovaska E..

Towards a Data Model of End-User Programming of Applications.

DOI: 10.5220/0005109602720281

In Proceedings of 3rd International Conference on Data Management Technologies and Applications (DATA-2014), pages 272-281

ISBN: 978-989-758-035-2

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

2012b and 2014). The Tiles4Data data model creates

the following added value for its users:

 Domain data – The data that experts and

professionals of a specific domain produce and

use. The drivers based on the Tiles4Data

provide this data available for end-users.

 Driver specifications – The data model provides

a standard model to provide Semantic End-User

Application Programming Interfaces (S-APIs),

drivers and driver environments available for

EUP.

 End-user’s applications – The data model

provides a standard model to describe the end-

user’s applications produced by EUP tools.

 Output data – The data model provides a

standard way for an application to publish

output data.

 Input data – The data model provides a standard

way for an application to consume input data.

The added values the Tiles4Data data model

provides are: 1) The systematic way to create

reusable and configurable drivers that visualise the

S-APIs and application scripts to end-users. 2) The

systematic way to process data, visualise data, share

data and monitor data relating to the execution of an

end-user’s application.

This paper is structured as follows. Section 2

describes background related to the Tiles4Data data

model, Section 3 describes the design of the

Tiles4Data data model and then Section 4

exemplifies the use the Tiles4Data data model.

Discussion related to the approach is provided in

Section 5. Finally, conclusions are drawn in Section

2 BACKGROUND

In the beginning of the history of electricity

appliances the lack of standards of electricity

voltages and electricity frequencies caused problems

for electricity producers, consumers and device

manufacturers. Over time the 230 V standard has

become widespread so that 230 V equipment can be

used in most parts of the world with the aid of an

adapter or a change to the equipment's connection

plug for the specific country (Wikipedia, 2014). The

situation in the information age data is like in the

electricity appliances in the beginning, there are no

generic standards for data but a huge number of

different kinds of data formats are used in the

software systems causing problems for data

producers, data consumers and the developers of

applications and digital services. For example,

handling of various data formats causes

dependencies between the client code and legacy

software components and makes it more difficult to:

Implement reusable processing components for the

data and replace the software components with new

ones. Thus, there is a great need for data models

standardising the representation of data. The rest of

this section discusses the terminology used in this

paper, the models used in the representation of data,

open data and open APIs and the existing EUP

approaches.

Terminology

2.1

The following terminology is used in this paper (part

of the terms are taken from (Palviainen et al, 2012,

2012b and 2014)):

Professional API – An API that is targeted for

programmers and for the software development.

S-API – The S-API describes capabilities

(commands) and the inputs, outputs and execution

branches of the commands and assists the use of

professional APIs by providing easy access to the

information/operational capabilities that are

available in the professional APIs.

Driver – implements S-API and makes the

capabilities and data of professional APIs available

for end-user programming. A driver is a reusable

and configurable processing component that can

process data, visualise data, share data and monitor

data in the application execution phase or in the

post-processing phase.

Driver specification – A driver specification

defines a symbolic name, an S-API and possibly a

run-time identifier (URI) for a driver.

Application script – An end-user’s application is

described as an application script consisting of

driver specifications and execution sequences

(commands) that are executed in the application

execution phase or in the post-processing phase.

Data Models

2.2

The World Wide Web has been originally designed

for direct human processing. In order to better

support machine processing there has been

developed the next-generation Web, called Semantic

Web for establishing semantic interoperability on

the Web and for enabling construction of intelligent

and interoperable services — such as information

brokers, search agents, and information filters —

which offer greater functionality than the current

stand-alone services (Decker et al, 2000).

Extensible Mark-up Language (XML) (W3C,

2000) and Resource Description Framework (RDF)

(W3C, 2004) standards support establishing of

semantic interoperability on the Web, but XML

addresses only document structure. RDF better

TowardsaDataModelofEnd-UserProgrammingofApplications

273

facilitates data interoperation, representation and

exchange by providing a data model that can be

extended to address sophisticated ontology

representation techniques (Decker et al, 2000).

Furthermore, languages such as SPARQL (W3C,

2008) and N3 (Berners-Lee and Conolly, 2011) can

be used in description of queries for semantic data.

The Gleaning Resource Descriptions from Dialects

of Languages (GRDDL) is a mark-up based on

existing standards: for declaring that an XML

document includes data compatible with the RDF

and for linking to algorithms (typically represented

in XSLT) that are capable of extracting this data

from the document (Bodle, 2011). JavaScript Object

Notation (JSON) is a lightweight data-interchange

format that is easy for humans to read and write and

is easy for machines to parse and generate (JSON,

2014).

Linked Data has the potential to enable a

revolution in how data is accessed and utilised

(Berners-Lee et al, 2009). The success of Web APIs

has shown the power of applications that mash up

content from different Web data sources. However,

application developers face the challenge of scaling

their development approach beyond fixed,

predefined data silos, to encompass large numbers of

data sets with heterogeneous data models and access

methods (Berners-Lee et al, 2009).

The described techniques support representation

of data but are not designed for end-users since the

use of these techniques requires technical knowledge

and typically only SW professionals can use them.

Open Data and Open APIs

2.3

The idea of open data is to make data or part of data

freely available to everyone to use and republish as

they wish, without restrictions from copyright,

patents or other mechanisms of control (Auer et al,

2007). In United States, Great Britain and other parts

of Europe there is a clear tendency to increase the

utilisation of open data (Poikola et al, 2011). For

example, the European Union (EU) has INSPIRE

directive (Inspire, 2014) that tends to create an

environmental spatial data infrastructure across

Europe and enable the public access to this data.

The more lightweight business model of Web

2.0 companies emphasizes the “read/write” Web.

Significant content flows both upstream and

downstream from the site’s users and therefore users

are both purchasers and contributors (Greaves,

2007). This business model also often includes open

APIs that let companies share their data and leverage

others’ data. Thus, open APIs provide new ways of

sharing and participating and support

interoperability by providing the tools to share data

used to develop Web applications, achieve seamless

integration of social media services, and give rise to

mutually beneficial third-party developer

ecosystems that build on top of social media

platforms (Bodle, 2011).

The open data and open APIs are now more

targeted for software professionals and software

enthusiasts. There is a clear need for approaches

providing the open data and capabilities of open

APIs available for EUP of applications.

End-User Programming

2.4

The EUP methods aim at bridging the gap between

the use and programming of applications (Mørch,

1998; Mørch et al, 2004). For example, the

programming-by-example (Hartmann et al, 2007),

visual programming (Kovatsch, 2010), script-based

creation (Ousterhout, 1998), repository-based

creation (Miller, 2003), and tailoring of applications

techniques (Won et al, 2006) are introduced for

EUP.

We have developed an end-user programming

approach (Palviainen et al, 2012, 2012b and 2014)

supporting interoperability of smart spaces and

creation of cross-smart space applications. The

approach is based on easy-to-apply S-APIs and on

driver specifications that are first added to the

application to define the drivers that are used in the

application. The execution sequence is then

composed of the commands of the specified drivers.

Unlike professional APIs, the S-API does not just

define operations and the inputs and outputs of

operations but structures, i.e., commands that also

describe the execution branches to which the end-

users can bind other commands. Thus, the end-user

does not need to use if-else structures in

programming; but the “if” is implemented inside a

command, whereas the execution branches define

the “then” branches to which the end-user can insert

other commands. In addition, end-users can easily

tailor applications for new purposes by inserting

commands to the execution branches that relate to

the commands of an application. This paper extends

our EUP approach by outlining how the data related

to EUP should be represented so that end-users

could benefit from this data in the EUP and

execution phases of applications.

3 THE DESIGN OF THE

Tiles4Data DATA MODEL

The Tiles4Data data model is depicted in Figure 1. It

is designed for the representation of data relating to

our EUP approach (Palviainen et al, 2012, 2012b

and 2014) that consists of four main steps: a) The

DATA2014-3rdInternationalConferenceonDataManagementTechnologiesandApplications

274

driver development, b) end-user programming, c)

application execution and d) post-processing steps.

The SW professionals are responsible for the driver

development, producing S-APIs and drivers that

open the professional data and capabilities of

professional APIs to end-users. Application’s input

data and output data can contain domain data and

data about the user’s preferences, user’s context

(e.g., user’s location), user’s input, execution path of

the application and errors related to the application

execution. The post-processing of this data is based

on drivers, too. Thus, the same driver components

can be used in the application execution and post-

processing phases. The use of a driver in post-

processing requires that it is connected to a smart

space that is used in post-processing. The end-user

can then see the driver’s capabilities in the EUP tool,

select the capabilities for post-processing and

configure the inputs of the selected capabilities for

using the capabilities for various purposes and for

various kinds of data.

The next subsections discuss the design of the

Tiles4Data data model (in Figure 1) from two

viewpoints: from the software professional’s

viewpoint and end-user’s viewpoint. However, these

viewpoints overlap and many of the presented issues

are related to the both viewpoints.

Viewpoint 1 – Software

3.1

Professionals

The Tiles4Data data model must be suitable for SW

professionals that develop S-APIs and drivers for

end-user programming. Thus, it must support:

Representation of Interesting Data – The data

model should enable easy: a) use of data and b)

representation of data that is interesting for end-

users and used in the everyday life of end-users. We

used the composite pattern (Gamma et al, 1995) and

data types of the existing programming languages

such as Java and C++ as a starting point in the

design of the Tiles4Data data model. In order to

make the learning curve smoother for non-

programmers, the data is described by using a small

number of easy-to-apply data elements that are

Figure 1: The elements of the Tiles4Data data model are used for describing the end-user data.

Tiles4Data DataModel

Content-References

Cross-References

Data Primitives

Data Composites

Core Elements

Tiles4Data

+Name

+DataType

AdditionalData

<<DataCollection>>

DataCollection

<<Tiles4Data>>

CrossReference

<<DataCollection>>

Content-Reference

<<Tiles4Data>>

Text

<<Tiles4Data>>

Boolean

<<Tiles4Data>>

Number

<<Tiles 4Data>>

Range

<<Tiles4Data>>

Unit

<<Text>>

Duration

<<Number>>

BeginTime

<<Number>>

GPSLocation

<<Text>>

List

<<DataCollection>>

Image

<<Content-Reference>>

Route

<<DataCollection>>

Cell

<<DataCollection>>

Table

<<DataCollection>>

WebPage

<<Co ntent-Reference>>

Audio

<<Content-Reference>>

Video

<<Content-Reference>>

ContentLink

<<Co ntent-Reference>>

List Section

<<Cross-Reference>>

Table Section

<<Cross-Reference>>

Route Section

<<Cross-Reference>>

DomainData

+DomainType

Guidance

<<DataCollection>>

TowardsaDataModelofEnd-UserProgrammingofApplications

275

based on concepts such as number, time, and

location that the users use in their everyday life. The

use of composite pattern enables easy creation of

hierarchical data structures i.e., the data primitives

and data composites can be composed to other data

composites. The Tiles4Data data model contains 8

primitive types and 5 composite types. Primitive

types are: Text, Boolean, Number, Range, Unit,

Begin Time, Duration, and GPS Location.

Composite types are List, Table, Cell, Route and

Guidance.

Representation of Interesting Fragments of Data

– Often only a small fraction of the available data is

interesting for the user. For a programmer it is easy

to write a small snippet of code extracting the data

from the data structure but how could a non-

programmer use only small fractions of the data?

One possibility is to put (at least) a part of the

burden of data selection for the SW professionals

that open data for EUP. For this purpose there are

provided cross-reference elements that do not

contain data but: i) refer to elements of data

collections that could provide interesting data for the

end-user, ii) define a descriptive name for the

referred data and iii) thus assists the use of

interesting fragments of data in the drivers. The

cross-reference element types of the Tiles4Data data

model are: List Section, Table Section and Route

Section.

Representation of Interesting Content related to

Data – In many cases streamed content such as

textual, image, audio, and video content could add

value to the provided data. In cross-smart space

applications, the streamed content is not directly

transported between the smart spaces and drivers but

this kind of content is embedded in the data model

by using the content-reference elements that refer to

(i.e., specify URLs for) the streamed content. The

content-reference element types of the Tiles4Data

data model are: Web Page, Image, Audio, Video and

Content Link.

Adding Value to the Data – Meta-data and

quality information of data will increase the value of

data (Immonen et al, 2014 and 2014b). It is possible

to add additional data (e.g., meta-data, cross-

reference elements, content-reference elements and

guidance elements) to each data element of the

Tiles4Data data model to enhance the usability/value

of the provided information and guide the end-users

in the use of data. The additional data can provide a

textual description for the data, describe the origin of

the data, or even provide a reference to a preview

image that a default visualization component has

produced for the data.

Evolution of Data – Often in software

development projects it is difficult to create data

structures to cover all possible use cases. In addition,

this will lead to a more and more complex data

models that: Will evolve over the time and are

difficult to maintain and use. The Tiles4Data domain

data models consist typically of few elements and

the structures of data models do not evolve over

time. However, it is easy to add additional data to

the models and to ensure the backward compatibility

of the models, i.e., the data that was available in the

previous data model will exist in the extended data

model, too. If a completely new data model is

needed, a new model and domain type (URL) must

be defined for the new domain data model.

Transportation of Data – The prototype of the

Tiles4Data data model is implemented in Java. The

GSON library (GSON, 2014) is capable of

converting Java objects to JSON and vice-versa. We

used the GSON and implemented toolkits for

Tiles4Data to JSON and for JSON to Tiles4Data

conversions. Thus, the Tiles4Data data can be

exported to JSON format, transported to other

drivers that finally import the data from the received

JSON objects.

Viewpoint 2 – End-Users

3.2

The Tiles4Data data model is designed to assist the

use of data in the EUP and application execution

steps. The Tiles4Data data model supports:

Selection of Interesting Data – In order to

support selection of data elements, each Tiles4Data

data element has a data type (e.g., text, number or

table). A name and domain type can also be defined

for the data elements. The names, data types, domain

types and cross-reference elements support the

selection of data; the drivers can be configured to

select data that has a particular name, data type,

and/or domain type.

Selection of Drivers – The data type and domain

type are used in the selection of drivers. For

example, a visualisation driver could take only data

collections as an input.

Validation of the Output-Input Connections of

Drivers – The EUP tool uses the data types and

domain types of the Tiles4Data data for type

checking for ensuring that only compatible output-

input connections are created; the tool that can either

prevent creation of invalid output-input connections

or then warn the end-user about invalid output-input

connections (e.g., visualise invalid connections with

a red colour).

Visualisation and Browsing of Data – Often the

use of data requires visualisations for the data. It is

easy to implement drivers to provide visualisations

for the hierarchical Tiles4Data data that enable the

end-user to browse the data and to see what kind of

data is available. Application scripts, S-APIs, driver

specifications, and application’s input data and

DATA2014-3rdInternationalConferenceonDataManagementTechnologiesandApplications

276

output data are represented as Tiles4Data data, too.

As a benefit, in the EUP phase it is easy to provide

visualisations for: a) application scripts to assist the

user to comprehend what happens inside an

application and thus assists the selection and

tailoring of an application, b) S-APIs to assist in

searching and understanding of the capabilities and

data provided in S-APIs, and c) driver specifications

to assist the searching of drivers for different

purposes.

Sharing of Data – The sharing data for other

applications and users is based on drivers that are

capable of: a) publishing Tiles4Data data to shared

databases and b) querying/fetching Tiles4Data data

from the shared databases.

Monitoring of Data – This is based on the

drivers that monitor the execution environment,

react to the changes in the environment and inform

the user about the changes in the Tiles4Data data.

4 EXAMPLE – THE USE OF

Tiles4Data DATA MODEL FOR

ELECTRICITY DATA

This section exemplifies how the Tiles4Data data

model can be used in the representation of domain

data and how the reusable drivers can process,

visualise, share, and monitor the Tiles4Data data in

the application execution phase.

Creation of a Tiles4Data Data

4.1

Model

The Nord Pool Spot (Nord Pool Spot, 2014)

provides electricity spot price data (open data) via a

Web Service. We decided to implement a driver for

the Nord Pool Spot and by this way opened the

service’s capabilities and data for EUP.

In the driver implementation, we first created a

representation for electricity price of the Tiles4Data

elements in Java. The electricity spot price data is

represented as a table containing number primitives

(see Figure 2). Each number primitive provides

additional data that defines the unit (cents / kWh) for

the number and time when the data value is valid

i.e., begin time and duration for the value in

milliseconds. The EUP tool must represent the time

values in more user-friendly way, for example, “the

begin time is “28

May 2014 4 pm”. The name of

the electricity producer text element and the

“Electricity Prices for Last Day” and “Electricity

Prices for Last Night” cross-reference elements were

added as an additional data to the table. As a result,

it is easy for the end-user to configure a visualizer

driver to represent “Electricity Prices for Last Day”

in a line diagram because (s)he does not need to

exactly define the cells providing the data in

question. Moreover, the end-user could, for

example, use the time values of the data to limit the

visualized price information for a given day. A

WebPage element was added as a guidance element

to provide a URL link to the Nord Pool Spot market

place.

Secondly, we used a transformer tool for

transforming the created Tiles4Data data model into

a Java class offering direct methods to assist the use

of the data elements of the Tiles4Data data model in

the drivers. Thirdly, we defined an S-API for the

driver and transformed a driver skeleton from the S-

API and finally implemented the actual driver code

in Java. The driver contains the getElectricityPrice

command that reads electricity price data form the

Nord Pool Spot, represents this data via the

Tiles4Data data model, and finally provides the

electricity price data as an output.

Processing of the Tiles4Data Data

4.2

We have an early stage prototype for the browsing

view of the Tiles4Data data that enables the user to

see what kind of data is available and configure the

processing parameters for the data. An example of a

very simple reusable and configurable processing

component is a driver that calculates the average

(i.e., creates a new representation for the data) of the

numbers existing in a table. The user must configure

the inputs of the driver to define that the average is

calculated from the number elements (that are

produced in the execution of an application) whose

domain type is

“http://electricity.com#ElectricityPrice”. The driver

represents the calculated average as a Tiles4Data

number whose domain type is “http://electricity.com

#ElectricityPrice”. In addition, the user can

configure that additional data is attached to the

produced Tiles4Data number to define a unit (cents /

kWh) for the average number.

Visualisation of the Tiles4Data

4.3

Data

The visualisation of data is based on reusable drivers

that can be configured to produce (e.g., diagram, tree

and table) visualisations for the whole data or only

for the data elements of cross-references, or for the

specific kind of elements (selection is based on the

data types or domain types) of the data model.

Figure 3 depicts diagram, bar and tree visualisations

for hourly electricity price data, electricity use and

electricity costs. The visualisations are produced by

using a configurable driver that is capable of

TowardsaDataModelofEnd-UserProgrammingofApplications

277

Figure 2: A Tiles4Data data model for electricity price

data.

Figure 3: Diagram and tree visualisations for electricity

price data.

visualising the Tiles4Data data in a browser view by

using HTML5 and various HTML5 visualisation

libraries, such as RGraph JavaScript library

(RGraph, 2014) and D3 (D3, 2014).

Sharing of the Tiles4Data Data

4.4

The user’s unique id such as the user’s phone

number and timestamp is attached to the published

Tiles4Data data. The query of Tiles4Data data is

based on: user ids, timestamps, data types and

domain types and on reusable and configurable data

fetching drivers. The user can configure a data

fetching driver to query data that his/her friends

have produced to a shared database or try to fetch

specific kind of domain data from the database. For

example, the user could use this driver to fetch

location data about his/her friends from the shared

database and then use other driver to visualise

his/her friends’ locations in a map view.

The administrators of databases must take care

of the garbage collection of the shared data. Most of

the produced and consumed data is thought as open

and therefore requires no security measures to be

taken into operation. On the other hand, if the

applications using open data are used for business or

for example, to control the usage of electrical

appliances, the confidentiality, integrity, and

availability of the data (e.g., provided by the Nord

Pool Spot) has to be assured. Garbage collection,

security and privacy issues are not in the focal point

of this paper, but these should be taken into account

when a data is shared into an open database.

Monitoring of the Tiles4Data Data

4.5

Monitoring context or value changes is enabled by a

reusable driver that monitors and classifies

Tiles4Data data. The driver is first configured to

monitor data whose domain type is

“http://electricity.com#ElectricityPrice”. Secondly, a

limit or a range is configured for the data value. For

example, the user can define that if the numeric

value is over 15 (cents / kWh) then the result will be

a textual Tiles4Data data that has value “Electricity

Price is High”. The representation of data is

changed, too; a textual explanation is produced from

the numeric value. Thereafter, this textual

explanation is delivered to a reusable driver that

sends the Tiles4Data data to a desired email address.

Naturally, an application can be running in the

background of the user’s smart phone and the user

can be notified by a toast or similar as an alternative.

5 DISCUSSION

A great and interesting benefit of the Tiles4Data

data model is the possibility to create reusable and

configurable processing components (i.e., drivers)

for data originating from different domains. These

Ele ct ric it yPric e s

<<Table>>

+DomainType: htt p://electricity .com#ElectricityPriceC ollection

Ele ct ricit y

Price Cell

<<Cell>>

+Row: 1

+Column: 1

Elec t r ic ity Price from 16 to 17 o'clock 28th

2014

<<Number>>

+DomainType: http://electricity.com#ElectricityPrice

+Value: 15

Unit for Electricity Price

<<Unit>>

+DomainType: http://electricity.com#CentsPerKWH

Ele ct ric it y Pro duce r A

<<Text>>

+DomainType: http://electricity.com#ElectricityProducer

When this price data is valid.

<<BeginTime>>

+BeginTime: 1401281949833

Ele ct ricit y Pric e s for La st Da y

<<Cross-Reference>>

+BeginRow: 1

+EndRow: 8

+Column: 2

Electricity Prices for Last Night

<<Cross-Reference>>

+BeginRow: 15

+EndRow: 24

+Column: 2

Electricity Prices for Last Evening

<<Cross-Reference>>

+BeginRow: 9

+EndRow: 14

+Column: 2

Duration

<<Duration>>

+Duration: 3600000

Help for

Ele ct ric it y

User

<<Guidance>>

Help Te xt

<<Text>>

+Value: This data model prov ides electricity price data from the last day.

Market Place for Electricity

<<WebPage>>

+URL: http//www.nordpoolspot.com

+De scription: Elect ricity price data is obtained f rom Nord Pool Spot.

DATA2014-3rdInternationalConferenceonDataManagementTechnologiesandApplications

278

components enable the end-users to create rich and

meaningful applications tailored to their specific

needs and also make the modification of these

applications easy and fast.

The RDF and JSON provide generic and

standard ways for describing data. The RDF or

JSON based data can be represented via the

Tiles4Data data model and the Tiles4Data data

model can be represented as an RDF or JSON data.

Thus, the Tiles4Data data model can be seen as a

layer inserting convenience methods to the RDF or

JSON based data models to assist the use and

production of data. Firstly, there are ready-made

methods for searching data elements based on the

name, data type and domain type. Secondly, in

generic data formats such as in RDF there are many

alternative ways for describing the data and it can be

difficult to decide how the data should be

represented. The Tiles4Data provides a very limited

set of building blocks for describing data and data

structures. It is easy to learn to use the Tiles4Data

data models, the development of data models is

more straightforward and the development time of

drivers is shorter. This is a crucial issue; a great

number of drivers and developers implementing

drivers for EUP should exist. Easy-to-use data

models are one important step towards this. The

limited data model makes the development of EUP

tools easier, too. Compared to very generic data

models, it is easier to provide EUP tools for a

limited and predefined set of data elements. For

example, in comparison to RDF, a tailored UI can be

provided for each Tiles4Data data element type to

assist the end-user in the input of data and in the use

of data.

It is important to note that the Tiles4Data data

model does not yet provide a complete solution for

all kind of data. However, it is possible to extend the

model with new elements for needs that may

possibly arise in the future. Although more

validation is needed for the Tiles4Data data model,

our initial tests show that:

 The use of the composite pattern enables

flexible creation of hierarchical data

structures and thus the Tiles4Data data

model suits well for the representation of

hierarchical domain data. However, streamed

data cannot be directly represented via the

Tiles4Data data model but the handling of

streamed data is based on the content-

reference elements and on the drivers

capable of using the referred content for

different purposes.

 The Tiles4Data data model is used in the

EUP phase and execution phase of

applications. Driver specifications, S-APIs,

application scripts and applications’ domain

specific input/output data, such as the

electricity price data and electricity

consumption data are represented as

Tiles4Data data.

 The Tiles4Data domain data models do not

evolve over time. However, it is always

possible to add additional data to enhance the

usability/value of the provided information.

The additional data does not prevent the

backward compatibility of the model, i.e., the

data that was available in the data model will

exist in the extended data model, too. Thus,

the evolution of data structures is supported,

too.

 Reusable and configurable drivers can be

provided for the Tiles4Data data. As a result,

the end-users will get more possibilities to

affect the utilization of data. For example,

the data can be visualized in a way that is

suitable for a particular user, the data can be

flexibly shared with other users, and the end-

users can configure monitoring mechanisms

for the data, too.

 The development of data models/drivers

requires co-operation with the end-users; the

developers must co-operate with the end-

users, understand what data and what

fractions of data are interesting for the end-

users, and implement drivers that provide the

interesting data and the required additional

data as Tiles4Data data.

However, the Tiles4Data data model still needs to

be:

 Applied to represent different kinds of

domain data and the usage experiences have

to be analyzed, and

 Validated from the end-user perspective by

performing usability tests in a field in order

to ensure that the non-programmers can

really comprehend and use the Tiles4Data

data model in different kinds of application

domains.

6 CONCLUSIONS

This paper describes the Tiles4Data data model that

is designed i) for end-users, ii) for SW professionals

that open capabilities and data of legacy software

systems for end-user programming, and iii) for post-

processing of data. In our vision, the applications

created in end-user programming represent data via

an easy-to-apply Tiles4Data data model that is easy

to comprehend and use by the non-programmers.

The Tiles4Data data model extends our end-user

TowardsaDataModelofEnd-UserProgrammingofApplications

279

programming approach; the drivers can

communicate in different data formats with legacy

software components. However, the input data and

output data of the drivers is represented via the

Tiles4Data data model that enables: a) composition

of data from a small set of easy-to-apply data

elements, b) insertion of additional data to the data

elements, c) definition of cross-references that

specify data elements that are assumed to be

interesting for the end-users, and d) definition of

content-references to assists the end-users in the use

of the data.

The Tiles4Data data model enables creation of

reusable drivers capable of automatically processing

the Tiles4Data data for different purposes,

visualising the data, sharing the data, and monitoring

changes in the data. Typically the use of drivers

requires configuration effort. The user must: a)

Decide which data is interesting and b) configure the

drivers to perform the desired processing for the

interesting data.

REFERENCES

Auer, S., Bizer, C., Kobilarov, G., Lehmann, J., Cyganiak,

R. and Ives, Z., 2007. DBpedia: A Nucleus for a Web

of Open Data. The Semantic Web. Springer Berlin

Heidelberg.

Berners-Lee, T. and Connolly, D. (Eds.), 2011. Notation3

(N3): A readable RDF syntax,

http://www.w3.org/TeamSubmission/n3/.

Berners-Lee, T., Cyganiak, R., Hausenblas, M., Presbrey,

J., Seneviratne, O. & Ureche, O. E., 2009. Realising A

Read-Write Web of Data.

Bodle, R., 2011. Regimes of sharing. Information,

Communication and Society, 14, 320-337.

Decker, S., Melnik, S., Van Harmelen, F., Fensel, D.,

Klein, M., Broekstra, J., Erdmann, M. & Horrocks, I.,

2000. The Semantic Web: the roles of XML and RDF.

Internet Computing, IEEE, 4, 63-73.

D3, 2014. D3 Javascript Library [Online] Available from:

http://d3js.org/

Fielding, R. T., 2000. Architectural styles and the design

of network-based software architectures. University of

California, Irvine.

Gamma, E., Helm, R., Johnson, R. & Vlissides, J. (1995)

Design Patterns, Addison-Wesley.

Greaves, M., 2007. Semantic Web 2.0. Intelligent Systems,

IEEE, 22, 94-96.

GSON, 2014. Google-gson [Online] Available from:

http://code.google.com/p/google-gson/

Hartmann, B., Wu, L., Collins, K. & Klemmer, S. R.,

2007. Programming by a Sample: Rapidly Creating

Web Applications with d.mix. Proceedings of the 20th

annual ACM symposium on User interface software

and technology. Newport, Rhode Island, USA, ACM.

Immonen, A., Palviainen, M. & Ovaska, E., 2014.

Requirements of an Open Data Based Business

Ecosystem. IEEE Access, 2, 88-103.

Immonen, A., Palviainen, M. & Ovaska, E., 2014b.

Towards open data based business: Survey on usage of

open data in digital services. International Journal of

Research in Business and Technology, 4, 286-295.

INSPIRE, 2014. INSPIRE directive [Online] Available

from: http://inspire.jrc.ec.europa.eu

JSON, 2014. JavaScript Object Notation (JSON) [Online]

Available from: http://www.json.org/

Kovatsch, M., Weiss, M. & Guinard, D., 2010.

Embedding internet technology for home automation.

IEEE Conference on Emerging Technologies and

Factory Automation (ETFA).

Miller, R. C., 2003. End-user Programming for Web

Users. The End User Development Workshop at CHI

Conference. Ft. Lauderdale, Florida, USA.

Mørch, A. I., 1998. Tailoring tools for system

development. Journal of Organizational and End User

Computing (JOEUC), 10, 22-29.

Mørch, A. I., Stevens, G., Won, M., Klann, M., Dittrich,

Y. & Wulf, V., 2004. Component-based technologies

for end-user development. Communications of the

ACM - End-user development: tools that empower

users to create their own software solutions, 47, 59-

62.

Nord Pool Spot, 2014. Nord Pool Spot [Online] Available

from: http://www.nordpoolspot.com.

Ousterhout, J. K., 1998. Scripting: Higher level

programming for the 21st century. IEEE Computer,

31, 23-30.

Palviainen, M., Kuusijärvi, J. & Ovaska, E., 2012.

Framework for End-User Programming of Cross-

Smart Space Applications. Sensors, 12, 14442-14466.

Palviainen, M., Kuusijärvi, J. & Ovaska, E., 2012b.

Architecture for end-user programming of cross-smart

space applications. the 4rd International Workshop on

Sensor Networks and Ambient Intelligence (SeNAmI

2012). Lugano, Switzerland.

Palviainen, M., Kuusijärvi, J. & Ovaska, E., 2014. A semi-

automatic end-user programming approach for smart

space application development. Pervasive and Mobile

Computing, 12, 17-36.

Poikola, A., Kola, P. & Hintikka, K. A., 2011. Public data-

an introduction to opening information resources.

Ministry of Transport and Communications, Helsinki,

Finland.

RGRAPH, 2014. RGraph: HTML5 charts library [Online]

Available from: http://www.rgraph.net/

WIKIPEDIA, 2014. Wikipedia, ”Mains electricity,”

[Online] Available from:

http://en.wikipedia.org/wiki/Mains_electricity#Voltag

e_levels.

Won, M., Stiemerling, O. & Wulf, V. (Eds.), 2006.

Component-Based Approaches to Tailorable Systems,

Dordrecht, Netherlands, Springer.

W3C (Ed.), 2000. Extensible Markup Language (XML)

1.0 (Second Edition).

DATA2014-3rdInternationalConferenceonDataManagementTechnologiesandApplications

280

W3C (Ed.), 2004. RDF Vocabulary Description Language

1.0: RDF Schema.

W3C (Ed.), 2008. SPARQL query language for RDF.

TowardsaDataModelofEnd-UserProgrammingofApplications

281