search

ga4gh / mme-apis

Documentation for the MatchmakerExchange APIs
https://github.com/ga4gh/mme-apis
34 stars 19 forks source link

Figure out how to handle HPO versioning/new terms #52

Closed buske closed 8 years ago

buske commented 9 years ago

The policy group mentioned the issue of new/incompatible HPO versioning between groups, and proposed sending the full set of ancestor terms for each term transferred over the API as a potential solution.

We need to figure out a solution for this.

Relequestual commented 8 years ago

Decipher has since been able to move to the newer version of HPO! However obviously this doesn't solve the problem laid out in this issue.

Is there a Task Team which might have some ideas on this issue? Interoperability between ontology versionins is different to translation between different ontologies.

Relequestual commented 8 years ago

This is similar to https://github.com/ga4gh/mme-apis/issues/51

fschiettecatte commented 8 years ago

The root issue is that HPO does not have a versioning system. GeneMatcher maps from its internal ontology (PhenoDB) to HPO, and mappings are updated from HPO weekly, so if a PhenoDB points to an HPO term that is retired, that will be update to point to the new term. Not perfect but it means that we can resolve all HPO terms that are sent our way.

We could set up a system where every 6 month we declare the current version of HPO to be the one to support (much like the ULMS has two releases a year), but that has issue too.

mellybelly commented 8 years ago

HPO is versioned. please use the versioned IRIs and do not create your own versioning system for HPO. I think a monthly update would be reasonable - we release monthly. For example, use a version IRI such as: http://purl.obolibrary.org/obo/hp/releases/2016-01-13/hp.owl

I’ll work on getting some better documentation up about this.

On Feb 23, 2016, at 12:16 PM, François Schiettecatte notifications@github.com<mailto:notifications@github.com> wrote:

The root issue is that HPO does not have a versioning system. GeneMatcher maps from its internal ontology (PhenoDB) to HPO, and mappings are updated from HPO weekly, so if a PhenoDB points to an HPO term that is retired, that will be update to point to the new term. Not perfect but it means that we can resolve all HPO terms that are sent our way.

We could set up a system where every 6 month we declare the current version of HPO to be the one to support (much like the ULMS has two releases a year), but that has issue too.

— Reply to this email directly or view it on GitHubhttps://github.com/ga4gh/mme-apis/issues/52#issuecomment-187884963.

Dr. Melissa Haendel

Associate Professor Ontology Development Group, OHSU Library www.ohsu.edu/library/ontologyhttp://www.ohsu.edu/library/ontology Department of Medical Informatics and Clinical Epidemiology Oregon Health & Science University haendel@ohsu.edumailto:haendel@ohsu.edu skype: melissa.haendel 503-407-5970 Appointments: Shanez De Silva desilva@ohsu.edumailto:desilva@ohsu.edu

fschiettecatte commented 8 years ago

The page you point to is password protected, can't get to it.

mellybelly commented 8 years ago

will fix, stay tuned- we moved to github and not everything got migrated perfectly, apparently

Relequestual commented 8 years ago

OK, so now at the very least there is a build ID we could use, however an eventual version number via github will be benificial! HOWEVER.

How to obtain the latest version of HPO is not the topic of this issue. That issue is here: https://github.com/ga4gh/mme-apis/issues/41

The question is, how do we, or any entity, handle version missmatch of HPO? Because it will happen. As long as we try to keep mostly up to date (in step with monthly releases), then it shouldn't cause much of a problem, as long as our code expects it.

Personally I feel the main issue was probably with Decipher not being able to move from a pretty old version, but now that has been lifted and we're keeping up to date.

I think this issue is for each database to handle, and isn't an issue we can solve universally. However, I think this raises part of another issue, regarding how we respond to requests with explanaition of what parts of the request were translated to something other than what was sent. AKA https://github.com/ga4gh/mme-apis/issues/84

I'm in favour of closing this issue in preference of #84

antbro commented 8 years ago

well put! +1 T

Ben Hutton wrote:

OK, so now at the very least there is a build ID we could use, however an eventual version number via github will be benificial! HOWEVER.

How to obtain the latest version of HPO is not the topic of this issue. That issue is here: #41 https://github.com/ga4gh/mme-apis/issues/41

The question is, how do we, or any entity, handle version missmatch of HPO? Because it will happen. As long as we try to keep mostly up to date (in step with monthly releases), then it shouldn't cause much of a problem, as long as our code expects it.

Personally I feel the main issue was probably with Decipher not being able to move from a pretty old version, but now that has been lifted and we're keeping up to date.

I think this issue is for each database to handle, and isn't an issue we can solve universally. However, I think this raises part of another issue, regarding how we respond to requests with explanaition of what parts of the request were translated to something other than what was sent. AKA #84 https://github.com/ga4gh/mme-apis/issues/84

I'm in favour of closing this issue in preference of #84 https://github.com/ga4gh/mme-apis/issues/84

— Reply to this email directly or view it on GitHub https://github.com/ga4gh/mme-apis/issues/52#issuecomment-188736324.

fschiettecatte commented 8 years ago

Agreed +1

Relequestual commented 8 years ago

Will await on @buske to +1 and close, as he opened this issue.

buske commented 8 years ago

More than happy to close this. +1 :)