Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Broaden definition of 'counting' (APOLLO_SV_00000033) #266

Open
dillerm opened this issue Feb 17, 2023 · 27 comments
Open

Broaden definition of 'counting' (APOLLO_SV_00000033) #266

dillerm opened this issue Feb 17, 2023 · 27 comments

Comments

@dillerm
Copy link

dillerm commented Feb 17, 2023

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
Copy link
Contributor

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
Copy link
Contributor

@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
Copy link
Collaborator

hoganwr commented Feb 20, 2023 via email

@hoganwr
Copy link
Collaborator

hoganwr commented Feb 20, 2023

See this commit:

7f84490

@zhengj2007
Copy link
Contributor

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
Copy link
Collaborator

hoganwr commented Mar 8, 2023 via email

@zhengj2007
Copy link
Contributor

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
Copy link
Collaborator

hoganwr commented Mar 8, 2023 via email

@zhengj2007
Copy link
Contributor

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
Copy link
Collaborator

hoganwr commented Mar 8, 2023 via email

@zhengj2007
Copy link
Contributor

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
Copy link
Collaborator

hoganwr commented Mar 8, 2023 via email

@cmungall
Copy link
Contributor

cmungall commented Mar 8, 2023

The OBO-wide discussion on adoption vs obsolete-and-replace is here
OBOFoundry/OBOFoundry.github.io#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
Copy link
Contributor

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
Copy link
Author

dillerm commented Mar 14, 2023

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."

@dillerm dillerm mentioned this issue Mar 14, 2023
Open
@zhengj2007
Copy link
Contributor

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
Copy link
Collaborator

hoganwr commented Mar 14, 2023 via email

@zhengj2007
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Collaborator

hoganwr commented Mar 14, 2023 via email

@alanruttenberg
Copy link
Contributor

@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
Copy link
Contributor

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
Copy link
Contributor

@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 zhengj2007 mentioned this issue Mar 15, 2023
Closed
@zhengj2007
Copy link
Contributor

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

@matentzn
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

alanruttenberg commented Mar 15, 2023 via email

@cmungall cmungall mentioned this issue Mar 16, 2023
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@cmungall @alanruttenberg @hoganwr @zhengj2007 @matentzn @dillerm