Metadata standards for CarbonPlus Credit

[clevinson]

Problem Statement

With the first CarbonPlus credits soon to be issued, we should be thinking about how the actual on-chain metadata looks like for the CarbonPlus Grassland credit when we put it on chain. This came up in our blockchain <> Registry sync between myself and @rsteinhe

Approach

One potential solution that I can think of involves using the "metadata" field in the credit class to include a link to the JSON schema representation of the metadata stored on each vintage. Schemas could be hosted on regen.network (as we are the credit designer), or we could put the credit schema directly in the metadata JSON...

Credit Class Metadata

{
  "className": "CarbonPlus Grasslands",
  "url": "http://regen.nework/credits/grassland",
  "issuanceMetadataSchema": "http://regen.network/credits/grassland/issuanceMetadata.json",
}

Credit Class Metadata

Potential fields for what the CarbonPlus Grasslands metadata could actually look like:

- total amount of credits issued in this vintage
- amount of CO2 equivalent sunk in this vintage
- start_time of vintage (baseline)
- end_time of vintage
- geojson polygon of credit vintage area
- carbon stock
  - start_time value
  - end_time value
- cobenefits
  - start_time value
  - end_time value
- project developer (url linking to registry)
- land steward (url linking to registry)

The above will be ironed out in more detail between @rsteinhe and Gisel. Once we have clear requirements, should there be an RFC on regen ledger for aligning on how we do the actual schema?

Data Module

One thing that is missing from here still is how we link credits to the data module. One idea for how to do this is to have a "evidence" field in the issuance metadata, which is an array of JSON objects structred as so:

{
  "cid": [CID],
  "evidenceDescription": "monitoring report for 2019 Wilmot vintage",
  "evidenceType": "pdf"
}

or

{
  "cid": [CID],
  "evidenceDescription": "soil sample from XYZ Lab 2019",
  "evidenceType": "pdf"
}

The one missing piece for me on the above, is where the digital signatures fit into hte picture, and how we actually identify the signer as someone "important" (e.g. that the signature on a given CID comes from a public key controlled by the monitor.

I'm curious if others have different understandings of how this stuff would work. Again, once we get requirements aligned on from the Science team, I think it'd be useful to have a brainstorming session with the engineering team and eventually write up an RFC, thoughts?

[aaronc]

If anyone has time to look into the git history they'll see how I'd started working on stuff for linking together the various documents as an RDF graph using URIs based on the hash/content ID. I know looking through the git history might not be the most efficient way to do this so I'll try to write it up when it's earlier in the day. Or I can walk everyone through the prior work in a call sometime. But TLDR using the RDF graph data model and CID based URIs has been the design since late 2017 even though I rarely talk or write about it (nowadays) and it still seems like an appropriate solution.

[aaronc]

The signature also is dealt with in the data module using SignData. The signer would have a DID like did:xrn:fbeienfiwn64284. That's why there's a : in our bech32 prefix.

[aaronc]

Regarding schema hosting we could reconsider the on chain approach that's in this repository if anyone wants to explore the git history. I'm not sold on the on chain schema registry approach for an MVP, but maybe it makes sense long term when there's mature DAO based governance

[aaronc]

JSON schema also is useful for making web forms. It's not a very good model for linked data. But the two aren't incompatible if you're using JSON-LD. Shack/Shex don't seem quite mature enough to provide a full RDF/linked data solution

[aaronc]

Heres the old RDF based x/schema module: https://github.com/regen-network/regen-ledger/tree/aef7721f6d4eabc08aebce2d926b21507d991864/x/schema. It would replace JSON schema and also Shacl/Shex with something less caught up with RDF's confusing open world semantics.

Also for RDF graphs you wouldn't use raw CIDs (a standard I think we probably don't want to rely on too heavily). The current standard is URDNA2015. But I think we'd want to consider just making a merkle hash instead (#64). Raw CIDs are most useful for PDFs, etc.

[robert-zaremba]

Instead of JSON schema, how about using a proto file?

[robert-zaremba]

Here is a discussion about upgradeability: #193

[robert-zaremba]

We will be creating new issues based on the latest thinking. So this one will be closed once we have new set of tasks.

[ryanchristo]

This is being tracked by the registry team