alanruttenberg
commented
2 years ago @nico I agree to your enumerated points. I would add one, which is that APs that are added should serve more than one ontology and be relatively universal. And obviously, these APs should be minimized and efforts made to not have relatively insignificant variants. I have the same objection to #1 as I raised about RO - violates the well-scoped ontology rule, at least, and eventually yields a huge artifact that is unpleasant to use. There's a place for smaller sets of annotation properties that are tailored for use in a small set of domains.
On Mon, Dec 20, 2021 at 1:05 PM Nico Matentzoglu @.***> wrote:
@zhengj2007 https://github.com/zhengj2007 and I are planning an OMO workshop for next year (March time), and currently thinking about the most important items to go over. It is a major problem that there are many important issues to solve, and all of these issues will demand space during the meeting. As far as I understand, it is @zhengj2007 https://github.com/zhengj2007 key concern to discuss the OMO scope: Which APs should be in, which should be out. For the ones that are in, are they required or optional?
But before we do that, we should agree on the philosophy of OMO, which is not exactly clear. I guess there could be two ways to define what OMO is conceptually:
- The RO for Annotation properties. This means:
- Anything goes: if someone wants a property "editors note", they can register it if it makes some basic sense (i.e. pertain to OBO ontology metadata).
- An acceptance to OMO does not imply OBO Foundry recommends using it.
- Similar to RO, we could maintain an omo-core.owl which contains only the recommended and required properties and their value sets.
- OBO ontologies may choose to import an OMO module instead of the whole thing, or core.
- A small core vocabulary for APs on which we want to reconcile across OBO foundry ontologies.
- If someone wants a new property "editors note", they add it wherever. If they want it to be added as a recommended property, we have some SOP to get it in.
- OBO ontologies typically import the whole thing.
My assumption is most people are thinking option 1, plus perhaps a "omo-core" module.
For the workshop, I would suggest, rather than "rejecting" APs from OMO, which could be pretty time-consuming, focussing on what goes in omo-core, and for that, I would suggest to focus on the following main issues:
- Attribution: How do we unify contributor annotations across the board. Goal: Being able to aggregate contributions across OBO ontologies.
- Synonymy: How do we do synonyms (exact, related, close)? How does this fit with synonym types? (#70 https://github.com/information-artifact-ontology/ontology-metadata/issues/70 )
- Obsoletion model: How do we model obsoletions, replacements, obsoletion reasons etc.
- Term provenance: How do we track which term comes from where? (iao:importedFrom vs rdfs:isDefinedBy, etc). What about versions?
- Minimal term metadata model: what metadata SHOULD be present on new terms?
I would encourage everyone to look through the tracker and label all priority issues with workshop https://github.com/information-artifact-ontology/ontology-metadata/labels/workshop. Looking forward to this!
— Reply to this email directly, view it on GitHub https://github.com/information-artifact-ontology/ontology-metadata/issues/83, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB3CDUQXI3VCTUNQ4OBZP3UR5V7HANCNFSM5KOJRU2Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you are subscribed to this thread.Message ID: @.***>
matentzn
@zhengj2007 and I are planning an OMO workshop for next year (March time), and currently thinking about the most important items to go over. It is a major problem that there are many important issues to solve, and all of these issues will demand space during the meeting. As far as I understand, it is @zhengj2007 key concern to discuss the OMO scope: Which APs should be in, which should be out. For the ones that are in, are they required or optional?
But before we do that, we should agree on the philosophy of OMO, which is not exactly clear. I guess there could be two ways to define what OMO is conceptually:
omo-core.owlwhich contains only the recommended and required properties and their value sets.My assumption is most people are thinking option 1, plus perhaps a "omo-core" module.
For the workshop, I would suggest, rather than "rejecting" APs from OMO, which could be pretty time-consuming, focussing on what goes in omo-core, and for that, I would suggest to focus on the following main issues:
I would encourage everyone to look through the tracker and label all priority issues with workshop. Looking forward to this!