# Integrating Knowledge Graphs into Distribution Grid Decision Support Systems +
## 4 Power Knowledge Graph
### Concepts  
Some concepts required for the construction of a power system model have already been defined in PowerSystem.owl. We extend this ontology to accommodate concepts needed to represent additional types of information, such as geographical locations, events, and maintenance activities. These concepts allow the building of a representation of the system beyond its basic electrical components. We introduce two essential concepts--_Element-Asset_ and _cNode. Element-Asset_ is equivalent to the category _ElectricalEquiment_ from PowerSystem.owl that can represent a wide range of types of assets. In the proposed PowerLOV, the concept _Element-Asset_ has the following attributes:  
* _id_--which is the same as the asset identifier assigned by a utility;
* \(x\), _y_--for the asset location using the utility's proprietary system of coordinates;
* _longitude_ and _latitude_--representing the geographical location of the asset. The concept _cNode_ is a fictitious connection point that allows the connection of assets. A single _Element-Asset_ is connected to two _cNodes_, each connecting two adjacent _Element-Assets_. _Element-Asset_, as a node in the graph, is connected via _cNodes_ to other _Element-Assets_. Additionally, each asset node is connect to other nodes defined in PowerLOV for the  
Figure 1: RDF triples with _Element-Asset_ as their subject. purpose of providing descriptive information about the asset. We define three groups of nodes that can be used to describe _Element-Asset_. The first group consists of nodes that identity the type of asset, its specification, and information about maintenance activities performed on the asset. The group contains:  
* _Components_--class that contains a number of subclasses called _ComponentType_ that identify the asset type using the following subclasses: _Switch_, _VoltageRegulator_, _EnergyMeter_, _ElectricalLine_, _PowerGenerator_, _CapacitorBank_, _SwitchGear_, _Sectionalizer_, _Elbow_, _Recloser_, _Fuse_, _SubstationBus_, _FaultIndicator_, _IsolationPoint_, _Breaker_, _SubstationTransformer_;
* _ConnectionStatus_--with subclasses _ConnectionStatusTypes_ that indicate the operational status of an asset: _Connected_ or _Opened_;
* _Phases_--class of _PhaseValue_ which stands for the phase(s) to which an asset is connected;
* _Orientations_--with two subclasses of type _OrientationType_ that indicate whether an asset is _undegroundCable_ or _overheadLine_;
* _Voltages_--with subclasses _VoltageValue_ which specify the rated and connected voltages of an asset;
* _Customers_--with subclass _Customer_ whose instances represent customers of the modeled system. The second group of nodes is related to the topology of the system, that is, the geographic location of the assets. Besides the obvious location indicators, such as the service area and the feeder, to which an asset is (indirectly) connected, we introduce a much finer division of service areas, a grid of polygons. The motivation to introduce such a grid of polygons is twofold: (1) to better localize different elements and events at the resolution that is \"between\" service areas and geographical coordinates; and (2) to introduce the possibility of adding \"extra\" data--for example, weather data--that enhance the possibilities of analysis of power system behavior under different (weather) conditions even further. The classes of the second group are:  
* _ServiceAreas_--with a number of subclasses _ServiceAreaNames_ representing names of the utility's service coverage zones;
* _Feeders_--a superclass of _FeederID_ that provides identification of the upstream feeder to which an asset is (indirectly) connected;
* _GridCell_--identification of an individual grid cell in the grid of polygons. The third group of nodes represents system events in which the asset was involved. Here, we define categories describing details of an event and its cause.