EIC list about energy-reference-data HOT 11 OPEN

Open issues to transofrm to dcat namespace/domain

• EICContact_MarketParticipant.name
• EICContact_MarketParticipant.phone1
• EICContact_MarketParticipant.electronicAddress
• EICCode_MarketParticipant.streetAddress
• EICCode_MarketParticipant.VATCode_Name.name
• EICCode_MarketParticipant.ACERCode_Name.name - is this needed?
• EICCode_MarketDocument.docStatus (active/inactive)
• EICCode_MarketDocument.deactivationRequested_DateAndOrTime.date
  Date

https://eepublicdownloads.entsoe.eu/clean-documents/EDI/Library/cim_based/schema/EIC_document_uml_model_and_schema_v1.0.pdf

from energy-reference-data.

Linking

• StandardEicTypeList Concept -> EIC Collection

• EIC Concept -> StandardEicTypeList Concept

• Open question: How to link Concept -> Collection

http://energy.referencedata.eu/StandardEicTypeList/Z -> skos:Collection rdf:about="http://data.europa.eu/energy/EIC/Function/AccountingPoint"
http://data.europa.eu/energy/EIC/10Z-CH-DE-00017K -> http://energy.referencedata.eu/StandardEicTypeList/Z

from energy-reference-data.

• For the link between Concept->Collection see https://www.w3.org/TR/skos-reference/#collections section 9.3
• It looks like we can go for rdfs:domain

Another good option to use is dcterms:isPartOf

for EICCode_MarketDocument.docStatus (active/inactive) we have adms:status in DCAT

For the phone, email we can use https://www.w3.org/TR/vcard-rdf/

from energy-reference-data.

ACERCode_Name.name - is this needed?

Of course. The more ids the better. ACER itself has BIC, GLEI, GLN.

• I would add Wikidata.

You need to make a distinction about an organization or resource, its identifiers, and docs about those identifiers.

from energy-reference-data.

• For Address:

  • http://www.w3.org/ns/locn#fullAddress (prefix = locn)
  • EICCode_MarketDocument.eICCode_MarketParticipant.streetAddress.townDetail

• VAT

  • https://schema.org/vatID (prefix = schema)
  • EICCode_MarketDocument.eICCode_MarketParticipant.vATCode_Names.name

• Postal Code

  • http://www.w3.org/ns/locn#postCode (prefix = locn)

from energy-reference-data.

Question for Alvaro:

• Is this correct way to refer to ESMP EIC Object Class?
  • urn:iec62325.351:tc57wg16:451-n:eicdocument:1:1#EICCode_MarketDocument

from energy-reference-data.

Reply from Alvaro:

https://eepublicdownloads.entsoe.eu/clean-documents/EDI/Library/cim_based/schema/EIC_document_uml_model_and_schema_v1.0.pdf

Schema v1.0 references to EIC document v1.1.

Schema and market document versions are not correlated

urn:iec62325.351:tc57wg16:451-n:eicdocument:1:1

To summarize v1.1 of eic document is the last version of the profile. Version 1.1 of the profile is reference in v1.0 of the schema above

from energy-reference-data.

Initial version ready, example -> https://energy.referencedata.eu/EIC/10Y1001A1001A39I

@Sveino @gridDigIt please review

from energy-reference-data.

The sample file looks good to me at first sight.

Just for me to understand, how are we going to refer to an EIC code from a 61970 instance file? I guess that it will be using the dcterms:identifier but just to be sure. e.g. urn:eic:10Y1001A1001A39I

from energy-reference-data.

@marrodal That is correct. I've added urn:eic:$1 as "URN formatter" on Wikidata: https://www.wikidata.org/wiki/Property:P8645 in Dec 2021.
I've also added http://energy.referencedata.eu/EIC/$1 as "formatter URI for RDF resource"

@Haigutus @Sveino @gridDigIt Here is some feedback about the current representation.
You can compare http://energy.referencedata.eu/EIC/53XPL000000OSMP5 to https://transparency.ontotext.com/resource/eic/53XPL000000OSMP5, which has the following data
(Note "VIES" refers to the EU VAT Information Exchange System, in the Transparency project we consulted it regarding the validity of VAT numbers):

@prefix tr: <https://transparency.ontotext.com/resource/tr/>.
@prefix eic: <https://transparency.ontotext.com/resource/eic/>.
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.

eic:53XPL000000OSMP5> a tr:EnergyResource;
  tr:addressInVies """DĘBOGÓRZE 
RUMSKA 28
81-198 KOSAKOWO""";
  tr:countryCode "PL";
  tr:dateUpdated "2017-05-22"^^xsd:date;
  tr:description "Consumer, Metered Point Operator, Network User, Party Connected To Grid, Storage System Operator";
  tr:eic "53XPL000000OSMP5";
  tr:eicType <https://transparency.ontotext.com/resource/type/Eic/X>;
  tr:function "Consumer", "Information Provider",
    "Meter Administrator", "Metered Data Aggregator", "Metered Data Responsible", "Metering Point Administrator",
    "Metering Point Operator", "Network User", "Nomination Validator", "Party Connected To Grid",
    "Storage System Operator";
  tr:name "Gas Storage Poland sp. z o.o.";
  tr:nameInVies "GAS STORAGE POLAND SPÓŁKA Z OGRANICZONĄ ODPOWIEDZIALNOŚCIĄ";
  tr:notation "GSP";
  tr:vatInVies true;
  tr:vatNumber "PL5272643619";
  tr:viesCheckDate "2022-02-14"^^xsd:date .

You can also see the EIC data that we map at https://transparency.ontotext.com/spec/#eic-fields
and https://transparency.ontotext.com/spec/#eic-mapping.

1. It would be nice to have per-EIC HTML pages, so we can use it as "formatter URL" in Wikidata
2. rdf:type leaves a lot to be desired:
   • schema:Thing is not useful because it's too general,
   • skos:Concept is not correct: an individual is not a concept, only general concepts like ENTSOE lookup list values are
   • EICCode_MarketDocument is not correct: a document transmits that information, but the individual identified by EIC is an EnergyResource (PowerSystemResource, MarketParticipant, Zone, etc)
   • a type EnergyResource is lacking
3. dcterms:identifier should be URI not string. This pertains both to http://energy.referencedata.eu/EIC and its members.
   Eg instead of "urn:eic:53XPL000000OSMP5" use <urn:eic:53XPL000000OSMP5>
4. You've described the functions of a resource through the link skos:Collection.skos:member. That's a valid approach, but when you download the resource's entity RDF, these inverse links are not present, so a linked data crawler cannot discover them. Please include the links: read about symmetric concise bounded description.
5. It would be nice to include a link to <eicType/X>, which means "Party". I.e. to represent the "meaning" of the 3rd letter of the EIC explicitly
6. cim:DateAndOrTime.date: it is not clear enough that this is "date updated"
7. countryCode is missing (MarketParticipantIsoCountryCode in CSV, eICCode_MarketParticipant.streetAddress/townDetail/country in XML)
8. Sometimes too many fields are mixed up in the same RDF prop (they are separate in our representation: https://transparency.ontotext.com/resource/eic/19XVSP---------I), eg:

<http://energy.referencedata.eu/EIC/19XVSP---------I>
    cim:Names.name
        "A0001933F.PL",              # ACER code
        "Balance Responsible Party", # function
        "Energy Supplier",           # function
        "PL6312241337",              # VAT code
        "TAURON_TSGZE" ;             # name

9. parent is missing (EicParent in CSV, eICParent_MarketDocument.mRID in XML). Eg eic:19XVSP---------I should have parent eic:19XTAURON-PE-SAJ
10. responsibleParty is missing (EicResponsibleParty in CSV, eICResponsible_MarketParticipant.mRID in XML). Eg eic:19W000000000203G should have responsible eic:10XPL-TSO------P

from energy-reference-data.

Tweet: https://twitter.com/valexiev1/status/1689180747750621184

from energy-reference-data.