Contract Delivery Date Actual Delivery Date Deliverable Type
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
The ontology and query examples are described using free text descriptions and UML-like diagrams to describe ontological relationships among concepts and groups of concepts. These diagrams are used to facilitate the comprehension of ontological concepts and their relationships. Along with that, example instances are used to illustrate how to populate ontology instances in RDF/Turtle [TURTLE]. For the description of the example queries, the GAMBAS project uses a subset of SPARQL 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, 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#
xsd
http://www.w3.org/2001/XMLSchema#
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
The GAMBAS framework should be able to support Operational GE_001
1 - High different devices.
requirements
The GAMBAS framework provides crowd-levels for The scope of the GE_004
1 - High each bus journey.
product
The GAMBAS framework running on mobile devices GE_005 should be implemented in Java or provide Java Mandated constraints 1 - High interfaces.
The GAMBAS framework enables providing adaptive The purpose of the GE_007
1 - High and customized information to users.
product
The GAMBAS framework simplifies the development of The purpose of the GE_008
1 - High services that acquire data from different devices.
product
The GAMBAS framework enables the development of The purpose of the GE_009
1 - High composed services.
product
The GAMBAS framework enables the optimization of The purpose of the GE_010
1 - High services based on usage behavior.
product
The GAMBAS framework enables proactive service The purpose of the GE_011
1 - High offerings based on the current user context.
product
The GAMBAS framework enables proactive service The purpose of the GE_012
1 - High offerings based on the current user context.
product
The GAMBAS framework enables the acquisition of GE_013
The scope of the work 1 - High travel- and environment-related data.
The application services are able to compute possible Relevant facts and GE_014
1 - High end-to-end bus routes.
assumptions
The application services are able to aggregate and Relevant facts and GE_015
1 - High share crowd levels from busses.
assumptions
The GAMBAS
GE_016 environmental quality data for a geolocated point in The scope of the work 1 - High the city.
The application services are able to record and predict Relevant facts and GE_017
1 - High crowd-levels.
assumptions
Personal devices should have internet access to Relevant facts and GE_018 retrieve data from social networks and collaboration
1 - High
assumptions
tools. The application services are able to aggregate and Relevant facts and
GE_019 1 - High share environmental information.
assumptions
In summary, the RDF Formalisms and Ontologies are related to the general requirements GE_001, GE_008, GE_009, GE_015, and GE_019. By providing a unified view of the data, they enable the 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.
Table 3 - Data Representation and Query Processing Requirements. Requirements concerning the RDF formalisms and ontologies are marked in white.
ID Description
Type
Priority
The data representation must provide a unified view of Functional and data DQ_001
1 - High the data among connected devices and services.
requirements
The processing and query execution system should Functional and data DQ_002
1 - High support dynamic discovery of data.
requirements
Basic data storing and processing will be provided for Operational DQ_003
1 - High constrained computer systems (CCS).
requirements
The data processing should be able to adapt to Functional and data DQ_004
1 - High changes in the network and incoming data.
requirements
The data representation and query language should be Functional and data DQ_005
2 - Medium generic.
requirements
The data representation must support spatial data in Functional and data DQ_006
1 - High different formats.
requirements
The data processing framework should cope with Functional and data DQ_008
1 - High intermitted disconnections.
requirements
Performance
DQ_009 The data processing framework should be scalable. 2 - Medium
requirements
The linked data discovery infrastructure does not Functional and data DQ_010 require the user to expose a particular type of
1 - High
requirements
information. The data representation should provide a data model Functional and data
DQ_011 1 - High for the information relevant to the use cases.
requirements
Functional and data DQ_012 The data representation should be extensible.
2 - Medium
requirements
The data processing framework supports continuous Functional and data DQ_013
1 - High queries on changing data.
requirements
The data representation and query processing Functional and data DQ_014
1 - High framework should be interoperable.
requirements
The data representation should provide support for Functional and data DQ_016
1 - High context generalizations.
requirements
Large data storage and advanced query processing will
Operational
DQ_017 be provided in back-end computer systems (BCS) or 1 - High
requirements
traditional computer systems (TCS). The data representation should be based on Linked Functional and data
DQ_018 1 - High Data principles.
requirements
Stream processing will be provided in back-end Operational DQ_019
1 - High computer systems or traditional computer systems.
requirements
Basic RDFS reasoning will be support on the stream Functional and data DQ_020
1 - High processing.
requirements
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).
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
The GAMBAS ontology consists of a number sub-classes, the core classes being User, Place, Activity, BusRide, and Bus. 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. 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 shows the User class in the GAMBAS ontology. 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, and they can be described using the concepts in the Privacy
Preference vocabulary given by the Privacy Preference Ontology (PPO) [PPO] . 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.2.
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”. To preserve the user’s privacy, instances of the User class will be stored in the mobile devices of the
re spective users. The user’s location, current and next activities are dynamic properties. That means that their values are constantly monitored and the system can react to changes in any of these properties. All remaining properties are expected to change less often and are therefore considered static. Figure 3 shows an example of how to use the above concepts to describe a user within the GAMBAS scope, using the Turtle syntax.
ex:john a gbs:User, pimo:Agent; foaf:nickname "userid"^^xsd:string ; ex:john gbs:current ex:activity1 ; gbs:pastActs ex:archive1 ; . ex:archive1 a gbs:PastActivities ; gbs:act ex:activity2 ; gbs:act ex:activityn; . ex:activity2 a gbs:BusRide ; prov:wasAssociatedWith ex:user ; prov:startedAtTime ".."^^xsd:datetime ; prov:endedAtTime ".."^^xsd:datetime ; . pimo:createdPimo ex:pimodule1 ; gbs:setting ex:privacyPrefs1 ; foaf:knows ex:paul ; foaf:knows ex:ringo ; spt:actArchive ex:history1 ; spt:nearby ex:point1 ; . ex:friendly a spt-ct:Mood ; . ex:activity23 a :BusRide ; ao:mood ex:friendly ; prov:wasAssociatedWith ex:john ; prov:startedAtTime "2012-04-03T00:00:00Z"^^xsd:dateTime ; prov:endedAtTime "2012-04-03T00:00:00Z"^^xsd:dateTime ; gbs:serviceBus ex:bus123 ; gbs:path ex:transfer1 ; #checkins done during the ride gbs:path ex:transfer2 ; gbs:path ex:transfer3 ; .
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.
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.
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" ; dc:title " Museo Nacional Centro de Arte Reina Sofía" ;
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].
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.
A bus ride consists of a path, which is a set of transfers. Each transfer has its start/end bus stop, and its schedule. Every time a bus reaches a stop A and goes to stop B, an instance of tst:Transfer is created for the segment A-B. Transfers are numbered in sequence, in order to recover the their order. For the GAMBAS usecases, we are also interested in the distance covered by a transfer segment. In addition we also want to access the live estimated arrival and departure times, as well as the live information about the crowd level of each transfer segment. Therefore we have extended the available ontology according to our needs. Note that since the start/end bus stops of a transfer segment are instances of the class tst:ServiceStop, it is also possible to have access to the time schedule (both planned and estimated) of all BusRides arriving/leaving a particular stop. Figure 7 illustrates the BusRide class.
Figure 7 - GAMBAS Ontology: BusRide Class
Instances of the BusRide class are provided by the transport layer and will be stored in an external semantic data storage, which will most likely reside in a server from the transport provider. Information regarding the bus stops and the schedule are static, while the estimated departure/arrival times and crowd level will be dynamically updated during the course of that bus ride. Historical information of past BusRide instances will be stored for analysis and prediction of user behaviour. Figure 8 shows an example of an instance of the BusRide class.
ex:friendly a spt-ct:Mood ; . ex:activity23 a :BusRide ;
ao:mood ex:friendly ; prov:wasAssociatedWith ex:john ; prov:startedAtTime "2012-04-03T00:00:00Z"^^xsd:dateTime ; prov:endedAtTime "2012-04-03T00:00:00Z"^^xsd:dateTime ; gbs:serviceBus ex:bus123 ; gbs:path ex:segment1 ; gbs:path ex:segment2 ; gbs:path ex:segment3 ;
. ex:segment1 a transit:Transfer ;
transit:fromStop ex:stop80 ; transit:toStop ex:stop81 ; transit:sequence "1"^^xsd:integer ; gbs:crowdLevel "80" ; gbs:serviceBus ex:bus567 ; gbs:ride ex:activity23 ; gbs:distance "65.3" ;
. ex:segment2 a transit:Transfer ;
transit:fromStop ex:stop81 ; transit:toStop ex:stop82 ; transit:sequence "2"^^xsd:integer ; gbs:crowdLevel "30" ; gbs:serviceBus ex:bus567 ; gbs:ride ex:activity23 ; gbs:distance "80.4" ;
. ex:schedule1 a tst:Schedule ;
transit:scheduleService ex:plazamayor ; gbs:scheduleStart "2012-01-01T00:00:00Z"^^xsd:dateTime ; gbs:scheduleEnd "2012-06-15T00:00:00Z"^^xsd:dateTime ; gbs:exception ex:exception1 ; gbs:journey ex:segment4 ; gbs:journey ex:segment5 ; gbs:journey ex:segmentn ;
. ex:exception1 a tst:Schedule ;
gbs:scheduleStart "2012-12-25T00:00:00Z"^^xsd:dateTime ; gbs:scheduleEnd "2013-01-03T00:00:00Z"^^xsd:dateTime ; gbs:journey ex:segment7 ; gbs:journey ex:segment8 ;
. ex:segment4 a tst:Transfer ;
tst:fromStop ex:stop1 ; tst:toStop ex:stop2 ;
. ex:estimatedSchedule1 a gbs:EstimatedSchedule ;
gbs:scheduleBus ex:bus123 ; tst:date "2012-04-02T21:13:54Z"^^xsd:dateTime ; gbs:journey ex:segment5 ;
. ex:busline1 a tst:Service ;
tst:schedule ex:schedule1 ; gbs:estimatedSchedule ex:estimatedSchedule1 ;
. ex:stop1 a tst:Stop ;
tst:serviceStop ex:serviceStopLine1 ; . ex:serviceStopLine1 a tst:ServiceStop ;
tst:service ex:busLine1 ; tst:arrivalTime "21:13:54Z"^^xsd:time ; tst:departureTime "21:23:00Z"^^xsd:time ;.
Figure 8 - Example of an instance of the GAMBAS BusRide Class
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.
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 ;
. ex:route1 a tst:Route ;
gbs:path ex:firstjourney ; gbs:path ex:secondjourney
Figure 10 - Example of an instance of the GAMBAS Bus Class
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.
PREFIX : http://www.gambas-ict.eu/ont/ SELECT * WHERE ?x a :User .
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 foaf: http://ns.com/foaf/0.1/ PREFIX : http://www.gambas-ict.eu/ont/ SELECT ?activity WHERE ?x foaf:nick "userid" . ?activity :current ?x. FILTER ( ?endtime > NOW ) .
Figure 12 - Query: Status (i.e. current activity) of a user
PREFIX foaf: http://ns.com/foaf/0.1/ PREFIX pimo: http://www.semanticdesktop.org/ontologies/pimo/ PREFIX : http://www.gambas-ict.eu/ont/ SELECT ?calendar WHERE ?x foaf:nick "userid" ; :personalinfo ?pim . ?calendar pimo:isDefinedBy ?pim .
Figure 13 - Query: Calendar of a user
The “personalinfo” property provides an instance of the pimo vocabulary, which in turn can return the calendar via the “isDefinedBy” property.
PREFIX foaf: http://ns.com/foaf/0.1/ SELECT ?friend WHERE ?x foaf:nick "userid" ; foaf:knows ?friend .
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.
PREFIX foaf: http://ns.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 ) .
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).
PREFIX foaf: http://ns.com/foaf/0.1/ PREIX : http://www.gambas-ict.eu/ont/ SELECT ?arch WHERE ?x foaf:nick "userid" ; :pastAct ?arch .
Figure 16 – Query: Past activities
PREFIX foaf: http://ns.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 . FILTER (?endtime < "2012-04-03T00:00:00Z"^^xsd:dateTime) . FILTER (?starttime > "2012-04-02T00:00:00Z"^^xsd:dateTime) .
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 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> .
Figure 18 – Query: Bus rides on a given bus line for a given user
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) .
Figure 19 – Query: Bus rides on a given bus line for a given user, within a specific time interval
PREFIX foaf: http://ns.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> .
Figure 20 – Query: Bus rides on a given bus line for a given segment
PREFIX foaf: http://ns.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 ; prov:endedAtTime ?endtime .FILTER (?endtime < "2012-04-03T00:00:00Z"^^xsd:dateTime) . FILTER (?starttime > "2012-04-02T00:00:00Z"^^xsd:dateTime) .
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 routes. The query from Figure 18 checks for buses connected to a bus ride via the “servicebus” property, which have a given bus line id (given by <buslineURI>). The bus line of a bus can be retrieved using the “transit:service” property. In the queries from Figure 20 and Figure 21, the property “path” is used to check for a particular segment, given by <segmentURI>.
4.2 Queries about buses
The information about buses, bus stops and bus lines can be retrieved with the queries listed in this section. To get the nearest bus stops, given a GPS location we can query as follows.
PREFIX transit: http://vocab.org/transit/terms/ PREFIX geo: http://www.w3.org/2003/01/geo/wgs84_pos# PREFIX : http://www.gambas-ict.eu/ont/ SELECT ?station 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") .
Figure 22 – Query: Nearest bus stops, given a GPS location
Alternatively, we can ask for bus stops near a symbolic location.
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> .
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.
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 .
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.
PREFIX transit: http://vocab.org/transit/terms/ SELECT ?busline WHERE ?busline a transit:Service .
Figure 25 – Query: All bus lines
PREFIX transit: http://vocab.org/transit/terms/ SELECT ?stops WHERE ?stops a transit:ServiceStop .
Figure 26 – Query: All bus stops
PREFIX : http://www.gambas-ict.eu/ont/ SELECT ?bus WHERE ?bus a :Bus .
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.
PREFIX transit: http://vocab.org/transit/terms/ SELECT ?route WHERE <buslineURI> transit:route ?route .
Figure 28 – Query: Route of a bus line
PREFIX transit: http://vocab.org/transit/terms/ SELECT ?stops WHERE <buslineURI> transit:serviceStop ?stops .
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).
PREFIX SELECT ?busline WHERE <busstopURI> :busLineAtStop ?busline .
Figure 30 – Query: Bus lines that run through a given bus stop
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 . OR { ?journey transit:fromStop <givenstop> . ?journey transit:toStop <givenstop> . } . FILTER (?date == <givendate>) .
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 transit: http://vocab.org/transit/terms/ SELECT ?schedule WHERE ?schedule a transit:Schedule . transit:scheduleService <buslineURI> .
Figure 32 – Query: Schedule information of a bus line
For retrieving the information regarding when a bus line departs or arrives at a certain bus stop, for a given time, we can use the query shown in Figure 33, which looks at the stops serviced by the busline.
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> .
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.
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> .
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).
PREFIX : http://www.gambas-ict.eu/ont/ SELECT ?busline WHERE <givenbus> :busline ?busline .
Figure 355 – Query: Bus line associated with a bus
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 .
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.
PREFIX transit: http://vocab.org/transit/terms/ PREFIX : http://www.gambas-ict.eu/ont/ SELECT ?crowdlev,?seq WHERE {?transfer :crowdLevel ?crowdlev ; ?busride :path ?transfer ; transit:sequence ?seq. ?busride :serviceBus <givenbus>. } order by desc(xsd:integer(?seq)) limit 1
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 : http://www.gambas-ict.eu/ont/ SELECT ?estimatedtime
WHERE ?sched a :EstimatedSchedule ; :scheduleBus <busURI> .
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).
PREFIX : http://www.gambas-ict.eu/ont/ SELECT ?tracearchive WHERE ?tracearchive a :PastActivities ; :serviceBus <busURI> .
Figure 399 – Query: Historical bus traces
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 . FILTER (?endtime < "2012-04-03T00:00:00Z"^^xsd:dateTime) . FILTER (?starttime > "2012-04-02T00:00:00Z"^^xsd:dateTime
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
The GAMBAS framework should be able to support Operational GE_001
1 - High different devices.
requirements
The GAMBAS framework simplifies the development of The purpose of the GE_008
1 - High services that acquire data from different devices.
product
The GAMBAS framework enables the development of The purpose of the GE_009
1 - High composed services.
product
The application services are able to aggregate and Relevant facts and GE_015
1 - High share crowd levels from busses.
assumptions
The application services are able to aggregate and Relevant facts and GE_019
1 - High share environmental information.
assumptions
The data representation must provide a unified view of Functional and data DQ_001
1 - High the data among connected devices and services.
requirements
The data representation and query language should be Functional and data DQ_005
2 - Medium generic.
requirements
The data representation must support spatial data in Functional and data DQ_006
1 - High different formats.
requirements
The data representation should provide a data model Functional and data DQ_011
1 - High for the information relevant to the use cases.
requirements
Functional and data DQ_012 The data representation should be extensible.
2 - Medium
requirements
The data representation and query processing Functional and data DQ_014
1 - High framework should be interoperable.
requirements
The data representation should provide support for Functional and data DQ_016
1 - High context generalizations.
requirements
The data representation should be based on Linked Functional and data DQ_018
1 - High Data principles.
requirements
Basic RDFS reasoning will be support on the stream Functional and data DQ_020
1 - High processing.
requirements
GE_001, GE_008, GE_009: The RDF formalisms and ontologies provide an unified data 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. DQ_016: One of the properties of ontologies is to allow context generalisations. In the second phase of the project, other activities (such as shopping) will be added as sub classes of the Activity class. In addition, other means of transport can be added. 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 standards both follow the Linked Data principles. In addition, each instance of a class will be 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]
Cognitive Engineering. http://www.loa.istc.cnr.it/DOLCE.html
DOLCE :
a Descriptive
[FOAF] FOAF Vocabulary Specification. http://ns.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 . [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
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
domain : This field indicates the property domain. If it does not appear it means that the
property domain can be any class (owl:thing). range: This field denotes the property range. The range of a Datatype property is expressed