- remove redundant properties
- add ic-s2:powerForecastElement
- remove incorrect domain on endTime

Removal of class virtual device and property haslimitrange (substitued by allowedlimitrange)

Conflicts:
	ontology/Interconnect/ic-data.ttl

change range and property type on ic-s2:fillRate

change property supplyrange from datatypeproperty to objectproperty

delate class ic-s2:ControlScheme, individuals of the class and property hasoptimizationscheme

insert domain and range on property supplyrange

removal of the property costvalue

removal of property demandratevalue

removal of property costcurrency

update domain on the property endTime

remove the property ic-s2:leakBehaviourDetail

fix domain on hasunitofmeasure from intersectionof to unionof

add numberRange as range of ic-s2:hasDemandRate

adding range ic-s2:NumberRange on property hascost

removal of the class ACMeasurementPhaseDifference  according to our latest conceptualization of voltage. n.b we still have the conceptualization of 'acmeasurementphasedifference' which is ic-tplg:ACMeasurementPhase. - removal of the individual of acmeasurementphasedifference according to our latest conceptualization
-removal of long series of blank nodes with restrictions (erroneously produced by protege in the script file)

change in the diagram. Alignment  with the latest conceptualization of voltage

update on the comment of ic-data:GaussianDatapoint

removal of max qualified cardinality with blank node at the bottom

removal of description of the domain of ic-tplg:hastopologicalassociation from ic-data

typo correction

change of datatypeproperties in object properties (in time ontology, interval is a class)
removal of suproperties relationships because of conflicting range domain with the superproperties

device_3 example individual removal

removal of a duplicate property (we have that conceptualization in hasoperationmode)

ic-flex ttl file in line with the latest conceptualization

-	I have internally (in the ttl file) re-defined om:hasprefix because it was giving an error.

-	I added the objectproperties includescommand and concernsdevice. They were not present in the ttl model.
-	I removed the restriction on user profile at the level of the preference. We already use the domain and range on preference.
-	I added the object property belongstouser (which was present in the diagram but not in the model).
-	I added the objectproperty hasLocation
- I put a restriction on the class preference.

-	In the diagram, I have added the class measurement phase difference and the instances of this class (which were defined in the model).

-	In the ttl file, schema:place and acmeasurementphase were defined as subclasses of topological location. However, in the diagram and examples they are not subclasses of topology. So I moved their position to classes in the ttl.file
-	I have inserted distance as the subclass of topological location (we use distance in the example and is conceptualized in the diagram)
-	I have added a basic comment to acmeasurementphase
-	I added a comment on voltage
-	I defined the object property haspoint. I put a domain range restriction on this property.
-	I defined the property isInsubgridOf with a domain on Device
-	I changed the name of the property hasMeasurementphase to hasACphase (as defined in the diagram).  I removed the domain (device) from this property since it is used also for GridSegment
-	I defined the property isinACphase
-	I defined the property ISACPhaseof
-	I defined the property hasACphase
-	I defined the class ACPhaseName
-	I instantited the individuals of ACPhaseName
-	I defined the objectproperty is topological association of
-	I defined the object property hasphasename

-	I changed the diagram from ic-fc:hasquantile to ic-data:hasquantile (since in the ttl models are both defined as ic-data:hasquantile)
-	I changed the gaussiandatapoint from ic-fc to ic-data in the diagram (according to the definition provided in our ttl model)
-	I changed the property has stardarddeviation from ic-fc to ic-data in the diagram
-	I changed the color of the arrows hascreationtime/etc. from the diagram because the previous ones where white at the top (they were indicating a subclass relationship according to our use).