Release COB with COB ids + mappings, rather than with the mapped IDs #244
Comments
I would support this. However, don't the SSOM mappings use |
|
I am opposed. The plan all along has been not to change IDs. |
|
Can you offer your position on who should "own" the IDs? Like, should GO cede their "Molecular Function" term to COB for management and be disallowed from editing it in their own space? Or do yo think it is ok that COB, as an upper ontology, should dependent on everything else. So if a PATO developer wakes up one morning deciding that PATO:quality should be a material entity, having that permeate through COB through all of OBO? (The example is stupid, but you get the point) |
|
I am not thinking here in terms of ownership, but of correctness and minimal disruption. It's long been a principle, despite occasional pushback, that we don't mint more than one ID for one thing and we don't change IDs unless terms don't make sense or are accidentally duplicated or whatever, and we don't change the meaning of terms. Mappings are outside the semantic web stack we use and I think it's fair to say that many users will not be aware of them, nor know how to apply them in their own settings. Nor should they be obligated to. As far as ownership goes, I think of our ontology developers as stewards, not owners. If we follow the logic of wanting to "own" all our terms then the logical extension is that all ontologies should have their own IDs and just map pervasively. I can say from experience that this is a losing strategy, and an original impetus for developing the foundry was to avoid that. If the terms would be better stewarded in their original ontologies then have an automated build that pulls them into COB. If they would be better managed as a set in COB (my gut) then the ontologies that that originally minted them should import COB. I believe that's the goal anyways. The "stupid" example is indeed stupid. We have a principle that the extension of a class doesn't change. It's bad behavior to do this. If an ontology does that then it's misbehaving and all the mappings in the world won't help with the breakage that ensues. |
|
I wanted to give my $.02 quickly: While I understand and favor Alan's
preference to not introduce new identifiers in an ideal world, *the reality
of OBO development is that we do not have an ideal world*. For good and bad
reasons, ontology developers do not prioritize updating their ontologies to
serve a greater integration goal that COB has. Speaking for as a driving
member of OBI which has really tried to be at the forefront of this, we
still haven't completed our COB integration (not for lack of wanting, but
for lack of developer time to get it done and test out all the consequences
which are not trivial).
Nico's suggestion is a 'realism based' approach to ontology development and
integration; in this case realism of what can be expected from ontology
developers. By making COB the 'owner' of its terms, and allowing to
showcase what integration can achieve (and what problems it discovers)
without waiting for individual ontology developers to act, I think we will
be much faster in showing success, and making people want to adopt.
The fact that *all of this is essentially volunteer/side project work*
needs to be triple stressed (both on the COB side and for ontology
projects).
If we were a centrally run company, there would be no question that Alan's
approach is right. But we are not.
- Bjoern
…On Mon, Aug 21, 2023 at 5:01 PM Alan Ruttenberg ***@***.***> wrote:
I am not thinking here in terms of ownership, but of correctness and
minimal disruption. It's long been a principle, despite occasional
pushback, that we don't mint more than one ID for one thing and we don't
change IDs unless terms don't make sense or are accidentally duplicated or
whatever, and we don't change the meaning of terms. Mappings are outside
the semantic web stack we use and I think it's fair to say that many users
will not be aware of them, nor know how to apply them in their own
settings. Nor should they be obligated to.
As far as ownership goes, I think of our ontology developers as stewards,
not owners. If we follow the logic of wanting to "own" all our terms then
the logical extension is that all ontologies should have their own IDs and
just map pervasively. I can say from experience that this is a losing
strategy, and an original impetus for developing the foundry was to avoid
that.
If the terms would be better stewarded in their original ontologies then
have an automated build that pulls them into COB. If they would be better
managed as a set in COB (my gut) then the ontologies that that originally
minted them should import COB. I believe that's the goal anyways.
The "stupid" example is indeed stupid. We have a principle that the
extension of a class doesn't change. It's bad behavior to do this. If an
ontology does that then it's misbehaving and all the mappings in the world
won't help with the breakage that ensues.
—
Reply to this email directly, view it on GitHub
<#244 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADJX2ISIWGRG5BOUI57TLBDXWPZFZANCNFSM6AAAAAA3V35UBI>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
--
Bjoern Peters
Professor
La Jolla Institute for Immunology
9420 Athena Circle
La Jolla, CA 92037, USA
Tel: 858/752-6914
Fax: 858/752-6987
http://www.liai.org/pages/faculty-peters
|
|
And yet given that people don't update their ontologies regularly, many of them will already be integrated with COB by way of having already imported or MIREOTed the existing terms, and will become less integrated should a new set of ids be put out there. |
|
Correspondingly, ontologies that are interested in COB will lose absolutely nothing by importing COB if it is using the already-existing terms from older ontologies. |
|
Curious, I went to look at COB in ontobee. I hadn't realized that that version does use existing pre-existing OBO ids. Looking at assay, which is still OBI_0000070 and eyeballing the list of uses, there are something like 40 ontologies that use that ID. Changing it to some new COB id will require all 40 to update. How is that desirable? |
|
Our approach has been to take an ontology, rip out the terms mapped to COB,
replace them with the COB term, using the Sssom mappings. As you point out
those are currently pre existing ids. But in some cases, different terms
get changed into one (eg 'cell' from GO and CL) . And that is where the
problem comes in that Nico described when we e.g. want to change a label or
add an Axiom.
…On Wed, Aug 23, 2023, 1:41 PM Alan Ruttenberg ***@***.***> wrote:
Curious, I went to look at COB in ontobee. I hadn't realized that that
version does use existing pre-existing OBO ids. Looking at assay, which is
still OBI_0000070. Eyeballing it, there are something like 40 ontologies
that use that ID. Changing it to some new COB id will require all 40 to
update. How is that desirable?
—
Reply to this email directly, view it on GitHub
<#244 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADJX2IRWOBTDXDHRWLE7EDLXWZTIFANCNFSM6AAAAAA3V35UBI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
If you want to change an axiom, change an axiom. We change axioms when we need to, not to change the meaning of a term, but to clarify it or make it more effective for reasoning. Ditto label. How exactly does having an duplicate ID for a same or almost-the-same-except-for-inconsequential-change make a difference? Changing the ID does nothing but bring in extra work forever down the line in order to make sure that old IDs are aligned to new IDs. And what if you add an axiom to COB but not to the original, what happens to the SSOM mappings? Remove the mapping? Require everyone be aware of these changes? In addition, SSOM does nothing for non-ontology mentions such as those in papers, in spreadsheets, in queries, in datasets, or in other existing workflows. For a select few who want to use SSOM fine, but don't impose it's mandatory use for absolutely everybody, in every possible context where an ID might have been mentioned. Not an a careful search, but worth browsing https://www.google.com/search?q=obi%3A0000070 |
|
In the case where there are duplicate IDs (CL,GO:cell), pick one an use it throughout. If 1/2 use one id and 1/2 use other then 50% have to change vs 100% if a completely new ID is minted. |
|
As I said Alan, I agree with you in principle, and all your arguments
illustrate well why it would be great if we could just keep one ID per
concept. But you are not getting to the problem that we are trying to
solve. I think this part of your response gets closest to it:
If you want to change an axiom, change an axiom. We change axioms when we
need to, not to change the meaning of a term, but to clarify it or make it
more effective for reasoning. Ditto label. How exactly does having an
duplicate ID for a same or
almost-the-same-except-for-inconsequential-change make a difference
The duplicate terms address the problem of WHO makes a change and WHERE the
change is made.
You seem to be suggesting one of two things: 1) the 'home' ontologies of
terms like 'cell' will readily and quickly implement any change we ask them
to do in their own ontology for the greater good of COB and OBO integration
or 2) the 'home' ontologies of terms like 'cell' will give up control of
these terms completely and trust that they will be managed in COB.
Based on experience so far, neither of this will happen. So by coining a
new ID for COB terms that are typically based on one (or more) OBO terms,
but defined and labeled with maximum interoperability in mind, we are able
to work faster towards interoperability and figure out what causes problems
while not messing with the source ontologies - until they are ready to do
so.
I want to stress again that I see and agree with the downsides you are
pointing out. But I beg you to focus a bit more on the practical
implementation - even if it is ugly and messy. Nico and team are dealing
with the realities on a large scale, my work has similar issues on a
smaller scale.
Maybe it would be good if you joined one of the operation calls where we
are discussing these things?
Bjoern
…--
Bjoern Peters
Professor
La Jolla Institute for Immunology
9420 Athena Circle
La Jolla, CA 92037, USA
Tel: 858/752-6914
Fax: 858/752-6987
http://www.liai.org/pages/faculty-peters
|
|
My views arise out of practical considerations and actual experience having to deal with this sort of thing both in SPARQL and using other technologies. The worse part about it is that changes such as using a different IDs tend to be invisible in already existing projects. One thing that lands up happening is that existing queries return some but not all information. It may be there's a short term gain by going the direction you are going but the long term costs are high. Perhaps they don't seem as present because we're looking at this from the perspective of the developer. I think the consumer has to come first. I think it is reasonable to have the original authors maintain the terms, either in their own ontology or as part of COB and our principles around responsiveness ought to govern their work on this. Realistically, how many changes are we expecting there to be for the already defined terms. I haven't reviewed them all but aren't they pretty mature? I'm afraid if we can't even get the source ontologies to contribute/maintain these terms then it's a demonstration of a serious failure of our enterprise. It's frequently the case that it doesn't work to try to fix a social problem with a technical fix. This is one of those cases, IMO. Here I would at least try to get the relevant parties together and see if we can't come to some reasonable agreement on how to maintain the terms. Perhaps we can talk offline... |
|
I can join an operations call if you tell me which to join. |
|
TBH, I find all the arguments here to some degree convincing. However, let us be clear about what this discussion here means for our progress: If #226 is any indication, the only thing that will happen is that we all lose valuable time in our lives arguing our points, and in the end, the issue will freeze, not be implemented and COB will just go stale. In my opinion, we need to find a better way to have this discussion: Driving COB forward. All impactful projects we have as OBO Ops Technical Working Group (ROBOT, ODK, OBO Dashboard, RO, PURL system) have one thing in common: they are driven by people that actually do the groundwork - so we have "authority by involvement". 100's of decisions are being made in these projects per year that 60% of the community would not agree with (we are now implementing a technique for using DL Queries WITHIN SPARQL in ROBOT - even Chris Mungall has been crying when he heard this). But - overall the tools are used, and make a difference! If we had these kinds of discussions here every time we wanted to make a feature in ROBOT.. There would not be a ROBOT. @alanruttenberg are you willing to argue your point AND go fix all the problems your solution entails for us (the people driving to roll out COB)?
I am not saying you are wrong with much of what you say, but you are not in the trenches. But being "right" always comes at a cost! |
|
It was resolved a few years ago that CL owns 'cell' (apart from the CARO class), and GO has accepted that. Let's not relitigate that issue. |
|
Ok, @addiehl you are right, but the point still stands. Mondo:disease, OGMS:disease, DOID:disease; anatomical entity in 40 different ontologies; various instances of "role" classes. Everything in NCIT, FMA; you can tell dozens of stories why each individual one was a mistake. Many such battles have not been fought yet. The point is now: we need a practical path forward.. using COB ids solves these issues. The "right" way needs a lot more time and resources, which we don't, and wont, have. |
|
I am willing to help. I need to first review COB and understand where it stands. It might help to have a call with you and Bjoern so you can debrief me on history so I'm aware of all relevant issues and so I don't go into conversations blind. On the specifics you suggest:
I would like COB to succeed and I think, perhaps naively, that others do too and will do their best to help it be a success. |
|
I now spend again too many hours writing and rewriting a response. I added my original response below, but the matter of fact is that we first need to agree on the following: What is COB?These are the assumptions I work under, not the assumptions of any other COB developer!
If we can't even agree with these 4 premises, we should not try to solve the following. OLD, now deprecated message I wroteI am a bit doubtful but I applaud your enthusiasm to help out. Even if you were to do all the work required here, I am still doubtful this is the right path. It will take so long to sort everything out, that COB is dead before it started (remember #226? Now multiply by 100). As I think your path will take ages to sort out, I would suggest we do it like this:
I will give you two problems to chew on for starters.
Some disconnected thoughts:
|
|
I can sympathize with the effort it takes to craft these responses. They take me a while compose too. I can comment on some of it now, but not all. The original post is very useful and actionable. The cob-to-external.tsv list looks like a good place to start, as is the version of COB that is in Ontobee where obviously some choices were made. MIREOT: I use that term in a generic sense. There are a number of ways to implement it. I know what SLME is - I hadn't known the acronym, or that it was being used in production. Back when I was actively doing OBO technical work and implementing MIREOT for the first time, I had hoped we would get there. I'm glad to hear it is being used. See e.g. my suggestion on how to leverage it in Protege. You should understand that for my day-to-day work I generally use my own bespoke tools, which can do most if not all of what ROBOT can. I use SLME regularly, not via robot but via my LSW2 tools many of which pre-exist ROBOT. Queries: If you have have OBI:assay in a query and one now adds COB:assay as a different term with some data sets using the COB term, then the old queries will return fewer than the correct number of results when run on combined data sets. I presume you aren't suggesting that the COB:assay would be subclass of OBI:assay, in which case the queries would indeed continue to work. In work I did pre-ontology it wasn't uncommon to have even single databases change over the years in a less-than-controlled way, with the result being that to get all the answers to some query you had to reverse engineer what all the possible ways of representing what you were looking for and writing long disjunctive (SQL UNION) queries. That is not a happy state of affairs and the experience is why I push so hard to minimize what I believe to be unnecessary changes. On the "what is COB?" notes, given that you acknowledge these are not necessarily the views of all COB developers, I don't think it's necessary for us to completely agree in order to get work done. I'll comment not for the purpose of arguing but to help you have a model of where I'm coming from.
2,3 I'm not sure there's anything "simple". Given that it's a messy field, I suspect "simple" is probably an illusion. But yes, I see that there may be cases where we can't agree on upper level term and we'll have to do something to make progress. Whether doing so yields resilience we will see. To better understand if it would we would have to extrapolate to the kinds of changes imagined, to the type of things people try to do with it, and then assess the extent to which those changes do or don't effect those things. Perhaps some of that has been done, but I haven't been party to such discussions. You and I have had an exchange at some point about being "uncommitted" and we don't completely see eye-to-eye on that. I would aim to be as committed as is practical which I think is more than "uncommitted". In the case of disease, it's clear there isn't consensus. OTOH there are people who do use a more precise definition and whatever we do shouldn't make their efforts to do so moot. I'll have a better idea of the extent of the problems once I've done some work.
|
|
So how do you suggest that we proceed? And on what timeline? I was trying to plan the next step in the evolution of OBO which we call GUOBO (Grand Unified OBO Ontology), which is basically an attempt to create a single coherent, all-encompassing ontology where all the individual OBO ontologies that pass a certain quality threshold are "components". One of the key principles of GUOBO is that all participating ontologies are fully aligned with COB (more strictly, there exists no class in the namespace of the ontology that does not fall under one of the classes in COB). This means we are starting to roll out COB in a few ontologies now to get this process started. We cant start this process unless we have some clarity on how the axiomatisation and annotations of the COB classes are extracted from the set of ontology dependencies.. |
|
FWIW, I don't think there will ever be a "Grand Unified OBO Ontology" (GUOBO) using the mapped (i.e., non-COB) IRIs. There is just too much disagreement (as already discussed). COB needs to be its own thing, with its own semantics. There already exists Mappings between the COB iris and external iris already exist. However, the |
|
@matentzn I will try to review the mappings TSV this week and so some triage. As for the larger questions of strategy it's a bit much for me to think through given my day job and lack of background on COB trajectory in general. I think it would be helpful to talk if you have time so we can go back and forth and I can get a better picture of the bigger process. |
|
I think I've changed my original position on this ... shocking eh? After starting a few new ontologies using the COB ids, I found it aggravating to have to "rewire" the subclasses to point to the COB parents. It is easier (at least for me) to use the IDs from the original ontologies. That being said, we need to decide on what COB is meant to do within the OBOF. My original hope was that COB would have a separate semantics (hence, requiring new IDs) that would harmonize/resolve some of the never ending debates. A kind of upper-level bridge between the strict and non-strict BFO communities. I have pretty much given hope of this ever happening (sorry). My thoughts at the moment are that COB should serve as kind of junction box that provides a centralized resource to facilitate OBOF imports. Doing this, however, would require compromise. The formal semantics imposed by the source ontologies would need to be weakened. The BFO folks (I suppose that I partially belong in that crowd) will have to relax what I call "BFO purity tests", and live with high level classes like "disease or disorder". Otherwise, I think we will just continue on debating issues ad nauseam. |
|
There are a lot of good points on all sides here. (For those here who don’t yet know me, I’m coming to COB from the OBI dev team, and I intend to help out with COB development tasks as I’ve done with OBI.) At risk of stating the obvious, part of the conundrum is that each of these courses of action addresses some of COB's basic desiderata about this issue, including:
Yet solutions that are optimal by some of these principles are inherently unoptimal by others: an ontology over which we have full control is an ontology for which we are doing all the work that has to be done. Furthermore, there are certain unideal facts that further constrain the solutions available to us:
My goal in summarizing these threads of the conversation is to make it easier to analyze which possible solutions both align with COB’s desiderata and can coexist with the unideal facts. Notably, the two options discussed here, minting COB IRIs for core COB terms or building COB primarily out of terms imported from other ontologies, are not mutually exclusive. Here is one proposition for how to move forward on this issue that, I believe, would balance our desiderata and our constraints: We keep non-COB terms in COB as a blanket policy, but we grant COB authority to mint IRIs for any terms for which either (1) no term with an equivalent extension currently exists (an obvious and uncontroversial right), (2) several terms with conflicting definitions and extensions are already in widespread use, necessitating COB as a consensus-driver (e.g., disease/disorder would likely be a good candidate), or (3) a previously-acceptable term imported in COB becomes logically or semantically unacceptable, and efforts to fix it in cooperation with its host ontology are either impossible or unsuccessful. This approach would have several notable benefits. As @matentzn said, it’s unlikely that many ontologies (e.g. GO) would be interested in ceding major terms to COB. By using their terms as much as possible, COB fosters goodwill, likely increasing the odds that other ontologies will want to cooperate/align with COB. Preserving existing IRIs also requires significantly less work up front and overall than replacing them, so we can roll out COB much faster. I think @wdduncan’s experience here is informative about the value of keeping existing IRIs where possible. We also avoid wasted time and effort involved in replacing stable and workable terms that have non-COB-IRIs (a lot of OBI terms, for instance, but also certain terms from other ontologies), and it requires less work from ontologies that use current non-COB terms to align with COB. But by granting COB the right to liberally replace non-COB-IRI-terms with COB-IRI-terms whenever we judge it necessary, we shield ourselves from much of the vulnerability that comes from a policy of blanket acceptance of external ownership of the terms in COB’s scope. Ultimately: the only work required of us is the strictly necessary work; we lean into interoperability and ease of use by defaulting to using what is already there; and we treat inclusion of external ontology terms in COB as a privilege that we can revoke when it no longer serves us. Some notable downsides of this approach are that it requires us to be vigilant about changes made by other ontologies to terms in COB, and it requires us to be responsive when undesirable changes occur. Both of these things are eminently possible—arguably all ontologies that import any external terms face these issues—but I would argue that solutions that place the onus on us to be responsive are preferable to those that require other ontologies to be responsive, as the former is within our control. The path I outlined is just one of many viable options. I'm proposing it now mostly to suggest an evaluative framework for choosing COB's path forward and then to ask: which solution(s) is/are best at satisfying COB’s desiderata and coexisting with the unideal facts? |
|
@sebastianduesing First of all, your comment is a rare example of clarity with next to no "opinion baggage" and very actionable analysis of the current situation. It can't have been easy to write this, so I thank for you this! TBH, I am very happy to proceed on a solution that follows your way of thinking. Of course, we need some simple "conditions" for making a "minting" decision - disease may be a bit less controversial (basically there is no other way unless we want major groups to boykott cob, but still there will be resistance), but I am sure we can develop conditions that allow this even for more controversial cases. However, your argument does not address key technical problems. Which ontology will we import "GO:molecular function" from? GO or COB? Who has the last word in case of a clash (this is not the sociotechnical question to which you describe a good path forward, just the technical)? If we import from both, we greatly increase the "attack surface" for conflicts (imagine a change in an upper level alignment). Given what you say we basically need a guarantee that that certain classes "are not editing without announcement on the COB tracker". I think this is doable - so we can go to GO and say: can you agree that changes to MF CC and BP must be announced on the COB tracker prior to implementation? We basically assume that these classes, once created, don't change. I am fine with that. We could try and move this issue forward based on this assumption. |
|
@matentzn Thank you for your response! I’m glad to hear you would be happy to proceed on a solution like that; resolving this issue would be a big step forward for COB, so I’m happy to support progress of any sort here. I completely agree that there are some important technical questions that need to be answered before a strategy like the one I proposed could be implemented. You raised a really good question about which ontologies should be the source of imported terms. The answer to that may be at least partially dependent on what we see as COB’s role with respect to the terms in its domain. If we want COB to be a one-stop shop for mid-high-level biomedical terms, importing from COB is probably the better choice. If we want COB to be something like a source of truth—by which I mean that COB serves to organize/interconnect reliable and trustworthy mid-high-level terms within its domain, pointing users to useful terms and showing them how to use them in relation to other terms to which they may not be connected in their native ontology—it would probably be preferable to import from the original source ontology. I personally lean towards the second option, importing from the original source, but I think there are good cases to make for either strategy, and I agree that importing from both is basically untenable. I recognize there are significant technical dimensions to this problem beyond with the ideological question I just mentioned. I’m not confident that I know exactly how the technical consequences of each path would shake out, though I’ll look into it and try to get a better handle on that. I like your proposal that, as a condition for inclusion in COB, we require GO/similar owners of high-level COB terms to announce changes to those terms on the COB tracker prior to implementation. Firstly, I think that’s a reasonable compromise to make with those other ontologies—we use their terms, essentially routing traffic to their ontologies, rather than replacing them with our own terms, and in return they notify us of relevant changes to those terms—but secondly I also suspect that those critical terms will not be changed very often because they’re also critical to the ontologies that host them. I searched through GO’s GitHub and found no substantive changes to “GO:molecular function” over their ~10 year GitHub history (at least as far as I could find, searching both the label and the IRI/PURL in open/closed issues/PRs). And as you said earlier in this thread, they haven’t renamed “molecular_function” to “molecular function” in five years—I suspect they’re not eager to touch its axioms either. I would guess that this applies to most high-level COB terms. That being said, if we want a bit of a confidence check to make sure that other important COB terms have a similarly stagnant edit history in their source ontologies, I can come back with that info. For these high-level terms, keeping them the way they are so nothing breaks is a high-stakes issue for us, but it’s also a high-stakes issue for their source ontology. That’s not to say groups never make changes that break their own ontologies, but I think we can reasonably anticipate that any changes to these high-level terms will be rare and conservative, and as such, I suspect it wouldn’t be a significant burden on the source ontologies to post on COB’s issue tracker whenever changes get made. We might suggest adding an editor’s note to those terms as a reminder that changes should be reported to COB. I’ll also volunteer to be the one to reach out to other ontologies about this, if we commit to this path—assuming no one else wants that job. All that to say, I think the assumption that these classes generally won’t change is a reasonable one. Returning to your comment about conditions for making the decision to mint a new IRI, I definitely think we can find a way to allow for even the more controversial cases. I think it may be helpful to pull together a short list of cases that are controversial/complicated for which we could ideally justify minting a new IRI, so we could try to construct a set of rules based on those test cases. If you have any cases that come to mind (or if anyone else looking at this issue has any), that would be a great start. I’ll also see if I can find any that stand out as interesting test cases. Thanks again for the time you’ve spent on this discussion—I’m hoping this will result in some significant steps forward for COB. I’m happy to help out in any way I can along the way! |
|
EDIT: My method of searching for edit history did not catch everything I thought it was catching. This information is incorrect. ORIGINAL:
I'm happy to check on any other terms of interest, but based on this, I think it's reasonable to assume that high-level terms like these are likely to remain stable in their host ontologies. |
|
Similarly, GO molecular function and GO cellular component also had their definitions adjusted in the past year. |
|
Thanks for pointing that out. I'd been searching for the IRIs for those terms, and that PR doesn't come up in that search. Sorry, I jumped the gun on that one—please disregard my comment from earlier today. I'll do a more thorough search for edit history for those terms and come back with that info. |
|
The information on QuickGO is helpful. Thank you, @addiehl, I was very wrong about this—I thought I was catching more in my GitHub issue/PR searches than I actually was. Lesson learned. So we can't assume that these terms are stable in their source ontologies. Thinking again about the proposal to require the source ontologies to notify COB of impending changes, ~2 definition changes in 8 years is at least not frequent enough to make that very much of a burden on the source ontologies. If this is the approximate rate of change for terms like these, I think that that's still a reasonable option. |
Add cob-native.owl product Note that this product always existed, we just did not expose it. There is ongoing discussion on whether the native one should be default or not - please discuss this here: - OBOFoundry/COB#244 The purpose of this PR is to be more transparent about the current contents of COB
Add cob-native.owl product Note that this product always existed, we just did not expose it. There is ongoing discussion on whether the native one should be default or not - please discuss this here: - OBOFoundry/COB#244 The purpose of this PR is to be more transparent about the current contents of COB
Currently, we curate COB using COB ids, and swap out COB ids with exact matches (e.g. COB:cell nucleus with GO:cell nucleus).
This is cumbersome for a variety of reasons:
I would like to put forward a motion to publish COB with mappings instead of rewiring the ids.
See some relevant fun side issue here: #243
The text was updated successfully, but these errors were encountered: