ILCD-formatted process names

[dt-woods]

In an effort to move closer to openLCA best practices and FLCAC metadata compliance, I propose updating process names for the electricity baseline.

The ILCD format is as follows:

Base name; treatment received, production route(s), standard(s) fulfilled; production or consumption type, location type; quantitative flow properties

Electricity baseline process names come in a few different formats (see examples below).

• "base name"
  • (e.g., nuclear fuel extraction, processing, and transport)
• "base name" - "treatment"
  • (e.g., coal extraction and processing - Central Appalachia, BIT, Processing)
  • (e.g., petroleum extraction and processing - DFO PADD 1)
• "base name" - "fuel type" - "location"
  • (e.g., Electricity - BIOMASS - Arizona Public Service Company)
  • (e.g., power plant construction - coal_const - Arizona Public Service Company)
• "base name"; "standard"; "treatment" - "location"
  • (e.g., Electricity; at grid; consumption mix - US)

Thoughts or considerations on representative ILCD style names?

[m-jamieson]

I'm generally okay with moving towards the FLCAC standards. I think my main concern here is the changing of UUIDs and possibly breaking models that relied on the old naming convention for default providers, etc.

[pweiler22]

From a FLCAC metadata/curation perspective this would be a nice improvement. We are in the process of making these naming changes in USLCI for both flows and processes so this would help with consistency. I agree with your interpretation of the ILCD guidance. As long as the UUIDs stay consistent then this shouldn't affect the current use of eLCI in openLCA databases but I'm not familiar with the other use cases outside of openLCA.

[dt-woods]

One way to maintain UUIDs across process name changes would be to add them to our metadata YAML. These could be read during the process generation step to ensure they stay the same. Or we update the UUIDs one last time (since we just updated them for v2 of eLCI), and stick with them as associated with ILCD naming scheme, and assist any other models when it comes time for them to upgrade their electricity.

My understanding is that default providers are based on UUIDs, and that the "prefer" default providers will read across process with the correct quantitative reference flow, not so much the process name. Newly named processes with updated UUIDs should still show up in the drop-down in openLCA as a potential provider.

[dt-woods]

Another option would be to post-process the names to ILCD format. Could be a parameter to add to the configuration files. That way the UUIDs don't change, as they are set on the original naming scheme.

[m-jamieson]

It's not so much the use cases outside openLCA, that someone out there may be using the process "natural gas extraction and processing - Appalachian" in their own model of a natural gas power plant for example. Their expectation that downloading a new version of the electricitylci with a known update to that process would replace the existing process and they would get the new inventory. If the process name changes, the unit process doesn't get updated because openLCA can't determine that the old process should be replaced by the new process "natural gas; extraction through transmission; Appalachian; US" or whatever the final name will be.

Or in another instance, they may import a process that has a differently named default provider in a database with a revised naming convention, and the process won't automatically connect. I'm actually not 100% sure how default providers work when importing processes via JSON-LD, so maybe this isn't even a valid concern.

I don't know if even having the same UUID with differently named processes will prevent some of these things happening because I can't remember all the things openLCA checks against when determining whether a process needs to be updated vs just adding a new process.

I bring all this up just as something to consider. In the end, it may be worth these risks to implement this standard naming convention. It probably is.

[dt-woods]

Good point on versions of processes. Pretty sure (as far as JSON-LD, and extended to derby database), the unique key is the UUID. If the UUIDs match, the version numbers are compared to see which to keep (e.g., replace with the latest version is an option when importing datasets into openLCA). I think if we keep versioning up our processes with eLCI, then users would know which is the latest, and which are older.

[dt-woods]

First draft of ideas for ILCD-formatted process names

Current Name	ILCD Name
nuclear fuel extraction, processing, and transport	Uranium fuel extraction, processing, and transport; beneficiated, in-situ leaching; United States
coal extraction and processing - Central Appalachia, BIT, Processing	Bituminous coal extraction and processing; underground mining; Central Appalachia
power plant construction - ngcc_const - Arizona Public Service Company	Natural gas power plant construction; combined cycle, 50 MW capacity; Arizona Public Service Company
Electricity; at user; consumption mix - US	Electricity grid mix; consumption mix, at user, United States; 120 V, AC
Electricity - COAL - Midcontinent Independent System Operator	Electricity generation; coal power plant; Midcontinent Independent System Operator; high-voltage

[bl-young]

Good point on versions of processes. Pretty sure (as far as JSON-LD, and extended to derby database), the unique key is the UUID. If the UUIDs match, the version numbers are compared to see which to keep (e.g., replace with the latest version is an option when importing datasets into openLCA). I think if we keep versioning up our processes with eLCI, then users would know which is the latest, and which are older.

Agree. Everything should update fine for users if the UUIDs are the same.

[bl-young]

First draft of ideas for ILCD-formatted process names

I forget exactly how location objects are used, but recall that if a process has a location associated with it, that location's ID will get appended to the name in the UI. I think ideally the strict name field should not have the location in it?

[m-jamieson]

Hrm, looks like you're right. I guess what we might have is "location type" as "Balancing authority area" for power plants or "natural gas basin" for natural gas, and then providing the shapefiles for those, and specifying those shapes in the process metadata.

That's probably a lot more work than we're ready to do for these near-term releases. Perhaps for now it's best to put this on the list of things to do for a version 3?

[bl-young]

I think its fine to have the location in the name but not if you also have a location object. Otherwise you get "... - US - US - US"

[dt-woods]

Hrm, looks like you're right. I guess what we might have is "location type" as "Balancing authority area" for power plants or "natural gas basin" for natural gas, and then providing the shapefiles for those, and specifying those shapes in the process metadata.

I agree that location type is different than location name. I think that could help address the issue Ben points out. Do we need shapefiles if we are just using the same location names as before (e.g., Bonneville Power Administration)? I mean, we have dated shapefiles if we need them (e.g,. 2020–2022).

[dt-woods]

An outcome of using the ILCD standard without location-specific naming is that we will have a bunch of processes all with the same name:

• Electricity generation; coal power plant; balancing authority area; high-voltage
• Electricity generation; coal power plant; balancing authority area; high-voltage
• Electricity generation; coal power plant; balancing authority area; high-voltage
• Electricity generation; coal power plant; balancing authority area; high-voltage

If they have location entities, then openLCA will courteously append location after the name in the Navigation:

• Electricity generation; coal power plant; balancing authority area; high-voltage - Arizona Public Service Company
• Electricity generation; coal power plant; balancing authority area; high-voltage - Arlington Valley, LLC
• Electricity generation; coal power plant; balancing authority area; high-voltage - Associated Electric Cooperative, Inc.
• Electricity generation; coal power plant; balancing authority area; high-voltage - Avangrid Renewables, LLC

Programmatically, it adds an additional step for us to search the location field to distinguish one process from another.

For the openLCA practitioners, I guess it is more aesthetically pleasing to not have location duplicated. Notably, the provider drop-down in the Inputs/Outputs also appends the location to assist users selecting the correct process.