ic-flex.md

@@ -2,17 +2,17 @@ The flexibility ontology module (ic-flex) is by design tightly integrated with S
 
 ![Flexibility.drawio](uploads/d3c5aca5f762dbdf371063bca312e85f/Flexibility.drawio.png)
 
-The main concept of the ic-flex module is the ic-flex:FlexOffer, which allows to represent a flexibility offer (or schedule) as a combination of multiple time-series, data-points and forecasts. For example, we can create a flexibility offer that includes a time-series ex:T-power of power values, combined with a time-series ex:T-costs of associated costs. Alternatively, if the costs are the same for all the power values in the offer, we can associate a single data-point ex:D-costs to the entire ex:T-power time-series. Figure 12 further shows that it is possible to specify a creation time (ic-data:hasCreationTime), validity period (ic-data:hasEffectivePeriod) and provenance (ic-data:producedBy) for the offer, on top of the creation time, validity period and provenance already specified for the time-series and data-points included in the offer.  
+The main concept of the ic-flex module is the `ic-flex:FlexOffer`, which allows to represent a flexibility offer (or schedule) as a combination of multiple time-series, data-points and forecasts. For example, we can create a flexibility offer that includes a time-series `ex:T-power` of power values, combined with a time-series `ex:T-costs` of associated costs. Alternatively, if the costs are the same for all the power values in the offer, we can associate a single data-point `ex:D-costs` to the entire `ex:T-power` time-series. Figure 12 further shows that it is possible to specify a creation time (`ic-data:hasCreationTime`), validity period (`ic-data:hasEffectivePeriod`) and provenance (`ic-data:producedBy`) for the offer, on top of the creation time, validity period and provenance already specified for the time-series and data-points included in the offer.  
 
-The additional key aspect that we captured in the ic-flex module is that a flex offer can also include various categories of flexibility, which we modelled as subclasses of the ic-flex:FlexibilityProfile class (which in turn is a subclass of saref:Profile) as follows:
+The additional key aspect that we captured in the ic-flex module is that a flex offer can also include various categories of flexibility, which we modelled as subclasses of the `ic-flex:FlexibilityProfile` class (which in turn is a subclass of `saref:Profile`) as follows:
 
 - Power profile flexibility is implemented using the existing SAREF4ENER. This type of flexibility is typical for devices that perform a task (with a clear start and end) with a corresponding power profile that is known or can be predicted. Their main flexibility comes from the ability to change the start time of that power profile. Note that the existing s4ener:PowerProfile in SAREF4ENER was modelled based on EEBUS SPINE, but we have now additionally aligned it with the power profile specified in the pR EN 50492-12-2 that describes the S2 interface (see Section 3.3).
-- Tariff based flexibility (ic-flex:TariffBased) is implemented using the incentive table module (see Section 4.4). 
-- Power limit flexibility (ic-pwlm:PowerLimit) is implemented using the power limit module (Section 4.5). 
-- Power Envelope flexibility (ic-flex:PowerEnvelope) is implemented using the S2 ontology that follows the S2 specification. It is used for devices that can be influenced to use a minimum and/or maximum amount of power over time. The flexibility manager cannot control the amount of power produced or consumed by the device directly, but it can dictate power limits, which can change over time.
-- Demand driven flexibility (ic-flex:DemandDriven) is implemented using the S2 ontology that follows the S2 specification. It can be used for systems that are flexible in the type of energy carrier they use but are not capable of buffering or storing energy. 
-- Operation mode flexibility (ic-flex:OperationMode) is implemented using the S2 ontology that follows the S2 specification. It is for devices that have the possibility to control the amount of power they produce or consume, without significant effects on their future flexibility options. These devices are modelled as a state machine, where each state (referred to as an operation mode) has an energy production or consumption associated with it.
-- Fill rate based flexibility (ic-flex:FillRateBased) is implemented using the S2 ontology that follows the S2 specification. It can be used for devices that have the ability to store or buffer energy. How energy is stored or buffered does not matter, as long as there is a means to measure how full the storage or buffer is.
+- Tariff based flexibility (`ic-flex:TariffBased`) is implemented using the incentive table module (see Section 4.4). 
+- Power limit flexibility (`ic-pwlm:PowerLimit`) is implemented using the power limit module (Section 4.5). 
+- Power Envelope flexibility (`ic-flex:PowerEnvelope`) is implemented using the S2 ontology that follows the S2 specification. It is used for devices that can be influenced to use a minimum and/or maximum amount of power over time. The flexibility manager cannot control the amount of power produced or consumed by the device directly, but it can dictate power limits, which can change over time.
+- Demand driven flexibility (`ic-flex:DemandDriven`) is implemented using the S2 ontology that follows the S2 specification. It can be used for systems that are flexible in the type of energy carrier they use but are not capable of buffering or storing energy. 
+- Operation mode flexibility (`ic-flex:OperationMode`) is implemented using the S2 ontology that follows the S2 specification. It is for devices that have the possibility to control the amount of power they produce or consume, without significant effects on their future flexibility options. These devices are modelled as a state machine, where each state (referred to as an operation mode) has an energy production or consumption associated with it.
+- Fill rate based flexibility (`ic-flex:FillRateBased`) is implemented using the S2 ontology that follows the S2 specification. It can be used for devices that have the ability to store or buffer energy. How energy is stored or buffered does not matter, as long as there is a means to measure how full the storage or buffer is.
 
 The S2 ontology (ic-s2 module) has been designed to thoroughly follow the S2 specification of the EN50491-12-2 standard (see Section 3.3). As ic-s2 reflects the S2 underlying data model, it is a rather detailed ontology compared to the more general nature of the ic-flex module represented in Figure 12. For this reason, the ic-s2 module is not presented in this document, but is available in the public InterConnect ontology repository.