Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


As a goal, we would like to guide realization of an energy system that is interoperable, by standardizing the meaning of data exchanged and guide implementation of open source projects developing exchange (interfaces) based on these standards. We focus on the business side of interoperability as common understanding, trust and transparency of data used and data exchanged is a fundamental part of the energy system of the future, regardless of geography.

Data Architecture Workgroup Office Hour

Teleconference weekly on Thursdays, 7:00 US Pacific Time. Meeting details can be found in the LF Energy Community Calendar or below.

  • during the northern winter: 07:00 -0800 (PST) → 16:00 +0100 (CET)


Join Zoom Meeting:

Meeting ID: 918 1839 9821


If you like to add you topic to add to the agenda, feel free to add it.

Topics for the meeting of 03 June 2021

  • Alberto's opinion on strategic direction
  • Feedback of Shuli on our link to European Union (Entso-E) and US state / federal regulation 
  • Feedback of Shuli on connecting Microsoft to present about "Microsoft Energy Grid Ontology for Digital Twins"
  • See above focus and goal of data architecture stream.  This relates to focus on data architecture and separate the focus and deliverables from data-platform architecture.  We do have implementation of data models and interfaces in scope though (it is data architecture), but not perse Data ingestion, data processing, data integration, data analysis \ science, data distribution, data visualisation solutions in scope. 

Topics for the meeting of 27 May 2021

  • Strategic directions of the working Group
    • Daniel: split logic and implementation on platforms.
    • Robbie: seperation is also practices in software design. Bring in use cases and decide per use cases. Footprint comes  Separation between open data and private data is important.
    • Donald:  appreciate the split, but a lot is IEC CIM related.  Focus consumer side of things. EPRI. Focus USA. Put US standards on agenda to assess for applicability. Understand what is going around in the grid. Participating to learn what you are doing. Green button alliance is interested in coverage of standards. 
    • Rob:  we can contribute a lot for LFE. Share Knowledge. Guidelines LFE projects. Guied LFE with rules, goals, standards.
    • Benoit:  FAWG is also struggeling to create an interesting agenda.  Level of FAWG, assembly of experts to guide projects on LFE.  Talk about what is missing and clarify goal. Not a deciding assemly, advising. For data architecture group same type of challenge. Standard and certificaton. Propose a solution from data architecture group. 

We will create a parking lot, with topics of interest and then vote on priority. 

  • open energy ontology (OEO) - generic, not specific to Energy! Mostly adopted in Germany. Relationships and objects. 
  • Microsoft Energy Grid Ontology for Digital Twins.  Microsoft comment / explain this topic. Github repop is adaptation of CIM model, following MIT license.  Multiple objects from CIM but minimalistic.  Ask Microsoft about scope and about what the've organisated with IEC to get here.  

recent OEO paper: Booshehri, Meisam, et al (1 September 2021). "Introducing the Open Energy Ontology: enhancing data interpretation and interfacing in energy systems analysis". Energy and AI. 5: 100074. ISSN 2666-5468. doi:10.1016/j.egyai.2021.100074. Open access.

Topics for the meeting of 29 April 2021

Topics for the meeting of 25 March 2021

Presentation of Ibrahim Haddad (Executive Director, LF AI & Data Foundation) - presentation on LF AI and Data


Topics for the meeting of 4 March 2021

  • Robbie Morrison is just adding this stub at 10:00 (CET) on 4 March but presumes the meeting is cancelled?

Topics for the meeting of 4 February 2021

Session to prepare questions toward second OSDU session.

OSDU Onboarding 24 12 20.pptx

OSDU LFEnergy Architecture Introduction v2.pptx 


Questions LFEAnswers Shell (dd 5 February 2021)

What components are open source frameworks based and what are Schlumberger Delfi developed or Shell developed? What does Delfi  / Shell developed mean code wise?

Shell developed means an API specification and implementation of a data platform developed with Shell called SDU.  It was started in early 2018 and contributed to the OSDU Forum in early 2019 as the initial baseline for OSDU development.

DELFI developed means it was originally developed in Schlumberger to support the DELFI environment to support both internal and commercial upstream workflows.  Internally, the code was referred to as the Data EcoSystem (DES) and has been in development since 2015 and contributed to the OSDU Forum in late 2019.

Because the SLB code base  had both a larger footprint and contained an implementation of business logic deeper than the API specification, it was chosen to become the basis for future OSDU development.

The components in R3 that were contributed from Schlumberger to this space include what is referred to as

Components from Shell’s implementation that were not present in the Schlumberger implementation that are being ported/redeveloped on top of the new code, include the Delivery Service and support for Global (multi-region) deployment.  Most of the other Shell contributed services had a corresponding SLB implementation and thus the deltas were treated as requirements.

In addition to Shell and Schlumberger, there have been existing code contributions from other companies as well. Most notably, this included an optimized cloud friendly bulk seismic representation (OpenVDS) from Bluware.

Beyond the initial code contributions, there are other development activities that started in Open Source, including:

What function has OFP in total architecture?

    1. Open Footprint
    2. Is not part of OSDU but I expect it to be added over time: Not technical difficult.

How do you see OSDU be adopted and used in LFE community? I mean focus with current community is with oil and not with power right. Wat is goal of Shell to put it forward at LFE?

How is lineage implemented? How is discovery implemented? How is meta date capturing and usage implemented? 

Re: Lineage

First, there is a notion of versioning which is distinct from lineage. 

  • Versioning is used when a new record is inserted that is not strictly a derivative of a previous record (think simply update from an external source). 
  • Lineage is based on the notion that one record is derived from other records whether it be of the same type or a new type.

Version is managed by the system’s support for immutability.

Lineage is largely a usage convention agreed by the community of developers and data modelers.  It is captured as references to ancestor records in the metadata.  There is a lot of interest in supplementing this with an activity model which can be more expressive than simply linkage.

Re: Discovery

All metadata structures in the system are described in the Schema service.  When a metadata record is stored (storage service), it triggers an event.  An indexing service listens to the event, parses the metadata record according to the structure defined in the Schema service and maps it to an ElasticSearch index which can then be used for search.  This makes the system flexible in that a user defines a structure, and this structure is then used directly for search without the need for custom indexers.  If custom indexers are required for unique search patterns (such as full geospatial (GIS) rather than elastic spatial, then they can be accommodated by creating new consumption zones (a different topic).

Security standards for all data, in Rest, transit in use? Any cryptograph standard implemented and evolution on roadmap?

You can see the Open Source version of the security requirements at

There is a security standard document on the member side (you must be a OSDU Member to read it while it is in development) that is a formal version of the requires as well as the cloud providers response on how they meet the requirements. 

Security (and operations) has a shared responsibility model; so, some aspects can be addressed in the Open Source code; others are addressed at time of deployment and yet others during operations.

Given that this is an Open Source development, compliance is enforced through certification of a deployable system.  A deployed system that does not meet the security standards defined by the OSDU Forum cannot be certified. 

Future roadmap. How does development of platform look like including view on backwards compatibility

The initial developments were primary focused on a backlog of contributions of existing code.  These contributions will continue as the backlog of contributions in the Upstream Oil and Gas space has not been exhausted (far more to go).  The members of the Forum itself are also pivoting towards becoming carbon neutral and embracing new energy sources; so we can expect to see contributions and new developments in this space.

The system supports this through a variety of means.

  • Data structures are declarative (and versioned), so it is easy to add new data types to expand the coverage.
  • Data is immutable; this avoids destructive updates to data since any updates are either a new version of the data with the same format or a derivative of the data with a different format and/or some process applied.
  • Data and Services are developed with semantic versioning (major, minor, patch) and the system support the concurrent existence of both. Data – to honor immutability and Services to support upgrades while maintaining backward compatibility.

Could you elaborate on the D-WIS


What is the programming language is used to transform datasets?

The system is microservices, so accommodative of many languages.  However, development convention has primarily settled on 3 languages.

  • System services are largely written in Java
  • Data oriented services are largely written in either Python (lightweight transforms) or C++ (legacy plus heavy weight / HPC transforms).  Python will probably become the dominate language for new transforms.

What does minimum viable governance mean?  Does it exclude type of use cases because if it (compliancy for instance) or does it adept to what is needed?

Minimum – means whatever is necessary with a bias towards making it easy to bring in new data.  Concretely, it means describing your data making it discoverable and tagging the data to understand whether you have the right to use it. Policies can be additive, since you always have the right to reject data coming in the system, or add additional policies on usage later (new entitlements engine).

The principle was introduced because of the tendency in the past to refuse the admission of anything less than perfectly described, perfectly formed data.

Is focus on Interoperability not a business and IT goal to focus, or what principles are in place for interoperability purpose? 

Interoperability is not a principle, because it is the primary goal of the system.

  • Break down barriers by making information easily discoverable, available and usable across domain and functional silos
  • integrated approach; breaking down barriers
    • among vertical silos;
    • between planning and operations;
    • between operators and suppliers; and
    • past and future knowledge.

Principles help us decide on competing / alternative approaches towards achieving the goal

Why is data mesh / user (group) centricity not reflected in data principles?

Maybe because the principles were written 5+ years ago, and the notion of data mesh as an implementation pattern came in later.  Data-mesh is an architectural/design decision.

How are generic types supported (details).

The data structures from the records are declarative and registered via the schema service with corresponding metadata records stored in the storage service which can then be discovered via the search service .  The goal is to be able to represent anything described in well-formed JSON; although there are complications when trying to map JSON to ElasticSearch indices to consider.

Some tutorials on how this works can be found in

If used with LFE, the platform is a separated one from the oil focus instance? For what purpose are the concepts kinds and namespaces used in the platform?

there is no notion of the single deployable “instance” in OSDU. Different companies will find different ways of deploying it, whether it be multiple regions for within a company, multiple companies in a SaaS or national repositories.

There is, currently, one software baseline officially supported in Open Source; and given the rapid rate of development of the core platform, it is premature to think about forking and developing in parallel.   What can be done (by design) is independently developing data representations, ingestions, enrichments, optimized domain services that plugin to the core platform.  These can be developed anywhere – and probably should be developed close to the community of interest.

Re:  Namespaces

The purpose of “kinds” is to support the addition of new data representations to the platform as a user function rather than a development one.  This allows for the footprint to expand based on the scope of interest of the consumer.  The naming convention for a kind (namespace, authority, …) is intended to provide context into the type of data that the kind is describing. 

For instance, for electricity, you could think about capturing the packages and entities defined in CIM as a set of kinds.

Are there semantic standards in use of the Oil & Gas industry, if so how are they used in the platform?


What meta model is used to describe the semantics? What tools are used describe the semantics?


What meta model is used for the provenance/lineage? W3c PROV?


How are API's generated out of the metamodel?

There are two types of APIs,

  • Generic API’s that are meta-model independent.  The underlying meta-models are discoverable, described and can be queried.  Thus, the contract is in the meta-model, not in the API
  • Domain specific API’s that are type-safe, express strong semantics, and optimized access to content.  There is code behind these APIs.

The contract that binds these together is that the actual persistence of data in the platform from the domain specific APIs complies with the requirements to be discoverable, described….

What semantics are used to publish the discovery services? DCAT?

The semantics are described in the definition and registration of JSON metadata models in the Schema services and the mapping is performed by model specific services (such as mapping to elastic search).

 “Well Known Schemas (WKS)”; Can you give example? Do you have a list?

A WKS is a community defined model.

The concept CQRS is used at application level implementation, right? The generic storage layer / data distributed layer is decoupled from this

The concept is deeper than just the typical view of an application layer.  The ability to expose multiple metadata records on the same data with different views represents a platform level of CQRS.  The simplest example would be search, where the properties used in search can be narrower, or different from the properties initially loaded into storage.  Keep in mind that “applications” can also run inside the platform producing (Command) new representations for specific consumers (Query).


Who owns the data?

the system can be deployed by anyone.  Whoever runs the instance is liable for the data (note:  the notion of data ownership vs. data liability are different since the platform is often used to host licensed data by users and thus the owner is an external contractual; entity.
Is the platform multi-tenant?yes, some providers of the platform are SaaS providers and thus need to host multiple customers in a single instance for cost/operations reasons (there is support for string isolation between tenants).  Even in a single customer deployment, different partitions can be used to separate business units, contractual data, business continuity needs, ….

Does the platform control somehow personal data (privacy affected)?

the system has no direct recognition of or support for personal data (PII). In Upstream technical computing, personal data is peripheral to workflows of interest.  By convention, any personal data loaded into the system should remain incidental to the purpose of the platform unless stronger controls are added.

Personal information does come into strong play with respect for security and auditability.  Such logs that contain this information should be protected.


Real-time and streaming services D-WIS* (details/roadmap)


OPEN DATA LABEL  (from Robbie Morrison)

On the "open data" label: My questions to Shell related to the legitimacy of using the phrase "open data" when the data held — aside from that mandated public domain by certain national authorities — was governed by brokered contracts restricting its use and further publication.  Indeed a central design feature of the OSDU was the tagging of data with its contractual attributes to automate this process — my reading admittedly.  There are clear touchstone definitions for "open data", one community‑driven from the Open Knowledge Foundation (OKI) and another stated in recital 16 of the Open Data Directive 2019/1024.  This question was discussed in an engaged manner but I did not record a clear answer (although I am happy to be corrected).  The term "open data" is not protected by legislation, so instead I suggested perusing a voluntary "code of practice for open data in the energy sector" under Directive 2005/29/EC on Unfair Commercial Practices.  The feasibility of this option is still be be determined.

On data ownership more generally: Worth noting too that data cannot be "owned" as such (some questions were also related to data ownership).  Setting aside European database rights for the moment, data is either private, its movement restricted by contract (as per the OSDU proposal), subject to human rights considerations when personal (under the GDPR), or publicly available.  Certain data needs to be published under statutory reporting for public interest reasons (usually to address market failure) which is why some electricity sector data needs to be provided to the ENTSO‑E Transparency Platform.  Notwithstanding, other legal considerations, such as unfair completion, various civil wrongs, and misappropriation may apply, but these are not fundamentally matters underpinned by data ownership.

Topics for the meeting of 28 January 2021



Presentation of Johan Krebben, IT CTO, Royal Dutch Shell on  OSDU (Open Surface Data Universe) presentation. To be decided how much time needed.

Background and interest

Paper on Equinor (was Stadoil and StadoilHydro) relational database Slegge containing subsurface data:

  • Xiao, Guohui, Diego Calvanese, Roman Kontchakov, Domenico Lembo, Antonella Poggi, Riccardo Rosati, and Michael Zakharyaschev (2018). Ontology-based data access: a survey. ISBN 978-0-999-24112-7. In Proceedings of the Twenty-Seventh International Joint Conference on Artificial Intelligence. 5511–5519.

My blog on SzenarienDB which uses the same ontology-based data access:

Topics for the meeting of 21 January 2021


Set the agenda

Topics for the meeting of 14 January 2021


Set the agenda

storyline TAC document

  • intro of workgroep
  • Data guidline porpuse
  • interoperability importance
  • interoperability framework
  • Rule of workgroep

Topics for the meeting of 07January 2021


Set agenda

Plan timeslot in TAC on proposal on data architecture guidance on 2nd of February

Johan Krebben, IT CTO, Royal Dutch Shell.  OSDU (Open Surface Data Universe) presentation.

Status of document proposal to present to TAC on data architecture guidance

Update from previous meeting

Robbie Morrison was asked to post details of the e-Gridmap video he had briefly reported on:

The YouTube URL is marked at my 2 minute long question on open sourcing the underlying code.   Elering could well be interested in doing so.

Topics for the meeting of 17th of December 2020


Set the agenda

Leadership: who likes to take over the role of Sander

TAC presentations: who does what

Use approach of LFEdge?

Use set of standards and maturity model : Update on the maturity model document uploaded)

Use phases of LFEnergy.

From phase 3 comply to standards on various levels you can standardise on

Very short reports from Robbie Morrison on:

Topics for the meeting of 10th of December 2020


Set the agenda

Jonas van den Bogaard will join us on how we can bring the data architecture to the TAC 

  • What is the process?
  • What kind of advice can we give?
  • Alignment with the LF energy on project maturity models and data architecture maturity?

Very short reports from Robbie Morrison on:

  • Icebreaker One Open Energy phase II completion
  • DBpedia Databus project (am trying to talk that project into using the Open Energy Modelling Initiative community as a pilot)
  • EERAdata metadata joint publication (all aspects including provenance, semantics, and legal)
  • some recent attempts to get CC‑BY‑4.0 licensing on to the ENTSO‑E Transparency Platform
  • subseasonal to seasonal climate forecasting for energy workshop held 4 December 2020
  • the Linux Foundation OS‑Climate project (OS = operating system, to create a digital twin of the entire planet?)

Rob's improvement


Jonas: 30-60 minutes introduction into data architecture. Jonas can put us on the agenda.

Perspective: project use focused (how can projects use/benefit from the data architecture; why); some slides would be nice.

Discussions on the next steps could be discussed later.

Landing page links for the above short reports from Robbie Morrison:

Robbie Morrison also mentioned the frictionless data concept from the Open Knowledge Foundation (OKFN):

Rob presented an idea for an maturity framework for LF energy data architecture aspects.

The maturity model 

Naveen Goswamy suggested to look into grid‑wise architecture model and map these models

We need to be careful to ..

Derrick Oswald

Exchange methods need more clarity, particularly in relation to control signalling.

Rob will share his proposal to fill in.

Topics for the meeting of 3th of December 2020


Set the agenda


Rob's suggestions in terms of interoperability maturity:

1 datamodel
2 description / definition
3 exchange language (Technical format, e.g. JSON)
​ 4 exchange method (E.g. filesharing / API)

Open standards are only allowed. Proprietary standards are not allowed.

Eric made his first changes to the document to make it ready to discuss it with Jonas (TAC).

Topics for the meeting of 26th of November 2020


Set the agenda


The current architecture guideline only provide direction. More can be done (e.g. testing).

Maturity levels suggestions:

1 collaboration with other projects within the ecosystem (e.g. LF energy project or other related projects)

2 Using standards (if exists)

3 Test the interoperability between projects

Projects can go to the data office hours to get help to the next phase.


To doWho
Review the document for the TACWho did not do it so far
Ask the TAC chair to join the office hours to discuss the TAC recommendationsSander
Write a TAC Recommendation list Sander & Rob (after 3 December)

Questions for Jonas van den Bogaard(TAC Chairman):

How can we bring the architecture document to the TAC?

What form/ how? When?

Do we need to split it up?

Topics for the meeting of 19th of November 2020


Set the agenda

Discuss the next steps how to move the data architecture to the next level


To doWho
Review the document for the TACAll
Write a TAC Recommondation list Sander & Rob

Other posposals:

Aks the TAC:

What is to way to inprove the interobability of the LF energy projects?

Current ideas:

  • LF energy landscape field with semantics used
  • Criteria for project stages
  • Part of the yearly project evaluation

Interesting project to look at:

Topics for the meeting of 12th of November 2020


Set the agenda

What is our propose? (discussion last week)

  • STEPS 
    • What is the vision of LFenergy
    • What is the goal of this team?
    • What are the guidelines, principles 
    • What are our products
    • what is our implementation strategy
    • what is our commitment to this
    • Deliverables

Do we want to add SARGON to the referance models?


Discussion how we bring the data architectur to a new level.

  • Rob suggests to embed the data architecture principles into the LF energy. Becomming a member LF energy project requires you to comply with the data architecture lines. E.g. start with lineage. Measure the compliance with the data architecture guidelines.
  • The TAC can be an good place to promote guidelines.
  • Join the projects to make it happen
  • Collaboration between projects in the ecosystem is a maturity level. LFedge encourage project to collaborate with the ecosystem. 
  • Start an open source project to measure the compliance with the data architecture lines
  • Expand recommendation and guidelines to reference implementations (open source) of the recommended standards to fastrack and ease adoption by the projects.

Not so much operating modes,but more possible practical guidelines, methods: 

  • EH: Create a dictionary associated with functional domains that can be used, when projects ask to become part of ecosystem (functional domain?) then projects have to prove they comply to these definitions with their interfaces.
  • EH: If projects expose interfaces to ecosystem, they have to deliver metadata on provenance of input they used to get to the output they generate

<<Please add your suggestion to the list; How can we bring the data architecture to a new level within LF Energy and related projects>>

Topics for the meeting of 5th of November 2020


Set the agenda

Presentation of the SARGON onlology

What is our propose? (discussion last week)

  • STEPS 
    • What is the vision of LFenergy
    • What is the goal of this team?
    • What are the guidelines, principles 
    • What are our products
    • what is our implementation strategy
    • what is our commitment to this


Dainiel is looking into this project. It might be relevant for our community.

Slides of the SARGON ontology:

View file
nameSARGON data model for energy.pptx

Here are the likes into the projects, repos, and mentioned publication respectively.

Topics for the meeting of 29th of October 2020


Set the agenda

Presentation of the SARGON onlology

Outline of deliverables + time horizon

Topics for the meeting of 22th of October 2020


Set the agenda: are their any topics for today?

Status of the invite of: Operator fabric / OpenEEmeter / Powsybl

Unfortunately Robbie Morrison cannot make this meeting due to a clash. But a couple of comments nonetheless:

  • I have been contributing to the Icebreaker One (IB1) Open Energy project via advisory group 2 (AG2) covering policy, legal, and regulation. That project will build a proof-of-concept data portal and is being commissioned under the United Kingdom governments Modernising Energy Data Access (MEDA) initiative.
  • The Horizon 2020 (H2020) openENTRANCE project and the European Commission recently ran the Energy Modelling Platform — Europe (EMP‑E) 2020 conference. Data was less of a focus than modeling and analysis, but the topics of meteorological data and anticipated future climate change were covered in Focus Group 1.  Full recordings should be available in due course.

Notes: Gianluca will each out to check on the SARGON onlology

Sander will contact the invites of other projects.

Topics for the meeting of 15th of October 2020 <Cancelled>

Topics for the meeting of 8th of October 2020 <Cancelled>

Topics for the meeting of 1th of October 2020 <Cancelled>

Topics for the meeting of 24th of September 2020


Set the agenda: are their any topics for today?

Status of the invite of: Operator fabric / OpenEEmeter / Powsybl

Discussion: What needs to be added to the document to bring it to the TAC?

Open source and Standards update CEN / CENELEC

Marc Costa


Gianluca will ask somebody form SARGON to give some explanation in this group.

Derrick made a docker container for CIMtool.

The Relationship Between Open Source Software and Standard Setting

The upcomming meetings are cancelled due to the availibility of Sander

Daniel Lázaro can be reached by the invited projects if they want to present their projects and talk about semantics in the cancelled period.

Topics for the meeting of 17th of September 2020

  • Welcome
  • Set the agenda

Robbie Morrison

  • brief comparison of European and United States intellectual property law covering data
  • (could someone download and screen share the PDF I earlier posted to the mailing list, TIA)

View file

  • some updates:
  • OPSD are updating datasets, to be complete by 10 October 2020
  • PowerGenome are running workshop on 28-Sep-2020 19:00 CEST, more here
  • United Kingdom MEDA phase two organizations selected, namely Icebeaker One and Siemens, with Electron missing out
  • Update on CIMTool Derrick Oswald


We decided to share the relevant slides this wiki. A decision on how to record video is not needed.

CIMTool development:

  • Mainly used to keep the exsisting profiles
  • Eric and Todd are working on the software
  • The goal is upgrade CIMtool to the Eclipse plaform 4x
  • The draf standards 501/502 will be added to the tool

New agenda items can be added to this group.

Topics for the meeting of 10th of September 2020

  • Welcome
  • Set the agenda
  • Evaluation of the previous sessions with RIAPS/OEDI/CoMPAS
    • Was it useful? Does it help with the data architecture?
    • Do we want to invite more projects?


Connecting to the project is use-full, However the OEDI and RIAPS had little relation with the data architecture.

OpenEEmeter, PowSyBl and OperatorFabric will be invited to present their project as well. Sander Jansenwill invite them.

Opentaps project:

Derrick Oswald will reach out to the maintainers of CIMtool to ask them to join a office-hour to talk about their roadmap and collaboration.

Topics for the meeting of 3th of September 2020

Proposed agenda : one hour later at 08:00 PDT -0700 and 17:00 CEST +0200:

 Michael Rossel of OEDI 

  • Project focus and introduction
  • Data input
  • Data output
  • Used semantics (What standards are used? e.g. for the meta data catalogue)

Robbie Morrison

  • brief comparison of European and United States intellectual property law covering data
  • (could someone download and screen share the PDF I earlier posted to the mailing list, TIA)

Summary of the OEDI project:

  • The OEDI project is an open data project, not at open source project! However they release/build some open source software for consumption.
  • Data providers decide on the semantics of their datasets.
  • Everyone can summit datasets as long they comply with the rules.
  • AWS provides the storage currently for free to the project. The OEDI is looking into other cloud providers to migitate risk of AWS charging money.
  • The datacatalogus is build with CKAN. The catalogus supports DCAT.

View file

Topics for the meeting of 27th of August 2020

  • Welcome
  • Set the agenda
  • Review action list updates

Gabor Karsai form the RIAPS project

  • Project focus and introduction
  • Data input
  • Data output
  • Used semantics (What standards are used? e.g. for the meta data catalogue)

Summary of the RIAPS project:

  • Energy related project since it is funded by energy research money, it can be used for other applications
  • Semantics are relevant in the application side not in RIAPS itself
  • RIAPS is "partly" compatible with openFMB (openFMB uses IEC 61850 and IEC CIM)
  • The goal is the make it production grade and apply it in the field. A production grade project is work in progress.
  • Exsisting (demo) applications are research focused (for now). 
  • Any application message format can be used as long it can be used with ZeroMQ


View file
nameRIAPS-Overvview-Data aspects.pdf

Topics for the meeting of 20th of August 2020


  • Welcome
  • Set the agenda
  • Review action list updates
  • TAC seating update
  • COMPAS Sander Jansen
  • Open data

Meeting notes:

Review the M490 SGAM introduction to the document Eric Houmeswill check this later on

Sander Jansen and Eric Houmes will start with the TAC. Based on the TAC converstations, we can change this

 The COM-PAS project was presented. The COM-PAS slides can be found here.

Robbie Morrison made some comments about open data (see below)

Robbie Morrison will make suggestions to record the workgroup meetings form a legal an practical pespective.

Sander Jansen will request @Michael Rossel to join the 3th of september and asks the RIAPS project to join next week

Daniel Lázaro will contact RAIPS for setting the expectations to join next week.

Follow up:

(I, Robbie Morrison, was asked to record my comments about developing country transfers, please move this content elsewhere if this is not the best place. Or alternatively delete this comment.)

There are three projects promoting open source/data/access for  energy policy development for developing country:

  • Global Power System Transformation Consortium — aimed at up-skilling the entire industry from operations to public policy
  • U4RIA guidelines — a set of principles to improve transparency, community engagement, robustness, and trust
  • LF Energy — based on recent comments by Shuli Goodman


IEEE (6 July 2020). Global Power Systems Transformation Consortium: landscape analysis of relevant standards, testing, and certification activities. IEEE.  Closed access.

OPM and UK Aid (August 2019). Synthesis Report on the "Fourth Roundtable Discussion on Strategic Energy Planning" (Trieste 28 June 2019). United Kingdom: Oxford Policy Management and UK Aid. U4RIA Section 4 (pages 7–8) titled "Working groups on modelling standards and capacity building".

Meeting 13 August 2020 16:00 CEST


  • Work on data architecture working document together.
  • Chosing one interesting project that needs guidance or can serve the purpose of first project "to test our guidance  on"
  • Sharpen goal in above mentioned banner (our mission statement).
  • Information models plotted on SGAM (what standard to use where)
  • OEDI semantics (someone from the OEDI project)
    • Project focus and introduction
    • Data input
    • Data output
    • Used semantics (What standards are used? e.g. for the meta data catalogue)

Meeting notes:

Everybody agrees with the Working group goal with the addition of adding open source.

Daniel Lázaro will ask the RIAPS project to join the office hour to talk semantics (see the OEDI initiative).

Sander Jansen will add a basic introduction to the SGAM in the data architecture document.:

Google Drive Live Link
 Gianluca Dianese and Naveen Goswamy can you guys review and improve it.

Eric Houmes will connect with the LF energy guys to see if we can check against standards/information models

More information on LF energy project activity can be found here:, Other examples can be found here.

Topics of last meeting 6 August 2020 16:00 CEST were


  • Getting to know each other better as we had a couple of new contributors.
  • Express the main interests and topics to address
  • Confirm the main goal of our data architecture stream which is Interoperability and semantic standards to help interaction, 
  • Issues that might have to be solved to be successful (like Legal issues (intellectual property ownership), specific local rules that apply. 
  • Next steps data architecture document, work together on this document in next sessions to finalize a first set we work with.
  • Data architecture project support was not a topic for today 


Welcome to the LF Energy Data Architecture Working Group!

Topics for further discussion:

Meeting 6 August 16:00 CEST


  • Modernising Energy Data Access (MEDA) (Robbie Morrison?)
  • Next steps data architecture document
  • Data architecture project support: ? 
  • August 6, 2020 - follow soon

Active Members

Working Documents

Data Architecture Working Document