feat: project metadata separation

Description

Closes: https://github.com/regen-network/regen-registry/issues/1420 Closes: https://github.com/regen-network/regen-registry-standards/issues/35 Closes: https://github.com/regen-network/regen-registry-standards/issues/25

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and please add links to any relevant follow up issues.

I have...

[ ] provided a link to the relevant issue or specification
[ ] reviewed "Files changed" and left comments if necessary

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add your handle next to the items reviewed if you only reviewed selected items.

I have...

[ ] confirmed all author checklist items have been addressed
[ ] reviewed code correctness and readability
[ ] reviewed documentation is accurate
[ ] manually tested (if applicable)

hey @S4mmyb 👋 i just wanted to loop you in on a question that has come up while @blushi and i were reviewing these changes. the question is should we include an @id field in the project metadata? i'm going to try to explain why we asking this question.

when i was writing up the new project page/unanchored project metadata, it bothered me that there was no reference to a project id. without a project id, when you look at the JSON document for a project page independently, you are left wondering, well which project is this for? i think that this document should be more self-describing, so that's why i proposed an addition here.

@blushi made the suggestion that we could use the @id property and provide the project id in the form of a URI. this is nice because it provides a link between an unanchored project metadata and the on-chain project.

now we are wondering if we should do the same in the anchored project metadata. because the anchored metadata also has no reference to the on-chain project id. this would mean that both the project and project page metadata would have a link to the same node in our graph. here are some minimized examples:

A project page/unanchored project with an @id field (note the nice URI):

{
  "@context": {
    "schema": "http://schema.org/",
    "regen": "http://regen.network/",
    ...
  },
  "@type": "regen:Project-Page",
  "@id": "https://app.regen.network/project/C01-002",
  ...
}

Here is what we are thinking about adding to the project/anchored metadata:

{
  "@context": {
    "schema": "http://schema.org/",
    "regen": "http://regen.network/",
    ...
  },
  "@type": "regen:C01-Project",
  "@id": "https://app.regen.network/project/C01-002",
  ...
}

@blushi and i like the idea of adding this from the perspective of a more complete graph. but @blushi pointed out that this means that when we are creating a new on-chain project, from the perspective of the UI, we would need create the on-chain project first because we are depending on the incremented project id in the metadata now. so it's a bit awkward because we would need to sign two transactions to include the project id in the on-chain project metadata.

curious to hear your thoughts!

hey @S4mmyb 👋 i just wanted to loop you in on a question that has come up while @blushi and i were reviewing these changes. the question is should we include an @id field in the project metadata? i'm going to try to explain why we asking this question.

when i was writing up the new project page/unanchored project metadata, it bothered me that there was no reference to a project id. without a project id, when you look at the JSON document for a project page independently, you are left wondering, well which project is this for? i think that this document should be more self-describing, so that's why i proposed an addition here.

@blushi made the suggestion that we could use the @id property and provide the project id in the form of a URI. this is nice because it provides a link between an unanchored project metadata and the on-chain project.

now we are wondering if we should do the same in the anchored project metadata. because the anchored metadata also has no reference to the on-chain project id. this would mean that both the project and project page metadata would have a link to the same node in our graph. here are some minimized examples:

A project page/unanchored project with an @id field (note the nice URI):
{
  "@context": {
    "schema": "http://schema.org/",
    "regen": "http://regen.network/",
    ...
  },
  "@type": "regen:Project-Page",
  "@id": "https://app.regen.network/project/C01-002",
  ...
}
Here is what we are thinking about adding to the project/anchored metadata:
{
  "@context": {
    "schema": "http://schema.org/",
    "regen": "http://regen.network/",
    ...
  },
  "@type": "regen:C01-Project",
  "@id": "https://app.regen.network/project/C01-002",
  ...
}
@blushi and i like the idea of adding this from the perspective of a more complete graph. but @blushi pointed out that this means that when we are creating a new on-chain project, from the perspective of the UI, we would need create the on-chain project first because we are depending on the incremented project id in the metadata now. so it's a bit awkward because we would need to sign two transactions to include the project id in the on-chain project metadata.

curious to hear your thoughts!

Hey hey, sorry for the late comment! I totally agree putting the project ids in the schemas make a lot of sense and honestly I'm surprised we didn't think of it sooner! I think the changes you have right now look great and we should move forward with them. In terms of how we operationally include the projectID field in the anchored and unanchored JSON-LD files I think we can really take two approaches:

Add the projectID to the metadata prior to instantiation. In this scenario the credit issuer would need just need to look at what the next projectID would be (as it auto-increments) and add it to the metadata before calling create-class-project. Though this doesn't seem like the ideal solution, I actually don't think it would be that big an issue because project creation is permissioned and we really won't have projects coming online frequently enough to potentially have conflicts. If we did we could always fix it with the update-class-metadata call.
Create the project on-chain without the ID field, then perform an update-class-metadata call.

I think either approach works and we can really choose which ever we prefer as I think we will be custodially managing the registration and metadata creation processes in the short term. In the longer run I would say we do option 2 and manage the experience creatively through our user story experience, though I'm not fully sure what that would look like. Thoughts @wgwz @clevinson @blushi

Hey hey, sorry for the late comment! I totally agree putting the project ids in the schemas make a lot of sense and honestly I'm surprised we didn't think of it sooner! I think the changes you have right now look great and we should move forward with them. In terms of how we operationally include the projectID field in the anchored and unanchored JSON-LD files I think we can really take two approaches:

Add the projectID to the metadata prior to instantiation. In this scenario the credit issuer would need just need to look at what the next projectID would be (as it auto-increments) and add it to the metadata before calling create-class-project. Though this doesn't seem like the ideal solution, I actually don't think it would be that big an issue because project creation is permissioned and we really won't have projects coming online frequently enough to potentially have conflicts. If we did we could always fix it with the update-class-metadata call.

Create the project on-chain without the ID field, then perform an update-class-metadata call.

I think either approach works and we can really choose which ever we prefer as I think we will be custodially managing the registration and metadata creation processes in the short term. In the longer run I would say we do option 2 and manage the experience creatively through our user story experience, though I'm not fully sure what that would look like. Thoughts @wgwz @clevinson @blushi

To follow up on that conversation and share the recent discussions I had with @wgwz and @clevinson about that: This might be challenging to implement for C03 projects that are created automatically from the bridge service. Quoting Cory here:

I think we can at best say that this is optional. It doesn’t seem possible to reliably add this as part of auto generated metadata on the bridge service Also of note- we did discuss indexing onchain data into Apache Jena in rdf format during our offsite so I think long term we may actually be able to get this info in sparql queries without having the project ID in the project metadata dataset explicitly

cc/ @S4mmyb

regen-network / regen-registry-standards