Document Title Document Version
D4.1.2 RDF Sensor Formalisms and Ontologies 2 0.3
Project Number Project Acronym Project Title
FP7-‐2011-‐7-‐287661 GAMBAS Generic Adaptive Middleware for Behavior-‐driven Autonomous Services
Contract Delivery Date Actual Delivery Date Deliverable Type Deliverable Access
M22 Nov 30st, 2013 R (Report) PU (Public)
Document Author or Reviewer Organization Work Package
Josiane Xavier Parreira NUIG WP4
Wolfgang Apolinarski UDE WP4
Josiane Xavier Parreira NUIG WP4
Abstract
This document is the second version of the RDF formalisms and ontologies specification. The formalisms and ontologies are used to support the description of the data in the GAMBAS project, such as sensor data, users’ activities and intentions. They concern the data, data properties, and queries found in the GAMBAS scenarios. The first version of this document provided the initial set of classes, properties and queries related to the project, based on the based on a set of initial requirements that were created from the Use Case Specification (D1.3) and from additional input given by all GAMBAS partners.
This version of the deliverable also takes into account the feedback during the implement of the first application prototype (D1.4.1). We have performed a full analysis of the first version of the document, and have updated it accordingly to reflect the decisions taken on the prototype. We have also extended the initial version by considering more use cases from the Use Case Specification (D1.3).
0.2 UDE Review of the initial version
Table of Contents
1
Introduction ... 1
1.1
Purpose ... 1
1.2
Scope ... 1
1.3
Specification Methodology ... 1
1.4
Structure ... 2
1.5
Reading Recommendation ... 2
2
Requirements ... 3
2.1
General Requirements ... 3
2.2
Data Representation and Query Processing Requirements ... 4
3
The GAMBAS Ontology ... 7
3.1
Main differences from the previous version ... 8
3.2
User Class ... 8
3.3
Place Class ... 11
3.4
Activity Class ... 12
3.5
Journey Class ... 12
3.6
TravelMode Class ... 14
3.7
Bus Class ... 15
3.8
Jogging Class ... 16
3.9
Shopping Class ... 17
4
Query Specification ... 18
4.1
Query about users ... 19
4.2
Queries about buses ... 22
5
Requirements Coverage ... 24
6
Bibliography ... 27
Table of Figures
Figure 1 – The GAMBAS Ontology and its dependencies ... 7Figure 3 – Example of an instance of the GAMBAS User Class ... 10
Figure 4 – GAMBAS Ontology: Place Class ... 11
Figure 5 – Example of an instance of the GAMBAS Place Class ... 12
Figure 6 – GAMBAS Ontology: Activity Class ... 12
Figure 7 – GAMBAS Ontology: Journey Class ... 13
Figure 8 – Example of an instance of the GAMBAS Journey Class ... 14
Figure 9 – GAMBAS Ontology: TravelMode Class and its subclasses ... 15
Figure 10 – Example of an instance of the GAMBAS BusRide Class, a subclass of TravelMode ... 15
Figure 11 – GAMBAS Ontology: Bus Class ... 16
Figure 12 – Example of an instance of the GAMBAS Bus Class ... 16
Figure 13 – GAMBAS Ontology: Jogging Class ... 17
Figure 14 – Example of an instance of the GAMBAS Jogging Class ... 17
Figure 15 – GAMBAS Ontology: Shopping Class ... 18
Figure 17 – Query: Activities involving a given bus line for a given user ... 19
Figure 18 – Query: Activities involving a given bus line for a given user, within a specific time interval ... 19
Figure 19 – Query: Bus rides on a given bus line for a given segment ... 19
Figure 20 – Query: Bus rides on a given bus line for a given segment, within a time interval ... 20
Figure 22 – Query: Journeys which involved areas with a CO2 level above a threshold ... 20
Figure 23 – Query: Users who had gone jogging with a particular user ... 21
Figure 24 – Query: Products bought by the user. ... 21
Figure 25 – Query: Users which can access loation information ... 21
Figure 26 – Query: Latest location of a user. ... 21
Figure 27 – Query: Bus stops next to the location of a user. ... 22
Figure 28 – Query: Nearest bus stops, given a location ... 22
Figure 29 – Query: Nearest bus stops, given a GPS location ... 22
Figure 30 – Query: All bus lines ... 22
Figure 31 – Query: All bus stops ... 22
Figure 32 – Query: All buses ... 23
Figure 33 – Query: Route of a bus line ... 23
Figure 34 – Query: Bus stops of a bus line ... 23
Figure 35 – Query: Bus lines that run through a given bus stop ... 23
Figure 36 – Query: Bus lines that run through a given bus stop, filtered by given date ... 23
Figure 37 – Query: Bus lines that run through a given bus stop, filtered by given date ... 24
Figure 38 – Query: Bus lines that run through a given bus stop, filtered by given date ... 24
List of Tables
Table 1 -‐ CURIE prefix binding 2
Table 2 -‐ General Requirements. Requirements concerning the RDF formalisms and ontologies are marked in
white. 3
Table 3 -‐ Data Representation and Query Processing Requirements. Requirements concerning the RDF
formalisms and ontologies are marked in white. 4
Table 4 – Requirements concerning the RDF formalisms and Ontologies 25
1
Introduction
This document describes the second version of the RDF formalisms and ontologies of the GAMBAS project.
1.1
Purpose
This document describes the required RDF formalisms and ontologies to support the description of the data in the GAMBAS project, such as sensor data, users’ activities and intentions. They concern the data, data properties, and queries found in the GAMBAS scenarios. The first version of this document provided the initial set of classes, properties and queries related to the project, based on a set of initial requirements that were created from the Use Case Specification (D1.3) and from additional input given by all GAMBAS partners.
This version of the deliverable also takes into account the feedback during the implement of the first application prototype (D1.4.1). We have performed a full analysis of the first version of the document, and have updated it accordingly to reflect the decisions taken on the prototype. We have also extended the initial version by considering more use cases from the Use Case Specification (D1.3).
The formalisms and ontologies are a key player in enabling data interoperability in the GAMBAS project, as they provide a unified view of the heterogeneous data produced by the different players in the GAMBAS use cases. Such a unified view, based on semantic descriptions of the data and the data sources, is in line with the Linked Data paradigm, and it not only facilitates data understanding, but it also improves data discovery and integration between both objects and persons, and other sources of data that follow the same paradigm, such as the Web of Data.
The first version of the deliverable provided general concepts that cover the use cases on the transport domain. It also contained an initial set of queries that were expected in the different use cases. This second version of the deliverable revisits the concepts from the first version, and updates/extends them, based on the feedback during the implementation of the first version of the application prototype (D1.4.1). It also considers the use cases on the environmental scenario.
Beyond the project’s internal usage, the GAMBAS project will also make the ontologies and this specification document available to the public. The public availability of the specification not only enables the sharing of knowledge with interested third parties but it also helps to promote the wider acceptance of concepts and mechanisms that are developed within the project.
1.2
Scope
The RDF formalisms and ontologies version 2.0 provides the concepts, properties and queries found in the GAMBAS transport and environmental scenarios. The vocabularies described will be used to model and encode the data in the second version of the application prototype (D1.4.2).
1.3
Specification Methodology
For the description of the example queries, the GAMBAS project uses a subset of SPARQL and CQELS query semantics and syntaxes rather than creating a new query language.
1.4
Structure
The remainder of this specification document is structured as follows. Section 2 revisits the relevant requirements defined in the GAMBAS Requirements Specification D1.1. The requirements that are covered in this deliverable are taken from General Requirements and the Data Representation and Query Processing Requirements. Section 3 provides informative descriptions of the GAMBAS ontology for the transportation and environmental scenarios, which now consists of 8 main classes that are presented in detail in 8 sub-‐sections. Thereafter, Section 4 presents an extensive query set from the use cases, and how they are modelled following the ontology description.
1.5
Reading Recommendation
The normative and informative parts of this specification are identified by use of labels within various sections. Generally, everything in the specification is considered to be normative, apart from the examples. This specification makes use of CURIE syntax [CURIE] as an abbreviated syntax for expressing URIs. The following CURIE prefix bindings are defined:
Table 1 -‐ CURIE prefix binding
gbs http://www.gambas-‐ict.eu/ont/
spt http:// spitfire-‐project.eu/ontology/ns/
gr http://purl.org/goodrelations/v1
pimo http://www.semanticdesktop.org/ontologies/pimo/
vso http://www.heppnetz.de/ontologies/vso/ns#
ppo http://vocab.deri.ie/ppo#
olo http://purl.org/ontology/olo/core#
xsd http://www.w3.org/2001/XMLSchema#
2.2
Data Representation and Query Processing Requirements
Table 3 shows the list of Data Representation and Query Processing Requirements, in a compact form. Please refer to specification D1.1 for the full description of the requirements.
DQ_003 Basic data storing and processing will be provided for constrained computer systems (CCS).
Operational
framework should be interoperable.
Functional and data traditional computer systems (TCS).
Operational
computer systems or traditional computer systems.
Some of these requirements concern the query processing module and are not addressed by the RDF formalisms and Ontologies. The requirements that directly concern the RDF Formalisms and Ontologies are highlighted in white. By using RDF and ontologies we directly address DQ_018, since they are at the core of Linked Data principles. They also provide a unified data representation that is generic, extensible and supports context generalisations (DQ_001, DQ_005, DQ_011, DQ_012, DQ_016). The ontology to describe the locations allows different levels of abstraction to represent spatial information (DQ_006). Finally, the query processing will be designed to query RDF and RDF in stream format; therefore it will be interoperable with this specification (DQ_014). All these requirements were already covered in the first version of this deliverable, and the current version continues to support them.
3
The GAMBAS Ontology
Figure 1 shows the GAMBAS ontologies, its classes, the dependencies among the classes, as well as the external ontologies from which the ontology extends concepts and properties. The external ontologies include PIMO [PIMO], SPT [SPITFIRE], GoodRelations [GR], Ordered List [OLO], and Vehicle Sales [VSO]. The PIMO Ontology provides a vocabulary for describing calendaring data (events, tasks, meetings). The SPITFIRE Ontology (SPT), developed within the SPITFIRE project, aligns already existing vocabularies – such as DOLCE [DOLCE], wgs84 [wgs84] and FOAF [FOAF] – to enable the semantic description of, not only sensor measurements and sensor metadata, but also of the context surrounding them. In particular, the activities sensed by sensors are modelled and related with social domain vocabularies and complex event descriptions. The GoodRelations ontology is widely used to describe business and product offerings. We take advantage of the Ordered List Ontology to represent a sequence of steps. An OrderedList is a list of slots with indexes to each slot and points to next and previous slots. The Vehicle Sales ontology is a web vocabulary for describing cars, boats, bikes, and other vehicles for e-‐commerce, and it is useful in the context of GAMBAS to generalise the means of transport of a user. The descriptive specifications presented in the figures are supplemented by a normative description in Annex I.
The updated version of the GAMBAS ontology consists of a number of sub-‐classes, the core classes being User, Place, Activity, Journey, TravelMode, Bus, Jogging and Shopping. These classes are described in detail in the next sections.
From the Use Case Specification (D2.1) it is clear that the GAMBAS project encompasses a large variety of data. The data variety is not only related to how the data is represented but also refers to the temporal aspects. For instance we have static information about bus routes, as well as the current location of buses, which are continuously streamed into the systems.
The nature of the devices involved in the GAMBAS project is also very heterogeneous. As described in the Requirements Specification (D1.1) there are different classes of devices – from back-‐end computer systems to constrained computer systems. For example, the buses timetables are stored in external servers in the transportation layer, whereas the users’ preferences and their location are kept in their mobile devices for privacy purposes. To enable data interoperability, the GAMBAS ontology was created to describe and represent the different types of data. All the data following the ontology description will be stored in Semantic Data Storages, which will be available in different locations and devices.
3.1
Main differences from the previous version
The current ontology updates/extends the previous ontology, based on the first application prototype (D1.4.2). It also adds data description from the environmental scenario. The main differences from the previous version can be summarised as follows:
• The User class now includes privacy properties on the user profile that addresses particular needs of the GAMBAS use cases. We continue to use the Privacy Preference Ontology (PPO) for defining access levels of users to classes. We have also changed the names of a few properties for clarity’s purpose.
• The Place class now contains properties about the weather and environmental aspects. These are particularly important for the environmental use cases we now cover. We also created a subclass that concerns bus stops.
• A Journey class was introduced to replace the TRANSIT ontology. The TRANSIT vocabulary was confusing, ambiguous and inflexible when modelling the different segments in a route. With our Journey class the definition of bus stops and routes is clear.
• A Journey between two points can consist of multiple transportation modes (e.g. walking, bus). Our ontology now allows a better representation of such properties. A travel mode can be specified to each part of a journey.
• The stream of information about crowd levels is now recorded as a property of the Bus class. Aggregated values can be stored in the journeys’ segments.
• We address the environmental scenario, and introduce two new classes that are sub-‐classes of the Activity class, namely Jogging and Shopping.
3.2
User Class
user’s preferences. As a data provider, users allow GAMBAS to acquire personal data such as location and activities (e.g. travelling in a public transport, jogging, shopping, etc).
Figure 2 shows the User class in the GAMBAS ontology. As in the initial version, it is a subclass of the spt:Agent class from the SPITFIRE ontology, which allows us to describe the user’s profile such as name, email, and addresses. Privacy settings are crucial in GAMBAS. As in the earlier version we use the Privacy Preference vocabulary given by the Privacy Preference Ontology (PPO) [PPO]. However, during the implementation of the application prototype it was clear that the PPO was not suitable to describe users’ shared keys and permission settings, which are needed in the privacy preserving data exchange mechanism of GAMBAS. Therefore we have added privacy related properties to the user profile. More specifically, we have extended the Profile class to include the sharedKeys and certificates used in the privacy frameworks. We have also removed the “role” property, as it became clear in the prototype this distinction is not required.
The user’s calendar information, which will be used as input for the user’s intent analysis, is described by creating a PIMO (Personal Information Model) instance. Users are connected to other users via the “foaf:knows” property, which allows us to list the friends of a user. The location of a user is also available and can be represented with the Place class, described in Section 3.3.
Figure 2 – GAMBAS Ontology: User Class
Users in GAMBAS perform activities, for instance, commuting in a bus or shopping. The GAMBAS ontology provides a vocabulary to represent the user’s activities, include the past, future and current ones. Past and current activities will be used in combination to determine which are the user’s next activities. This will be done by the user’s intent analysis. A description of the Activity class is given in Section 3.4.
3.3
Place Class
The location of a user of activity in GAMBAS can be capture by different sensors (e.g., GPS, WIFI, GSM). The GAMBAS Place class, shown in Figure 4, provides different properties to the different representations. The new version of this class is very similar to the first version. It extends the spt:Place class, which already provides a vocabulary that includes concepts like, city, street, and GPS coordinates. The Place class extends spt:Place by enabling the representation of bus stops and cell location. The CellReading class extends the spt:OV class, which provides the vocabulary to describe sensor observations. We extended the Place class in different ways. We added weather information: a class Weather is now associated with a place. Weather has two properties – current and prediction – and both extend the spt:OV class to describe weather information, both current and forecasted. As in the first version of the class, a noise level can be associated with every location, which will be used, combined with the user’s preferences, to suggest optimal travel routes. We extended the class by adding properties related to the environmental scenario, such has CO2 levels and pollen count. It is important to note that locations can be described by the set of locations it contains. This allows us to aggregate information from smaller areas, to generate a broader view. Lastly, as bus stops are a very relevant type of place in the GAMBAS use cases, we have created a subclass of Place, called BusStop to specifically describe those locations. In addition, we can have a property associated with a bus stop that lists all the bus lines that serve that stop.
Figure 4 – GAMBAS Ontology: Place Class
Figure 5 – Example of an instance of the GAMBAS Place Class
3.4
Activity Class
In the GAMBAS project, a user may perform different activities, e.g. visiting a location, shopping, taking the bus or train, jogging, etc. The GAMBAS Activity class, shown in Figure 6, provides the properties to describe an activity. Every activity can have a start/end location and start/end time. Locations are represented as instances of the Place class. For representing the time we use the xsd:datetime description from the OWL Time ontology [OWL-‐Time].
Figure 6 – GAMBAS Ontology: Activity Class
The Activity class have not changed compared to the first version, since the different activities are modelled as subclasses. For the first version of the ontology we had focused on users travelling in a bus. This activity was updated and is described in the next section. In addition, this updated version of the ontology now also considers the environmental scenario and we have introduced two new classes that address it: Shopping and Jogging. They will be described later in this document.
3.5
Journey Class
We had initially created a BusRide class that refers to an activity of users travelling in a bus. However, an activity is usually associated to a more general journey, which can involve bus trips, as well as
ex:leg1 a gbs:Leg ; #Legs are delimited by start/end locations gbs:startLocation ex:PlazaMayor ;
gbs:endLocation ex:stop2 ;
gbs:distance “10” ; #distance between the two stops. .
ex:PlazaMayor a :Place ;
gbs:pollenCount “2” ; #environmental data gbs:co2Level “300” ;
gbs:contains ex:point1 ; #pollenCount and co2Level of ex:PlazaMayor applies to ex:point1
.
ex:point1 a :Place ; geo:lat "40.409248" ; geo:long "-3.69407" ; geo:alt "10.47881" ;
dc:title " Museo Nacional Centro de Arte Reina Sofía" ; .
other transportation modes (e.g. walk between two bus stops to switch buses). To address this we have modified our ontology by creating a Journey class to model the activity of users moving between two locations (e.g. from home to work). A journey consists of a series of segments, or steps, and these steps are described using the class Step, which was also added to the GAMBAS ontology.
In each entity of the class Step we can specify a number of properties, such as arrival/departure times (both scheduled and estimated), duration, distance covered, and start/end locations. Moreover we can specify the travel mode used in each instance of Step, which will be described in the next section.
In some cases we are interested in recording every segment between two consecutive bus stops, i.e. to check whether a user might meet a friend or not. By using the gbs:singleSteps property we can model this case, and each Step will correspond to two consecutive points in the journey. However, we might also be interested in a more compact version of the journey, where steps in which the travel model hasn’t changed can be represented by one single step. This provides a shortcut to determine when a user entered or left a bus, for instance. For that we have created a gbs:compactSteps property. Note that this compact version can be created at any time from the list of single steps. While it provides some redundant information it greatly improve the performance of some queries. In addition we also introduced a mechanism to keep track of the order in which the steps were performed during the journey. We take advantage of the Ordered List Ontology [OLO] to represent a sequence of instances of the Step class. An OrderedList is a list of slots with indexes to each slot and points to next and previous slots. In our case, each slot contains an item of type Step. Figure 7 illustrates the Journey class, and an example is given in Figure 8.
Figure 8 – Example of an instance of the GAMBAS Journey Class
The instances of the Journey class can be store in the user’s mobile device or a trusted external server. Information regarding the schedules is static, while the estimated departure/arrival times will be dynamically updated.
gbs:distance “10” ; #distance between the two stops. gbs:scheduleArrival "21:13:54Z"^^xsd:time ;
gbs:scheduleDeparture "21:23:00Z"^^xsd:time ;. gbs:travelmode ex:walk ;
gbs:instructions “walk from Plaza Mayor to stop2” ; .
ex:step2 a :Step ;
gbs:startLocation ex:stop2 ; gbs:endLocation ex:stop3 ;
gbs:distance “15” ; #distance between the two stops. gbs:scheduleArrival "21:30:00Z"^^xsd:time ;
gbs:scheduleDeparture "21:35:00Z"^^xsd:time ;. gbs:travelmodel ex:busride ;
Figure 9 – GAMBAS Ontology: TravelMode Class and its subclasses
Figure 10 shows a simple example of an instance of the BusRide class. Note that most of the information associated with a bus ride is already recorded in the Journey class.
Figure 10 – Example of an instance of the GAMBAS BusRide Class, a subclass of TravelMode
3.7
Bus Class
A bus ride is performed by a bus, and this is also represented in the GAMBAS ontology. Figure 11 shows the Bus class. We have made one important change in the ontology, which was to associate the stream of crowd levels to a bus. These aggregated values can be recorded and stored in instances of the BusRide class, to compute statistics of the crowd levels in the different bus routes. In addition, we can represent the route of a bus line by reusing our Journey class. Other properties, such as the bus line name, the bus status (in service or not), and the bus’ current location, remained unchanged.
ex:busride1 a gbs:BusRide ; gbs:user ex:John ;
gbs:crowdLevel “50” ; gbs:serviceBus ex:bus ; .
Figure 11 – GAMBAS Ontology: Bus Class
The information about buses will be provided by the transport layer and stored in an external
semantic data storage. The bus location, crowd levels and its status are constantly updated. Figure 12 below shows an example of an instance of the Bus class.
Figure 12 – Example of an instance of the GAMBAS Bus Class
3.8
Jogging Class
Most of the use cases of the environmental scenario are related to the mobility scenario and can be directly modelled by the existing classes (e.g. Pollution levels, pollen alerts, etc). One use case, however, requires the addition of one class to model users running with a friend.
The Jogging class is a subclass of the Activity class, and it can record the path followed during the jog, the distance covered, the aggregated CO2 and pollen levels and the friends met during the jogging. Since we don’t expect changes regarding transportation mode during a Jogging activity we can model
ex:bus123 a gbs:Bus ;
gbs:busline ex:Sevilla-Hortaleza ; vso:seatingCapacity "100"^^xsd:integer ; vso:VIN "12245254"^^xsd:string ;
prov:performs ex:busride1 ; gbs:status gbs:inService ; gbs:location ex:point1 ; gbs:busUser ex.:John ; gbs:crowdLevel “40” ; .
ex:Sevilla-Hortaleza a gbs:BusLine ; gbs:route ex:journey1 ;
the path taken as one single instance of the Step class, which already provides all the required properties (start/end location, polyline, duration).
Figure 13 shows the Jogging Class, and an example of an instance of the class is given in Figure 14.
Figure 13 – GAMBAS Ontology: Jogging Class
Figure 14 – Example of an instance of the GAMBAS Jogging Class
The jogging activities will be recorded in the mobile device of the user that performed the activity.
3.9
Shopping Class
In addition this extended version of the ontology includes a Shopping class, which is also a subclass of the Activity class, to describe the use case of user’s shopping. Instead of proposing a new class to model stores and their products, we use the GoodRelations ontology [GR], which is well known and widely used. The Shopping class allows us to enlist the products bought by the user during this activity as well as shops visited. Figure 15 shows the Shopping Class, and an example of an instance of the class is given in Figure 16. The shopping activities will be recorded in the user’s mobile device.
ex:jog a gbs:Jogging ; gbs:runWith gbs:Paul ; gbs:distance “5” ; gbs:co2Level “250” ; gbs:path ex:step ;
prov:startedAtTime "09:00:00Z"^^xsd:time ; prov:endedAtTime "09:30:00Z"^^xsd:time ; .
ex:step a :Step ;
gbs:startLocation ex:jogStart ; gbs:endLocation ex:jogEnd ; gbs:distance “5” ;
gbs:polyline “(38.5, -120.2), (40.7, -120.95), (43.252, -126.453)” ; .
Figure 15 – GAMBAS Ontology: Shopping Class
Figure 16 – Example of an instance of the GAMBAS Shopping Class
4
Query Specification
The data instantiated from the GAMBAS ontology is represented as RDF [RDF]. SPARQL [SPARQL] is the most widely used RDF query language, and therefore it will be used as a query language in the GAMBAS context. However, some of the data in GAMBAS will be available as a stream of RDF data, or RDF streams. This is the case for the dynamic information, like the location of a user. For handling RDF streams we will use an extension of the SPARQL query language, called the CQELS query language [CQELS]. The full specification of the SPARQL query semantics and syntaxes are defined by the W3C and can be found at [RDF]. In the RDF data model, each instance must have a globally unique URI. An RDF instance has properties that have values as literals or other instances. A literal can have text or numeric value. In the context of GAMBAS the SPARQL-‐SELECT and CQELS-‐SELECT queries are enough to cover the use cases. The output of these queries is results sets in tabular form of literal and URI. Query results can be easily serialised (for example in XML [XML] or JSON [JSON]).
In the previous version of this deliverable, an initial list of relevant queries was created, based on the uses cases and the feedback from all GAMBAS partners. In this deliverable we revisit some of those queries, in order to highlight the changes in the ontology, and we add a new set of queries that concerns the environmental use cases. For clarity we group the queries into two groups: queries
ex:shopping1 a gbs:Shopping ; gbs:visited ex:eletronicsShop ; gbs:bought ex:tablet;
prov:startedAtTime "11:00:00Z"^^xsd:time ; prov:endedAtTime "12:00:00Z"^^xsd:time ; .
ex:eletronicShop a gr:BusinessEntity ; gr:legalName “MediaMarkt” ;
gr:hasOffer ex:tablet; .
ex:tablet a gr:Offering ;
gr:hasPriceSpecification ex:price ; .
ex:price a gr:UnitPriceSpecification ; gr:hasCurrency "USD"^^xsd:string ; gr:hasCurrencyValue "99.90"^^xsd:float ;
gr:validThrough "2012-12-31T23:59:59Z"^^xsd:dateTime ; .
concerning users, and queries about buses. In both groups we can identify a number of queries from the transport as well as the environmental domain.
4.1
Query about users
Queries concerning user’s personal information, calendar, list of friends and list of activities have remained the same so we focus on the queries that were affected by the changes in the ontology.
For analysing the users’ intent, we need access to information like the activities where a bus ride on a particular bus line was involved. Especially for the case where we want to discover whether two users have been on the same bus, we can ask for activities with a particular bus line and via a particular step. A step in this case corresponds to the route between two consecutive bus stops (given by the URIs of the start and end locations). In both cases, we can narrow the search to a time interval. These queries are shown below.
Figure 17 – Query: Activities involving a given bus line for a given user
Figure 18 – Query: Activities involving a given bus line for a given user, within a specific time interval
Figure 19 – Query: Bus rides on a given bus line for a given segment PREFIX foaf: http://xmlns.com/foaf/0.1/
PREFIX prov: http://www.w3.org/ns/prov# PREFIX : http://www.gambas-ict.eu/ont/ SELECT ?activity
WHERE ?x foaf:nick "userid" . ?activity a :Journey ; prov:wasAssociatedWith ?x ; :compactStep ?step. ?step:TravelMode ?busride. ?busride a :BusRide ;:serviceBus ?bus . ?bus:busLine <buslineURI> .
PREFIX foaf: http://xmlns.com/foaf/0.1/ PREFIX prov: http://www.w3.org/ns/prov# PREFIX : http://www.gambas-ict.eu/ont/ SELECT ?activity
WHERE ?x foaf:nick "userid" . ?activity a :Journey ; prov:wasAssociatedWith ?x ; :compactStep ?step. ?step:TravelMode ?busride. ?busride a :BusRide ;:serviceBus ?bus . ?bus:busLine <buslineURI> .
?activity prov:startedAtTime ?starttime ; prov:endedAtTime ?endtime . FILTER (?endtime < "2012-04-03T00:00:00Z"^^xsd:dateTime) . FILTER (?starttime > "2012-04-02T00:00:00Z"^^xsd:dateTime) .
PREFIX foaf: http://xmlns.com/foaf/0.1/ PREFIX prov: http://www.w3.org/ns/prov# PREFIX : http://www.gambas-ict.eu/ont/ SELECT ?busride
WHERE ?x foaf:nick "userid" . ?activity a :Journey ; prov:wasAssociatedWith ?x ; :singleStep ?step. ?step :startLocation <startLocURI> ;:endLocation <endLocURI> ;:travelMode ?busride. ?busride a :BusRide ;:serviceBus ?bus . ?bus gbs:busLine <buslineURI> .
?activity prov:startedAtTime ?starttime ; prov:endedAtTime ?endtime .FILTER (?endtime < "2012-04-03T00:00:00Z"^^xsd:dateTime) .
WHERE ?x foaf:nick "userid" ; :pastActs ?acts. ?acts :act ?journey ; :compactStep ?step. ?step :travelMode a :BusRide .
PREFIX foaf: http://xmlns.com/foaf/0.1/ PREFIX prov: http://www.w3.org/ns/prov# PREFIX : http://www.gambas-ict.eu/ont/ SELECT ?journey
Figure 23 – Query: Users who had gone jogging with a particular user
The query below let us retrieve the set of products bought by the user.
Figure 24 – Query: Products bought by the user.
To ensure privacy, each user can set permissions to different data that is being monitored. This will determine who can access a particular information type. For example, the query below returns the list of users who can access location information of a particular user.
Figure 25 – Query: Users which can access location information
As we mentioned earlier, this deliverable extends the query set by showing queries that involve dynamic information. For that we use the CQLES query language that resembles SPARQL. The main difference is the introduction of the STREAM command that allows us to specify a window of data within the stream. The query below retrieves the current location of a user.
Figure 26 – Query: Latest location of a user.
In all query examples in this deliverable <streamURI> refers to the URI from where the stream with the data in question can be accessed. The parameter [NOW] extracts the latest location streamed. CQELS is a very flexible language, allowing an easy integration of static and dynamic data. For example, for suggesting bus stops near the user, we can write the following query:
PREFIX foaf: http://xmlns.com/foaf/0.1/ PREFIX prov: http://www.w3.org/ns/prov# PREFIX : http://www.gambas-ict.eu/ont/ SELECT ?user
WHERE ?x foaf:nick "userid" . ?activity a :Jogging ; prov:wasAssociatedWith ?x ; :runWith ?user.
PREFIX foaf: http://xmlns.com/foaf/0.1/ PREFIX prov: http://www.w3.org/ns/prov# PREFIX gr: http://purl.org/goodrelations/v1 PREFIX : http://www.gambas-ict.eu/ont/ SELECT ?product
WHERE ?x foaf:nick "userid" . ?activity a :Shopping ; prov:wasAssociatedWith ?x ; :bought ?product.
PREFIX : http://www.gambas-ict.eu/ont/ PREFIX ppo: http://vocab.deri.ie/ppo# SELECT ?user
WHERE ?x foaf:nick "userid" ; :settings ?set . ?set a ppo:PrivacyPreference; :ppohasCondition ?cond. ?cond ppo:classAsObject :Place. ?set ppo:hasAccessSpace ?spc. ?spc ppo:hasAccessAgent ?user.
PREFIX foaf: http://xmlns.com/foaf/0.1/ PREFIX prov: http://www.w3.org/ns/prov# PREFIX : http://www.gambas-ict.eu/ont/ SELECT ?location
WHERE ?x foaf:nick "userid" .
STREAM <streamURI> [NOW] {?x :location ?location}. ?nearby a :BusStop ; spt:nearby ?location.
PREFIX : http://www.gambas-ict.eu/ont/
PREFIX spt: http:// spitfire-project.eu/ontology/ns/ SELECT ?place
WHERE ?place a :BusStop ; spt:nearby <locationURI>.
PREFIX : http://www.gambas-ict.eu/ont/
PREFIX geo: http://www.w3.org/2003/01/geo/wgs84_pos# PREFIX spt: http:// spitfire-project.eu/ontology/ns/
SELECT ?place
WHERE ?place a :BusStop ; spt:nearby ?location. ?location a :Place ; geo:Lat “50.0” ; geo:long “3.0”.
WHERE ? busline a :BusLine ; :route ?busRoute
PREFIX : http://www.gambas-ict.eu/ont/ PREFIX olo: http://purl.org/ontology/olo/core# SELECT ?start ?stop
WHERE {?busline a :BusLine ; :route ?busRoute. ?busRoute :orderedSteps ?list. ?list olo:slot ?slot . ?slot olo:item ?step ; olo:index ?index . ?step :startLoc ?start ; :endLoc ?end}
ORDER BY ASC(?index).
WHERE <busstopURI> :busLine ?busline . ?busline :route ?route. ?route prov:startedAtTime ?start ; prov:endedAtTime ?end.
requirements were addressed in this deliverable.
PREFIX foaf: http://xmlns.com/foaf/0.1/ PREFIX : http://www.gambas-ict.eu/ont/ SELECT ?estimateddeparture
WHERE ?x foaf:nick "userid" ; :location ?stop. ?stop :busline ?line . ?line :route ?route . ?route :singleStep ?step . ?step :startLocation ?stop ; :scheduleDeparture ?scheduleDeparture
Table 4 – Requirements concerning the RDF formalisms and Ontologies
framework should be interoperable.
• GE_015, GE_16, GE_019: Environmental information (i.e. noise level, pollen count, CO2 levels, etc), as well as crowd level information are represented in the ontology and therefore can be queried and further processed.
• DQ_001, DQ_005: The ontology provides the vocabulary for a unified representation of the data in the GAMBAS framework. Both RDF and SPARQL – the data format and query language used – are generic and widely used. The CQELS language for stream processing is very close to SPARQL which favours adoption by SPARQL users. Moreover, RDF can be easily serialised to other data formats.
• DQ_006: The Place class allows different representations of spatial data.
• DQ_011, DQ_012: The GAMBAS ontology provides a model to describe the data from the GAMBAS use cases. Its modular, which makes it easy to extend. At any time, new classes and properties can be added, with minimum effort. This has already been done in this new version of the deliverable. The ontology can be further extended, if needed.
• DQ_014: By using the RDF and SPARLQ/CQELS standards, we have guaranteed that the data model and query language are interoperable. This can be seen in the query examples presented in this deliverable.
• DQ_016: One of the properties of ontologies is to allow context generalisations. As example, two new sub classes of Activity were added in this version of the deliverable. In addition, other means of transport can be added to the Transport Mode class. Queries can be performed at any level on this class hierarchy. That means that, for example, one can query for any activity a user has perform, regardless of its type.
• DQ_18: The RDF and SPARQL/CQELS standards both follow the Linked Data principles. In addition, each instance of a class will have a URI as unique identifier that is dereferenceable.
6
Bibliography
[CQELS] Danh Le Phuoc, Minh Dao-‐Tran, Josiane Xavier Parreira, Manfred Hauswirth: A Native and Adaptive Approach for Unified Processing of Linked Streams and Linked Data. International Semantic Web Conference (1) 2011: 370-‐388
[CURIE] CURIE Syntax 1.0. http://www.w3.org/TR/curie/
[DOLCE] DOLCE : a Descriptive Ontology for Linguistic and Cognitive Engineering.
http://www.loa.istc.cnr.it/DOLCE.html
[FOAF] FOAF Vocabulary Specification. http://xmlns.com/foaf/spec/.
[GR] GoodRelations Language Reference. http://purl.org/goodrelations/v1
[JSON] Serializing SPARQL Query Results in JSON.
http://www.mindswap.org/~kendall/sparql-‐results-‐json/
[OLO] The Ordered List Ontology. http://purl.org/ontology/olo/core#
[OWL-‐Time] Time Ontology in OWL. http://www.w3.org/TR/owl-‐time/
[PIMO] Personal Information Model. http://www.semanticdesktop.org/ontologies/2007/11/01/pimo/#
[PPO] Privacy Preference Ontology. http://vocab.deri.ie/ppo
[RDF] Resource Description Framework (RDF): Concepts and Abstract Syntax. http://www.w3.org/TR/rdf-‐ concepts/
[SPARQL] SPARQL Query Language for RDF. http://www.w3.org/TR/rdf-‐sparql-‐query/
[SPITFIRE] The SPITFIRE Ontology. http://spitfire-‐project.eu/ontology/ns/
[TURTLE] Terse RDF Triple Language. http://www.w3.org/TR/2012/WD-‐turtle-‐20120710/
[VSO] Vehicle Sales Ontology. http://www.heppnetz.de/ontologies/vso/ns
[WGS84] WGS84 Geo Positioning: an RDF vocabulary . http://www.w3.org/2003/01/geo/wgs84_pos .
[XML] SPARQL Query Results XML Format. http://www.w3.org/TR/rdf-‐sparql-‐XMLres/
Annex A. Normative specification of ontologies
Annex A.1. Reading term descriptions
! normative-‐references: It contains a list of normative references that describe precisely
the intended meaning of the ontology term.
! restrictions: This field contains the property restrictions for the class. Property restrictions
are documented in accordance with the OWL Abstract Syntax.
! normative-‐instances: This field is a list of CURIEs with the normative instances (if any) for the
class.
Property Description Specific Fields
! domain: This field indicates the property domain. If it does not appear it means that the described property is a subproperty (rdfs:subPropertyOf axiom).
! super-‐property-‐of: This field contains a list of all those ontology properties defined as a subproperty of (rdfs:subPropertyOf axiom) the described property.
! instance-‐of: This field is a list that represents the class membership of the instance.
! inverse-‐property-‐of: This field contains a list of all properties that are inverse of described property.
! property-‐values: This field is composed by a list that represents the property values (represented as RDF Typed Literals) that must have the described instance.
Annex A.2. GAMBAS Ontology
URI: http://www.gambas-‐ict.eu/ont/gambas.owl
CURIE: gambas:PastActivities
Class Place
Abstract – This class represents the general abstraction of a place. CURIE: gambas:Place
sub-‐class-‐of
http://spitfire-‐project.eu/ontology/ns/Place
super-‐class-‐of
http://www.semanticdesktop.org/ontologies/pimo/PersonalInformationModule
Abstract – This class represents the general abstraction of a step within a journey.
range
http://purl.org/goodrelations/v1/BusinessEntity
Property voice tag location
The location associated with a voice tag – This property is used to describe the location associated with a voice tag.
CURIE: gambas:voicetaglocation
domain
gambas:VoiceTag
range
gambas:Place
