Document Title Document Version D4.1.1 RDF Sensor Formalisms and Ontologies 0.5
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
M12 Jan 31st, 2013 R (Report) PU (Public)
Document Author or Reviewer Organization Work Package
Josiane Xavier Parreira NUIG WP4
Myriam Leggieri NUIG WP4
Stefan Foell OU WP4
Marcus Handte UDE WP4
Abstract
0.2 OU Review.
0.3 NUIG Added feedback from partners.
0.4 UDE Internal review.
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 User Class ... 8
Figure 1 – The GAMBAS Ontology and its dependencies 7
Figure 2 - GAMBAS Ontology: User Class 9
Figure 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 11
Figure 6 - GAMBAS Ontology: Activity Class 12
Figure 7 - GAMBAS Ontology: BusRide Class 12
Figure 8 - Example of an instance of the GAMBAS BusRide Class 14
Figure 9 - GAMBAS Ontology: Bus Class 15
Figure 10 - Example of an instance of the GAMBAS Bus Class 15
Figure 11 – Query: All users 16
Figure 12 - Query: Status (i.e. current activity) of a user 16
Figure 13 - Query: Calendar of a user 16
Figure 14 - Query: Set of friends of a user 17
Figure 15 – Query: Information about current bus ride 17
Figure 16 – Query: Past activities 17
Figure 20 – Query: Bus rides on a given bus line for a given segment 18 Figure 21 – Query: Bus rides on a given bus line for a given segment, within a time interval 18 Figure 22 – Query: Nearest bus stops, given a GPS location 19 Figure 23 – Query: Nearest bus stops, given a symbolic location 19
Figure 24 – Query: Bus line given a wifi reading 19
Figure 25 – Query: All bus lines 19
Figure 26 – Query: All bus stops 19
Figure 27 – Query: All buses 20
Figure 28 – Query: Route of a bus line 20
Figure 29 – Query: Bus stops of a bus line 20
Figure 30 – Query: Bus lines that run through a given bus stop 20 Figure 31 – Query: Bus lines that run through a given bus stop, filtered by given date 20
Figure 32 – Query: Schedule information of a bus line 20
Figure 33 – Query: Information about arrival/departure times of a bus line 21
Figure 34 – Query: Distance between two consecutive stops 21
Figure 35 – Query: Bus line associated with a bus 21
Figure 36 – Query: Bus status 21
Figure 37 – Query: Bus crowd level 21
Figure 38 – Query: Live estimated bus schedule 22
Figure 39 – Query: Historical bus traces 22
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
1
Introduction
This document describes the first 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 RDF formalisms and ontologies are 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 deliverable is the initial step to enable data interoperability in the GAMBAS project. The formalisms and ontologies 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 follows the same paradigm, such as the Web of Data.
In this first version of the deliverable, the general concepts are provided, but they are sufficiently extensible for the use cases on the transport domain. The deliverable also describes an initial set of queries that are expected in the different use cases. The concepts will be used by the other work packages to described and access their data. The developed ontology described in this deliverable will be refined and expanded further in D4.1.2, based on the feedback from the other work packages and the initial application prototype (D1.4.1).
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 1.0 provides basic concepts, properties and queries found in the GAMBAS scenarios. The vocabularies described will be used to model and encode the data in the initial application prototype (D1.4.1). The more elaborated concepts and properties will be provided in the iterated version of this deliverable.
1.3
Specification Methodology
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, which includes 5 main classes that are presented in detail in 5 sub-sections. Thereafter, Section 4 presents an extensive query set from the use cases in the transport domain, 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/ tst http://vocab.org/transit/terms/
pimo http://www.semanticdesktop.org/ontologies/pimo/ vso http://www.heppnetz.de/ontologies/vso/ns# ppo http://vocab.deri.ie/ppo#
2
Requirements
This section revisits the relevant requirements defined in the GAMBAS Requirements Specification D1.1. Intuitively, the requirements that are covered in this deliverable are taken from General Requirements and the Data Representation and Query Processing Requirements.
2.1
General Requirements
Table 2 lists the general requirements of the overall GAMBAS systems that have been identified in the GAMBAS Requirements Specification (D1.1). The table contains only the id, a short description, the type of the requirement and its priority. Please refer to the GAMBAS Requirements Specification document for a complete description of the requirements, including acceptance criteria and prioritization rationales.
As described in the Requirements Specification, the general requirements target the GAMBAS framework as a whole (GE_001, GE_005), its applications (GE_004, GE_013, GE_016), and pre-requisites to enable the system (GE_014, GE_015, GE_017, GE_018, GE_019). They also specifically target the GAMBAS middleware (GE_007, GE_008, GE_009, GE_010, GE_011, GE_012).
From this set of general requirements, the RDF formalisms and Ontologies only addresses a subset. This subset is marked in white. The requirements marked in grey will be handled within other specifications.
Table 2 - General Requirements. Requirements concerning the RDF formalisms and ontologies are marked in white.
ID Description Type Priority
GE_001 The GAMBAS framework should be able to support different devices.
Operational
requirements 1 - High
GE_004 The GAMBAS framework provides crowd-levels for each bus journey.
Mandated constraints 1 - High
GE_007 The GAMBAS framework enables providing adaptive and customized information to users.
The purpose of the
product 1 - High
GE_008 The GAMBAS framework simplifies the development of services that acquire data from different devices.
The purpose of the
GE_010 The GAMBAS framework enables the optimization of services based on usage behavior.
The purpose of the
product 1 - High
GE_011 The GAMBAS framework enables proactive service offerings based on the current user context.
The purpose of the
GE_012 The GAMBAS framework enables proactive service offerings based on the current user context.
The purpose of the
product 1 - High
GE_013 The GAMBAS framework enables the acquisition of
travel- and environment-related data. The scope of the work 1 - High
GE_014 The application services are able to compute possible end-to-end bus routes.
Relevant facts and
assumptions 1 - High
GE_015 The application services are able to aggregate and share crowd levels from busses.
Relevant facts and
assumptions 1 - High
GE_016
The GAMBAS framework enables providing environmental quality data for a geolocated point in the city.
The scope of the work 1 - High
GE_017 The application services are able to record and predict crowd-levels.
Relevant facts and
assumptions 1 - High
GE_018
Personal devices should have internet access to retrieve data from social networks and collaboration tools. support of different devices and facilitate the data integration. Allowing data from different sources to be integrated is one of the major objectives of Linked Data.
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_004 The data processing should be able to adapt to changes in the network and incoming data.
Functional and data
requirements 1 - High
DQ_005 The data representation and query language should be generic.
Functional and data
requirements 2 - Medium
DQ_006 The data representation must support spatial data in
DQ_009 The data processing framework should be scalable. Performance
requirements 2 - Medium
DQ_010
The linked data discovery infrastructure does not require the user to expose a particular type of information.
Functional and data
requirements 1 - High
DQ_011 The data representation should provide a data model for the information relevant to the use cases.
Functional and data
requirements 1 - High
DQ_012 The data representation should be extensible. Functional and data
requirements 2 - Medium
DQ_013 The data processing framework supports continuous queries on changing data.
Functional and data
requirements 1 - High
DQ_014 The data representation and query processing framework should be interoperable.
Functional and data
requirements 1 - High
DQ_016 The data representation should provide support for context generalizations.
Functional and data
requirements 1 - High
DQ_017
Large data storage and advanced query processing will be provided in back-end computer systems (BCS) or computer systems or traditional computer systems.
Operational
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 TRANSIT [TRANSIT], PIMO [PIMO], SPT [SPITFIRE], and Vehicle Sales [VSO]. TRANSIT provides a vocabulary for describing transit systems, routes, stops and schedules, and its schema is based on the General Transit Feed Specification published by Google. 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 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.
Figure 1 – The GAMBAS Ontology and its dependencies
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. The 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
User Class
The User class is used to describe users in the GAMBAS framework. In GAMBAS, users play the roles of both data consumer and provider. As a consumer it has access to services provided by the GAMBAS user intention interface such as suggestions of bus routes, given the 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 - 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 complete description of the Activity class is given in Section 3.3.
Audio data coming from mobile devices is also part of the GAMBAS project. It will interface with the Semantic Data Storage, but the data and the query processing will be performed by legacy services. The audio fingerprints associated to a user will be represented by the gbs:Fingerprint class and can be retrieved via the user’s property “gbs:reducedAudio”.
Figure 3 - Example of an instance of the GAMBAS User Class
3.2
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. 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. Moreover, a noise level can be associated with every location, which will be used, combined with the user’s preferences, to suggest optimal travel routes.
gbs:path ex:transfer1 ; #checkins done during the ride gbs:path ex:transfer2 ;
Figure 4 - GAMBAS Ontology: Place Class
A directory of locations will be available in an external server. Users’ current location will be dynamically stored on the mobile device. Figure 5 shows an example of the use of the Place class.
Figure 5 - Example of an instance of the GAMBAS Place Class
3.3
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 will use the xsd:datetime description from the OWL Time ontology [OWL-Time].
ex:stop1 a transit:ServiceStop ;
transit:distance "0.0"^^xsd:double ; #distance from the main stop
transit:dropoff ex:stopOnRequest3 ; #arrangement required for passengers to be dropped off at this stop
transit:pickup ex:stopOnRequest3 ; #arrangement required for passengers to be picked up at this stop
transit:station ex:PlazaMayor ;
transit:stop ex:track1 ; #specific place of the service stop area where people hop on or drop off
spt:nearby ex:point1 ;
transit:service ex:busline1 ; #the specified arrangements for dropping off and picking up are valid for this bus line.
.
ex:PlazaMayor a transit:Station ; transit:stationStop ex:track1 ; transit:stationStop ex:track2 ; transit:stationStop ex:track3 ; spt:nearby ex:point1 ;
.
ex:point1 a gbs:Place ; geo:lat "40.409248" ; geo:long "-3.69407" ; geo:alt "10.47881" ;
Figure 6 - GAMBAS Ontology: Activity Class
Other properties of an Activity depend on the type of the activities. Each activity type defines a subClass of the Activity ontology. For the first phase of the project we will focus on users travelling in a bus, which is described in the next section. Other activities, such as jogging or shopping, will be added in the second phase of the project.
3.4
BusRide Class
A bus ride is a type of activity that a user can perform in GAMBAS. The BusRide class is used to describe this type of activity. It extends the TRANSIT ontology, which is available for describing transit systems, routes, stops and schedules.
3.5
Bus Class
A bus ride is performed by a bus, and this is also represented in the GAMBAS ontology. Figure ? shows the Bus class. It contains information such as the bus line, the bus status (in service or not), and the bus’ current location.
Figure 9 - GAMBAS Ontology: Bus Class
As in the case of a bus ride, the information about buses will be provided by the transport layer and stored in an external semantic data storage. The bus location and its status are constantly updated. Figure 10 below shows an example of an instance of the Bus class.
Figure 10 - Example of an instance of the GAMBAS Bus Class ex:bus123 a :Bus ; a ssn:Platform ;
tst:agency ex:EMT ;
gbs:busline ex:Sevilla-Hortaleza ; gbs:busline ex:PlazaMayor-ElEspinillo ; vso:seatingCapacity "100"^^xsd:integer ; vso:VIN "12245254"^^xsd:string ;
gbs:pastAct ex:TraceHistorybus123 ; prov:performs ex:activity90 ; gbs:status gbs:inService ; spt:nearby ex:point1 .
ex:dublinair a tst:Service ; tst:schedule ex:schedule1 ; tst:agency ex:EMT ;
tst:route ex:route1 ; .
4
Query Specification
The data instantiated from the GAMBAS ontology is represented as RDF [RDF]Fehler! Verweisquelle konnte nicht gefunden werden. 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 queries concerning RDF streams will be addressed in the next version of this deliverable and also on deliverable. 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 queries are enough to cover the use cases. The output of a SPARQL-SELECT query is results sets in tabular form of literal and URI. Query results can be easily serialised (for example in XML [XML] or JSON [JSON]).
Based on the uses cases and the feedback from all GAMBAS partners, an initial list of relevant queries was created. Next we described every query in detail, and show how the query can be represented. For clarity we group the queries into two groups: queries concerning users and queries concerning buses.
4.1
Query about users
For retrieving the list of all users registered at the system we can use the following query.
Figure 11 – Query: All users
The following three queries return, respectively, the status (i.e. current activity), the calendar, and the list of friends of a particular user.
PREFIX : http://www.gambas-ict.eu/ont/ SELECT *
WHERE ?x a :User .
PREFIX foaf: http://xmlns.com/foaf/0.1/ PREFIX : http://www.gambas-ict.eu/ont/ SELECT ?activity
Figure 14 - Query: Set of friends of a user
Given that the user is in a bus, we would like the retrieve all useful information associate with the user’s current bus ride. Given that bus ride is a sub class of activity, this is done by the following query.
Figure 15 – Query: Information about current bus ride
The property “wasAssociatedWith” checks if the activity is associated with the user in question. The end time of an ongoing activity can be set to a default high value for the comparison in the filter condition. In case the current activity is not a bus ride the query above would return an empty set.
The historical information about past activities is store and can be queried. For instance, one can request the set of all past activities (Figure 16), or alternatively, select only the sub set of activities that occurred within a particular time interval (Figure 17).
Figure 16 – Query: Past activities
Figure 17 – Query: Past activities within a given time interval
For analysing the users’ intent, we need access to information like the set of bus rides where a particular bus line was involved. Especially for the case where we want to discover whether two users has been on the same bus, we can ask for bus rides with a particular bus line and via a particular segment. A segment is defined as the bus route between two consecutive bus stops. In both cases, we can narrow the search to a time interval. These queries are shown below.
PREFIX foaf: http://xmlns.com/foaf/0.1/ SELECT ?friend
WHERE ?x foaf:nick "userid" ; foaf:knows ?friend .
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 :BusRide ; prov:wasAssociatedWith ?x ; prov:endedAtTime ?endtime.
FILTER ( ?endtime > NOW ) .
PREFIX foaf: http://xmlns.com/foaf/0.1/ PREIX : http://www.gambas-ict.eu/ont/ SELECT ?arch
WHERE ?x foaf:nick "userid" ; :pastAct ?arch .
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" ; :pastAct ?arch . ?arch :act ?activity . ?activity prov:startedAtTime ?starttime ; prov:endedAtTime ?endtime .
Figure 18 – Query: Bus rides on a given bus line for a given user
Figure 19 – Query: Bus rides on a given bus line for a given user, within a specific time interval
Figure 20 – Query: Bus rides on a given bus line for a given segment
Figure 21 – Query: Bus rides on a given bus line for a given segment, within a time interval
In the examples show how the TRANSIT ontology can be used to represent buses, bus lines, and
WHERE ?x foaf:nick "userid" . ?activity a :BusRide ; prov:wasAssociatedWith ?x ; :serviceBus ?bus . ?bus transit:service <buslineURI> .
PREFIX prov: http://www.w3.org/ns/prov# PREFIX transit: http://vocab.org/transit/terms/ PREFIX : http://www.gambas-ict.eu/ont/ SELECT ?busride
WHERE ?x foaf:nick "userid" . ?activity a :BusRide ; prov:wasAssociatedWith ?x ; :serviceBus ?bus . ?bus transit:service <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 transit: http://vocab.org/transit/terms/ PREFIX : http://www.gambas-ict.eu/ont/ SELECT ?busride
WHERE ?x foaf:nick "userid" . ?activity a :BusRide ; prov:wasAssociatedWith ?x ; :path <segmentURI> ; :serviceBus ?bus . ?bus transit:service <buslineURI> .
PREFIX foaf: http://xmlns.com/foaf/0.1/ PREFIX prov: http://www.w3.org/ns/prov# PREFIX transit: http://vocab.org/transit/terms/ PREFIX : http://www.gambas-ict.eu/ont/ SELECT ?busride
WHERE ?x foaf:nick "userid" . ?activity a :BusRide ; prov:wasAssociatedWith ?x ; :path <segmentURI> ; :serviceBus ?bus . ?bus transit:service <buslineURI> . ?activity prov:startedAtTime ?starttime ;
Figure 22 – Query: Nearest bus stops, given a GPS location
Alternatively, we can ask for bus stops near a symbolic location.
Figure 23 – Query: Nearest bus stops, given a symbolic location
Locations can have wifi readings associated with them. The query below retrieves the bus lines that go over a particular location identified by a wifi reading.
Figure 24 – Query: Bus line given a wifi reading
The represent the wifi readings we reuse the SPITIFIRE ontology. It allows us to retrieve the location of sensor generating the reading. The query then checks if the location is a bus stop (“transit:Station”), before returning the bus lines.
The next three queries return the set of all bus lines, all bus stops, and all buses respectively.
Figure 25 – Query: All bus lines
WHERE ?station a transit:Station ; :location ?point . ?point geo:lat ?lat ; geo:long ?long . FILTER (?lat > "50.0") .
FILTER (?lat < "53.0") . FILTER (?long > "-3.0") . FILTER (?long < "-1.0") .
PREFIX dc: http://purl.org/dc/elements/1.1/ PREFIX transit: http://vocab.org/transit/terms/ PREFIX : http://www.gambas-ict.eu/ont/ SELECT ?station
WHERE ?station a transit:Station ; :location ?point . ?point dc:title <locationName> .
PREFIX snn: http://purl.oclc.org/NET/ssnx/ssn# PREFIX transit: http://vocab.org/transit/terms/ PREFIX : http://www.gambas-ict.eu/ont/ SELECT ?busline
WHERE <wifireading> spt:outOf ?sensor . ?sensor ssn:onPlatform ?point. ?point a transit:Station ; ?location :busLineAtStop ?busline .
PREFIX transit: http://vocab.org/transit/terms/ SELECT ?busline
WHERE ?busline a transit:Service .
PREFIX transit: http://vocab.org/transit/terms/ SELECT ?stops
Figure 27 – Query: All buses
For a particular bus line, we can query for the bus route, as well as bus stops associated with the bus line.
Figure 28 – Query: Route of a bus line
Figure 29 – Query: Bus stops of a bus line
For a given bus stop we can, for instance, retrieve the set of bus lines that run on that stop (Figure 30). Alternatively, we can filter this request by selecting only the bus lines on a given date (Figure 31).
Figure 30 – Query: Bus lines that run through a given bus stop
Figure 31 – Query: Bus lines that run through a given bus stop, filtered by given date
The query above looks at the schedule of the bus lines to retrieve the dates, which are then selected according to the filtering criteria. To retrieve all the schedule information for a given bus line, we can use the query below.
PREFIX : http://www.gambas-ict.eu/ont/ SELECT ?bus
WHERE ?bus a :Bus .
PREFIX transit: http://vocab.org/transit/terms/ SELECT ?route
WHERE <buslineURI> transit:route ?route .
PREFIX transit: http://vocab.org/transit/terms/ SELECT ?stops
WHERE <buslineURI> transit:serviceStop ?stops .
PREFIX
SELECT ?busline
WHERE <busstopURI> :busLineAtStop ?busline .
PREFIX transit: http://vocab.org/transit/terms/ PREFIX : http://www.gambas-ict.eu/ont/ SELECT ?busline
WHERE ?schedule a transit:Schedule ; transit:date ?date ; :journey ?journey ; transit:scheduleService ?busline .
Figure 33 – Query: Information about arrival/departure times of a bus line
The distance between two consecutive bus stops is represented in the ontology and can be easily retrieve using the following query.
Figure 34 – Query: Distance between two consecutive stops
For a given bus we can, for instance, query for the bus line associated with it (Figure 355) or for its status (Figure 366).
Figure 355 – Query: Bus line associated with a bus
Figure 366 – Query: Bus status
In addition, we would like to get the current information of the crowd level of a bus. This is done by first determining which is the current transfer segment in which the bus is location, i.e. the one with the highest sequence number, then extracting its crowdlevel, as shown below.
Figure 377 – Query: Bus crowd level
Despite the pre-defined schedules, some bus might arrive at their stops a different time as expected, due to multiple reasons, like traffic jams. In the GAMBAS projects, the buses will constantly update their arrival and departure times, as the bus ride goes on. This live information can be retrieved via the “EstimatedSchedule” property, as shown below.
PREFIX transit: http://vocab.org/transit/terms/ PREFIX : http://www.gambas-ict.eu/ont/ SELECT ?arrival ?departure
WHERE <givenstop> transit:serviceStop ?servicestop . ?servicestop transit:arrivalTime ?arrival ; transit:departureTime ?departure ; transit:service <givenbusline> . <givenbusline> transit:schedule ?schedule . ?schedule :scheduleStart ?start; :scheduleEnd ?end :journey ?transfer . ?transfer transit:to <givenstop> . filter ?start < NOW() . filter ?end > NOW() . filter ?arrival < <giventime> . filter ?departure > <giventime> .
PREFIX transit: http://vocab.org/transit/terms/ SELECT ?dist
WHERE ?transfer a transit:Transfer. ?transfer :distance ?dist. ?transit transit:fromStop <location1>. ?transfer transit:toStop <location2> .
PREFIX : http://www.gambas-ict.eu/ont/ SELECT ?busline
WHERE <givenbus> :busline ?busline .
PREFIX prov:http://www.w3.org/ns/prov# PREFIX : http://www.gambas-ict.eu/ont/ SELECT ?status
WHERE ?bus a :Bus . ?status prov:wasAssociatedWith ?bus .
PREFIX transit: http://vocab.org/transit/terms/ PREFIX : http://www.gambas-ict.eu/ont/ SELECT ?crowdlev,?seq
Figure 388 – Query: Live estimated bus schedule
Finally, the queries below involve the historical information associated with buses. The query in Figure 399 retrieves all the recorded bus traces of a given bus. The result of this query can be also filtered by selecting only traces within a given time interval (Figure 40).
Figure 399 – Query: Historical bus traces
Figure 40 – Query: Historical bus traces given a time interval
5
Requirements Coverage
In this section we will re-visit the requirements listed in Section 2. The table below summarises all the requirements that concerns the RDF formalisms and ontologies. Following, we discuss how these requirements were addressed in this deliverable.
Table 4 – Requirements concerning the RDF formalisms and Ontologies
ID Description Type Priority
GE_001 The GAMBAS framework should be able to support different devices.
Operational
requirements 1 - High
GE_008 The GAMBAS framework simplifies the development of services that acquire data from different devices.
The purpose of the
product 1 - High
The GAMBAS framework enables the development of The purpose of the PREFIX : http://www.gambas-ict.eu/ont/
SELECT ?estimatedtime
WHERE ?sched a :EstimatedSchedule ; :scheduleBus <busURI> .
PREFIX : http://www.gambas-ict.eu/ont/ SELECT ?tracearchive
WHERE ?tracearchive a :PastActivities ; :serviceBus <busURI> .
PREFIX prov:http://www.w3.org/ns/prov# PREFIX : http://www.gambas-ict.eu/ont/ SELECT ?trace
WHERE ?tracearchive a :PastActivities ; :serviceBus <busURI> ; :trace ?ride . ?ride prov:startedAtTime ?starttime ; prov:endedAtTime ?endtime .
DQ_005 The data representation and query language should be generic.
Functional and data
requirements 2 - Medium
DQ_006 The data representation must support spatial data in different formats.
Functional and data
requirements 1 - High
DQ_011 The data representation should provide a data model for the information relevant to the use cases.
Functional and data
requirements 1 - High
DQ_012 The data representation should be extensible. Functional and data
requirements 2 - Medium
DQ_014 The data representation and query processing framework should be interoperable.
Functional and data
requirements 1 - High
DQ_016 The data representation should provide support for context generalizations. representation and query language, regardless of the device. Allowing data from heterogeneous sources to be easily integrated.
GE_015, GE_019: Environmental information (i.e. noise level), and crowd level 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. 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 usecases. Its modular, which makes it easy to extend. At any time, new classes and properties can be added, with minimum effort. In fact, the ontology will be extended in the second phase of the project, based on feedback from the GAMBAS partners.
DQ_014: By using the RDF and SPARLQ 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.
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/.
[JSON] Serializing SPARQL Query Results in JSON.
http://www.mindswap.org/~kendall/sparql-results-json/
[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/
[TRANSIT] TRANSIT: A vocabulary for describing transit systems and routes. http://vocab.org/transit/terms/
[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 .
Annex A. Normative specification of ontologies
Annex A.1. Reading term descriptions
Each term (class, property, normative instance) used in this deliverable is documented normatively in this annex. A term description is composed by the following fields:
The term's Local Name, conveyed in the title of the corresponding section. Class local names start with a capital letter. Property local names start with a lower case letter. Normative instance local names start with a prefix that it is equal to the local name of their class.
A full URI (represented as a [CURIE]) that univocally identifies the term.
A human-readable term description composed by label (rdfs:label) and full text (rdfs:comment).
A set of fields that give additional details about the term in question. All term descriptions may contain:
normative-references: It contains a list of normative references that describe precisely
the intended meaning of the ontology term.
informative-references: It is a list of informative references that clarifies the meaning of
the ontology term.
The fields used in a class description are described as follows:
sub-class-of: This field contains a list of all those ontology classes for which the described
class is a subclass (rdfs:subClassOf axiom).
super-class-of: This field contains a list of all those ontology classes defined as a subclass
(rdfs:subClassOf axiom) of the described class.
in-domain-of: This field contains a list of all those ontology properties whose domain includes
the class.
in-range-of: This field contains a list of all those ontology properties whose range includes
the class.
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
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
Namespace : @PREFIX gambas http://www.gambas-ict.eu/ont /gambas.owl #
Class Activity
Abstract Activity – This class represents the users’ activities. CURIE: gambas:Activity
sub-class-of
http://spitfire-project.eu/ontology/ns/Activity
super-class-of
gambas:BusRide
Class Bus
Abstract Bus – This class represents the general abstraction of a bus. CURIE: gambas:Bus
sub-class-of
http://www.heppnetz.de/ontologies/vso/ns#BusOrCoach
Class Bus Ride
Abstract Bus Ride – This class represents a bus ride performed by a user. CURIE: gambas:BusRide
sub-class-of
gambas:Activity
Class Cell Reading
Abstract Cell Reading – This class represents the general abstraction of a cell reading. CURIE: gambas:CellReading
sub-class-of
http://spitfire-project.eu/ontology/ns/OV
Class Estimated Schedule
Abstract– This class represents the general abstraction of the estimated schedule of a bus. CURIE: gambas:EstimatedSchedule
sub-class-of
http://vocab.org/transit/terms/Schedule
Class Fingerprint
Abstract– This class represents the general abstraction of a user’s audio fingerprint. CURIE: gambas:Fingerprint
Abstract– This class represents the general abstraction of the past activities of a user. CURIE: gambas:PastActivities
Class Personal Information
Abstract– This class represents the personal information of a user. CURIE: gambas:PersonalInformation
sub-class-of
http://www.semanticdesktop.org/ontologies/pimo/PersonalInformationModule
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
Class User
Abstract– This class represents the general abstraction of a user. CURIE: gambas:User
sub-class-of
http://spitfire-project.eu/ontology/ns/User
Property act
The activities belonging to Past Activities - This property is used to describe the activities which belong to the set of Past Activities.
CURIE: gambas:act
domain
gambas:Past Activities
range
gambas:Activity
Property bus Line
The line of a bus - This property is used to describe the bus line a bus is operating. CURIE: gambas:busLine
range
Property bus User
The location of cell readings - This property is used to describe the location of cell readings. CURIE: gambas:cellLocation
The crowd level of a bus ride transfer - This property is used to describe the crowd level, i.e. number of passengers, in a bus ride transfer.
CURIE: gambas:crowdLevel
range
xsd:Integer
Property current
The activity that is currently being performed - This property is used to describe the activity that is currently being performed, i.e., it has not yet ended.
CURIE: gambas:current
range
gambas:Activity
Property default
The default activity of a user - This property is used to describe the default activity of a user, if needed. bus, represented by the final stop the bus is directed to.
CURIE: gambas:direction
domain
gambas:Bus Ride
range
Property distance
The distance covered during each bus transfer - This property is used to describe the distance (in kilometers) covered during each bus transfer.
CURIE: gambas:distance
domain
http://vocab.org/transit/terms/Transfer
range
xsd:double
Property estimated Arrival
The estimated arrival of a bus at a bus stop - This property is used to represent the estimated arrival time of a bus at a bus stop.
CURIE: gambas:estimatedArrival
domain
gambas:Estimated Schedule
range
xsd:datetime
Property estimated Departure
The estimated departure of a bus at a bus stop - This property is used to represent the estimated departure time of a bus at a bus stop.
CURIE: gambas:estimatedDeparture
domain
gambas:Estimated Schedule
range
xsd:datetime
Property exception
The exception in the usual schedule in which a different schedule is run - This property is used to describe an exception in the usual bus schedule.
CURIE: gambas:exception
Property hop Off Time
The end time of a bus ride - This property is used to describe the end time of a bus ride for a given user.
CURIE: gambas:hopOffTime
domain
gambas:User
range
xsd:datetime
Property hop On Time
The start time of a bus ride - This property is used to describe the start time of a bus ride for a given user.
CURIE: gambas:hopOnTime
domain
gambas:User
range
xsd:datetime
Property journey
The transfer from one stop to the next one - This property is used to represent a transfer between one stop and the next one.
CURIE: gambas:journey
domain
http://vocab.org/transit/terms/Schedule
range
http://vocab.org/transit/terms/Transfer
Property location
The location of an entity - This property is used to describe the place where an entity is located.
CURIE: gambas:location
range
gambas:Place
Property next
The next activity - This property is used to represent the activity that will follow the current one. The start/end times might not be known.
CURIE: gambas:next
range
Property noise Level
The noise level of a location - This property is used to describe the noise level detected at a location.
CURIE: gambas:noiseLevel
domain
gambas:Place
range
xsd:Double
Property past Acts
The past activities of a user - This property is used to represent the user’s past activities. CURIE: gambas:pastActs
range
gambas:User
Property path
The path of a bus ride - This property is used to describe the path of a bus ride, i.e. the segment of the bus ride that has been covered.
CURIE: gambas:path
range
http://vocab.org/transit/terms/Transfer
Property personalinfo
The user’s personal information - This property is used to describe the personal information of a user (e.g. name, address, e-mail).
CURIE: gambas:personalinfo
domain
gambas:User
range
gambas:Personal Information
Property reduced Audio
Property schedule Bus
The bus reffered to by a schedule - This property is used to describe the bus which a schedule refers to.
CURIE: gambas:scheduleBus
domain
http://vocab.org/transit/terms/Schedule
range
gambas:Bus
Property schedule End
The end time of validity for a bus schedule - This property is used to describe the end time of validity for a bus schedule.
CURIE: gambas:scheduleEnd
domain
http://vocab.org/transit/terms/Schedule
range
xsd:datetime
Property schedule Start
The start time of validity for a bus schedule - This property is used to describe the start time of validity for a bus schedule.
CURIE: gambas:scheduleStart
domain
http://vocab.org/transit/terms/Schedule
range
xsd:datetime
Property service Bus
The bus servicing a particular route - This property is used to represent the bus servicing a particular route (i.e. bus ride).
CURIE: gambas:serviceBus
range
