search

regen-network / regen-registry-standards

:seedling: RDF and SHACL schemas for Regen Registry
4 stars 1 forks source link

Update VCS project metadata SHACL graph with `sh:group`s #16

Closed blushi closed 2 years ago

blushi commented 2 years ago

Description

Closes: https://github.com/regen-network/regen-registry/issues/909

Needed for front-end validation of project forms. This is based on https://www.figma.com/file/TyhFaXqko9F8OvLEE4Zomg/Issuer-Create%2FEdit-Projects%2C-Credit-Class%2C-Batches?node-id=2%3A4449

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...

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...

blushi commented 2 years ago

Hey @blushi @wgwz, thanks for the patience on my responses as I get back from the conference. I spent some time with @clevinson thinking through how we're structuring metadata for project pages and here are our thoughts.

Generally speaking, the only information we should be storing in our on-chain metadata IRIs are information and relationships we want to query against. Right now the information and outlined in the credit class and credit batch seems pretty straight forward as most users will want to know this like, which methodology is used by a credit class or what the retirement serial number is for a certain batch. For projects it should be similar, and we should only store info want to query against, like the size or location, methodology used, start & end date, etc...

With that in mind, things like images and videos should probably not be included in the metadata IRIs we store on chain. Obviously this adds in some complexity in the way we are currently structuring our SHACL schemas and building our project pages as we've blended much of the info we store off-chain, such as images or geojson files, query-able info we want to store on-chain, like we have here. With that in mind, we might want to take out any non-query-able info from the C01-verified-carbon-standard-project.ttl, so anything in the regen:ProjectPageMediaGroup.

I know this adds on some extra work (possibly outside this PR), but I think it might be best in the long run. Thoughts?

So just to be sure, we only want to pull out from the metadata referenced on-chain everything related to Media, right? What about the project developer profile image?

Right now, all the metadata is stored in the project table metadata column anyway and not referenced on-chain, so I don't believe we need to change the way things work currently. But later on, when we have on-chain projects, we can store only "query-able" info in the metadata_graph table (just as we do currently for on-chain credit class/batch metadata) and keep storing the rest of the info related to media within the off-chain project table. This means we'll need to adapt:

S4mmyb commented 2 years ago

So just to be sure, we only want to pull out from the metadata referenced on-chain everything related to Media, right? What about the project developer profile image?

Hmm, that's a good question. I think maybe not as it's not querable and we want to stay consistent, but it would be much cleaner just to include it the way you have it so I'm split on this one. What do you think @blushi @wgwz ?

On a somewhat related note, during our retreat we talked about introducing DiDs associated with regen addresses where you could "verify" the organization or entity claiming claims against certain actions. There were some ideas circulating about anchoring a a website, twitter, or linkedin profile, to an address to provide some sort of verification of the individual/org on the other end and I'm wondering if where we would put the image in that scenario.

S4mmyb commented 2 years ago

Right now, all the metadata is stored in the project table metadata column anyway and not referenced on-chain, so I don't believe we need to change the way things work currently. But later on, when we have on-chain projects, we can store only "query-able" info in the metadata_graph table (just as we do currently for on-chain credit class/batch metadata) and keep storing the rest of the info related to media within the off-chain project table. This means we'll need to adapt:

  • this project SHACL graph: in particular, I believe we could have one SHACL shape for C01 query-able project metadata and another one for just media data
  • the way we query project data from the project page (we'll need to do this anyway once we have on-chain projects)
  • the project creation form logic to save the query-able metadata in metadata_graph table and the rest in project.metadata

This all sounds good to me

wgwz commented 2 years ago

Hmm, that's a good question. I think maybe not as it's not querable and we want to stay consistent, but it would be much cleaner just to include it the way you have it so I'm split on this one. What do you think @blushi @wgwz ?

@S4mmyb based on what you raised in comments and how @blushi is thinking about that, I think that it makes sense to me. As I was reading Marie's comments, I was thinking that it could be helpful to have on-chain and off-chain versions of these schemas. I just wanted to propose that as a way to phrase the difference.

Also sorry for falling off on the whole C01-project discussion. I'm glad to see we've opened another issue for that. I think I'm missing some understanding on that thread but I guess we can discuss further as we handle this new task (https://github.com/regen-network/regen-registry/issues/941)

S4mmyb commented 2 years ago

Hmm, that's a good question. I think maybe not as it's not querable and we want to stay consistent, but it would be much cleaner just to include it the way you have it so I'm split on this one. What do you think @blushi @wgwz ?

@S4mmyb based on what you raised in comments and how @blushi is thinking about that, I think that it makes sense to me. As I was reading Marie's comments, I was thinking that it could be helpful to have on-chain and off-chain versions of these schemas. I just wanted to propose that as a way to phrase the difference.

Also sorry for falling off on the whole C01-project discussion. I'm glad to see we've opened another issue for that. I think I'm missing some understanding on that thread but I guess we can discuss further as we handle this new task (regen-network/regen-registry#941)

Great point @wgwz! I think this dovetails too on some of the stuff we were talking about as it relates to the keplr login and user profiles. Let's maybe discuss this in the architecture call?

wgwz commented 2 years ago

@S4mmyb sounds good! i'll be sure to add a topic for this.