Add sh:closed to the main SHACL shapes

[wgwz]

We should add this snippet to the main SHACL shapes we use for validating classes, batches and projects:

  sh:closed true ;
  sh:ignoredProperties ( rdf:type ) ; 

This says that the only properties allowed in the data graph/JSON-LD are the properties defined in the SHACL shape.
By default, SHACL does not check for extra fields in data graphs.
This will keep our data graphs only containing what is needed.

[ryanchristo]

Where would we use this and what do you mean by the "main" shapes?

I'm wondering if we should be concerned about restricting fields, say for a someone using the registry standards and adding their own custom fields on top, but maybe we don't want to support within this repository in that case. Do you see any potential negative outcomes of doing this?

[wgwz]

I think what I had in mind here, is that for each of main components of our data model (credit classes, credit batches and projects) that are specific to a certain credit (C01-04) we could lock down the "shape" so that if a new field is somehow added to the "ops folder" (the on-chain data) then our SHACL CI check will throw an error. that just means that if someone wants to update the on-chain metadata, they would also have to update the SHACL.

i.e. suppose i wanted to add a new field to the C01 credit class. i would need to edit these two files:

1. the "live" on-chain credit class metadata: https://github.com/regen-network/regen-registry-standards/blob/main/ops/C01/credit-class-metadata/C01-verified-carbon-standard-credit-class.jsonld
2. the C01 SHACL schema: https://github.com/regen-network/regen-registry-standards/blob/main/ops/C01/credit-class-metadata/C01-verified-carbon-standard-credit-class.jsonld

if i didn't update the SHACL schema, the PR i open would be blocked by the SHACL CI check.
i see the main benefit of adding this as a sort of data integrity check for what ends up on chain.
this might be a weak point, but it's stronger in the case where we have a workflow such that we only ever anchor data that's been successfully merged into the main branch of this repo (it's passed our CI check).

I'm wondering if we should be concerned about restricting fields, say for a someone using the registry standards and adding their own custom fields on top, but maybe we don't want to support within this repository in that case. Do you see any potential negative outcomes of doing this?

i can't see any negative outcomes here. because what i'm thinking here is like a restriction on the credit classes (and other metadata) where we're sort of already the steward of. and i guess we're not saying we're not open to modifying these. and also if there was somehow a community credit that wanted to add their own standard here, we're not forcing them to use our schema's. ASIDE from the fact that there are benefits of using our schema's (like pretty credit class pages etc)

[ryanchristo]

Thanks for the explanation.

Yea, maybe we should further discuss on our next architecture call or when @blushi is back. Would also be curious to hear thoughts from @clevinson and/or @S4mmyb.

The restriction seems to be a positive for data integrity but a potential negative for flexibility and efficiency.