search

obophenotype / ncbitaxon

Build for NCBITaxon
BSD 3-Clause "New" or "Revised" License
25 stars 7 forks source link

Plan on regular (scripted?) releases? #13

Open bjonnh opened 6 years ago

bjonnh commented 6 years ago

Is there any plan/idea/need to get this updated on a regular basis?

cmungall commented 6 years ago

It's been 4mo, so I manually triggered another release https://build.berkeleybop.org/job/build-ncbitaxon/

in principle nothing stopping us automating this. In theory the manual process allows us to check for diffs and send any warnings if major changes have happened, in practice no one has time for this.

thoughts @pmidford @balhoff @jamesaoverton?

jamesaoverton commented 6 years ago

Automated releases are a good idea. We'd need some basic checks for breakage.

The upstream data we use is updated every week, I believe. At IEDB we refresh the taxonomy for each of our weekly builds.

General comments: At IEDB we don't use this OWL file -- I have custom code that works with the source data directly to build the subsets we need. Just the size of the taxonomy makes simple things hard when working directly in OWL. Changes to the taxonomy are often significant and frequently cause trouble for us at IEDB. We don't currently have good tools for diffing, visualizing, and assessing changes. I'm hoping my Knotation stuff can help with this, when it's ready.

cmungall commented 6 years ago

Just noting an area where frequent updates typically cause problems

We use the taxslim release with disjointness axioms added: http://purl.obolibrary.org/obo/ncbitaxon/subsets/taxslim-disjoint-over-in-taxon.owl

When we accidentally end up super-imposing two versions, the result has unsatisfiable classes. This can happen when we mix a robot-derived import chain with the full release, as these may not be in sync.

I don't think we should hold up releases based on this but I think this problem may affect others

pmidford commented 6 years ago

Perhaps run the automated release more often, but do a manual release less frequently (6 months, 1 year) or if someone reports a problem like the one you mentioned with disjointness.  I'm not using the NCBI release at the moment, but I expect I will be using it again sometime in the coming year or so.

On 07/30/2018 03:07 PM, Chris Mungall wrote:

Just noting an area where frequent updates typically cause problems

We use the taxslim release with disjointness axioms added: http://purl.obolibrary.org/obo/ncbitaxon/subsets/taxslim-disjoint-over-in-taxon.owl

When we accidentally end up super-imposing two versions, the result has unsatisfiable classes. This can happen when we mix a robot-derived import chain with the full release, as these may not be in sync.

I don't think we should hold up releases based on this but I think this problem may affect others

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/obophenotype/ncbitaxon/issues/13#issuecomment-409027751, or mute the thread https://github.com/notifications/unsubscribe-auth/AAX3jnTolEfr5Yn6YFTFrz9DGWaqZhpHks5uL4OPgaJpZM4Vksay.

cmungall commented 6 years ago

The fix for the disjointness superimposition problem (which manifests in either automated or manual release) is for us all to adopt better import practice, we hope this will be implemented in the next month or two https://github.com/balhoff/ultimate-ontology-makefile

cmungall commented 5 years ago

We should also run integration tests with each release.

https://github.com/INCATools/ontology-development-kit/issues/118

For now, we could do against GO, CL, Uberon as these are where taxon constraints are most widely applied and hence most likely to yield incoherency on a new release. We can add OBI and others too but not sure how sensitive they are to minor changes higher up.