Timeline and migration plan for MSO release?

[cmungall]

Is there a timeline, and a plan for assisting existing ontologies to migrate?

Will there be concurrent changes in SO? For example, will the OWL version of SO include axioms that make an ontological commitment to being information entities?

Many ontologies currently use SO as molecular entities. This will break if SO imports declare subclasses to a disjoint class. Are there resources to help people migrate?

[mikebada]

@cmungall We've been making really good progress this year; we have a few more issues to take care of, but I think Karen is on board for an official transition/release to the refactored SO/MSO soon, perhaps a month or shortly thereafter.

We do not have a plan yet for assisting existing ontologies to migrate and it'd be very helpful to get your input on that. It'd be great if we (you, me, Mike Sinclair, and Karen, and possibly other interested parties) could meet soon to discuss this.

If by "information entities" you mean generically dependent continuants, then yes, the SO sequence entities are explicitly asserted to be GDCs in both the OWL and OBO versions. If you mean information content entities, then no, we have not declared them to be ICEs. (We haven't asserted them to be anything more specific than GDCs at this point.)

We have not explicitly asserted the SO sequence entities to be disjoint from the MSO sequence entities. However, if independent continuants are explicitly asserted to be disjoint from dependent continuants in the BFO (as I suspect they are), I see how that could cause problems, as the SO and MSO sequence entities have been (purposefully) placed under their proper respective BFO classes. This IDC/GDC deconflation has been a primary motivation for this refactoring, but I agree that we should try to assist people in the migration.

[mikebada]

@cmungall We could also discuss delaying the official release until primary parties that rely on the SO say that it won't break their resources; we can discuss this more when we meet.

[msinclair2]

Hi Chris,

In addition to what @mikebada said, I think there may be very easy ways to make the transition. The taxonomy for SO itself has changed quite significantly, and so this is another thing to adjust to in the transition.

In most cases, the IRIs for MSO entities have been kept exactly the same as the SO entities that depend on them except that the prefix has been changed from SO_ to MSO_. This should make switching from using SO to using MSO entities instead easy for those ontologies that use SO entities as molecular entities.

As far as RO, it depends on your domain/range restrictions, and we can talk about that.

Also, I would like to bring to your attention that there is still a pull request to add generically depends on to RO that has not yet been approved. This is a crucial relation, linking the new SO to MSO, and so far we have defined it locally using an SO-prefixed IRI, and I would like to have it as an import from RO instead.

I think you (@cmungall), me, @keilbeck, and @mikebada should meet very soon to discuss these issues.

[cmungall]

Thanks

Yes in theory it should be straightforward but these things never are and there will likely be a period of things crashing and burning. One of the challenges is that we can't just do a global search and replace on everything since everything is distributed over different ontologies, github repos, databases (e.g use of SO in annotation extensions is probably embedded in multiple RDBMSs, hardwired into different annotation interfaces etc).

I will have limited resources to help manage the transition unfortunately. Might be good to make a start of all ontologies that use SO (e.g query ontobee sparql). This will just be a subset but a start. I can help do this on the GO side.

[mikebada]

Thanks, Chris.

If by 'global search and replace on everything' you mean my suggestion on the Noctua issue page to replace the SO namespace with the MSO: We figured that since the most prominent use of the SO is for sequence annotation, we should seek to minimize disruption/pain for the sequence annotators and their tools and databases; therefore, the design has been to allow them to keep using the SO for sequence annotation. So, for users only doing sequence annotation and possibly reasoning only over the SO, hopefully they can migrate with little to no change in their tools and databases.

The users for whom there will be greater disruption/pain are those who are reasoning with the SO along with other ontologies that are using SO classes to refer to molecular entities, but we figured this would be a much smaller subset of users. But yes, we should try to compile a list of such resources and work with them.

[keilbeck]

Chris
Thanks for the comment. I agree - lots of questions about the transition.
I think the thing that needs to happen first is the public comment phase. We need to get the idea out there and have people take a look. In this time period, we can figure out who will be affected and how.
And then we should focus on an active transition. Michael has contacted the GreekC developers in Europe to have a peek, but I think this needs to be a wider discussion.

There will need to be a time of maintaining two ontologies though. I just don't see us flipping a switch.

Our own browser will break. That can be the start of the list of things affected.

Any comments you have about how to manage this would be greatly appreciated.

--Karen