Need at least one documentation source

[WesIngwersen]

We need to add at least one documentation source so that users can find documentation

[WesIngwersen]

The upstream datasets should also have a documentation source that is perhaps separate if available

[WesIngwersen]

@jump2conclusionsmatt I started a metadata_fixes branch for working on these different issues with the metadata tag

[bl-young]

Flagging this so we can make sure the upstream models use the same source. @dannyhage

We have sources for both coal and gas - but it might make sense to generate them (and their UUIDs) with the code instead.

[m-jamieson]

Someone please correct me if I'm wrong, but there doesn't appear to be any examples for entering openLCA "sources" correct? The request is to add these? This might take some work - will need to structure the data correctly within process_metadata.yml and then correctly implement it within process_dictionary_writer.py.

If openLCA "sources" aren't needed, I tried to provide links to data sources within the metadata text.

@WesIngwersen @bl-young

[bl-young]

I'm not familiar with a way to access sources within a process for the ipc. But it does look like you can create a source and add it to a json.

[bl-young]

Sorry looks like I was wrong: http://greendelta.github.io/olca-schema/html/ProcessDocumentation.html

[m-jamieson]

I think it'll be alright. olca_jsonld_writer has a way to generate sources already. I just need to find a clean way to add the sources in the yaml, so that they can be created in jsonld.

[m-jamieson]

Alright - this has been started. See process_metadata.yml for an example source. Anyone have real strong feelings about this format? Seems fairly straightforward. There are some changes in process_dictionary_writer and olca_json_ld_writer as well. Hopefully the changes to _source don't break anything. It appears to not ever be used, more specifically, no processes ever have "publication" defined.

[WesIngwersen]

@jump2conclusionsmatt Looks great in process_metadata.yml. Ideally the publication field would only be used when it has the primary documentation to describe that particular process. It's probably more valuable than the Sources field which doesn't necessary suggest exactly how those Sources are used.

[m-jamieson]

I added the rest of the sources. I was able to run ELCI without failures, so it seems okay. The one thing @WesIngwersen that I wanted to point out was the inclusion of the draft eLCI manuscript as a source. I know we had always intended to include documentation in the manuscript about some of these technologies that aren't well documented already (e.g., solar PV, wind). I don't know how you feel about that: (link to example)

[WesIngwersen]

@jump2conclusionsmatt Yes this is fine - we need to make sure we have documentation of the work somewhere and that was one intended source of it. I was hoping to get some more support to finish that..it is well on its way and hope we can find a way to complete it

[m-jamieson]

Was this kept open because there aren't sources for the technologies or various mixes? I added the eLCI manuscript as the default source to cover this. The one exception that I thought there might be is the eGRID-based consumption mix. @bl-young - didn't Troy have a manuscript for this? Can you post that info here or add it to process_metadata.yaml?

[hottleta]

I don't know what the preferred documentation would be but there are several publications in the works, I have been working with @TJTapajyoti to get the trading methodology submitted.

[m-jamieson]

Similar to this, I would just mark it as in preparation and put today's years and an author list. Just to give people the idea that documentation is in works somewhere. If it changes down the line, we can just update the metadata. So I just need a working title and authors I guess.

[WesIngwersen]

@hottleta @jump2conclusionsmatt Closing this issue for now as Matt put a temp reference in for the Hottle trade methodology in this commit