BlueBrain/nexus-schemas

genric

@genric

ok, let's try this tomorrow

genric

@genric

yep, got same error on hbp nexus: 'violations': ['No data was selected for validation']}

Mohameth François SY

@MFSY

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.

genric

@genric

https://bbp-nexus.epfl.ch/dev/v0/schemas/neurosciencegraph/simulation/modelscript/v0.1.0

SubCellularModelScriptShape

Mohameth François SY

@MFSY

I got an ‘Application is not available’. I think dev is no longer available

I suggest you work in staging

genric

@genric

yep

there are no incf schemas in staging

who should load them there?

at the moment I'm trying hbp nexus

over here: https://nexus.humanbrainproject.org/v0/schemas/brainsimulation/simulation/modelscript/v0.1.0

Oliver Schmid

@olinux

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

genric

@genric

yep, I'm half way making those changes :) just wanted to be sure I'm on the right track

Oliver Schmid

@olinux

Ok. Please make sure, you create a new version of the schema - otherwise we will not be able to reimport it to the HBP nexus (since the old one is already published)

genric

@genric

well :) I was hoping to avoid that

would it be possible to wipe those? Or there is already data there?

Mohameth François SY

@MFSY

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

genric

@genric

I'm not too much in favor of having versions diverge in the simulation domain

Mohameth François SY

@MFSY

Me neither. We just need to bump all the versions of the different schemas at the same time.

genric

@genric

ok, I'll make a pull request soon

Oliver Schmid

@olinux

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

Oliver Schmid

@olinux

since we're using semantic versioning, it could be interesting though to have an alias for schemas in nexus -> so you could upload/read from v0.1.LATEST ;)

genric

@genric

Well, there pros/cons to have version bump in lockstep for domains or have only patch bump for specific ones

My hope was that I try these schemas in sort of sandbox env before stabilizing them and publishing to prod

Oliver Schmid

@olinux

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)

genric

@genric

but unless they are published there is no way to try them :) workbench tests are good but I think they don't cover all possibilities

Oliver Schmid

@olinux

This would also mean that we would wipe and re-instantiate the integration environment on a regular base.

genric

@genric

this sound great, it will minimize the version bumping

nevertheless we need to discuss versioning strategies

Oliver Schmid

@olinux

@MFSY what do you think about having some staging in INCF? I think it's crucial because we have to be sure that a schema in master is final.

@genric - I agree - this is a complex topic and it would be good to have a common understanding

Mohameth François SY

@MFSY

Let have a meeting and discuss all of this. I set up one.

Oliver Schmid

@olinux

:thumbsup: thanks!

Andrew Davison

@apdavison

I'm unclear how things work with the various OntologyTermShapes. For example, with the SexOntologyTermShape, I guess somewhere there should be something that specifies the possible values for validation, e.g. "male", "female", but I don't see where that is.

Mohameth François SY

@MFSY

Hi @apdavison ,

I’ve opened while ago an issue on INCF/neuroshapes describing (proposing actually) a way to handle ontologies

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.

Mohameth François SY

@MFSY

I think the strategy is quite generic (unless objections). I would suggest we identify relevant defaults that both HBP and BBP use in term of brain regions, brain parcels, species, strains, cell types ….. and add those in the ontology term shapes

Mohameth François SY

@MFSY

For the sex ontology terms we can start by this:

{
      "@id": “this:SexShape",
      "@type": "sh:NodeShape",
      "or": [
        {
          "label": "The expected sex value is an ontology/vocabulary term: identified by an IRI.",
          "node": "{{base}}/schemas/neurosciencegraph/commons/labeledontologyentity/v0.1.0/shapes/LabeledOntologyEntityShape"
        },{
          "label": "The expected sex value is from a specific sex term from an ontology: identified by an IRI.",
          "node": "{{base}}/schemas/neurosciencegraph/commons/typedlabeledontologyterm/v0.1.0/shapes/SexOntologyTermShape"
        },{
         "label": "The expected sex value is a free plain text taken from a controlled list of values.",
          "datatype": "xsd:string”,
“in”:[“male”,”female”]
        }
      ]
    }

Tell me if this works for you

Andrew Davison

@apdavison

Thanks, I had seen that issue, but forgotten about it.
For context, I'm thinking about automatically populating a drop-down list in a GUI.

I was thinking that the IRI of the ontology could be specified as part of the constraint, and then the GUI could go fetch the list of valid ontology terms.

Where communities thrive

People

Repo info

Activity