Haigutus / Energy-Reference-Data

Reference Data for Energy domain using SKOS
0 stars 2 forks source link

rename `*TypeList` files and resources #23

Open VladimirAlexiev opened 1 year ago

VladimirAlexiev commented 1 year ago

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

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

So I propose to change the naming as follows:

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

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

Haigutus commented 1 year ago

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)

VladimirAlexiev commented 1 year ago

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 commented 1 year ago

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.