Introduction
The present webpage intends to complement the case study described in the paper entitled Constrained Generation Bids in Local Electricity Markets: A Semantic Approach by exposing the system's resource, input, and output files for test and proof purposes. It describes each file and its use so that the reader can better comprehend how the proposed solution works and is agnostic to the ontology used. The proposed local market library receives as input an RDF knowledge base (KB) file, as well as a configuration JSON file. The resource files include configuration JSON schemas to validate both the input configuration file and the results output, as well as SPARQL queries and updates to manage the KB data during the system's execution. These will be presented following the system workflow to enlighten the reader. The library's output is a JSON object.
Local Market Ontology
local-market.ttl ➚
The Local Market Ontology (LMO) is the application ontology developed for test and proof purposes. The system is agnostic to the ontology, but the resource SPARQL queries/updates that enable it, depend on the ontology used. If another ontology is used, the SPARL resource files must be updated accordingly. LMO imports two modules from the Electricity Markets Ontology (EMO), namely the Call for Proposal (CfP) ontology and the Electricity Markets Results (EMR) ontology. Extensions made to CfP and EMR, as well as LMO's classes and properties, are presented in section 3.2 of the paper. LMO is written in Turtle syntax.
Back to Top ⬆
local-market.ttl (V2) ➚
This version of the LMO demonstrates the flexibility of adding a new constraint to the system wihtout the need to reprogram it. For more details read the paper's Case Study.
Back to Top ⬆
Input Files
kb.jsonld ➚
This file instantiates individuals of LMO (local-market.ttl) by importing it. The RDF KB file has the input data necessary to run the local auction-based market algorithm, detailing the type of market pool to run (symmetric, by default, or asymmetric), the session and respective periods, and the players' bids and constraints. The system uploads this file to the triple store using the SPARQL 1.1 Graph Store HTTP Protocol. Although the file is written in JSON-DL, any RDF syntax is allowed.
Back to Top ⬆
config.json ➚
The configuration JSON file detains information about the KB file path and its RDF language (or syntax), the triple store server configuration, and the local market constraints templates for each bid constraint. The configuration file eases the use of remote KB files, as well as of different SPARQL triple stores available, and also to add, update, or remove constraints templates without the need to reprogram the system.
Back to Top ⬆
kb.jsonld (V2) ➚
This version of the KB demonstrates the flexibility of adding a new constraint to the system wihtout the need to reprogram it. For more details read the paper's Case Study.
Back to Top ⬆
config.json (V2) ➚
This version of the configuration file demonstrates the flexibility of adding a new constraint to the system wihtout the need to reprogram it. For more details read the paper's Case Study.
Back to Top ⬆
Resource Files
ordered-bids.sparql ➚
The library uses this resource file to get the ordered demand and supply bids for each period. It uses the respective period's graph with the updated data.
The system replaces the tags:
[PERIOD] - with the period number,[BID_TYPE] - with the transactions type (i.e., buy or sell), and[FUNCTION] - with DESC for demand bids and ASC for supply bids.
The queries' results are then used as inputs for the symmetrical pool algorithm.
Back to Top ⬆
set-temporary-player-period-results.sparql ➚
The library uses this resource file to update the respective period's graph using the results of the symmetric pool algorithm.
The system replaces the tags:
[PERIOD] - with the period number,[UUID] - with a system's generated unique identifier,[WAS_TRADED] - with a boolean value describing if the player traded or not in the pool,[TRADED_ENERGY] - with the amount of energy traded in the poll,[MARKET_PRICE] - with the pool's market price, and[OFFER_UUID] - with the offer's instance URI
Back to Top ⬆
period-constraints.sparql ➚
The library uses this resource file to get the player's bid contraints for the current period. The constraints are in the default graph. Bid constraints are ordered in the same way as in ordered-bids.sparql file and priority.
The system replaces the tags:
[BID_TYPE] - with the transactions type (i.e., buy or sell),[PERIOD] - with the period number, and[FUNCTION] - with DESC for demand bids and ASC for supply bids.
The queries' results are then used to get the constraint SPARQL templates from the
config.json file, which will be used to check if any players' restriction triggers.
Back to Top ⬆
period-has-updates.sparql ➚
The library uses this resource file to check if any constraint was triggered and it has to run the symmetric pool algorithm for the same period again. If it returns 0, the system continues for the next period, otherwise it removes the players' results of the current period, and the pool is rerun.
Back to Top ⬆
set-temporary-player-total-bought-energy.sparql ➚
At the end of the session, the library uses this resource file to set the players' session total bought energy.
The system replaces the tags:
[PER1] - with the session's 1st period's number,[PER2] - with the session's 2nd period's number,[PER3] - with the session's 3rd period's number, and[PER4] - with the session's 4th period's number.
Back to Top ⬆
set-temporary-player-total-cost.sparql ➚
At the end of the session, the library uses this resource file to set the players' session total cost.
The system replaces the tags:
[PER1] - with the session's 1st period's number,[PER2] - with the session's 2nd period's number,[PER3] - with the session's 3rd period's number, and[PER4] - with the session's 4th period's number.
Back to Top ⬆
set-temporary-player-total-income.sparql ➚
At the end of the session, the library uses this resource file to set the players' session total income.
The system replaces the tags:
[PER1] - with the session's 1st period's number,[PER2] - with the session's 2nd period's number,[PER3] - with the session's 3rd period's number, and[PER4] - with the session's 4th period's number.
Back to Top ⬆
set-temporary-player-total-sold-energy.sparql ➚
At the end of the session, the library uses this resource file to set the players' session total sold energy.
The system replaces the tags:
[PER1] - with the session's 1st period's number,[PER2] - with the session's 2nd period's number,[PER3] - with the session's 3rd period's number, and[PER4] - with the session's 4th period's number.
Back to Top ⬆
set-temporary-player-total-transacted-energy.sparql ➚
At the end of the session, the library uses this resource file to set the players' session total transacted energy.
The system replaces the tags:
[PER1] - with the session's 1st period's number,[PER2] - with the session's 2nd period's number,[PER3] - with the session's 3rd period's number, and[PER4] - with the session's 4th period's number.
Back to Top ⬆
session-constraints.sparql ➚
The library uses this resource file to get the player's bid contraints for the current session. The constraints are in the default graph. Session bid constraints are ordered by instant of arrival and priority.
Back to Top ⬆
session-has-updates.sparql ➚
The library uses this resource file to check if any constraint was triggered, and has to rerun the local market session. If it returns 0, the local market session concludes, and the system continues to the retrieval of results, otherwise it removes the players' results and reruns it.
Back to Top ⬆
