Schema.regen.network browser & RDFS Ontology POC

clevinson commented 1 year ago

Description

This PR sets up a basic ontology file in rdfs/regen.ttl and a corresponding next.js application that can be used to render and explore an RDFS ontology for RDF datasets and standards used within Regen Network.

To run locally:

cd schema-www
yarn install
yarn dev

Warning: Most of this code was written in collaboration with chatGPT, this is my first time coding a next.js app, or using tailwind. Please forgive me if there are antipatterns in this PR, I'll happily research and fix anything that folks point out as a problem or something sub-optimal with the way this code is currently laid out.

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)

aaronc commented 7 months ago

The biggest issue here I think is the usage of RDFS rather than reusing our existing SHACL files. Regardless of the benefits of RDFS vs OWL vs SHACL for this use case, I think we should be starting with the assumption that we're merging all the .ttl files in this repo and then creating a browser for them. If we think we need RDFS or OWL, we should add the relevant RDFS/OWL triples to the relevant .ttl files themselves in addition to the SHACL that's already there. It would be good to hear more of your thoughts on this, however, @clevinson and what your reasoning is for taking this approach.

clevinson commented 7 months ago

This is the slack thread where we were having most discussion around this: https://regen-network.slack.com/archives/C01LX9E8QN8/p1683743649349819

As I understood it, SHACL is a constraints language designed specifically for validating JSON-LD documents, which is similar, but different, from defining vocabularies.

The main example I used in my head was that if we had a property regen:ecosystemType with values a finite set of potential values, there isn't really a clear way to define this in SHACL without bounding the property to a specific object (e.g. a regen:Project or regen:CreditClass). And that we would actually need to define the constraints of ecosystem type on both the regen:Project and regen:CreditClass definitions.

Using something like OWL or RDFS (I think actually only OWL has the ability to express finite set of values for a property), one could actually define the property regen:ecosystemType and then separately say which classes can have this property.

Let me know if you think I'm misunderstanding something here @aaronc

aaronc commented 7 months ago

This is the slack thread where we were having most discussion around this: https://regen-network.slack.com/archives/C01LX9E8QN8/p1683743649349819

As I understood it, SHACL is a constraints language designed specifically for validating JSON-LD documents, which is similar, but different, from defining vocabularies.

The main example I used in my head was that if we had a property regen:ecosystemType with values a finite set of potential values, there isn't really a clear way to define this in SHACL without bounding the property to a specific object (e.g. a regen:Project or regen:CreditClass). And that we would actually need to define the constraints of ecosystem type on both the regen:Project and regen:CreditClass definitions.

Using something like OWL or RDFS (I think actually only OWL has the ability to express finite set of values for a property), one could actually define the property regen:ecosystemType and then separately say which classes can have this property.

Let me know if you think I'm misunderstanding something here @aaronc

So I think this depends on what we actually want to accomplish.

If we want to make it possible for users to look at our documentation and create compliant credit class or project graphs, then what we want to be doing is actually documenting the SHACL constraints for those graphs.

If we just want to descriptively talk about what properties and classes exist and what their potential domains and ranges are, then documenting that with RDFS and OWL (where necessary) makes sense.

I question though how much this descriptive use case actually serves our users. It might actually be more useful to have documentation of how to write JSON-LD that will pass our SHACL constraints. That's a very different undertaking. Ideally we would have a site that does both.

regen-network / regen-registry-standards