rename `*TypeList` files and resources about energy-reference-data HOT 3 OPEN

Source from what that data is generated is ENTSO-E code list XSD, no manual changes are done and purpose for now is to maintain backwards compatibility. Long discussions are to be had, how and what to change, but most likely as long as the code list XSD is the source of truth, we will have to stay with the naming as it is. We are thinking to leave the enumerations as they are and in parallel create new ones, that combine those with enumerations that can be used for grid models. (current XSD based code list is used only for market data, to align we might have the best approach to publish the XSD conversion as is, but mark it as deprecated and then recreate new codelist's that refer to the direct XSD conversions)

• Source Data XSD: https://github.com/Haigutus/Energy-Reference-Data/blob/master/Tools/urn-entsoe-eu-wgedi-codelists.xsd
• Conversion Script: https://github.com/Haigutus/Energy-Reference-Data/blob/master/Tools/entsoe_codelist.py

from energy-reference-data.

I use the same source and convert with a 15 line xsparql script (which is xquery but ++)

for $data in doc($input)/xs:schema/xs:simpleType[fn:matches(@name,"^Standard")]
 let $name := fn:replace(fn:replace($data/@name/string(),"^Standard",""),"TypeList","") 
...

The result is uniform like this, all I one file

<https://transparency.ontotext.com/resource/type/AllocationMode> tr:description "The identification of the method of allocation in an auction." .
 <https://transparency.ontotext.com/resource/type/AllocationMode/A01> a tr:CodeValue ;
  tr:codeList <https://transparency.ontotext.com/resource/type/AllocationMode> ; 
  tr:name "Order by price with pro rata" ;
  tr:notation "A01" .

(But using SKOS would be better).

I don't see anything sacrilegious in rationalizing the names. If you feel that "TypeType" descended to us on stone tablets straight from God, I'd say we have irreconcilable philosophical differences :-)

from energy-reference-data.

In principle I agree and it is an easy change to implement, but it will break one to one backwards compatibility, so we need to have discussion if, why and what to change.

On URL naming, I would say it is bad to put semantic meaning into URL structure.

from energy-reference-data.