rename *TypeList files and resources

[VladimirAlexiev]

There are 39 files with names like the following, using resource URLs like the following:

• entsoe-codelist-StandardObjectAggregationTypeList:
  <http://energy.referencedata.eu/StandardObjectAggregationTypeList/A12>
• entsoe-codelist-StandardTarifTypeTypeList.ttl:
  <http://energy.referencedata.eu/StandardTarifTypeTypeList/A05>

They're pretty bad (the second one is awful: what is TypeType?):

• an individual resource is NOT a list, so this word should not be in the URL
• it's better to use common prefixes delimited by /, rather than common suffixes

So I propose to change the naming as follows:

• entsoe-codelist-ObjectAggregation:
  <http://energy.referencedata.eu/type/standard/ObjectAggregation/A12>
• entsoe-codelist-Tariff.ttl:
  <http://energy.referencedata.eu/type/standard/Tariff/A05>

/standard is only needed if you expect other non-standard types to be added later.

Notice that "tariff" is spelled with "ff".

[Haigutus]

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

[VladimirAlexiev]

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 :-)

[Haigutus]

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.