Unified DOSDP template

[hkir-dev]

In relation with issues #97 created unfied dosdp templates. Major changes are:

• brainCellRegionMinimalMarkers.yaml, taxonomy_class.yaml, taxonomy_equivalent_class.yaml and taxonomy_minimal_markers.yaml merged to taxonomy_class.yaml
• CCN202002013_class.tsv splitted into two tables: automatically rolled CCN202002013_class_base.tsv and manually curated CCN202002013_class_curation.tsv

@shawntanzk I merged your updates to CCN202002013_class.tsv. But since this file not exist now, can you double check if your updates exists in the new CCN202002013_class_curation.tsv

[shawntanzk]

@hkir-dev just checked, the two changes I made are present in the new file :) thanks

[hkir-dev]

By the way, CI is failing because we are using a custom DOSDP & ODK version in this branch.

[dosumis]

By the way, CI is failing because we are using a custom DOSDP & ODK version in this branch.

Is this due to ODK not using the latest DOSDP release? Can this be fixed.

Looking at output - it might be a genuine error:

ValueError: Configuration schema validation failed: Additional properties are not allowed ('Ensemble_data' was unexpected)

Ensemble_data can't be a valid key in the new schema. Can the DOSDPs by checked manually with the new validator?

[dosumis]

Ahh.- just realised this looks like validation of taxonomy metadata files, not DOSDPs. Investigating further.

[hkir-dev]

Ahh.- just realised this looks like validation of taxonomy metadata files, not DOSDPs. Investigating further.

Yes, I added Ensemble_data to taxonomy config, but didn't updated the schema. Fixig it now

[dosumis]

Yes, I added Ensemble_data to taxonomy config, but didn't updated the schema. Fixig it now.

Makes sense. We should discuss key naming though - in case this ends up not being limited to ensembl as a source. Maybe reference_gene_list. @shawntanzk - any opinions on naming this?

[hkir-dev]

While checking this config issue I saw that in Human and Marmoset non_taxonomy_roots we defined Location_relation.

Now we only support Location_relation in Root_nodes (such as part_of/has_soma_location <Brain_region>). Should we add a similar logic to non_taxonomy_roots?

[shawntanzk]

Makes sense. We should discuss key naming though - in case this ends up not being limited to ensembl as a source. Maybe reference_gene_list. @shawntanzk - any opinions on naming this?

We will have separate reference gene lists for marmoset humans and mouse right? I think name needs species on it.

Now we only support Location_relation in Root_nodes (such as part_of/has_soma_location <Brain_region>). Should we add a similar logic to non_taxonomy_roots?

what did we do for mouse non_taxonomy_roots? do they not have that relation?

[hkir-dev]

what did we do for mouse non_taxonomy_roots? do they not have that relation?

No, mouse non_taxonomy_roots don't have Location_relation. I can comment out them if OK for you.

[dosumis]

what did we do for mouse non_taxonomy_roots? do they not have that relation?

Nope. Because we don't create data driven classes for them, or use the graph under them for adding axioms, so not needed.

[shawntanzk]

Oh, just took a look at it, yeah in that case, can just remove the relation for non_taxonomy_roots - sorry about that

[hkir-dev]

Oh, just took a look at it, yeah in that case, can just remove the relation for non_taxonomy_roots - sorry about that

I removed them, thanks.

[hkir-dev]

Fixed the config issue. Now CI error is related with our custom dosdp version as expected (multi_clause is still not a valid construct).

JSON does not conform to DOS-DP schema for pattern file at ../patterns/dosdp-patterns/taxonomy_class.yaml

DOSDP zero2many pull request is still pending for merge: INCATools/dosdp-tools#349

Before the ODK release we need a merged DOSDP release.