PlanetData
Network of Excellence
FP7 – 257641
D12.1.1NorthPole Case studies:
definition, requirements and design
Coordinator: David Norheim, Computas
With contributions from: Jens Kilde Mjelva, Computas;
Dumitru Roman, Sintef
2nd
1st Quality reviewer: Irene Celino
Quality reviewer: Steffen Stadtmüller
Deliverable nature:
Report (R)
Dissemination level:
Public (PU)
(Confidentiality)
Contractual delivery date:
30.11.2011
Actual delivery date:
Version:
0.7
Total number of pages:
31
Keywords:
LOD case studies, applications, use case specification, architectural design
PlanetData
Deliverable D12.1.1
Abstract
This document introduces two case studies / applications for consuming Norwegian linked open data
motivated from end-user needs combined and the value added by considering integration of new data sets.
The applications’ aim is to show practical benefits of aggregating open data for end-users and for data
journalists.
The two case studies are called Regional Development and Environmental Friendly Behaviour. The case
studies are described with a problem description and exemplified using storyboards. Furthermore, the two
applications are detailed with requirements specification, high-level architecture and design. An initial
validation plan for the case studies is outlined. This deliverable is meant to indicate and guide the
development and validation process of the two applications.
Page 2 of (31)
Deliverable D12.1.1
PlanetData
Executive summary
With the recent interest in LOD, combined with the highest Internet penetration in Europe after Iceland, and
second only to Sweden on mobile internet access in Europe, Norway offers interesting opportunities for
becoming a great testbed for consuming LOD data. In the context of PlanetData we aim at establishing such
a testbed – PlanetData-NorthPole – by creating applications consuming Norwegian LOD. In particular we
aim at providing case studies in highly sensitive domains for governments and the general public such as
regional development and environmental friendly behaviour, with a specific localization on Norway;
improve the existing Norwegian LOD and extend it with new data sets to support the proposed case studies;
and provide guidelines for other countries in the use of LOD for regional development and environmental
friendly behaviour applications. This document addresses the definition of the two case studies, the
requirements specification, the architectural design of the applications supporting the case studies, and the
preliminary validation plan of the two case studies. This document is meant to provide the necessary
information so that the tasks of prototype design & development will be able to deliver the needed
applications for validation.
The criteria for selecting the case studies for Norwegian LOD has been based on various aspects such as:
existence of a clearly identified end-user, with a clear need, allowing verification of the apps created;
consumption of several Norwegian data sets; availability of data sets as open data, preferably as linked open
data; potential of each additional data set to brings additional value to the application; possibility for the apps
to be replicated outside of Norway by configuration and/or making similar data sets available, etc. A
preliminary analysis of such aspects resulted in two case studies in the area of Regional Development and
Environmental Friendly Behaviour.
The Regional Development case study addresses the problem of how to speed up and improve the process of
collecting and aggregating data for monitoring regional developments. This has resulted in the specification
of use cases related to configuration of new data sets, visualisation of data distributed over regions, access to
relevant data for specific municipalities in Norway. Based on these use cases, a set of detailed system
requirements and a system architecture have been derived and are presented in this document. This case
study shall be relevant for data-journalists in Norway, both from the broadcasters and news agencies, who
have requested a tool allowing ad-hoc combinations of datasets in their regional footprint. A tool based on
linked data will increase its value as new datasets become available. Visualization and investigation should
also be available for public use, allowing citizens to drill into public data. User workshop testing and
questionnaire will validate this case study.
The Environmental Friendly Behaviour case study addresses the problem of deciding the most
environmental-friendly transportation options when faced with different transportation options for a short
regional trip, given constraints like time, weather, traffic and private preferences. This has resulted in the
specification of use cases related to access to transportation alternative(s) to next scheduled meeting in user’s
calendar, and visualization of various app-generated transport alternatives in the calendar application. Based
on these use cases, we present a set of detailed system requirements and a system architecture. This case
study shall be relevant for any citizen interested in applications assisting them in environmental friendly
behaviour. User field-testing and a questionnaire will validate this case study.
Page 3 of (31)
PlanetData
Deliverable D12.1.1
Document Information
IST Project
Number
Full Title
Project URL
Document URL
EU Project Officer
FP7 - 257641
PlanetData
Deliverable
Number
D12.1.1.
Title
Work Package
Number
WP12
Title
Date of Delivery
Status
Nature
Dissemination level
M14
Contractual
Actual
version 0.6
final□
prototype□ report □ dissemination □
public□ consortium □
Acronym
PlanetData
http://www.planet-data.eu/
Leonhard Maqua
NorthPole Case
studies: definition,
requirements,
design
NorthPole
M14
Authors (Partner)
Name
Partner
Responsible Author
Abstract
(for dissemination)
Keywords
David Norheim
Computas
E-mail
Phone
david.norheim@computas.com
+47 95946949
LOD, Norway, Application
Version Log
Issue Date
2011-11-06
Rev. No.
0.1
Author
David Norheim
2011-11-08
0.2
Dumitru Roman
2011-11-09
2011-11-11
0.3
0.4
Jens Kilde Mjelva
David Norheim
2011-11-11
0.5
Dumitru Roman
2011-11-11
2011-11-18
0.6
0.7
Stig Dørmænen
David Norheim (ed.)
Change
Intial version collected from wiki
pages
Minor changes and comments to the
content
Added more details on use cases
Completing the sections on
architecture and methodology and
validation
Overall improvements to the
document, focus on abstract,
executive summary, introduction
Review of architecture
Based on comments from reviewers.
Page 4 of (31)
Deliverable D12.1.1
PlanetData
Table of Contents
Executive summary ........................................................................................................................................... 3
Document Information ...................................................................................................................................... 4
Table of Contents .............................................................................................................................................. 5
List of figures .................................................................................................................................................... 6
List of tables ...................................................................................................................................................... 7
Abbreviations and Definitions ........................................................................................................................... 8
1 Introduction ................................................................................................................................................. 9
2 Motivation ................................................................................................................................................. 10
2.1 Why Regional Development? ............................................................................................................. 10
2.2 Why Environmental Friendly Behaviour? .......................................................................................... 11
2.3 Problem statements ............................................................................................................................. 13
2.3.1 Regional development ................................................................................................................. 13
2.3.2 Environmental Friendly Behaviour .............................................................................................. 14
3 Case studies specification ......................................................................................................................... 15
3.1 Use cases descriptions ........................................................................................................................ 15
3.1.1 Case study Regional Development .............................................................................................. 15
3.1.2 Case study Environmental Friendly Behaviour ........................................................................... 17
3.2 Requirements specification................................................................................................................. 19
3.3 Architecture ........................................................................................................................................ 24
3.3.1 Regional Development................................................................................................................. 24
3.3.2 Environment Friendly Behaviour................................................................................................. 25
3.4 Sketches of user interfaces ................................................................................................................. 27
3.5 Development methodologies .............................................................................................................. 29
4 Validation .................................................................................................................................................. 30
References ....................................................................................................................................................... 31
Page 5 of (31)
PlanetData
Deliverable D12.1.1
List of figures
Figure 1 – Open data sets related to Regional Development. Lines are potential links. ................................. 11
Figure 2 - Some relevant Norwegian open data sets related to environment and transport. Lines are potential
links. ......................................................................................................................................................... 12
Figure 3 - Regional Development Story Board ............................................................................................... 13
Figure 4 - Environmental Friendly Behaviour Story Board ............................................................................ 14
Figure 5 - Architecture of the Regional Development App ............................................................................ 24
Figure 6- Architecture of the Environmental Friendly Behaviour App........................................................... 25
Figure 7 - Illustration of a possible user interface for the Environmental Friendly Behaviour app ................ 27
Figure 8–Illustration of a Geo Chart................................................................................................................ 27
Figure 9–Illustration of a Geo Chart with details ............................................................................................ 28
Figure 10 - Scrum methodology ...................................................................................................................... 29
Page 6 of (31)
Deliverable D12.1.1
PlanetData
List of tables
Table 1 Use case 1.1 ........................................................................................................................................ 15
Table 2 Use case 1.2 ........................................................................................................................................ 16
Table 3 Use case 1.3 ........................................................................................................................................ 16
Table 4 Use case 2.1 ........................................................................................................................................ 17
Table 5 Requirements for case study 1 Regional Development ...................................................................... 19
Table 6 Requirements for case study 2 Environmental Friendly Behaviour ................................................... 21
Table 7 - Selection of required capabilities for the visualisation library ......................................................... 25
Table 8 Platform decision comparison table ................................................................................................... 26
Page 7 of (31)
PlanetData
Deliverable D12.1.1
Abbreviations and Definitions
LOD - “Linked Open Data”. Data sets publically available following the Linked Data principles1
Data Set - A collection of related sets of information that is composed of separate elements but can be
manipulated as a unit by a computer. (Oxford Dictionary)
1
http://www.w3.org/DesignIssues/LinkedData.html
Page 8 of (31)
Deliverable D12.1.1
1
PlanetData
Introduction
Norway is one of a handful of countries outside of the English-speaking world with a clear commitment to
open data.2 Being one of the first countries to implement the PSI-directive as a law in January 2009,3 each
new governmental project is today required to address publication of the data it creates or processes.
Simultaneously the community focusing on linked open data is ever increasing, and major governmental
agencies are involved in making their data available as Linked Open Data (LOD). However, as we write
2011, few if any, applications are using LOD as their data source.
We believe that the interest in LOD, combined with the highest Internet penetration in Europe after Iceland,4
and second only to Sweden on mobile internet access in Europe, Norway offers interesting opportunities for
becoming a great testbed for consuming LOD data. In the context of PlanetData we aim at establishing such
a testbed – PlanetData-NorthPole – by creating applications consuming Norwegian LOD. In this deliverable
we outline two case studies in highly sensitive domains for governments and the general public such as
regional development and environmental friendly behavior, as part of our endeavor of showing the use of
Norwegian LOD in practical settings.
This deliverable is part the deliverables “NorthPole” which focus on consuming and improving Norwegian
Linked Open Data for Regional Development and Environmental Friendly Behaviour. The overall objectives
are:
1. To specify and implement two case studies for demonstrating the use and benefits of LOD in
regional development and environmental friendly behaviour, with a particular localization on
Norway;
2. To improve the existing Norwegian LOD and extend it with new data sets to support the proposed
case studies;
3. To provide guidelines for other countries in the use of LOD for regional development and
environmental friendly behaviour applications.
This document addresses the first item and specifically aims to
1. define two case studies in the area of regional development and environment friendly behaviour,
respectively, localized in Norway,
2. detail requirements for the two case studies, and
3. outline an architecture and create a preliminary validation plan of the two case studies.
This document will provide the necessary information so that the tasks of T12.2 Prototype Design &
Development will be able to deliver the needed prototypes for validation.
This document is organized as follows. Section 2 describes the context and motivation for the two case
studies. Section 3 describes the requirements, high-level architecture and design, as well as the development
process for the two corresponding implementations. Finally, Section 3 outlines a validation plan for the two
case studies implementations.
2
http://www.data.gov/opendatasites
In Norwegian: http://www.lovdata.no/all/hl-20060519-016.html#9
4
http://www.techreaders.com/wp-content/uploads/2010/09/European-countries-with-the-highest-Internetpenetration.png
3
Page 9 of (31)
PlanetData
2
Deliverable D12.1.1
Motivation
The general motivation for the two case studies comes from brainstorming on scenarios that fulfil more than
one of the following criteria
1) A clear identified end-user, with a clear need, allowing verification of the apps created
2) Consuming several Norwegian data sets
3) The data sets are available as open data, preferably as linked open data
4) Each additional data set brings additional value to the application
5) An application created with traditional technologies would not be as agile/extendable as a LOD
consuming app.
6) Apps can be replicated outside of Norway by configuration and/or making similar data sets available
The two applications selected are called Regional Development and Environmental Friendly Behaviour
described in the following sections.
2.1
Why Regional Development?
Why? According to the Norwegian Government5, the overall objectives for its rural and regional politics
include freedom and equality when it comes to economical, social, demographical and environmental
conditions in counties and municipalities. Regions are often faced with challenges such as lack of
competitiveness and need for regeneration to various political challenges. The long-term trends and effects of
development schemas are however often not well understood and readily available to the public. Local news
agencies and the general public are often served numbers without being able to look behind the scene; it is
often hard to compare trends except what is served to you as ready-made illustrations through the official
channels from national statistics agencies and research agencies. There is a clear need in this domain for
support in creating visualization tools over statistical data or aggregated data to follow the long term effects
of regional development.
What and how? Inspired by Hans Rosling’s famous presentation tool Gapminder6, we will build this case
study focusing on innovations and development in various sectors in regions and municipalities. Central
Norwegian public sector data owners have opened their data as linked open data during 2010. The
Brønnøysund Registry Center7 has opened the national organization registry, Enhetsregisteret8. Others,
notably the Norwegian Research Council9, have already used the de-referable URIs from Enhetsregisteret
while publishing their own data sets. This case study will require the need to improve existing company
registry service (exporting also NACE codes), and to include geographical information (linking to
Kommuneregisteret10, the details of municipalities and counties). In addition it requires the use of
visualization tools. The successful implementation of this case study is dependent on improving the quality
of the data and links in the existing Norwegian LOD, and on useful and flexible analytics and visualization
of the linked data, which will be developed as part of this case study.
Some relevant data sets for Regional Development are shown in Figure 1. The data sets will be examined in
detail the deliverable D12.2.1 Report on Quality improvements of existing Norwegian LOD.
5
http://www.regjeringen.no/en/dep/krd/Subjects/rural-and-regional-policy.html?id=1238
http://www.gapminder.org
7
http://www.brreg.no/english
8
http://www.brreg.no/registrene/enhet
9
http://www.forskningsradet.no/en
10
http://www.kommunenokkelen.no/adresse/side2.do?side=kommuneregisteret
6
Page 10 of (31)
Deliverable D12.1.1
PlanetData
Figure 1 – Open data sets related to Regional Development. Lines are potential links.
2.2
Why Environmental Friendly Behaviour?
Why? The current Norwegian government has made a point that environmental friendly behaviour should
pay off. However, behaving environmental friendly is not an easy task even if financial incentives are there.
For example, often the information about public transportation and availability of city bikes is not as easily
available when a trip decision needs to be taken. In such situations, there is a need for applications that
combine linked open data in the environmental domain as a decision making tool.
What and how? In the private sector a number of applications and mobile apps have been created as a result
of the open-data initiatives. In Norway this includes applications ranging from real-time public transportation
information11, snow and ski conditions12, the presence of electric cars charging stations13, real time status for
city bike stands14, weather forecasts15 and many more. Common to all this is that they use only one source of
open information. Our proposed case study in the environmental domain will combine the use of
transportation (e.g. public transportation, electric cars parking lots, bikes stands) to events (e.g. concerts, art
galleries) while including other decision relevant real-time information (e.g. forecast, traffic messages). We
are in dialog with the Oslo municipality who are making this data available as open data. The application
will be made as a mobile app. The overall goal here is to invoke the citizen’s own interest in environmental
friendly behaviour. The successful implementation of this case study is dependent on extending the existing
Norwegian LOD with new data sets and ensuring the quality of the new data sets and their proper linking to
the existing Norwegian LOD, as well as on the usability of such an environmental friendly behaviour
application, which will be developed as part of this case study.
11
Trafikanten http://trafikanten.no/no/mobil/iPhone/
iMarka, http://www.nxcinteractive.com/nxcinteractive/Portfolio/iMarka
13
LadeNå!, http://www.apphuset.com/apps/ladenaa/
14
City Bikes, http://www.oslobysykkel.no/
15
Yr.no, http://itunes.apple.com/us/app/yr-no/id300709016?mt=8
12
Page 11 of (31)
PlanetData
Deliverable D12.1.1
Some relevant data sets for Environment Friendly Behaviour are shown in Figure 2. The data sets will be
examined in detail in WP12.2 – Improving and enhancing the Norwegian LOD, resulting in a report D12.2.1
Report on Quality improvements of existing Norwegian LOD.
Figure 2 - Some relevant Norwegian open data sets related to environment and transport. Lines are
potential links.
Page 12 of (31)
Deliverable D12.1.1
2.3
PlanetData
Problem statements
In the following the two case studies are detailed with problem descriptions, relevant stakeholders and then
exemplified by storyboards.
2.3.1
Regional development
Problem statement:
How can we speed up and improve the process of collecting and aggregating data for monitoring regional
developments?
Who are the Stakeholders? Data-journalists in Norway, both from the broadcasters and news agencies, have
requested a tool allowing ad-hoc combinations of datasets in their regional footprint. A tool based on linked
data will increase its value as new datasets become available. Visualization and investigation should also be
available for public use, allowing citizens to drill into public data.
The picture below illustrates the Regional Development case study in the form of a storyboard.
Figure 3 - Regional Development Story Board
Page 13 of (31)
PlanetData
2.3.2
Deliverable D12.1.1
Environmental Friendly Behaviour
Problem statement:
Faced with different transportation options for a short trip, which are the most environmental-friendly
options given constraints like time, weather, traffic and private preferences.
The added value proposition is to enable smarter/faster environmental friendly decision making for local
trips when options are available
Who are the stakeholders? Citizens interested in applications assisting them in environmental friendly
behaviour.
The picture below illustrates the Environmental Friendly Behaviour case study in the form of a storyboard.
Figure 4 - Environmental Friendly Behaviour Story Board
Page 14 of (31)
Deliverable D12.1.1
3
PlanetData
Case studies specification
This section provides a more detailed specification of the case studies in terms of supported use case,
requirements specification, architecture of the applications, and the user interfaces.
3.1
Use cases descriptions
The use cases are described with a use case template covering actors, stakeholders, successful and alternative
scenarios and more. The use cases are broken down into functional steps.
3.1.1
Case study Regional Development
In the case of Regional Development we have three identified use cases

Create a visualisation of data distributed over geographical regions

Get details about a specific municipality

Configure new data sets
These are detailed below.
Table 1 Use case 1.1
ID
1. 1
Title
Create a visualisation of data distributed over geographical regions.
Actors
Data-journalist
Coverage
Selecting data sets and variables in order to create a visualization of how regions
and/or municipalities are performing.
Stakeholders
Data set owner
Data journalist
Trigger
User has a hypothesis or facts he wants to visualise using available data.
Pre-conditions
Data sets available as linked open data.
Minimum result
Visualisation of data distributed over regions.
Success results
1. The user launches the application.
Main scenario
2. The application presents data sets and relevant variables.
3. The user selects one or more variables.
4. The data is visualized in maps.
Alternative
scenarios
Comments
Open questions
Priority
1
Relevant to
Case study Regional Development
Page 15 of (31)
PlanetData
Deliverable D12.1.1
Table 2 Use case 1.2
ID
1. 2
Title
Get details about a specific municipality.
Actors
Data-journalist
Coverage
Details showing what is known about the municipality in the currently available
linked data sets.
Stakeholders
Data set owner
Data journalist
Trigger
Clicking on a municipality (or region).
Pre-conditions
Use case 1.1
Minimum result
Listing data values in one municipality (or region)
Success results
1. The user has the application running.
Main scenario
2. He clicks on a specific region.
3. The system shows the details of the data values.
Alternative
scenarios
Comments
Open questions
Priority
2
Relevant to
Case study Regional Development
Table 3 Use case 1.3
ID
1. 3
Title
Configure new data sets
Actors
Data Administrator
Coverage
Setting up a new data set containing regional data variables.
Stakeholders
Data set owner
Data journalist
Trigger
New dataset is available as Linked Open Data.
Pre-conditions
The data set is available as linked data with links to regions. The data contains links
to regions.
Minimum result
Data is available for use case 1.1
Success results
Main scenario
1. The data administrator adds a reference to the new dataset.
2. The system lists the data set as available.
Alternative
scenarios
Comments
Page 16 of (31)
Deliverable D12.1.1
PlanetData
Open questions
Priority
3
Relevant to
Case study Regional Development
3.1.2
Case study Environmental Friendly Behaviour
Table 4 Use case 2.1
ID
2. 1
Title
Find transportation alternative(s) to next scheduled meeting in the user’s calendar
Actors
Meeting attendant
Coverage
Launching the application and “asking” it to find transportation alternatives from the
user’s current geo-position to the location of the next meeting in the user’s calendar.
Stakeholders
“Normal citizen”
Data set owners
Trigger
TBD
Pre-conditions
Transportation data sets available as linked open data.
User has a mobile device with:

Read and write access to user’s calendar.

Access to user’s geo-location, i.e. the coordinates of the user’s current position
Minimum result
Seeing one or more transportation alternatives generated from the app to the calendar
application, if any found
Success results
Easily see the differences in CO2 emission and time consumption between the
various transport events in the calendar. Hence the user has a solid platform when it
comes to choosing the best means of transportation.
Main scenario
1. The user launches the application.
2. The application generates requests to transportation linked open data
where arguments are based on the current position of the user and the
location of the user’s next calendar event.
3. Based on the available data the transportation alternatives are calculated.
4. Transportation alternatives are added as separate events to the user’s
calendar including environmental details and risk factors.
5. A “Transportation alternative(s) were added to your calendar” message
is displayed to the user.
6. The user opens his calendar application to view the generated
transportation alternatives.
7. The various transportation alternatives are displayed as separate events
in the calendar and include emission- and time consumption data.
Alternative
scenarios
1. No Transportation alternatives where found during the calculation.
2. A “ No transportation alternatives were found” message is displayed to the user.
Comments
Page 17 of (31)
PlanetData
Deliverable D12.1.1
Open questions
Priority
1
Relevant to
Case study Environmental Friendly Behaviour
Page 18 of (31)
Deliverable D12.1.1
3.2
PlanetData
Requirements specification
The table below shows the requirements for the two applications.
Table 5 Requirements for case study 1 Regional Development
Req.
#
Req. type
(Functional
/Nonfunctional)
Use case Description
ref.
Rationale
Acceptance
criteria
Priority
1=high
5=low
What is the system registering (user-input)?
1
F
UC-1.1
The system shall
register data set
selections
Selecting one or more
datasets shall be
possible in order to
control which data the
system will base its
visualizations on.
Verify that the
1
app only
visualizes data in
the sets selected
by the user
2
F
UC-1.1
The system shall
register data
variable selections
Selecting one or more
variables in a dataset
shall be possible in
order to limit which
data the system will
visualize.
Verify that the
app only
visualizes data
that is described
by the variables
selected by the
user
1
3
F
UC-1.2
The system shall
register selections
of parts of the
visualized data
Selecting an element
in the visualized data
shall return details of
the selected data
Verify that the
data in a
visualization is
clickable and
that clicks return
more details
3
What data/systems should be available to the system, what interfaces to which systems?
4
F
UC-1.1
The system shall be
connected to a chart
visualization
system
A chart visualization
system shall be
connected to the
system in order to
display location based
data
Verify that the
system can
connect to a
chart
visualization
system
1
5
F
UC-1.1,
Various Linked
Open Data shall be
available to the
system either
through RESTful
web service
request(s) or
SPARQLendpoints.
LOD shall be available
to the system in order
to have data to base
the visualizations on
Verify datasets
are available to
the system
1
UC-1.2,
UC-1.3
What should the system update (change, delete, add)?
Page 19 of (31)
PlanetData
6
F
Deliverable D12.1.1
UC-1.3
The system should
be able to add more
LOD sets to
visualize data from
Addition of new
datasets should
enhance the
visualization
possibilities
Verify that it is
possible to add
new LOD data
sets to the
system and that
the added data is
available for
analysis.
3
What shall the system calculate/compute?
7
F
UC-1.1
The system shall
present the user
with visualizations
of the selected data
sets
What shall the system deliver to the user?
The visualizations
shall be the core part
of the system
Verify that the
1
selected data sets
and/or variables
get visualized
8
F
UC-1.1,
The system shall
present the user
with datasets and
variables to choose
to base the
visualization on
The system shall
visualize data
connected to a
geographical
location on a geo
chart
The selectable datasets
and variables shall
correspond to the data
(LOD) the system is
connected to.
Verify that all
data sets the
system is
connected to are
selectable
1
Geo chart
visualisations are
powerful for
presenting geo-data.
Verify the
possibility of
visualizing data
on a geo chart.
3
The LOD should be
interlinked where
possible
This should let the
visualizations be based
on combinations of
two or more datasets
Verify that data
describing the
same thing are
doing this the
same way
3
The application
should be available
through web
browsers without
plugins
The application
shall be user
friendly
The independence of
plugins like Flash will
make the tool more
acceptable.
Verify that the
system works
w/o plugins.
3
For the application to
work give a good
overview, it must be
efficient and effective
to use.
Verify a user’s
perception of the
effectiveness
and efficiency of
the application.
2
UC-1.2
9
F
UC-1.2
Data model
10
F
UC-1.3
Non-functional requirements
11
N
UC-1
12
N
UC-1
Page 20 of (31)
Deliverable D12.1.1
PlanetData
Table 6 Requirements for case study 2 Environmental Friendly Behaviour
Req.
#
Req. type
(Functional
/Nonfunctional)
Use case Description
ref.
Rationale
Acceptance
criteria
Priority
1=high
5=low
The app should read all
it needs from the users
calendar and linked
data. If configuration
data is needed it should
not be though the app
itself.
Verify that the
app is working
without adding
information
manually.
3
What is the system registering (user-input)?
1
F
UC-2.1
The user shall not
have to enter any
information when
starting the app.
What data/systems should be available to the system, what interfaces to which systems?
2
F
UC-2.1
Various Linked
Open Data shall
be available to the
system either
through RESTful
web service
request(s) or
SPARQLendpoints.
The app shall need at
least data describing
real-time public
transportation
information and CO2 emission data in order to
generate transportation
alternatives.
Verify that at
least public
transportation
data and one
other
transportation
data set as well
as emission data
is available as
LOD.
1
3
F
UC-2.1
Private user data
– calendar events
and the
geographic
position of the
user – shall be
made available to
the app.
The coordinates of the
user’s geographical
position and the events
in the calendar on the
user’s mobile device
shall be needed in order
to form the requests to
the data sets described
in req. #2
Verify that the
app has readand write access
to the users
calendar data
and read access
to the
geographical
position of his
mobile device
1
4
F
UC-2.1
Communication,
forming requests The system shall
generate requests
to the required
LOD systems.
The system shall form
request to other (LOD)
systems in order to get
the data that will form
the basis for creating the
calendar events
Verify that the
application
forms valid
requests to
LOD-systems
based on the
private data.
1
An initial request
will be formed
with arguments
fetched from the
closed (user) data
from req. #3, e.g.:
“Find the 15
closest public
transportation
stops to the user’s
position”
Page 21 of (31)
PlanetData
5
F
Deliverable D12.1.1
UC-2.1
Communication,
handling replies The system shall
parse the data it
receives and add
emission
information to a
transport
alternative by
combining
emission data
with the transport
data.
The responses from the
requests the app sends to
the LOD-systems shall
contain the data needed
to add the described
transportation
alternatives as calendar
events by the
application.
Verify that the
app can parse
and keep
representation of
the LOD, public
transportation
data (and at least
one other
transportation
data set)
combined with
emission data, in
the application
memory.
1
Transportation calendar
events shall be needed
in order to form basis
for the user to choose a
mean of transportation,
i.e. whether to use
public transportation or
a taxi to get to his/her
next scheduled calendar
event.
Verify that a
programmaticall
y added
transportation
event with
emission data
has been added
to the user’s
device’s
calendar when
the app
terminates.
1
For the application to be
worth using, it should
provide the user with
“correct” travel
proposals.
Verify that the
added calendar
entries are
describing travel
proposals from
the user’s
position to the
actual location
of the event the
proposals were
generated from.
3
What should the system update (change, delete, add)?
6
F
UC-2.2
Application result
The system shall
add entries
(events) to the
user’s calendar
corresponding to
the transportation
alternatives
found. The added
calendar event(s),
i.e. travel
alternatives shall
at least contain
the following
information:
Start time, end
time, transport
type, route
description and
environmental
friendliness (e.g.
CO2 emission).
What shall the system calculate/compute?
7
F
UC-2.2
Application result
quality - The
added calendar
entries should to
be of quality w.r.t.
taking the user
from his current
position to the
actual address of
the calendar event
the entries where
based on.
What shall the system deliver to the user?
Page 22 of (31)
Deliverable D12.1.1
8
F
PlanetData
UC-2.2
User notifications
The app could
display a
notification
telling whether
transportation
alternatives where
found or not.
Feedback from the
application to the user
could inform the user
that the application has
really made something
happen.
Verify that the
3
user has received
an indication
that the
application has
“done
something”
when the app
terminates.
UC-2
The data lifting
and application
shall try to utilise
common linked
data vocabularies
for transportation
and environment.
This would make it
possible to use the
application in other
regions.
Verify that the
LOD actually
contains links to
other
vocabularies
describing
transportation
and/or
environment
3
The application
shall be user
friendly.
For the application to
work in the stressful
setting described, it
must be efficient and
effective.
Verify a user’s
perception of the
effectiveness
and efficiency of
the application.
2
Data model
9
F
Non-functional requirements
10
N
UC-2
Page 23 of (31)
PlanetData
3.3
Deliverable D12.1.1
Architecture
The next sections describe the architecture for the two applications, the Web-based application for the
Regional Development and the Mobile-based application for the Environment Friendly Behaviour. The
description of the data sets will not be covered here.
3.3.1
Regional Development
The architecture for this application is based on a web-client architecture using a Map visualisation API
preferably a JavaScript library. The data will be accessed using pure HTTP GET Linked Data URLs. Figure
5 shows the architecture for this application.
Map
visualisation
API
Organization
Register Data
LOD
DBPedia
HTTP
CS 1
Application
…
…
Figure 5 - Architecture of the Regional Development App
3.3.1.1
Web application decision factors
Map visualisation libraries should comply to the following requirements:

RDF support. Since the transport data we use come in an RDF format, support for easy handling of such
data via APIs should be possible. E.g. parse an RDF-file into a structure that is easy to work with in the
code.


Alternative: serialize the data as JSON/RDF, making "native parsing" easier (this option has its
drawback in that most Linked Data will not as of today deliver RDF in JSON format though there
is an upcoming standard from W3C).
Visualisation capabilities. Having the best foundation a choice of a good visualisation library is
important to get started. An analysis of required visualisation capabilities is given in the table below.
Page 24 of (31)
Deliverable D12.1.1
PlanetData
Table 7 - Selection of required capabilities for the visualisation library
Charting
Usability
Data
Quality
Geo chart
Click on elements
JSON capability *
Layout
Line chart
Hover over elements
Space efficiency
Bar chart
Colours
Performance
Pie chart
Legend
* The visualisation libraries themselves will need to handle JSON, a translation will be made from RDF to
JSON
Project participant published a report on this topic at the COLD workshop co-located with ISWC 2011 [1];
this will be used to make the final decision on what library to use.
3.3.2
Environment Friendly Behaviour
The architecture for this application is based on a mobile-client architecture using a API access to Calendar
and GPS. The data will be accessed using pure HTTP GET Linked Data URLs. Figure 6shows the
architecture for this application.
S
Mobile Device
…
Transporation
Emission Data
Public
Transportation
Data
Calendar
GPS
LOD
HTTP
CS2 Application
EL.
CarCharging
Stations Data
Figure 6- Architecture of the Environmental Friendly Behaviour App
3.3.2.1
Mobile platform decision factors
Relevant requirements include
Page 25 of (31)
PlanetData

RDF support. Since the transport data we use come in an RDF format, support for easy handling of such
data via APIs should be possible. E.g. parse an RDF-file into a structure that is easy to work with in the
code.


Alternative: serialize the data as JSON/RDF, making "native parsing" easier.
Calendar access. The application depends on reading data from the user's (Exchange) calendar. Being
able to get such data is hence a must.


Deliverable D12.1.1
Alternative (platform independent) - use Google Calendar Web API.
Prior experience with developing on a platform is a factor because the development time is limited.
Prior experience will speed up the development process.
Table 8 Platform decision comparison table
Platform
RDF support
Calendar access
Prior
experience by
developers
Risk
Native Android
Porting of Jena to
Android:
API support (>=
Android 4.0), via
"hacking" on prior
versions
~300 hours
No devices currently run
4.0. Calendar access not
guaranteed to work
across all deviceson
older versions.
Androjena.
Currently in v.04.
Also rdfonthego
Native iOS
Possible (old,
2005) port of
Redland from C to
Obj-C.
API support (>=
iOS4)
~200 hours
Presumably no RDF
support
PhoneGap
Possible if
integrated with
jQuery.
Possible through use
of native code. I.e.
writing a PhoneGap
Plugin.
None
No prior experience with
PhoneGap or Javascript.
Only RDF support if
integrated with jQuery.
Only calendar access if
integrated with native
code
jQuery Mobile
RDFQuery - JS
library
Possible if integrated
with PhoneGap (and
native code). Se
ePhoneGap
None
No prior experience with
jQuery or Jacascript.
Only Calendar access if
integrated with
PhoneGap (and native
code)
The Android option carries the least risk and is thus the chosen platform, due to most prior development
experience and its RDF support (Jena is well-known). However some additional effort is needed for calendar
support on pre 4.0, but this has been done with success by others and is documented.
Page 26 of (31)
Deliverable D12.1.1
3.4
PlanetData
Sketches of user interfaces
A few sketches have been made to illustrate ideas of interfaces; these are shown in Figure 7, Figure 8 and
Figure 9.
Figure 7 - Illustration of a possible user interface for the Environmental Friendly Behaviour app
Figure 8 – Illustration of a Geo Chart (illustration from dagbladet.no)
Page 27 of (31)
PlanetData
Deliverable D12.1.1
Figure 9 – Illustration of a Geo Chart with details (illustration from dagbladet.no)
Page 28 of (31)
Deliverable D12.1.1
3.5
PlanetData
Development methodologies
The development of the prototypes will be developed with the Scrum methodology. The application
requirements in section 3.2 will be implemented in two weeks pilots as shown in Figure 10. This will ensure
that time is spent on functional increments (sprint backlog) so that we continually have demonstrable
prototypes (working increment).
Figure 10 - Scrum methodology
This process will also allow for continuous feedback to WP12.2 that will improve quality of the linked data.
For more information on Scrum, see “A Scrum Process Description” by the Eclipse Process Framework
(EPF) Project [2].
Page 29 of (31)
PlanetData
4
Deliverable D12.1.1
Validation
This section outlines a general validation plan for the two applications. The overall evaluation comes from
three main categories of assessment, defined as the following:

Functional coherence of the system: the validation of the requirements

User acceptance: the application is beneficial to the end-user
To validate the functional coherence of the systems, the applications will be measured against the functional
and non-functional requirements in the previous chapter.
The user acceptance will be validated by a combination of field-testing and questionnaires.

In the case of Regional Development solution we will organise a small workshop with users where we
provide some instructions on the data sets available, and let the users play with the data and
visualisations. We will then provide a questionnaire to get feedback of the usefulness of the system.

The Environmental Friendly Behaviour app will be distributed to a number of business users with
frequent meeting schedules. It will be tested during a week of normal meetings, and the users will then
be given a questionnaire that both covers the user friendliness of the app, the accuracy of the options
and their perception of such an app could actually change their behaviour.
The validation results will be published in the D12.1.2 Report on Prototypes Development, Validation and
Evaluation.
Page 30 of (31)
Deliverable D12.1.1
PlanetData
References
[1]
Stuhr M., D. Roman, D. Norheim (2011). LODWheel – JavaScript-based Visualization of RDF Data.
To appear in the proceedings of the Second International Workshop on Consuming Linked Data
(COLD2011), collocated with ISWC 2011, October 23, Bonn, Germany.
[2]
A Scrum Process Description
http://epf.eclipse.org/wikis/scrum/
by
the
Eclipse
Process
Framework
(EPF)
Project
Page 31 of (31)