Academia.eduAcademia.edu

Figure 10 – uploaded by Muntazir Mehdi

See full PDFdownloadDownload figure
Figure 10: Building energy explorer dashboard [3]

Figure 10 Building energy explorer dashboard [3]

Related Figures (12)

Due to lack of vocabularies that bridge W3C Semantic Sensor Network Ontology and W3C Data Cube Vocabulary together [12], we define an ontology that uses concepts of WS3C RDF Data cube vocabulary to generate Data Cubes. Mainly due to the servicing characteristics of this ontology, we call it EDWH (Event Data Ware-House) Ontology. The Class hierarchy of the ontology is shown in figure 3.
Due to lack of vocabularies that bridge W3C Semantic Sensor Network Ontology and W3C Data Cube Vocabulary together [12], we define an ontology that uses concepts of WS3C RDF Data cube vocabulary to generate Data Cubes. Mainly due to the servicing characteristics of this ontology, we call it EDWH (Event Data Ware-House) Ontology. The Class hierarchy of the ontology is shown in figure 3.
The Event Registration Process is depicted in figure 4. The process is supported by a Web User Interface (UI). The first step of event registration on UI involves specification of the data source. In our scenario, source is a jms-source, hence in next step the user specifies the URL of the JMS server, the topic that is broadcasting events, the username and the password for accessing the server. Since there can be different types of events broadcasted on the same topic on the same server, the next thing is to select the event type for which data cubes must be generated.
The Event Registration Process is depicted in figure 4. The process is supported by a Web User Interface (UI). The first step of event registration on UI involves specification of the data source. In our scenario, source is a jms-source, hence in next step the user specifies the URL of the JMS server, the topic that is broadcasting events, the username and the password for accessing the server. Since there can be different types of events broadcasted on the same topic on the same server, the next thing is to select the event type for which data cubes must be generated.
While selecting the dimensions and measures, the user also has to specify intendedObjectURI and desiredObjec- tURI properties of each dimension or measure. An example selection of dimensions and measures for PowerConsump- tionEvent can be seen in figures 5 and 6. Both intendedOb- jectURI and desiredObjectURI are data properties of dimen- sion and measure classes of the ontology mentioned in sub- section 3.2. And both of these data properties contain values of the predicates. In the example shown in figure 5, the user has selected consumer, consumerType and consumerDepart- ment as possible set of dimensions for creating data cube. The intendedObjectURI and desiredObjectURI for each of the specified dimension is same since there is no nesting. In case of both consumer and consumerType, the correspond- ing values are URIs while consumerDepartment has literal value. In both figures 5 and 6 URIs are represented using circles and literal values are depicted by rectangles. In figure 6, the user selected powerUsage as measure. Notice that in- tendedObjectURI and desiredObjectURI are different since RDF event-data has a nested resource for powerUsage i.e. “:Amount”. In this case intendedObjectURI is powerUsage and desiredObjectURI is “hasDataValue”. After selecting the dimensions and measures, the next step in the event reg- istration process requires user to specify graph details. This graph detail is used to store generated data cubes. While inserting values for graph details, the user specifies name, detail and comments. The name of the graph is used to create a named-graph in triple store. After getting all nec- essary information from the user for registering an event is completed, the system will generate an instance of EDWH Figure 5: Example of selected dimensions
While selecting the dimensions and measures, the user also has to specify intendedObjectURI and desiredObjec- tURI properties of each dimension or measure. An example selection of dimensions and measures for PowerConsump- tionEvent can be seen in figures 5 and 6. Both intendedOb- jectURI and desiredObjectURI are data properties of dimen- sion and measure classes of the ontology mentioned in sub- section 3.2. And both of these data properties contain values of the predicates. In the example shown in figure 5, the user has selected consumer, consumerType and consumerDepart- ment as possible set of dimensions for creating data cube. The intendedObjectURI and desiredObjectURI for each of the specified dimension is same since there is no nesting. In case of both consumer and consumerType, the correspond- ing values are URIs while consumerDepartment has literal value. In both figures 5 and 6 URIs are represented using circles and literal values are depicted by rectangles. In figure 6, the user selected powerUsage as measure. Notice that in- tendedObjectURI and desiredObjectURI are different since RDF event-data has a nested resource for powerUsage i.e. “:Amount”. In this case intendedObjectURI is powerUsage and desiredObjectURI is “hasDataValue”. After selecting the dimensions and measures, the next step in the event reg- istration process requires user to specify graph details. This graph detail is used to store generated data cubes. While inserting values for graph details, the user specifies name, detail and comments. The name of the graph is used to create a named-graph in triple store. After getting all nec- essary information from the user for registering an event is completed, the system will generate an instance of EDWH Figure 5: Example of selected dimensions
Figure 6: Example of selected measures
Figure 6: Example of selected measures
The generation of multidimensional cubes is the core el- ement of our work. Multidimensional data cubes provide support to decision making tools and applications to run complex queries on historical data. In our system implemen- tation, we have defined an agent called the EDWH agent. The main responsibility of this agent is to aggregate data, generate data cubes and store them in the triple store. The basic structure of the EDWH agent is depicted in figure 7.
The generation of multidimensional cubes is the core el- ement of our work. Multidimensional data cubes provide support to decision making tools and applications to run complex queries on historical data. In our system implemen- tation, we have defined an agent called the EDWH agent. The main responsibility of this agent is to aggregate data, generate data cubes and store them in the triple store. The basic structure of the EDWH agent is depicted in figure 7.
Figure 9: An example RDF graph of cube Figure 8: An example multidimensional cube
Figure 9: An example RDF graph of cube Figure 8: An example multidimensional cube
The example cube that is shown in figure 8 is created using Time, ConsumerDepartment and ConsumerType di- mensions. This example cube is generated by applying any of the aggregate function (SUM, AVG, COUNT) over a pe- riod of one day. As shown in figure 9, the main subject of the RDF graph is “Cube” with RDF:Type :Cube and RDF:Type :PowerUsageEvent. A cube is composed of several observa- tions, as depicted in figure 9, and an example of one such observation of a cube is shown in listing 6. The example represents a cube generated using SUM(powerUsage) func- tion, grouped by ConsumerDepartment and ConsumerType and aggregated over a period of day.
The example cube that is shown in figure 8 is created using Time, ConsumerDepartment and ConsumerType di- mensions. This example cube is generated by applying any of the aggregate function (SUM, AVG, COUNT) over a pe- riod of one day. As shown in figure 9, the main subject of the RDF graph is “Cube” with RDF:Type :Cube and RDF:Type :PowerUsageEvent. A cube is composed of several observa- tions, as depicted in figure 9, and an example of one such observation of a cube is shown in listing 6. The example represents a cube generated using SUM(powerUsage) func- tion, grouped by ConsumerDepartment and ConsumerType and aggregated over a period of day.
ered by listener and client component at a frequency of be- tween 70 and 90 events/minute we wanted to determine the impact of the number of dimensions created. To do so, we registered the same event (PowerConsumptionEvent) with different number of dimensions. A chart showing the impact of changing number of dimensions for PowerConsumption- Event event is shown in figure 11. Figure 11: Size Chart for different No. of dimen- sions
ered by listener and client component at a frequency of be- tween 70 and 90 events/minute we wanted to determine the impact of the number of dimensions created. To do so, we registered the same event (PowerConsumptionEvent) with different number of dimensions. A chart showing the impact of changing number of dimensions for PowerConsumption- Event event is shown in figure 11. Figure 11: Size Chart for different No. of dimen- sions
For the second part of the evaluation, we observed the required query execution time (QET) and the perfor- mance of our system during the generation and storage of data cubes. Indeed, we defined a set of most commonly used queries in our scenario and executed them on different types of cubes stored in the EDWH and raw observations stored in the staging area. The type of queries that we executed are shown in table 2. The comparison of the recorded values for QET are shown in table 3. Figure 12: Performance Chart
For the second part of the evaluation, we observed the required query execution time (QET) and the perfor- mance of our system during the generation and storage of data cubes. Indeed, we defined a set of most commonly used queries in our scenario and executed them on different types of cubes stored in the EDWH and raw observations stored in the staging area. The type of queries that we executed are shown in table 2. The comparison of the recorded values for QET are shown in table 3. Figure 12: Performance Chart
Related topics:
Computer ScienceLinked DataLinked Open Data (LOD)Data PublishingWeb of Things (WoT)
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved