so I don't actually know how it selects the shape for validation
do you plan to load all incf/neuroshapes to staging?
Can you provide us with the identifier of the schema you want to use
?
and why the context of the data is so long ?
The one you point to above is no longer accessible.
SubCellularModelScriptShape
I suggest you work in staging
there are no incf schemas in staging
who should load them there?
at the moment I'm trying hbp nexus
This schema is in a protected area but only imports https://nexus.humanbrainproject.org/v0/schemas/neurosciencegraph/simulation/modelscript/v0.1.0
I think the problem is (as you've mentioned) that the schema you're referencing to does not contain the targetClass definition. It therefore doesn't match any shapes and the reported error is correct. I think the only way to solve this is to change the schem
would it be possible to wipe those? Or there is already data there?
This is how modelScript was modelled during the Hackathon:
- Entities of type nsg:MEModel (in neurosciencegraph/simulation/memodel) or nsg:SubCellularModel (in /neurosciencegraph/simulation/subcellularmodel) have a nsg:modelScript which should respectively conform to neurosciencegraph/simulation/modelscript/v0.1.0/shapes/EModelScriptShape and neurosciencegraph/simulation/modelscript/v0.1.0/shapes/SubCellularModelScriptShape.
We omit to propose a way to submit entities of type nsg:ModelScript. We’ll need to update the schemas and bumped the version
sorry @genric
Hm - I get your point, but since Nexus does not allow us to "unpublish" a schema (for good reasons) it only works that way. I'm not really sure if updating the version number for the whole domain is a good idea - you will create new versions for many schemas that stay identical. This requires an unnecessary data migration (I'm aware that as long as the input source is a single script, this is not too painful - but as soon as there are multiple sources providing data it will be). For me, this is a typical minor-version/bugfix change -> v0.1.1.
@genric to really answer question: We potentially could wipe it for now (since we have everything reproducible) - but I'm sure, similar issues will arise at some point when it's not possible to wipe anymore and I think we should discuss and practice this... :)
My hope was that I try these schemas in sort of sandbox env before stabilizing them and publishing to prod
Ok - What we can do is to provide the "non-tested" schemas in our integration environment first - but that would mean that we would have some kind of staging in the INCF gitrepo - like having a branch "integration" where they live until it's sure they are working, and then moved to master (where they are fetched for the production instances)
nevertheless we need to discuss versioning strategies
@genric - I agree - this is a complex topic and it would be good to have a common understanding
INCF/neuroshapes#53
The idea is as follows:
- we should provide relevant defaults for people to use. I think of ontology terms from NIFSTD (We can add relevant ontologies that HBP and BBP are using)
- we should allow users to use their own ontology term
- we should allow users that don’t have ontology terms ot still be able to use the schemas
We should avoid global constraint on the schemas at INCF/neuroshapes and enable each data integration/curation team platform enforce the ontologies they want.