create annotation property for a scheduled obsoletion

[cmungall]

• Label: 'scheduled for obsoletion on or after'
• Def: Used when the class or object is scheduled for obsoletion/deprecation on or after a particular date
• Range: xsd:date

We need this in GO: https://github.com/geneontology/go-ontology/issues/15532

[cmungall]

This would enable:

• A page e.g in ontobee that shows a list of all scheduled obsoletions
• Creation of reports of where inter-ontology terms used in logical definitions may be obsoleted, e.g. in robot @jamesaoverton @balhoff

[cmungall]

Any comments on this?

[mcourtot]

I had a thought about this but didn't manage to write it down quite as coherently as I'd like. Oh well, here are a few comments:

1. Timeliness Do we anticipate editors will add this to classes, format it properly, make a release, it will be reloaded (ontobee/ols...) in time? (most absolution occurs within 2 weeks AFAIK)
2. Usefulness The only resource I know that is very diligent about absolution is GO, and the current system of sending notice email is I think more efficient in terms of notifying people. I'm not sure users would periodically check an ontobee page.
3. Checks 2 options:
   • the terms that was due to be obsoleted is not actually obsoleted on the chosen date. The absolution may be postponed, canceled, or has been forgotten. What do we expect? An automated reminder? As per the comment above there may be term2 flagged for obsoletion by robot - does this get double checked or will we deprecate that external term and create an issue?
   • the term that was due to be obsoleted is obsoleted. How do we ensure timeliness of reload on ontobee/ols

In short, I'm not objecting to this but I'm not convinced of the usefulness given the time it usually takes to make edits and the need we'd have to keep different systems in sync. I'm happy for the term to be created, just wanted to start discussion.

[cmungall]

1. I'll train people to use YYYY-MM-DD! we'll have a dev triplestore that is loaded nightly in GO, or it could be a robot query that runs on individual ontologies at a CI job. Could be done when making import chain. The GO limit is arbitrary, I think we should extend/contract depending on the case at hand.
2. good point, but trying to instigate a culture change elsewhere. For the uberon/cl/go axis I have previously mentally managed the process. Managing multi-ontology imports is generally very problem fraught with issues. We're getting better. Robot will now warn if you are referencing a deprecated class in your axioms. We can extend it to give you a warning.
3. No need for automated reminders. I think the source ontology should be free to postpone/cancel. It should link to a github ticket, so people can watch that if they want in the weeds updates.

all good points thx. The goal is to make this work beyond GO and have good practice across obo

[mcourtot]

sounds good. do we have an AP for link to GH? I think we discussed this in the past, not sure it was implemented.

[cmungall]

do we have an AP for link to GH? I think we discussed this in the past, not sure it was implemented.

33 - I made it right after this one :-)

[mcourtot]

and look at that, I had already commented too ;)

[drseb]

Hey. Is this AP now only in GO? Can you give us a hint how to use this AP in HPO as well? Clone your strategy?

[cmungall]

Not yet - any chance you could get this in before the next release @zhengj2007 ?

[zhengj2007]

@cmungall OK. I will work on it before next release.

[zhengj2007]

@cmungall "xsd:date" does not show up in the datatype list. Can I use xsd:dateTime? Or is it better to use URL: http://www.w3.org/2001/XMLSchema#date? Thanks!

[cmungall]

I guess dateTime, see https://github.com/w3c/sdw/issues/987 cc @alanruttenberg

[balhoff]

Is there any issue with using other datatypes as values for annotation properties? I wouldn't expect so considering that these aren't visible to reasoners. However, I remember seeing some recent discussion raising this point, maybe related to that time ontology issue. I don't remember the conclusion. xsd:date seems simpler if you just want to note a date.

[zhengj2007]

If we use xsd:dateTime, we need to give both date and time, in the format like YYYY-MM-DDThh:mm:ss. Might be little bit extra work for developers. However, using unsupported datatype (http://www.w3.org/2001/XMLSchema#date), I am worried it may cause unexpected results. So, I prefer to use xsd:dateTime if we want to set the range.

[zhengj2007]

Label: 'scheduled for obsoletion on or after' Def: Used when the class or object is scheduled for obsoletion/deprecation on or after a particular date Range: xsd:dateTime ID: IAO_0006012

[zhengj2007]

Already in the release.