Make replaced-by single-valued

[matentzn]

See for a closely related discussion on the interpretation of "replaced by" #58.

The proposal here is to have "replaced by" (IAO:0100001) be officially single-valued, i.e. a single term can only ever be replaced with a single other term, not two or more terms (this is less strong then to say that the two terms must be identical in meaning, debate that in #58). For all cases in which a term is split into two classes with narrower meaning, we should use a different annotation, such as oboInOwl:consider.

Handful of violations on Ubergraph. (PO PR FOODON FBBT APO (cc @Clare72, @ddooley @nataled)

Vote

• 👍 : Makes sense to have "replaced by" be single-valued. Having more than one replacement term is confusing and hampers automated data updating.
• 👎 : I don't see why I should not be able to replace with more than one terms. We split terms regularly and I am not willing to contemplate using a different annotation property for these cases.

Voting closes Oct. 31st.

[hlapp]

Perhaps this would benefit from an explanation as to what would be recommended instead in the case of a term being split? I can see why one would want to use "replaced by" iff one term is being replaced by another, but the case if splitting terms isn't an uncommon one.

a single term can only ever be replaced with a single other term, not two or more terms

Note that technically asserting a property as functional does not prevent having multiple assertions of this property on the same subject with different objects. But the implication is that the objects are the same (individuals), which will almost certainly be undesired.

Hence, in general declaring a property as functional (as opposed declaring a convention for compliant ontologies, enforced by QC checks) has a risk of wreaking more unintentional havoc than of creating expected benefit. Though given that IAO:0100001 is an annotation property I'm wondering how asserting it as FunctionalProperty is even relevant. (Would this mainly be meant as "tagging" the property for corresponding QC checks?) Perhaps I'm missing something.

[matentzn]

Sorry @hlapp - I rephrased the issue. I just couldn't think of a better word, chose now "single-valued". I had offered a suggestion for splits (using consider)..

[gouttegd]

No objection to a single-valued replaced_by as long as there is the option of using oboInOwl:consider for cases where the replacement should not be done automatically but left for an human editor to ponder.

[Clare72]

This (replaced_by for single, consider for multiple) is current policy for FBbt, FBdv, FBcv, dpo.
Happy for it to be an ODK check.

[zhengj2007]

Besides, I'd prefer the value should be a term IRI.

[matentzn]

I agree @zhengj2007 I will make a vote about that next.

[alanruttenberg]

There are legitimate reasons to have more than one replaced-by. The replaced-by is not intended to be used automatically to redirect, since terms are obsolete which in many cases should means they are invalid. You don't want an invalid use slipping by unnoticed. In the case that a term didn't make sense, there might be several alternatives that are "close" to the replaced term.

As I review the definition I see it says "can be" replaced where the intention was "might be". I suggest that as a change. But even in the case of "can", there isn't an implication that it's the only choice.

Moreover, restricting to a single value isn't in the definition, and so this change would mean a change in how the term is intended to be used. We don't do that, right? One alternative is to add a new term that is explicitly single valued.

If replaced-by is changed  to mandate a single value, or there is a new term, I think it needs to be be documented as being associated with those obsolescence reasons where a straight substitution is reasonable.

[matentzn]

@alanruttenberg Let us take a step back here. Forget for a moment what is intended, what is defined. When the GO and IAO schools got married a decade ago, a few properties were chosen to be merged. While IAO itself may not have used replaced by with the intention of automatic replacement 40 ontologies or more from the old GO school did.

I think tightening the meaning of an annotation property is totally ok for a community like us. You don't have to use dc:contributor with ORCIDs (i.e. range restriction), but only if we do, we can truly integrate attribution metadata, same here.

There are legitimate reasons to have more than one replaced-by.

We will propose a different property for these as a next step.

@alanruttenberg please put yourself in my shoes. You know that your comment has only two possible consequences:

1. We ignore it, take the majority vote, change the definition of IAO and leave you unhappy.
2. We respect it, and do nothing. There is no universe in which we introduce a new replacedBy property that is single valued now. IAO:0100001 is too widely used, and getting people to change their license annotations, let alone term level metadata, has not happened in 4 years. Adding obsolescence reasons is not going to happen either (even less likely).

I am ok with doing 2. We can just keep adding QC checks into ODK with whatever we (as maintainers of ODK) think is best, but then I personally will leave the OMO project to others. No one is paid for metadata reconciliation, we all have to sacrifice personal work hours to make any progress and after the discussions at the last OMO workshop I wanted to shoot myself and abandon metadata harmonisation altogether. What I am asking of you is not (obviously not!!) to change or abandon your opinions, just be a bit more mindful how you communicate them. What I want to see more of is openness to respect the democratic process which can lead to a change in the definition of IAO:0100001, and encouraging such changes even if you don't agree with every one of them. Just say: "Ok, I respect the outcome of the vote, I just want to note that the original intention was X and that I have concern Y and Z", which allows other people to change their votes.

Another 45 minutes wasted writing this answer which certainly has zero benefit to anything. Ah well.

[graybeal]

@matentzn Nico, I appreciate your frustration (having been in your shoes) but I don’t think the previous comment was loaded or inconsiderate. It is consistent with the detailed consideration that comes with discussing standards and their revision in a community setting.

In the same vein, I don’t think your 45 minutes was wasted, either now or in any past exchanges. I greatly appreciate your thoughtfulness, and at the same time your motivated effort to make constructive progress in challenging domains.

In the end, our successful use of these standards will blend adherence to explicitly defined policies and rules, and general adoption of consensus best practices. It’s obvious in this case that communities need and want to follow a common practice (good), yet also true that in a few other communities that exact practice may not be desired or followed. In that situation, I lean toward solution 2, and don’t think the compromise is a lesser outcome of your initiative. But if you do think it is important (and feasible), can you specify the value proposition?

(Sorry if this is annoyingly indecisive!)

[matentzn]

I agree that the comment above was not loaded or inconsiderate when reading it in isolation. What I find problematic though is comments that are geared at vetoing the vote vs geared at swaying public opinion. I am totally fine with you, or Alan, or Hilmar or whoever trying to convince the community that they should vote for something else. @alanruttenberg did this successfully a bunch of times, recently with the numeric identifier requirement. No qualms there. But look at the vote:

12 for making replaced by singled valued vs 2 against. I am sure there will be some more against coming, and some more for, but do you find it right that a single person, whoever it is, can just block a vote like this?

[nataled]

Don't we typically have a commenting period before a vote is called? This ticket calls for a vote before discussing the merits of the proposal. I don't see any attempt at blocking a vote here.

[cmungall]

Don't we typically have a commenting period before a vote is called?

There has been an open issue for this for about 2 years:

• clarify definition of term replaced by - does it mean equivalent, or can be substituted in certain contexts? #58

On that issue I originally remarked that someones GO had multiple values for replaced_by, but since then GO has changed to be in line with other ontologies. GO is behind the proposal to formally make replaced_by single-valued.

@alanruttenberg

One alternative is to add a new term that is explicitly single valued.

I appreciate the historical context of what was originally intended, indeed I noted in #58 that the definition was potentially ambiguous, but the current interpretation followed by everyone is as that it's permitted to replace the obsolete ID with the replaced_by term - and indeed this is what ROBOT has implemented for a number of years. So this is just clarifying the definition, no need to mint a new IRI (of course, we will have an IRI for another AP that can be used to suggest potential replacements to be considered by a human curator)

[hlapp]

@matentzn can you say where you see an attempt to veto or block a vote? I don't, but perhaps I'm missing what you're seeing.

My reservations based on the critiques so far are the following:

• After the revision, to answer a question like "Which successor term(s) might an obsoleted term have been replaced with" I know have to convert into two queries rather than one, and simply discovering the "replaced by" annotation might lead me to an incomplete result. This needn't be a bad thing if the decision is that the metadata schema for terms needs to support more specific questions, such as "What is the one successor term that I should replace an obsolete term with".
• The proposition that there commonly is a term that stands in for an obsoleted term in a manner that doesn't need manual review merits some questioning. If one had the exact same semantics as the other, why not assert that? And if they don't, why suggest that one safely (i.e., without requiring expert review) replaces the other? And if that's not the explicit or implicit suggestion, why would then having multiple "replaced by" annotations be a real problem (and for whom)?
• Hasn't one of the standing rules for OBO ontologies been that if term definitions are modified in a non-trivial manner, i.e., in a manner that changes their semantics, the term identifier has to be obsoleted, and a new ID (i.e., a new term) needs to be created. Is this incorrect? And it it's not, I'm a little surprised that so many would, without further comment or extensive questioning as to why the merits would justify this, be fine with creating a precedent for violating that rule.
  Like, what's the argument that this is ought to be of little concern, or what's the argument that the anticipated merits should override even considerable concerns about this.

I guess I also want to add the meta-concern that if we want to treat ontology engineering as a science (and I would certainly want to), then I'd argue we should acknowledge that science isn't a democratic process. So I find using current popularity standings as an argument not very helpful or convincing.

It's for these reasons that I am currently registering a "No" "vote".

[matentzn]

I was also contacted privately by some people telling me I was reading @alanruttenberg comment wrong - sorry Alan, I have overreacted (I am not at my best atm, not an excuse, just an explainer why I may have felt you were trying to block the vote - apparently you didn't). I will get back to you in an email tomorrow. Metadata should be about ice-cold utility and not emotions., sorry :P Alan did not try to block a vote, I was just overwhelmed and felt that his suggestions were not reconcilable with the vote at hand. I was wrong, so let's go back to the debate. Thanks all for chipping in. (@nataled you are right that I should have left a non-vote period before, lets just keep the issue open for the rest of the month and gather arguments and then finalise the vote).