PlanetData
Network of Excellence
FP7 – 257641
D12.1.2 NorthPole Report on
prototypes, development, validation and
evaluation
Coordinator: Jens Kilde Mjelva, Computas
With contributions from: David Norheim, Computas;
Dumitru Roman, SINTEF
1st Quality reviewer: Irene Celino
Quality reviewer: Jacek Kopecky
2nd
Deliverable nature:
Report (R)
Dissemination level:
Public (PU)
(Confidentiality)
Contractual delivery date:
31.03.2012
Actual delivery date:
30.03.2012
Version:
1.0
Total number of pages:
34
Keywords:
LOD case studies, applications, prototypes, validation
PlanetData
Deliverable D12.1.2
Abstract
This document presents the prototypes of the applications developed for monitoring regional development in
municipalities in Norway and for supporting environmentally-friendly transportation decisions, based on the
use of (Norwegian) linked open data. It reports on the implementation of the applications described in
D12.1.1. For each prototype, we present the architecture of the application and interactions between
components and with the user, together with technologies used for the implementation, usage manual, and
preliminary validation of the prototype.
Page 2 of (34)
Deliverable D12.1.2
PlanetData
Executive summary
This document presents the prototypes of the applications developed for monitoring regional development in
municipalities in Norway and for supporting environmentally-friendly transportation decisions, based on the
use of (Norwegian) linked open data. It reports on the prototypical implementation of the applications
described in D12.1.1.
For each prototype, we present the architecture of the application and interactions between components and
with the user, together with technologies used for the implementation, and the usage manual.
The monitoring regional development prototype is a Web application that runs on a Web browser client. It is
written in HTML, CSS and Javascript. The jQuery library is used to simplify some of the Javascript. For
visualization of data in a map the Javascript library Raphaël is used. For dealing with the RDF data the
rdfQuery library is used for parsing RDF data. The interactions between components in this application are
described using sequence diagrams illustrating the steps involved in visualizing one or several aggregated
data variables from different data sets used in the application. The usage manual is provided through
screenshots of the graphical interface of the application, showing the data variables that can be selected by
the user, based on some predefined user-friendly queries capturing the data variables which need to be
visualized on the map, and how contextual and aggregated data is displayed on the map, based on the data
variables selected by the user.
The environmentally-friendly decision support prototype is a mobile application that has access to necessary
built-in functionality of the mobile device such as native calendar data, positioning tools (GPS), but also new
functionalities such as connecting to external LOD through HTTP. The application is built on top of the
Android platform, written in Java. For handling RDF data, it uses the AndroJena library. The interactions
between components in this application are described using sequence diagrams illustrating the process of
adding travel events/transport alternatives to the user’s calendar, and the process of adding data from various
LOD sources to be used in the application. The usage manual for this prototype is provided through
screenshots of the mobile application, showing the parameters that can be selected by the user (e.g. calendar,
preferred transportation options), and how the application suggests transportation options corresponding to
different levels of environmentally “friendliness”.
We perform a software validation in terms of how the applications fulfilled the original functional and nonfunctional requirements outlined in D12.1.1 and discuss how the functionalities have been fulfilled. An enduser validation plan is suggested through a questionnaire for each application to collect feedback from the
users of the applications. The questions concerned the added-value and potential benefits of the applications
to end-users, as well as some other potential enhancements of the applications.
Page 3 of (34)
PlanetData
Deliverable D12.1.2
Document Information
IST Project
Number
Full Title
Project URL
Document URL
EU Project Officer
FP7 - 257641
PlanetData
Deliverable
Number
D12.1.2.
Title
Work Package
Number
WP12
Title
Date of Delivery
Status
Nature
Dissemination level
Contractual
Acronym
PlanetData
http://www.planet-data.eu/
Leonhard Maqua
NorthPole Report
on prototypes,
development,
validation and
evaluation
NorthPole
M18
Actual
version1.0
final 
prototype □ report  dissemination □
public consortium □
M18
Authors (Partner)
Responsible Author
Name
Jens Kilde Mjelva
E-mail
[email protected]
Partner
Computas
Phone
+47 95946949
This document presents the prototypes of the applications developed for
monitoring regional development in municipalities in Norway and for
supporting environmentally-friendly transportation decisions, based on the use
of (Norwegian) linked open data.
LOD, Norway, Application, Prototype
Abstract
(for dissemination)
Keywords
Version Log
Issue Date
2012-02-13
2012-02-16
Rev. No.
0.1
0.2
2012-02-22
0.3
2012-03-20
0.4
2012-03-21
0.5
2012-03-22
0.6
2012-03-29
1.0
Author
Dumitru Roman
Dumitru Roman, Jens Kilde
Mjelva, Roy Grønmo
Jens Kilde Mjelva
Change
TOC, structure, preliminary content
Added end-user validation questions
Added CS2 architecture and
technical description
Dumitru Roman
Added software validation,
summary, usage manual for CS2,
abstract, introduction.
Jens Kilde Mjelva
Added CS1 architecture and
technical description
Dumitru Roman
Revised CS1 description, added
some text around figures, and added
executive summary. Included survey
results.
Dumitru Roman, Jens Kilde Updates based on comments from
Mjelva
reviewers; final version.
Page 4 of (34)
Deliverable D12.1.2
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 Prototypes ................................................................................................................................................. 10
2.1 Prototype CS1: Monitoring Regional Development Application ..................................................... 10
2.1.1
Architecture and Technical Description .................................................................................... 10
2.1.2
Usage Manual ............................................................................................................................ 13
2.2 Prototype CS2: Environmentally-friendly Decision Support Application ........................................ 16
2.2.1
Architecture and Technical Description .................................................................................... 16
2.2.2
Usage Manual ............................................................................................................................ 21
3 Validation ................................................................................................................................................. 24
3.1 Software Validation: Requirements Fulfilment ................................................................................ 24
3.2 End-User Validation ......................................................................................................................... 29
3.2.1
Method ....................................................................................................................................... 29
3.2.2
Preliminary Results of End-User Validation ............................................................................. 30
4 Summary and Outlook ............................................................................................................................. 33
References ....................................................................................................................................................... 34
Page 5 of (34)
PlanetData
Deliverable D12.1.2
List of figures
Figure 1. CS1 Application Structure overview ............................................................................................... 10
Figure 2. Sequence diagram illustrating the steps involved in visualizing one variable in the application .... 11
Figure 3. Sequence diagram illustrating the process of visualizing two variables in the application ............. 12
Figure 4. Homepage of the application ........................................................................................................... 13
Figure 5. Visualization of one data variable .................................................................................................... 14
Figure 6. Contextual information about one municipality............................................................................... 14
Figure 7. Visualization of two data variables (aggregated) ............................................................................. 15
Figure 8. The CS2 application structure .......................................................................................................... 16
Figure 9. UML Sequence Diagram explaining the process of adding travel events/transport alternatives to the
user’s calendar .......................................................................................................................................... 17
Figure 10. UML Sequence Diagram explaining the processof adding data from various LOD sources ........ 19
Figure 11. Android home screen with the icons of the “Environmental Friendly Travels” and calendar apps.
.................................................................................................................................................................. 21
Figure 12. The settings screen of the “Environmental Friendly Travels” app. ............................................... 22
Figure 13. Selection of preferred transport options and the calendar to be used in the app. ........................... 22
Figure 14. Suggestions for transport alternatives and their level of “environmental friendliness” ................. 23
Figure 15. Additional information about transportation options. .................................................................... 23
Figure 16. Preliminary results of the end-user validation of CS1 application ................................................. 32
Page 6 of (34)
Deliverable D12.1.2
PlanetData
List of tables
Table 1. Figure 2 steps details ......................................................................................................................... 11
Table 2. Figure 3 steps details ......................................................................................................................... 13
Table 3. Figure 9 step details ........................................................................................................................... 17
Table 4. Figure 10 steps details ....................................................................................................................... 19
Table 5. Requirements validation for CS1 ...................................................................................................... 24
Table 6. Requirements validation for CS2 ...................................................................................................... 26
Page 7 of (34)
PlanetData
Deliverable D12.1.2
Abbreviations and Definitions
LOD – “Linked Open Data”. Data sets publically available following the Linked Data principles.1
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).
Norwegian Data Sets – A collection of open or closed Norwegian data sets.
CS – Case Study.
Trafikanten –Trafikanten’s main purpose is to provide the public with up to date travel information for the
public transportation system in and around the counties Oslo and Akershus. TheTrafikanten data set is about
all public transportation, the current location and delays of route.
Grasrotandelen – Gaming funds benefit sporting and cultural activities as well as voluntary humanitarian
organizations all over the country through the Grassroot share (Grasrotandelen).Grasrotandelen is a registry
showing organisations that receive funding.
Enhetsregisteret – All legal entities in Norway are registered in the Central Coordinating Register for Legal
Entities (Enhetsregisteret) at Brønnøysund Registry Centre.
Tjenestemannsregisteret – A dataset containing age and gender distribution for all governmental agencies.
1
http://www.w3.org/DesignIssues/LinkedData.html
Page 8 of (34)
Deliverable D12.1.2
1
PlanetData
Introduction
This deliverable is part of WP12, “Call 1: NorthPole” which focus on consuming and improving Norwegian
Linked Open Data for monitoring regional developments in municipalities in Norway and for providing
support in environmentally-friendly transportation decisions.
In D12.1.1 NorthPole Case studies: definition, requirements and design (Norheim et al, 2011) we addressed
the specification of requirements for two prototypes in the aforementioned domains. This document reports
on the implementations of the two applications, and specifically aims to:
1. Provide a description of the implemented prototypes in terms of architecture, interaction
between components and with the end users, technologies used in the implementation, and user
manuals;
2. Provide a validation of the implemented prototypes in terms of software validation (degree of
fulfilment of the requirements specified in D12.1.1), and end-user validation (feedback about the
usefulness of the applications to potential end-users)
3. Outline possible extensions of the applications.
This document focuses on the prototypes implementations. The data sets, and the way they are used in the
two prototypes are presented in D12.2.1 NorthPole Report on quality improvements of existing Norwegian
LOD (Roman et al, 2011).
The rest of this document is organized as follows. Section 2 provides an overview of the prototypes of the
applications developed in the two case studies. We focus on the specification of the architecture, the
interactions between the components and with the user, the technologies used in the implementation of the
applications, and the user manuals. Section 3 describes the software and end-user validation method and
reports on some preliminary end-user validation results. Section 4 summarizes this document and outlines
possible extensions of the applications reported in this deliverable.
Page 9 of (34)
PlanetData
Deliverable D12.1.2
2
Prototypes
2.1
Prototype CS1: Monitoring Regional Development Application
This case study addresses the problem of how to speed up and improve the process of collecting and
aggregating data for monitoring regional developments, targeting data journalists and citizens interested in
learning more about regional developments in municipalities in Norway.
2.1.1
Architecture and Technical Description
The application structure is depicted in Figure 1. This application runs through a Web browser, aggregates
linked data and visualizes the aggregated data.
Organization
Register Data
Web Client
DBpedia
Map
visualisation API
(raphaël)
LOD
…
RDFQuery
…
CS1 Application
Sintef/Computas
Municipalites
HTTP
Figure 1. CS1 Application Structure overview
Technologies
The application is a Web application that runs on a Web browser client. This application is written in HTML,
CSS and Javascript. The jQuery2 library is used to simplify some of the Javascript.
The various LOD the application consumes are fetched as RDF data through HTTP-GET requests.
In order to easily utilize this data the application needs to parse RDF. This is done with help from the
rdfQuery3 library. With RDFQuery the application can easily parse an RDF resource referred to by an URI
such as the ones we have made available for all the Norwegian Municipalities. This data set is updated with
the latest data from DBpedia, Enhetsregisteret, Tjenestemannsregisteret and Grasrotandelen. See deliverable
2
http://jquery.com/
http://code.google.com/p/rdfquery/
3
Page 10 of (34)
Deliverable D12.1.2
PlanetData
D12.2.2 for a more information of this data set and how data is added to it from the dynamic sources;
DBpedia and Enhetsregisteret.
For visualization of data in a map the Javascript library Raphaël4 is used.
Functionality
The following UML Sequence Diagrams illustrates a successful run of the applications. The diagrams consist
of several labelled steps that are explained in detail in Table 1 and Table 2.
Figure 2. Sequence diagram illustrating the steps involved in visualizing one variable in the application
Table 1. Figure 2 steps details
Step Description
Details
1.
The user launches the Web application
2.
A graphical unit interface is displayed
3.
The user selects one property in the GUI that she wants to see visualized.
4
http://raphaeljs.com/
Page 11 of (34)
PlanetData
4.
5.
6.
7.
8.
Deliverable D12.1.2
The Javascript controller notifies a change in the list of selected properties and starts preparing the
selected property for visualization.
The controller loops through all the municipalities checking if it already has acquired data for
them. Note that at the first user run no municipality data will be already present.
For the municipalities for which no data was already found a HTTP GET for data about that
municipality is sent. RDF data is returned, parsed and made available for use in the application.
The data is stored in the memory of the Web client.
The map is updated and coloured according to the values of the selected property from the
acquired data for each municipality.
An updated GUI is made visible for the user.
Figure 3. Sequence diagram illustrating the process of visualizing two variables in the application
Page 12 of (34)
Deliverable D12.1.2
PlanetData
Table 2. Figure 3 steps details5
Step Description
Details
A.
The user has already visualized one variable.
B.
Another variable is selected in addition to that of A.
C.
Because data was already fetched in A no data typically will need to be fetched now, i.e. the first
part of the 'alt' will happen. Note that if some of the requests for municipality data sent during "A"
failed, the second part (else) of the alt will take place and the requests will be resent.
D.
The map will be updated with visualizations of the two variables. This means that the visualized
municipality values will be calculated by dividing the value of the first selected variable for the
municipality by the value of the second selected variable. Currently this is the case for all
combined variable visualizations. This can be extended by inclusion of other types of calculations
based on the data types of the variables.
2.1.2
Usage Manual
We will introduce the use of the application through a set of screenshots and explanations attached to each
screenshot.
Figure 4. Homepage of the application
Figure 4 provides a screenshot of the graphical interface of the application: on the left side a set of data
variables can be selected by the user, based on some predefined user-friendly queries capturing the data
variables which need to be visualized on the map on right side.
5
The message sequence in Figure 3 is very similar to that of sequence diagram in Figure 2, hence the details of some
steps are skipped.
Page 13 of (34)
PlanetData
Deliverable D12.1.2
Figure 5. Visualization of one data variable
When the user selects one data variable, the map is populated with relevant data (Figure 5). By clicking on
one municipality more contextual data is retrieved from the data sources used (Figure 6). If the user selects
more than one data variable, the data is aggregated and displayed on the map (Figure 7).
Figure 6. Contextual information about one municipality
Page 14 of (34)
Deliverable D12.1.2
PlanetData
Figure 7. Visualization of two data variables (aggregated)
The application is available online at http://opendata.computas.no/RegionalDevelopment.6
6
The application has been tested with Mozilla Firefox, Opera, Chrome and Safari.
Page 15 of (34)
PlanetData
2.2
Deliverable D12.1.2
Prototype CS2:
Application
Environmentally-friendly
Decision
Support
This case study addresses the problem of deciding the most environmentally-friendly transportation options
when the user is faced with different transportation options for a short regional trip, given constraints like
time, transport preferences, etc. The case study targets general citizens interested in becoming more
environmentally-friendly in their transportation options.
2.2.1
Architecture and Technical Description
The application structure corresponds to the one that was outlined in deliverable D12.1.1. The application
resides on a mobile device where it has access to necessary built-in functionality such as native calendar
data, positioning tools (GPS) as well as connecting to external LOD through HTTP.
RDF library,
AndroJena
Figure 8. The CS2 application structure
Technologies
The chosen development platform for the CS2 application was, as described in deliverable D12.1.1, the
Google Android platform. Java is the programming language used when programming Android applications.
The CS2 app is hence written in Java.
The various LOD the application consumes are fetched as RDF data through HTTP-GET requests.
In order to easily utilize this data the application needs to parse RDF. This is done with help of the
AndroJena library. Androjena is a porting of Hewlett-Packard's Jena semantic Web framework to the Google
Android platform7. With Jena the application can easily populate a java model of an RDF resource referred
to by an URI such as the ones we have made available by wrapping existing web services, e.g. Trafikanten.
The populated model is easy to handle and extend, meaning that data not needed by the application can be
ignored and various sources merged.
Functionality
The following UML Sequence Diagrams illustrates a successful run of the applications. The diagrams consist
of several labelled steps that are explained in detail in Table 3 and Table 4.
7
http://code.google.com/p/androjena/
Page 16 of (34)
Deliverable D12.1.2
PlanetData
Figure 9. UML Sequence Diagram explaining the process of adding travel events/transport
alternatives to the user’s calendar
Table 3. Figure 9 step details
Step Description
1.
Details
The user launches the “Environmental Friendly Behaviour” application
The application is launched by clicking the application icon on a mobile device
2.
The application requests access to the user’s calendars
The application uses the Android Calendar API to get the IDs and names of the user’s calendars.
E.g. 1 – Google Calendar (Private appointments), 2 – Google Calendar (Vacation) – 3 MS
Exchange Calendar (work). By using calendar IDs, the application can work with the calendars the
user the user chooses to make available to the application.
Page 17 of (34)
PlanetData
3.
Deliverable D12.1.2
The user is presented a graphical interface (GUI)
The GUI contains two settings items (see step 4) :
I.
“Available modes of transport”
II.
“Event Calendars”
And one action option (see step 5):
III.
“Generate transport alternatives”
4.
The user can optionally edit the settings
I.
II.
Which modes of transport the user has available, e.g. public transportation, bicycle and
gas car. This option controls which types of transport alternatives the application shall
generate.
Which calendar(s) the application shall generate events from. The application will
generate transport alternatives that take the user from his current position to the next
occurring event in any of the selected calendars.
5.
The “generate transport alternatives” action is selected
6.
The application launches a service responsible for generating transport alternative calendar
events
7.
The launched service is started on a new thread and is provided the values of the data set by the
user; the IDs of the calendars the user wants to generate events from and a list of the available
modes of transport, as well as the coordinates of the user’s current position which is given by the
mobile device’s geo positioning tools (e.g. GPS). (Note that the app requires GPS or some other
way to get the location, however this cannot manually be set by the user through the app
interface.)
The application service generates transport alternatives
8.
Transport alternatives data is created and mashed up with data from various Linked Open Data
sources. See the sequence diagram of Figure 10 and the corresponding table.
The generated transport alternatives data is added to the user’s calendars
9.
Various transport alternative events are added to the user’s calendars. If the user has more than
one calendar, the application will add the transport events to different calendars so that the colour
of the events will vary with the amount of emission (environmental friendliness). The id of the
calendar to place the event in is thus governed by whether the event has a CO2 emission value
over a certain threshold or not.
A notification is sent to the user informing him the results of the application run
A notification is displayed on the mobile device saying that transport alternatives were added to a
named calendar prior to a specified event (the next event in any of the selected calendars).
10.
The native calendar application is launched
The user can thus see the result of the application run, i.e. that various transport events have been
added to the calendar.
Page 18 of (34)
Deliverable D12.1.2
PlanetData
Figure 10. UML Sequence Diagram explaining the process of adding data from various LOD sources
Table 4. Figure 10 steps details
Step
Description
Details
A.
B.
The application finds the next calendar event (the target event)
The application uses the Android Calendar API to get the first calendar event from any of
the calendars selected by the user. The application asks only for events that have not already
occurred or started, are not transport events themselves and that are taking place within the
two next weeks. The event found is the target event.
The application asks Trafikanten for the coordinates of the location of the calendar
event.
The LOD Wrapper around the Trafikanten Web services is used for getting the coordinates
of the address specified as the location of the next calendar event found. More precisely the
app populates a RDF model by requesting data from the Trafikanten LOD address search
service. E.g. for the address “Lysakertorg 45”:
http://opendata.computas.no/trafikanten/id/placesByString/Lysaker%20torg%2045
Page 19 of (34)
PlanetData
Deliverable D12.1.2
C.
The application asks Trafikanten for public transportation data (travels)
D.
If public transportation (Trafikanten) is selected as an available transport mode, public
transportation travel details fetched from Trafikanten LOD and stored in the application.
The process of getting data from Trafikanten LOD is described in the Use Case 2 scenario
in deliverable D12.2.1.
The application asks NILU for air quality data and generates bike travel data
If bicycle is selected as an available transport mode, bicycle travel events are generated with
air quality risk data fetched from the LOD wrapper around NILU’s web services.
Air quality data is fetched from the measure station closest to the user’s coordinates.
Example RDF returning call: http://opendata.computas.no/nilu/data/station/10.75,59.95
The risk calculation is done based on a risk chart supplied by NILU under the
“Varslingsklasser”-tab
(warning
categories)
at
http://www.luftkvalitet.info/Theme.aspx?ThemeID=6fc2e3cd-424f-4c03-ad0c2b9c15369cd9. The obtained air quality data is mapped against the chart and the bike travel
events contains risk info ranging from low to high based on this.
E.
F.
The travel time of the bicycle transport event is calculated by multiplying the distance
between the coordinates of the user’s starting position and the coordinates of the target
event with an average bicycle travel speed (currently set to 15 kmph).
The application asks NOBIL for electric car charging station data and generates el.
car travel data
If electric car is selected as an available transport mode, electric car travel events are
generated with closest el. Car charging station data fetched from the LOD wrapper created
against Nobil’s web services. More precisely the coordinates of the target event, fetched in
step B, are used as parameters in a HTTP-GET request asking for the closets charging
stations,
e.g.
http://opendata.computas.no/nobil/data/chargingStationsByCoordinates/59.91673,10.74782
The URI of the closest charging station acquired is stored in the travel event and thus the
user is provided the location of the charging station closest to the target event position, for
example http://opendata.computas.no/nobil/page/chargingStation/1122.
The application generates gas/diesel car travel data
If diesel and/or gas car is selected as an available transport mode, a corresponding travel
event is generated.
The travel time of each car transport event, including electrical, is calculated by multiplying
the aerial distance between the coordinates of the user’s starting position and the
coordinates of the target event with an average car travel speed (currently set to 35 kmph.).
G.
Get emission data for transport alternatives
For each generated travel event a mode of transport is included in the data. The public
transport travels can consist of several travel stages where each is of a different type. For
instance take bus to X then train from X to Y.
The
various
transport
modes
are
represented
by URIs,
e.g.
train:
http://opendata.computas.no/trafikanten/id/transportType/6
Looking up these URIs return RDF which contains links to emission data delivered by DIFI.
For trains this link is http://opendata.computas.no/resource/emission/Tog. The application
gathers the emission data for all the modes of transport that are selected by the user so that
the total emission can be calculated for each travel event.
Page 20 of (34)
Deliverable D12.1.2
H.
PlanetData
Calculate and add emission data
The travel data fetched and generated in steps C-F is now extended with emission data.
The emission for each travel event is calculated by multiplying the travel distance with the
emission spent per kilometre data for the transport mode of the event. If the travel consists
of several travel stages (public transportation) the calculation is done separately for each
stage and then summed in order to display the total emission for the travel.
2.2.2
Usage Manual
We will introduce the use of the application through a set of screenshots and explanations attached to each
screenshot.
Figure 11. Android home screen with the icons of the “Environmental Friendly Travels” and calendar
apps.
Figure 11 shows the Android home screen displaying the icons of the “Environmental Friendly Travels” app
and user’s calendar (left); and an example of user’s calendar displaying two meetings in different locations
and current time (red horizontal bar) (right). The user wishes to find transportation means that can take her
on time from one location to the other.
Page 21 of (34)
PlanetData
Deliverable D12.1.2
Figure 12. The settings screen of the “Environmental Friendly Travels” app.
By opening the “Environmental Friendly Travels” app, a settings menu is displayed (Figure 12), allowing the
user to select the preferred transportation options (Figure 13 left) and the calendar to be used (Figure 13
right).
Figure 13. Selection of preferred transport options and the calendar to be used in the app.
After the selection of the available modes of transportation and the calendar, the user can select generation of
transport alternatives. The result of generation is displayed in the user’s calendar as new events
corresponding to the suggestions for transport alternatives (including estimated time): bus, bicycle, and car in
this example, each having assigned different levels of “environmental friendliness” (with green being most
environmental friendly, red being least environmental friendly, and yellow being in between);
Page 22 of (34)
Deliverable D12.1.2
PlanetData
Figure 14. Suggestions for transport alternatives and their level of “environmental friendliness”
The user can select the events corresponding to the generated transportation options and get additional
information about each of them (Figure 15). For example if the user selects the event corresponding to the
bus transportation suggestion, gets additional information such as the travel time, closest bus station,
destination bus station, and CO2 emission are displayed.In case the bicycle option is selected, the application
will inform the user of the air quality risk.
Figure 15. Additional information about transportation options.8
The application is available for download at http://opendata.computas.no/EnvironmentalFriendly/.9
Translation of the bottom parts: “Delta?” translates to RVSP. “Påminnelser” translates to “Reminders” and lets the user
add reminders for the events.
9
The application is developed for- and tested with Android version 2.2.
8
Page 23 of (34)
PlanetData
3
Deliverable D12.1.2
Validation
The validation of the applications is focused on two aspects: software validation (i.e. how the applications
fulfilled the original requirements outlined in D12.1.1) and end-user validation (i.e. how useful are the
applications for potential end-users). These two aspects are discussed in the following two subsections.
3.1
Software Validation: Requirements Fulfilment
In deliverable D12.1.1 a set of requirements were outlined for the applications. The below tables describe the
degree of fulfilment of the requirements by the implemented applications.
Table 5. Requirements validation for CS1
Req.
#
Description
Rationale
Acceptance
criteria
Degree of fulfilment
What is the system registering (user-input)?
1
2
3
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
app only
visualizes data
in the sets
selected by the
user
Partially fulfilled
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
Partially fulfilled
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
Fulfilled
The datasets plugged into
the application are added
manually by the application
developer. The current
implementation allows new
data sets to be included in
the application in a
programmatic way, but not
through a graphical
interface. The visualization
of data is done through the
specification of variables
from the data set (variables
specified through userfriendly questions)
The system allows
registration of data
variables but this is done by
the application developer,
not the end-user, through
predefined user-friendly
questions that when
selected by the end-user the
application visualizes data
selected by the user.
The data visualized in the
map is clickable and
retrieves additional
information.
What data/systems should be available to the system, what interfaces to which systems?
Page 24 of (34)
Deliverable D12.1.2
4
5
PlanetData
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
Fulfilled
Various Linked Open
Data shall be
available to the
system either through
RESTful web service
request(s) or
SPARQL-endpoints.
LOD shall be available
to the system in order to
have data to base the
visualizations on
Verify datasets
are available to
the system
Fulfilled
Verify that it is
possible to add
new LOD data
sets to the
system and that
the added data
is available for
analysis.
Fulfilled
Verify that the
selected data
sets and/or
variables get
visualized
Fulfilled
A map visualization system
is included in the Web
client that provided
location-based data for the
available queries.
A number of data sets are
included in the application
as reported in D12.2.1 and
D12.2.2.
What should the system update (change, delete, add)?
6
The system should
be able to add more
LOD sets to visualize
data from
Addition of new datasets
should enhance the
visualization
possibilities
The system allows new data
sets to be plugged to the
system in a programmatic
way as demonstrated by the
datasets made available in
the application
What shall the system calculate/compute?
7
The system shall
present the user with
visualizations of the
selected data sets
The visualizations shall
be the core part of the
system
The system allows
visualization of data
variables on a map, based on
the selected user queries.
What shall the system deliver to the user?
8
9
The system shall
present the user with
datasets and
variables to choose
to base the
visualization on
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
Partially fulfilled
The system shall
visualize data
connected to a
geographical location
on a geo chart
Geo chart visualisations
are powerful for
presenting geo-data.
Verify the
possibility of
visualizing data
on a geo chart.
Fulfilled
The datasets are presented to
the user implicitly, not
explicitly, through the
queries (data variables) that
the user can select. Data
variables are captured in the
user-friendly queries the
user can select.
The system allows
visualization of data
variables on a map that
covers municipalities in
Norway.
Data model
Page 25 of (34)
PlanetData
10
The LOD should be
interlinked where
possible
Deliverable D12.1.2
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
Fulfilled
The application
should be available
through web
browsers without
plugins
The independence of
plugins like Flash will
make the tool more
acceptable.
Verify that the
system works
w/o plugins.
Fulfilled
The application shall
be user friendly
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.
Fulfilled
The user can select queries
that combine data from
different data sets, and the
result can be displayed on
the map.
Non-functional requirements
11
12
The application is a Webbased and accessible
through a browser. No
plugins are necessary to
access the application.
See end user-validation
below.
As it can be observed from the degree of fulfilment of the requirements in the above table, the application
provided the core features it was supposed to implement. One thing to remark related to the requirements
that were only partially fulfilled is the fact that they are related to the capability that the end user selects and
automatically plugs-in new data sources, through a graphical interface. This feature proved difficult to
implement due to the short duration of the project. Nevertheless, the system supports inclusion of new data
sources, but they need to be manually included in the application and corresponding user-friendly queries
need to be defined and translated to SPARQL queries in order to retrieve (and visualize) data from newly
included data sources. To create the dynamic plug-in functionality, one would need to ensure that the data to
be added is made available aggregated on municipalities and registered to the application, provide the names
of the properties to be visualized (through user-friendly questions), together with the necessary graphical
interfaces. The aggregation of data on municipalities may be the most time-consuming step, depending on
the structure of the underlying data (what geographical features it contains that could be used to aggregate
the data).
Table 6. Requirements validation for CS2
Req.
#
Description
Rationale
Acceptance
criteria
Degree of fulfilment
Verify that the
app is working
without adding
information
manually.
Fulfilled
What is the system registering (user-input)?
1
The user shall not
have to enter any
information when
starting the app.
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.
Data is read directly from user’s
calendar and aggregation of linked
data is hidden to the end user.
What data/systems should be available to the system, what interfaces to which systems?
Page 26 of (34)
Deliverable D12.1.2
2
3
4
PlanetData
Various Linked Open
Data shall be available
to the system either
through RESTful web
service request(s) or
SPARQL-endpoints.
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.
Fulfilled
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 read- and
write access to the
users calendar
data and read
access to the
geographical
position of his
mobile device
Fulfilled
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.
Fulfilled
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”
Public transportation data and
other transportation data sets (e.g.
electric car charging stations) as
other relevant data sets (e.g.
emission data)are available as
LOD and included in the
application.
The app has access to the user’s
calendar data and makes use of
the geographical position of user’s
mobile device.
The app has been tested and it
provides valid requests to linked
data sets.
Page 27 of (34)
PlanetData
5
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.
Deliverable D12.1.2
The responses
from the
requests the
app sends to
the LODsystems 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.
Fulfilled
The app provides transportation
alternatives as calendar events.
The alternatives are aggregation
of data including public
transportation, emission data, etc.
What should the system update (change, delete, add)?
6
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).
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
programmatically
added
transportation
event with
emission data has
been added to the
user’s device’s
calendar when the
app terminates.
Fulfilled
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.
Fulfilled
The result of an execution of the
app results in event entries in
user’s calendar representing
transportation alternatives.
What shall the system calculate/compute?
7
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.
For the
application to
be worth using,
it should
provide the user
with “correct”
travel proposals.
The tested scenarios proved that
the calendar entries describe travel
proposals from the user’s position
to the actual location of the event.
What shall the system deliver to the user?
Page 28 of (34)
Deliverable D12.1.2
8
PlanetData
User notifications
The app could
display a
notification telling
whether
transportation
alternatives where
found or not.
Data model
Feedback from the
application to the
user could inform
the user that the
application has
really made
something happen.
Verify that the
user has received
an indication that
the application
has “done
something” when
the app
terminates.
Fulfilled
9
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
Fulfilled
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.
Fulfilled
The data lifting
and application
shall try to utilise
common linked
data vocabularies
for transportation
and environment.
Events are automatically
generated into the user’s calendar
if transportation options are
found. Otherwise, a pop-up
informs the user about
unavailability of transportation
means.
The app uses the QUDT
vocabulary10 to deal with
quantities and units (particularly
for measurement of pollution
data). No other directly relevant
vocabularies were deemed
necessary for the application.
Non-functional requirements
10
The application
shall be user
friendly.
The mobile application uses
standard graphical components
provided by Android. See also
end-user validation below.
As it can be observed from the degree of fulfilment of the requirements in the above table, the application for
UC is complete in terms of the fulfilment of the requirements outlined in D12.1.1.It worth noting that the
reliability of the application depends on the reliability of the services from which data is wrapped and
integrated.
3.2
End-User Validation
The purpose of the end-user validation is to collect feedback about the usefulness of the applications to
potential end-users. We outline below the end-user validation method and some preliminary results.
3.2.1
Method
The primary mean for end-user validation was the set-up and provisioning of a questionnaire for each
application to collect feedback from the users of the applications. The questions concerned the added-value
and potential benefits of the applications to end-users, as well as some other potential enhancements of the
applications.
3.2.1.1
CS1 Validation Method
For the CS1 application, a questionnaire was set up at http://kwiksurveys.com?u=UC1-eval, and contains the
following questions:
1. Did you find the Web application easy to use and self-explanatory?
2. Did the application give you interesting insight about trends in regional development in
municipalities in Norway?
10
http://qudt.org/
Page 29 of (34)
PlanetData
Deliverable D12.1.2
3. Which of the application questions about trends in regional developments in municipalities in
Norway did you find most interesting?
4. Did you find the visualization of the data intuitive?
5. What other types of questions/data about trends in regional developments in municipalities in
Norway would you like to be included in the application?
6. Any other feedback
3.2.1.2
CS2 Validation Method
For the CS2 application, a questionnaire was set up at http://kwiksurveys.com?u=UC2-eval, and contains the
following questions:
1. Did you find the mobile application easy to use and self-explanatory?
2. Did the application give you usable transport alternatives?
3. Did the application help you in making an environmentally-friendly decision?
4. What other types of transport alternative would you like to see included in the application (except
the existing ones: public transport, bicycles, gas/diesel/electrical cars)?
5. What other types of environmental parameters would you like to see included in the application
(except the existing one: CO2)?
6. What other functionalities would you like to be included in the application?
7. Any other feedback
3.2.2
Preliminary Results of End-User Validation
The applications have been presented internally at Computas and SINTEF and the attendees provided
feedback through the questionnaires. In the case of the CS1 application, the application was presented also
the personnel of the Brønnøysund Register Centre – one of the organizations from which data is used in the
application. A total of 12 responses have been received after the internal presentation. The preliminary
results of the CS1 questionnaires are presented in the Figure 16 below. The majority of the answers were
positive and highlighted the fact that such an application has an interesting potential. The visualization was
perceived as intuitive, and the concrete feedback points to potential future enhancements of the prototype.
Page 30 of (34)
Deliverable D12.1.2
PlanetData
Page 31 of (34)
PlanetData
Deliverable D12.1.2
Figure 16. Preliminary results of the end-user validation of CS1 application
The validation of the CS2 application is more complicated in the sense that the application needs to be tested
over a longer period of time. The application has been distributed to employees of Computas and SINTEF.
Page 32 of (34)
Deliverable D12.1.2
4
PlanetData
Summary and Outlook
This deliverable presented the prototypes of the applications developed for monitoring regional development
in municipalities in Norway and for supporting environmentally-friendly transportation decisions, based on
the use of (Norwegian) linked open data. We presented the architectures of the applications together with
technologies used for the implementation, usage manuals, and preliminary validation of the prototypes.
We foresee possible enhancement and extensions of the applications. In the case of CS1 (monitoring regional
development) it would be interesting to include new types of visualizations (e.g. pie charts) for some data
variables and data sets. A user interface for plug-in of new data sources and creation of user-friendly
questions (data variables) would make the application more generic and would enable the end user to
dynamically add new data sources and create/select data variables in a flexible way. To enable such a
dynamic plug-in data functionality, the data to be added needs to be made available aggregated on
municipalities and registered to the application, and additional functionality to specify the names of the
properties (through user-friendly questions) to be visualized needs to be provided. This application, and
especially the data sets made available in this case study, will be used by Computas and SINTEF and further
enhanced in the context of the Semicolon2 project11 which aims to test and establish methods, tools and
performance indicators that can be used as the basis for recommendations and standards for enhancing
collaboration across the public sector in Norway.
Concerning CS2 (for support for environmentally-friendly transportation decisions) we foresee porting the
application from Android to iPhone, as well as a desktop application, an enhanced user profile where use can
specify more refined constraints on transportation, as well as inclusion of new ways of calculating
“environmentally friendliness.”
11
http://www.semicolon.no/Hjemmeside-E.html
Page 33 of (34)
PlanetData
Deliverable D12.1.2
References
[1]
D. Norheim, J. K. Mjelva, D. Roman (2011). PlanetData deliverable D12.1.1 NorthPole Case studies:
definition, requirements and design, October 2011.
[2]
D. Roman, J. K. Mjelva, D. Norheim (2011). PlanetData deliverable D12.1.2 NorthPole Report on
quality improvements of existing Norwegian LOD, November 2011.
Page 34 of (34)