Contract Delivery Date Actual Delivery Date Deliverable Type
1 Introduction
This document describes the second version of the RDF formalisms and ontologies of the GAMBAS project.
1.1 Purpose
This document describes the required RDF formalisms and ontologies to support the description of the data in the GAMBAS project, such as sensor data, users’ activities and intentions. They concern the data, data properties, and queries found in the GAMBAS scenarios. The first version of this document provided the initial set of classes, properties and queries related to the project, based on a set of initial requirements that were created from the Use Case Specification (D1.3) and from additional input given by all GAMBAS partners.
This version of the deliverable also takes into account the feedback during the implement of the first application prototype (D1.4.1). We have performed a full analysis of the first version of the document, and have updated it accordingly to reflect the decisions taken on the prototype. We have also extended the initial version by considering more use cases from the Use Case Specification (D1.3).
The formalisms and ontologies are a key player in enabling data interoperability in the GAMBAS project, as they provide a unified view of the heterogeneous data produced by the different players in the GAMBAS use cases. Such a unified view, based on semantic descriptions of the data and the data sources, is in line with the Linked Data paradigm, and it not only facilitates data understanding, but it also improves data discovery and integration between both objects and persons, and other sources of data that follow the same paradigm, such as the Web of Data.
The first version of the deliverable provided general concepts that cover the use cases on the transport domain. It also contained an initial set of queries that were expected in the different use cases. This second version of the deliverable revisits the concepts from the first version, and updates/extends them, based on the feedback during the implementation of the first version of the application prototype (D1.4.1). It also considers the use cases on the environmental scenario.
Beyond the project’s internal usage, the GAMBAS project will also make the ontologies and this specification document available to the public. The public availability of the specification not only enables the sharing of knowledge with interested third parties but it also helps to promote the wider acceptance of concepts and mechanisms that are developed within the project.
1.2 Scope
The RDF formalisms and ontologies version 2.0 provides the concepts, properties and queries found in the GAMBAS transport and environmental scenarios. The vocabularies described will be used to model and encode the data in the second version of the application prototype (D1.4.2).
1.3 Specification Methodology
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 and CQELS query semantics and syntaxes rather than creating a new query language.
1.4 Structure
The remainder of this specification document is structured as follows. Section 2 revisits the relevant requirements defined in the GAMBAS Requirements Specification D1.1. The requirements that are covered in this deliverable are taken from General Requirements and the Data Representation and Query Processing Requirements. Section 3 provides informative descriptions of the GAMBAS ontology for the transportation and environmental scenarios, which now consists of 8 main classes that are presented in detail in 8 sub-‐sections. Thereafter, Section 4 presents an extensive query set from the use cases, and how they are modelled following the ontology description.
1.5 Reading Recommendation
The normative and informative parts of this specification are identified by use of labels within various sections. Generally, everything in the specification is considered to be normative, apart from the examples. This specification makes use of CURIE syntax [CURIE] as an abbreviated syntax for expressing URIs. The following CURIE prefix bindings are defined:
Table 1 -‐ CURIE prefix binding
gbs
http://www.gambas-‐ict.eu/ont/
spt
http:// spitfire-‐project.eu/ontology/ns/
gr
http://purl.org/goodrelations/v1
pimo
http://www.semanticdesktop.org/ontologies/pimo/
vso
http://www.heppnetz.de/ontologies/vso/ns#
ppo
http://vocab.deri.ie/ppo#
olo
http://purl.org/ontology/olo/core#
xsd
http://www.w3.org/2001/XMLSchema#
2 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. Some of requirements were already covered in the first version of this deliverable but the current version addresses more 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, G_016 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. The update version of the ontology also enables G_016, by providing means to describe environmental 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). All these requirements were already covered in the first version of this deliverable, and the current version continues to support them.
3 The GAMBAS Ontology
Figure 1 shows the GAMBAS ontologies, its classes, the dependencies among the classes, as well as the external ontologies from which the ontology extends concepts and properties. The external ontologies include PIMO [PIMO], SPT [SPITFIRE], GoodRelations [GR], Ordered List [OLO], and Vehicle Sales [VSO]. The PIMO Ontology provides a vocabulary for describing calendaring data (events, tasks, meetings). The SPITFIRE Ontology (SPT), developed within the SPITFIRE project, aligns already existing vocabularies – such as DOLCE [DOLCE], wgs84 [wgs84] and FOAF [FOAF] – to enable the semantic description of, not only sensor measurements and sensor metadata, but also of the context surrounding them. In particular, the activities sensed by sensors are modelled and related with social domain vocabularies and complex event descriptions. The GoodRelations ontology is widely used to describe business and product offerings. We take advantage of the Ordered List Ontology to represent a sequence of steps. An OrderedList is a list of slots with indexes to each slot and points to next and previous slots. The Vehicle Sales ontology is a web vocabulary for describing cars, boats, bikes, and other vehicles for e-‐commerce, and it is useful in the context of GAMBAS to generalise the means of transport of a user. The descriptive specifications presented in the figures are supplemented by a normative description in Annex I.
Figure 1 – The GAMBAS Ontology and its dependencies
The updated version of the GAMBAS ontology consists of a number of sub-‐classes, the core classes being User, Place, Activity, Journey, TravelMode, Bus, Jogging and Shopping. These classes are described in detail in the next sections.
From the Use Case Specification (D2.1) it is clear that the GAMBAS project encompasses a large variety of data. The data variety is not only related to how the data is represented but also refers to the temporal aspects. For instance we have static information about bus routes, as well as the current location of buses, which are continuously streamed into the systems.
The nature of the devices involved in the GAMBAS project is also very heterogeneous. As described in the Requirements Specification (D1.1) there are different classes of devices – from back-‐end computer systems to constrained computer systems. For example, the buses timetables are stored in external servers in the transportation layer, whereas the users’ preferences and their location are kept in their mobile devices for privacy purposes. To enable data interoperability, the GAMBAS ontology was created to describe and represent the different types of data. All the data following the ontology description will be stored in Semantic Data Storages, which will be available in different locations and devices.
3.1 Main differences from the previous version
The current ontology updates/extends the previous ontology, based on the first application prototype (D1.4.2). It also adds data description from the environmental scenario. The main differences from the previous version can be summarised as follows:
• The User class now includes privacy properties on the user profile that addresses particular
needs of the GAMBAS use cases. We continue to use the Privacy Preference Ontology (PPO) for defining access levels of users to classes. We have also changed the names of a few properties for clarity’s purpose.
• The Place class now contains properties about the weather and environmental aspects.
These are particularly important for the environmental use cases we now cover. We also created a subclass that concerns bus stops.
• A Journey class was introduced to replace the TRANSIT ontology. The TRANSIT vocabulary
was confusing, ambiguous and inflexible when modelling the different segments in a route. With our Journey class the definition of bus stops and routes is clear.
• A Journey between two points can consist of multiple transportation modes (e.g. walking,
bus). Our ontology now allows a better representation of such properties. A travel mode can
be specified to each part of a journey. • The stream of information about crowd levels is now recorded as a property of the Bus class.
Aggregated values can be stored in the journeys’ segments. • We address the environmental scenario, and introduce two new classes that are sub-‐classes
of the Activity class, namely Jogging and Shopping.
3.2 User Class
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 the GAMBAS framework has access to services provided by the GAMBAS user intention interface such as suggestions of bus routes or jogging areas, given the 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 the GAMBAS framework has access to services provided by the GAMBAS user intention interface such as suggestions of bus routes or jogging areas, given the
Figure 2 shows the User class in the GAMBAS ontology. As in the initial version, it is a subclass of the spt:Agent class from the SPITFIRE ontology, which allows us to describe the user’s profile such as name, email, and addresses. Privacy settings are crucial in GAMBAS. As in the earlier version we use the Privacy Preference vocabulary given by the Privacy Preference Ontology (PPO) [PPO]. However, during the implementation of the application prototype it was clear that the PPO was not suitable to describe users’ shared keys and permission settings, which are needed in the privacy preserving data exchange mechanism of GAMBAS. Therefore we have added privacy related properties to the user profile. More specifically, we have extended the Profile class to include the sharedKeys and certificates used in the privacy frameworks. We have also removed the “role” property, as it became clear in the prototype this distinction is not required.
The user’s calendar information, which will be used as input for the user’s intent analysis, is described by creating a PIMO (Personal Information Model) instance. Users are connected to other users via the “foaf:knows” property, which allows us to list the friends of a user. The location of a user is also available and can be represented with the Place class, described in Section 3.3.
Figure 2 – GAMBAS Ontology: User Class
Users in GAMBAS perform activities, for instance, commuting in a bus or shopping. The GAMBAS ontology provides a vocabulary to represent the user’s activities, include the past, future and current ones. Past and current activities will be used in combination to determine which are the user’s next activities. This will be done by the user’s intent analysis. A description of the Activity class is given in Section 3.4.
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. For 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. For
Figure 3 shows an example of how to use the above concepts to describe a user within the GAMBAS scope, using the Turtle syntax. The example shows, among other things, how users can set access levels to other users. In this particular example the user “John” is giving the user “Paul” access to his location. Note that the access is restricted to read-‐only, therefore Paul cannot modify or create instances of location for John.
ex:john a gbs:User, pimo:Agent; foaf:nickname "userid"^^xsd:string ; ex:john gbs:current ex:activity1 ; ex:john foaf:knows ex:paul ; gbs:Profile ex:johnProfile ; gbs:pastActs ex:archive1 ; gbs:settings ex:ppoJohn ; .
ex:archive1 a gbs:PastActivities ; gbs:act ex:activity2 ; gbs:act ex:activityn; . ex:activity2 a :Journey ; prov:wasAssociatedWith ex:user ; prov:startedAtTime ".."^^xsd:datetime ; prov:endedAtTime ".."^^xsd:datetime ; . .
ex:johnProfile a gbs:Profile; gbs:hasSharedKey “B8C382391061E449CE51B29C2549BB1F”; .
ex:ppoJohn a ppo:PrivacyPreference; ppo:hasCondition[
ppo:classAsObject gbs:Place ]; ppo:hasAccess acl:Read; ppo:hasAccessSpace[
ppo:hasAccessAgent ex:Paul>; ]. .
ex:activity23 a :Jogging ; ao:mood ex:friendly ; prov:wasAssociatedWith ex:john ; gbs:runWith ex:paul ; prov:startedAtTime "2012-04-03T10:00:00Z"^^xsd:dateTime ; prov:endedAtTime "2012-04-03T11:00:00Z"^^xsd:dateTime ; gbs:path ex:runningLeg ;
Figure 3 – Example of an instance of the GAMBAS User Class
To preserve the user’s privacy, instances of the User class will be stored in the mobile devices of the respective users, as initially described in the previous version of this deliverable. The user’s location, current and next activities are dynamic properties. All remaining properties are expected to change less often and are therefore considered static.
3.3 Place Class
The location of a user of activity in GAMBAS can be capture by different sensors (e.g., GPS, WIFI, GSM). The GAMBAS Place class, shown in Figure 4, provides different properties to the different representations. The new version of this class is very similar to the first version. It extends the spt:Place class, which already provides a vocabulary that includes concepts like, city, street, and GPS coordinates. The Place class extends spt:Place by enabling the representation of bus stops and cell location. The CellReading class extends the spt:OV class, which provides the vocabulary to describe sensor observations. We extended the Place class in different ways. We added weather information:
a class Weather is now associated with a place. Weather has two properties – current and prediction – and both extend the spt:OV class to describe weather information, both current and forecasted. As in the first version of the class, a noise level can be associated with every location, which will be used, combined with the user’s preferences, to suggest optimal travel routes. We extended the class by adding properties related to the environmental scenario, such has CO2 levels and pollen count. It is important to note that locations can be described by the set of locations it contains. This allows us to aggregate information from smaller areas, to generate a broader view. Lastly, as bus stops are a very relevant type of place in the GAMBAS use cases, we have created a subclass of Place, called BusStop to specifically describe those locations. In addition, we can have a property associated with a bus stop that lists all the bus lines that serve that stop.
Figure 4 – GAMBAS Ontology: Place Class
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:leg1 a gbs:Leg ; #Legs are delimited by start/end locations gbs:startLocation ex:PlazaMayor ; gbs:endLocation ex:stop2 ; gbs:distance “10” ; #distance between the two stops. . ex:PlazaMayor a :Place ; gbs:pollenCount “2” ; #environmental data gbs:co2Level “300” ; gbs:contains ex:point1 ; #pollenCount and co2Level of ex:PlazaMayor applies
to ex:point1
. ex:point1 a :Place ; geo:lat "40.409248" ; geo:long "-3.69407" ; geo:alt "10.47881" ; dc:title " Museo Nacional Centro de Arte Reina Sofía" ; .
Figure 5 – Example of an instance of the GAMBAS Place Class
3.4 Activity Class
In the GAMBAS project, a user may perform different activities, e.g. visiting a location, shopping, taking the bus or train, jogging, etc. The GAMBAS Activity class, shown in Figure 6, provides the properties to describe an activity. Every activity can have a start/end location and start/end time. Locations are represented as instances of the Place class. For representing the time we use the xsd:datetime description from the OWL Time ontology [OWL-‐Time].
Figure 6 – GAMBAS Ontology: Activity Class
The Activity class have not changed compared to the first version, since the different activities are modelled as subclasses. For the first version of the ontology we had focused on users travelling in a bus. This activity was updated and is described in the next section. In addition, this updated version of the ontology now also considers the environmental scenario and we have introduced two new classes that address it: Shopping and Jogging. They will be described later in this document.
3.5 Journey Class
We had initially created a BusRide class that refers to an activity of users travelling in a bus. However, an activity is usually associated to a more general journey, which can involve bus trips, as well as We had initially created a BusRide class that refers to an activity of users travelling in a bus. However, an activity is usually associated to a more general journey, which can involve bus trips, as well as
In each entity of the class Step we can specify a number of properties, such as arrival/departure times (both scheduled and estimated), duration, distance covered, and start/end locations. Moreover we can specify the travel mode used in each instance of Step, which will be described in the next section.
In some cases we are interested in recording every segment between two consecutive bus stops, i.e. to check whether a user might meet a friend or not. By using the gbs:singleSteps property we can model this case, and each Step will correspond to two consecutive points in the journey. However, we might also be interested in a more compact version of the journey, where steps in which the travel model hasn’t changed can be represented by one single step. This provides a shortcut to determine when a user entered or left a bus, for instance. For that we have created a gbs:compactSteps property. Note that this compact version can be created at any time from the list of single steps. While it provides some redundant information it greatly improve the performance of some queries. In addition we also introduced a mechanism to keep track of the order in which the steps were performed during the journey. We take advantage of the Ordered List Ontology [OLO] to represent a sequence of instances of the Step class. An OrderedList is a list of slots with indexes to each slot and points to next and previous slots. In our case, each slot contains an item of type Step. Figure 7 illustrates the Journey class, and an example is given in Figure 8.
Figure 7 – GAMBAS Ontology: Journey Class Figure 7 – GAMBAS Ontology: Journey Class
ex:list1 a olo:OrderedList ; olo:slot ex:slot1 ; . ex:slot1 a :Slot olo:item ex:step1 ; olo:next ex:slot2 ; .
ex:slot2 a :Slot olo:item ex:step2 ; .
ex:step1 a gbs:Step ; gbs:startLocation ex:PlazaMayor ; gbs:endLocation ex:stop2 ; gbs:distance “10” ; #distance between the two stops. gbs:scheduleArrival "21:13:54Z"^^xsd:time ; gbs:scheduleDeparture "21:23:00Z"^^xsd:time ;. gbs:travelmode ex:walk ; gbs:instructions “walk from Plaza Mayor to stop2” ; . ex:step2 a :Step ; gbs:startLocation ex:stop2 ; gbs:endLocation ex:stop3 ; gbs:distance “15” ; #distance between the two stops. gbs:scheduleArrival "21:30:00Z"^^xsd:time ; gbs:scheduleDeparture "21:35:00Z"^^xsd:time ;. gbs:travelmodel ex:busride ; .
Figure 8 – Example of an instance of the GAMBAS Journey Class
The instances of the Journey class can be store in the user’s mobile device or a trusted external server. Information regarding the schedules is static, while the estimated departure/arrival times will
be dynamically updated.
3.6 TravelMode Class
As we mentioned in the previous section, a journey is composed by multiple steps, and each step can
be performed by a different travel mode. We created an abstract class to model the different travel modes. At the moment, there are two possible subclasses: BusRide and Walk. We can extend this by adding other means of transport, like subway. Figure 9 illustrates the TravelMode class, as well as its subclasses. For steps where a bus ride was used we can specified further properties, like the bus used and the crowd level recorded. We can also attach the information about the user performing the bus ride directly to this class, which can be beneficial in some query cases.
Figure 9 – GAMBAS Ontology: TravelMode Class and its subclasses
Figure 10 shows a simple example of an instance of the BusRide class. Note that most of the information associated with a bus ride is already recorded in the Journey class.
ex:busride1 a gbs:BusRide ; gbs:user ex:John ; gbs:crowdLevel “50” ; gbs:serviceBus ex:bus ; .
Figure 10 – Example of an instance of the GAMBAS BusRide Class, a subclass of TravelMode
3.7 Bus Class
A bus ride is performed by a bus, and this is also represented in the GAMBAS ontology. Figure 11 shows the Bus class. We have made one important change in the ontology, which was to associate the stream of crowd levels to a bus. These aggregated values can be recorded and stored in instances of the BusRide class, to compute statistics of the crowd levels in the different bus routes. In addition, we can represent the route of a bus line by reusing our Journey class. Other properties, such as the bus line name, the bus status (in service or not), and the bus’ current location, remained unchanged.
Figure 11 – GAMBAS Ontology: Bus Class
The information about buses will be provided by the transport layer and stored in an external semantic data storage. The bus location, crowd levels and its status are constantly updated. Figure 12 below shows an example of an instance of the Bus class.
ex:bus123 a gbs:Bus ; gbs:busline ex:Sevilla-Hortaleza ; vso:seatingCapacity "100"^^xsd:integer ; vso:VIN "12245254"^^xsd:string ; prov:performs ex:busride1 ; gbs:status gbs:inService ; gbs:location ex:point1 ; gbs:busUser ex.:John ; gbs:crowdLevel “40” ; .
ex:Sevilla-Hortaleza a gbs:BusLine ; gbs:route ex:journey1 ; .
Figure 12 – Example of an instance of the GAMBAS Bus Class
3.8 Jogging Class
Most of the use cases of the environmental scenario are related to the mobility scenario and can be directly modelled by the existing classes (e.g. Pollution levels, pollen alerts, etc). One use case, however, requires the addition of one class to model users running with a friend.
The Jogging class is a subclass of the Activity class, and it can record the path followed during the jog, the distance covered, the aggregated CO2 and pollen levels and the friends met during the jogging. Since we don’t expect changes regarding transportation mode during a Jogging activity we can model The Jogging class is a subclass of the Activity class, and it can record the path followed during the jog, the distance covered, the aggregated CO2 and pollen levels and the friends met during the jogging. Since we don’t expect changes regarding transportation mode during a Jogging activity we can model
Figure 13 shows the Jogging Class, and an example of an instance of the class is given in Figure 14.
Figure 13 – GAMBAS Ontology: Jogging Class
ex:jog a gbs:Jogging ; gbs:runWith gbs:Paul ; gbs:distance “5” ; gbs:co2Level “250” ; gbs:path ex:step ; prov:startedAtTime "09:00:00Z"^^xsd:time ; prov:endedAtTime "09:30:00Z"^^xsd:time ; .
ex:step a :Step ; gbs:startLocation ex:jogStart ; gbs:endLocation ex:jogEnd ; gbs:distance “5” ; gbs:polyline “(38.5, -120.2), (40.7, -120.95), (43.252, -126.453)” ; .
Figure 14 – Example of an instance of the GAMBAS Jogging Class
The jogging activities will be recorded in the mobile device of the user that performed the activity.
3.9 Shopping Class
In addition this extended version of the ontology includes a Shopping class, which is also a subclass of the Activity class, to describe the use case of user’s shopping. Instead of proposing a new class to model stores and their products, we use the GoodRelations ontology [GR], which is well known and widely used. The Shopping class allows us to enlist the products bought by the user during this activity as well as shops visited. Figure 15 shows the Shopping Class, and an example of an instance of the class is given in Figure 16. The shopping activities will be recorded in the user’s mobile device.
Figure 15 – GAMBAS Ontology: Shopping Class
ex:shopping1 a gbs:Shopping ; gbs:visited ex:eletronicsShop ; gbs:bought ex:tablet; prov:startedAtTime "11:00:00Z"^^xsd:time ; prov:endedAtTime "12:00:00Z"^^xsd:time ; .
ex:eletronicShop a gr:BusinessEntity ; gr:legalName “MediaMarkt” ; gr:hasOffer ex:tablet; .
ex:tablet a gr:Offering ; gr:hasPriceSpecification ex:price ; .
ex:price a gr:UnitPriceSpecification ; gr:hasCurrency "USD"^^xsd:string ; gr:hasCurrencyValue "99.90"^^xsd:float ; gr:validThrough "2012-12-31T23:59:59Z"^^xsd:dateTime ; .
Figure 16 – Example of an instance of the GAMBAS Shopping Class
4 Query Specification
The data instantiated from the GAMBAS ontology is represented as RDF [RDF]. SPARQL [SPARQL] is the most widely used RDF query language, and therefore it will be used as a query language in the GAMBAS context. However, some of the data in GAMBAS will be available as a stream of RDF data, or RDF streams. This is the case for the dynamic information, like the location of a user. For handling RDF streams we will use an extension of the SPARQL query language, called the CQELS query language [CQELS]. The full specification of the SPARQL query semantics and syntaxes are defined by the W3C and can be found at [RDF]. In the RDF data model, each instance must have a globally unique URI. An RDF instance has properties that have values as literals or other instances. A literal can have text or numeric value. In the context of GAMBAS the SPARQL-‐SELECT and CQELS-‐SELECT queries are enough to cover the use cases. The output of these queries is results sets in tabular form of literal and URI. Query results can be easily serialised (for example in XML [XML] or JSON [JSON]).