by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 05 11:52
    MFSY synchronize #205
  • May 05 11:52

    MFSY on docs

    Updated step-by-step-kg-creatio… (compare)

  • Nov 22 2019 14:01
    MFSY synchronize #205
  • Nov 22 2019 14:01

    MFSY on docs

    Added link (compare)

  • Nov 22 2019 14:00
    MFSY synchronize #205
  • Nov 22 2019 14:00

    MFSY on docs

    Added kg embed (compare)

  • Nov 21 2019 11:21

    MFSY on gh-pages

    updated site (compare)

  • Nov 21 2019 11:20
    MFSY synchronize #205
  • Nov 21 2019 11:20

    MFSY on docs

    Added KG embeddings tutorial (compare)

  • Nov 21 2019 09:05
    MFSY synchronize #205
  • Nov 21 2019 09:05

    MFSY on docs

    Removed relationships.csv (compare)

  • Nov 21 2019 08:40

    MFSY on gh-pages

    updated site (compare)

  • Nov 21 2019 08:29
    MFSY synchronize #205
  • Nov 21 2019 08:29

    MFSY on docs

    Updated create-knowledge-graph.… (compare)

  • Nov 21 2019 08:07

    MFSY on gh-pages

    updated site (compare)

  • Nov 21 2019 03:26
    annakristinkaufmann synchronize #205
  • Nov 21 2019 03:26

    annakristinkaufmann on docs

    Added cell id list to notebook (compare)

  • Nov 21 2019 01:16
    samuel-kerrien synchronize #205
  • Nov 21 2019 01:16

    samuel-kerrien on docs

    Fixed typos and improved messag… (compare)

  • Nov 21 2019 01:08
    samuel-kerrien synchronize #205
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.

Mohameth François SY
@MFSY

Populating a drop down list from a root ontology term referenced in a schema is definitely a main (and nice) use case for this.

The question is which IRI to use for sex for example. The challenge is to find defaults IRIs that are commonly accepted in the community (From NIFSTD). I’m open to suggestion.

If you have IRIs for the sex ontology terms we can add them
even though putting male and female under nsg namespace will not hurt and is perfectly feasible
thoughts ?
Mohameth François SY
@MFSY
Will the following work ?:
{
      "@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  taken from a controlled list of values.",
          “nodeKind": “sh:IRI”,
“in”:[“nsg:Male”,”nsg:Female”]
        }
      ]
    }
Andrew Davison
@apdavison
I'm having problems with the ProtocolShape defined here (the old "No data was selected for validation" error): https://github.com/INCF/neuroshapes/tree/master/modules/core/src/main/resources/schemas/neurosciencegraph/core/protocol
and I note that there are no test data for this schema. Would it be possible to add some tests for this? I can then probably figure out where I'm going wrong.
Also to note there is a typo in the HadProtocolValueShape: "sh:PropetyShape"
Mohameth François SY
@MFSY
Hi Andrew
I’ll add the test

What version of neurosciencegraph/core/protocol are you using ?

But a "No data was selected for validation” issue is usually caused by a type difference between the submitted instance ( the protocol in your case) and the targetedClass in the schema.

Mohameth François SY
@MFSY

Also to note there is a typo in the HadProtocolValueShape: "sh:PropetyShape”

indeed

Mohameth François SY
@MFSY

HadProtocolValueShape is fixed:

INCF/neuroshapes#85

Andrew Davison
@apdavison
@MFSY I still can't get Protocol (or the new ExperimentalProtocol) working. When you have time, it would be really helpful to see a test for these shapes.
Mohameth François SY
@MFSY
Thank you for reporting this
I’ll have a look today and generate some tests for those
It would help a lot to see the type of errors you get
Mohameth François SY
@MFSY
There is a new version of the protocols shapes in review INCF/neuroshapes#172. We’ll add the tests there.
Mohameth François SY
@MFSY
The PR is now merged.