Broaden definition of 'counting' (APOLLO_SV_00000033)

[dillerm]

First, I just want to clear up whether 'counting' is one of the Apollo-SV classes that IAO is taking. If so, I would like to propose a slight change to the definition (see below--bolded text contains the change) and ask how we should go about making this change (i.e., do it now in Apollo-SV or later in IAO once it has an IAO IRI).

Current definition: The planned process of finding the number of elements in a finite set of objects.

New proposal: The planned process of finding the number of elements in a finite set of entities.

My reasoning for the change is that any independent continuant and many occurrents can be counted.

[alanruttenberg]

Better practice would not to change the extension of an existing class. Instead, rename the old class to something like "object counting", then add superclass "counting" with the broader definition.

[zhengj2007]

@dillerm Good caught. I didn't know that the IAO contains several Apollo-SV classes. The terms were not used by any IAO terms and imported using general import script. I think the terms were added in the IAO by mistake. I will remove them in next IAO release.

For the terms you are interested in, you can contact APOLLO_SV. If you think a broad 'counting' term is in IAO scope, you can submit a NTR to IAO.

[hoganwr]

NO actually Apollo-SV did cede several terms back to IAO

On Mon, Feb 20, 2023 at 10:35 AM jie zheng @.***> wrote:

@dillerm https://github.com/dillerm Good caught. I didn't know that the IAO contains several Apollo-SV classes. The terms were not used by any IAO terms and imported using general import script. I think the terms were added in the IAO by mistake. I will remove them in next IAO release.

For the terms you are interested in, you can contact APOLLO_SV. If you think a broad 'counting' term is in IAO scope, you can submit a NTR to IAO.

— Reply to this email directly, view it on GitHub https://github.com/information-artifact-ontology/IAO/issues/266#issuecomment-1437205574, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJR55QG7XKGSIF4J3EYK73WYOFNRANCNFSM6AAAAAAU74PPQY . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[hoganwr]

See this commit:

https://github.com/information-artifact-ontology/IAO/commit/7f844904ddded206c5af158bf6d6e316612fe0bb

[zhengj2007]

Hi @hoganwr, if the terms in IAO domain, I think we'd better to add the term in the IAO by assigning IAO term ID and deprecate the term in APOLLO_SV.

Current the APOLLO_SV terms were added in the iao_dev.owl directly. It would be hard to ensure that they remain consistent and up-to-date if either APOLLO_SV or IAO edit the terms .

[hoganwr]

I hate that approach. Why?

On Wed, Mar 8, 2023 at 3:48 PM jie zheng @.***> wrote:

Hi @hoganwr https://github.com/hoganwr, if the terms in IAO domain, I think we'd better to add the term in the IAO by assigning IAO term ID and deprecate the term in APOLLO_SV.

Current the APOLLO_SV terms were added in the iao_dev.owl directly. It would be hard to ensure that they remain consistent and up-to-date if either APOLLO_SV or IAO edit the terms .

— Reply to this email directly, view it on GitHub https://github.com/information-artifact-ontology/IAO/issues/266#issuecomment-1460856591, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJR55Q56M6XF7EYBEYPQY3W3DWBVANCNFSM6AAAAAAU74PPQY . You are receiving this because you were mentioned.Message ID: @.***>

[zhengj2007]

I am wondering for the term with APOLLO_SV prefix. Who will maintain it? IAO developer or APOLLO_SV developer? If IAO update the terms. How will APOLLO_SV know it and update it? In the other way, APOLLO_SV update the term, how will IAO notice it and also update it?

[hoganwr]

Those specific terms belong to IAO. IAO should maintain it.

The cost of new IRIs is lack of stability of identifiers. Plus a growing pile of obsoleted IRIs

On Wed, Mar 8, 2023 at 4:37 PM jie zheng @.***> wrote:

I am wondering for the term with APOLLO_SV prefix. Who will maintain it? IAO developer or APOLLO_SV developer? If IAO update the terms. How will APOLLO_SV know it and update it? In the other way, APOLLO_SV update the term, how will IAO notice it and also update it?

— Reply to this email directly, view it on GitHub https://github.com/information-artifact-ontology/IAO/issues/266#issuecomment-1460909964, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJR55XIKGRWXJR4I2W7HGTW3D3Z7ANCNFSM6AAAAAAU74PPQY . You are receiving this because you were mentioned.Message ID: @.***>

[zhengj2007]

So, it's better to add the term in the IAO if it is in IAO domain.

I still don't like to keep an IAO term with APOLLO_SV prefix since most people identify the term in which ontology based on the prefix.

To reduce the conflict when build an ontology that reuses the terms from external OBO Foundry ontologies, the base files (the OWL file that excludes any terms from external ontologies) are recommended to use. The base file can be generated automatically using ROBOT based on the ontology prefix. In this approach, the APOLLO_SV prefix terms will be excluded.

[hoganwr]

Again all that convenience for you comes at a high cost to ontology users who have to deal with frequently changing IRIs that represent the exact same thing

On Wed, Mar 8, 2023 at 5:34 PM jie zheng @.***> wrote:

So, it's better to add the term in the IAO if it is in IAO domain.

I still don't like to keep an IAO term with APOLLO_SV prefix since most people identify the term in which ontology based on the prefix.

To reduce the conflict when build an ontology that reuses the terms from external OBO Foundry ontologies, the base files (the OWL file that excludes any terms from external ontologies) are recommended to use. The base file can be generated automatically using ROBOT based on the ontology prefix. In this approach, the APOLLO_SV prefix terms will be excluded.

— Reply to this email directly, view it on GitHub https://github.com/information-artifact-ontology/IAO/issues/266#issuecomment-1460974478, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJR55THB3GLKCGEO3WM4TLW3ECN7ANCNFSM6AAAAAAU74PPQY . You are receiving this because you were mentioned.Message ID: @.***>

[zhengj2007]

The original ID will be recorded in the ontology. I think it can be handled automatically. Most OBO ontologies use this approach unless two relations which prefix is BFO since they are widely used and the cost of replacement is too high. I don't think it is the case for the APOLLO_SV prefix terms in IAO.

We may discuss the issue on OBO Operation committee meeting. I also want to know the OBO policy on it.

[hoganwr]

“Handled automatically” - only if you religiously follow replaced by annotations in every single query, lookup, etc.

Bill

On Wed, Mar 8, 2023 at 5:43 PM jie zheng @.***> wrote:

The original ID will be recorded in the ontology. I think it can be handled automatically. Most OBO ontologies use this approach unless two relations which prefix is BFO since they are widely used and the cost of replacement is too high. I don't think it is the case for the APOLLO_SV prefix terms in IAO.

We may discuss the issue on OBO Operation committee meeting. I also want to know the OBO policy on it.

— Reply to this email directly, view it on GitHub https://github.com/information-artifact-ontology/IAO/issues/266#issuecomment-1460989160, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJR55UCFUEBKPU22TOR4L3W3EDQVANCNFSM6AAAAAAU74PPQY . You are receiving this because you were mentioned.Message ID: @.***>

[cmungall]

The OBO-wide discussion on adoption vs obsolete-and-replace is here https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1676

I suggest carrying on this part of the conversation over there, and paying particular attention to Bjoern's comments based on experience with adoption in OBI and the resulting confusion caused to users.

[alanruttenberg]

Haven't read the OBO-wide discussion, but it's a first principle that one doesn't replace IRIs for stuff like this. IRIs are deprecated if they are meaningless, and we need the ability to move terms between ontologies without breaking people's data.

[dillerm]

Based on this discussion and the one linked by @cmungall , I think the following changes need to be made:

1. Re-label APOLLO-SV:00000033 from 'counting' to 'object counting' and add an rdfs:isDefinedBy annotation to clarify that the current home for this class is IAO (this should also be done for the five other Apollo-SV classes that IAO adopted, but I'll create a separate issue for that).
2. Create a new class with an IAO identifier called 'counting' and define it as "The planned process of finding the number of elements in a finite set of entities."

[zhengj2007]

Based on the discussion, OBO has not decided whether we should take adoption approach. I'd prefer to hold on the changes in IAO

Based on this discussion and the one linked by @cmungall , I think the following changes need to be made:

1. Re-label APOLLO-SV:00000033 from 'counting' to 'object counting' and add an rdfs:isDefinedBy annotation to clarify that the current home for this class is IAO (this should also be done for the five other Apollo-SV classes that IAO adopted, but I'll create a separate issue for that).
2. Create a new class with an IAO identifier called 'counting' and define it as "The planned process of finding the number of elements in a finite set of entities."

[hoganwr]

The linked thread chose the adoption approach and the issue was closed.

Was it not closed because that was the approach adopted?

Bill

On Tue, Mar 14, 2023 at 12:07 PM jie zheng @.***> wrote:

Based on the discussion, OBO has not decided whether we should take adoption approach. I'd prefer to hold on the changes in IAO

Based on this discussion and the one linked by @cmungall https://github.com/cmungall , I think the following changes need to be made:

1. Re-label APOLLO-SV:00000033 from 'counting' to 'object counting' and add an rdfs:isDefinedBy annotation to clarify that the current home for this class is IAO (this should also be done for the five other Apollo-SV classes that IAO adopted, but I'll create a separate issue for that).
2. Create a new class with an IAO identifier called 'counting' and define it as "The planned process of finding the number of elements in a finite set of entities."

— Reply to this email directly, view it on GitHub https://github.com/information-artifact-ontology/IAO/issues/266#issuecomment-1468679850, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJR55XUMGNK3MBEYJDYOOLW4C6W5ANCNFSM6AAAAAAU74PPQY . You are receiving this because you were mentioned.Message ID: @.***>

[zhengj2007]

Haven't read the OBO-wide discussion, but it's a first principle that one doesn't replace IRIs for stuff like this. IRIs are deprecated if they are meaningless, and we need the ability to move terms between ontologies without breaking people's data.

@alanruttenberg I agreed with you that we'd keep the IRI stable. For the purpose, we use import to reuse the existing terms such as MIREOT strategy. But I don't think OBO decide that one ontology can adopt the term from external ontology. If the developers of one ontology think the term should be in other ontology, they should request the new term to be added in that ontology at beginning.

[zhengj2007]

The linked thread chose the adoption approach and the issue was closed. Was it not closed because that was the approach adopted? Bill

I just noticed the issue is closed. But I see still many people strongly recommend against adoption.

@hoganwr Will APOLLO-SV import these terms from IAO in the future? In addition, if the meaning of 'counting' changed, shall we assign a new IAO ID and deprecate the APOLLO-SV one or give it back to APOLLO-SV? Thanks.

[hoganwr]

We were not planning on taking the terms back. They belong in IAO.

I strongly advocate the adoption approach with isDefinedBy annotations and IAO keeps the terms.

Bill

On Tue, Mar 14, 2023 at 12:22 PM jie zheng @.***> wrote:

The linked thread chose the adoption approach and the issue was closed. Was it not closed because that was the approach adopted? Bill

I just noticed the issue is closed. But I see still many people strongly recommend against adoption.

@hoganwr https://github.com/hoganwr Will APOLLO-SV import these terms from IAO in the future? In addition, if the meaning of 'counting' changed, shall we assign a new IAO ID and deprecate the APOLLO-SV one or give it back to APOLLO-SV? Thanks.

— Reply to this email directly, view it on GitHub https://github.com/information-artifact-ontology/IAO/issues/266#issuecomment-1468697310, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJR55WZFWOD5DG6GEHUFULW4DARHANCNFSM6AAAAAAU74PPQY . You are receiving this because you were mentioned.Message ID: @.***>

[alanruttenberg]

@hoganwr we definitely need a property that indicates which ontology a term is managed by. Common Core uses "is curated in ontology". I'm concerned that rdf:isDefinedBy may be being used in different ways and so it might be better to define a property specifically for this purpose. Ideally Ontobee could pay attention to this property and redirect appropriately.

I'm still very much against deprecating/allocating a new IRI.

@zhengj2007, what about adding a "is curated in ontology" property to IAO metadata?

[matentzn]

I was just informed about this issue - it seems very relevant to all of us, maybe move ticket here https://github.com/information-artifact-ontology/ontology-metadata/issues?

[zhengj2007]

@alanruttenberg I am fine with it. But I would like to know the OBO's decision and hope the whole OBO community follows the same rule.

@zhengj2007, what about adding a "is curated in ontology" property to IAO metadata?

[zhengj2007]

@matentzn For taking adoption approach, how can we set the purl redirection for the adopted terms?

[matentzn]

Lets first sort out on OBO Foundry level if we go with adoption or not.. There is a bit of a burden on James and the OBO PURL system if we start with this adopting approach, while migrating (deprecating and creating new) makes that a bit easier.

Anyways lets not discuss this here, lets discuss it on the OMO tracker or even the OBO Foundry tracker. My guess for the outcome: we have spent too much energy recently on trying to agree on things across OBO, and we probably wont agree on this one for a while. So we will have to probably think about tooling that support both workflows.

[alanruttenberg]

I am fine with rdfs:isDefinedBy, if that is what is already being used. Adoption was something that was anticipated from the start of the foundry, and necessary in an environment in which terms outside a domain may need to be defined for expedience, in the absence of an existing domain ontology. This will always happen.

[alanruttenberg]

We're not going to obsolete IRIs for any ontology I'm involved with. It's rude and against Web architecture. We're also going to adopt, because we planned on doing that from the start. Bill's request is entirely the sort of thing expected. The action is to bring the term into IAO and add the rdfs:isDefinedBy annotation.

On Wed, Mar 15, 2023 at 5:11 PM Nico Matentzoglu @.***> wrote:

Lets first sort out on OBO Foundry level if we go with adoption or not.. There is a bit of a burden on James and the OBO PURL system if we start with this adopting approach, while migrating (deprecating and creating new) makes that a bit easier.

Anyways lets not discuss this here, lets discuss it on the OMO tracker or even the OBO Foundry tracker. My guess for the outcome: we have spent too much energy recently on trying to agree on things across OBO, and we probably wont agree on this one for a while. So we will have to probably think about tooling that support both workflows.

— Reply to this email directly, view it on GitHub https://github.com/information-artifact-ontology/IAO/issues/266#issuecomment-1470848906, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB3CDWWG46JKJSN7ZGF7NTW4IV65ANCNFSM6AAAAAAU74PPQY . You are receiving this because you were mentioned.Message ID: @.***>