http://regen.network is not a good IRI prefix

[aaronc]

I'm noticing that most of our SHACL files use http://regen.network/ as their prefix.

Although it is not required that the referent of an IRI is dereferencable, it would be nice. The current design would make this pretty hard.

I propose we switch all prefixes to something that can be dereferenced. We can use https://schema.regen.network as the base URI and then for each SHACL file we should think about what its base URI would be. For instance if we published this repo to https://schema.regen.network and then downloaded shacl/common.ttl, all of the entities in that document should have the prefix https://schema.regen.network/shacl/common.ttl# (I'm not saying we adopt this structure however).

Let's think through how we structure our IRIs with this in mind.

[aaronc]

A couple alternatives could be:

• merging various SHACL .ttl files into a single one so we have something like https://schema.regen.network# instead of https://schema.regen.network/shacl/common.ttl#
• doing this sort of merge and returning it at http://regen.network when the HTTP Accept header is text/turtle. Unfortunately we can't do this with the current http://regen.network/ prefix, but it would have worked if we had chosen http://regen.network#

[wgwz]

Hey @aaronc 👋 one thing i wanted to point out is that typically it seems that prior to deploying a schema to a domain, concatenation of all turtle files generally happens, and the output is single file with all definitions. you can see this for example in the “shacl_validate.py” script. we used a CLI tool from the apache jena software called “riot” to do that. it’s specifically designed for combining multiple schema files.

[wgwz]

Please add your planning poker estimate with Zenhub @blushi

[wgwz]

Per slack convo's it seems like we might prefer to go with this option:

https://schema.regen.network#