Comments (18)
Regarding the adoption approach, I think we don't have a SOP yet and it might be not very simple.
Using APOLLO_SV_00000033 'counting' as an example. Current situation:
- APOLLO_SV_00000033 'counting' is in IAO and suppose to maintain the term.
- http://purl.obolibrary.org/obo/APOLLO_SV_00000033 redirect to APOLLO_SV rather than IAO.
- APOLLO_SV_00000033 'counting' is in APOLLO_SV as well and but not import from IAO.
- OBIB has the APOLLO_SV_00000033 'counting' that is imported from APOLLO_SV rather than IAO.
For adoption, I think we need to
- Indicate APOLLO_SV_00000033 'counting' is an adopted term in IAO. It seems we have reach agreement to use 'rdfs:is defined by'.
- http://purl.obolibrary.org/obo/APOLLO_SV_00000033 should redirect to IAO.
- APOLLO_SV should import the term from IAO since APOLLO_SV gave the term to IAO. Otherwise, if IAO modify the APOLLO_SV_00000033 'counting', the APOLLO_SV won't update the term accordingly.
- OBIB should import the term from IAO.
However, how to notify all ontologies importing APOLLO_SV_00000033 that IAO adopted the APOLLO_SV_00000033 'counting' and to import the term from IAO?
Maintaining an adopted term is an issue unless the term won't change after adoption. That is why I prefer the migration if the term is not widely used like 'part of'/'has part'.
from obofoundry.github.io.
I want to clarify my comment. It was not meant to be hostile. I apologize to those of you who interpreted it that way.
I just wanted us to pause and try (if that is possible) to assess the level of importance regarding this issue.
- Is it mission critical?
- Does having these tags need to be an OBO wide policy? Or is it something that is nice to have?
- If an ontology doesn't adopt the metadata tags, is there a default interpretation?
- If the GO community decides that it will only adopt another ontology's terms if it can mint a new IRI, then does the rest of Foundry have to also make its preference known?
from obofoundry.github.io.
A circumspect side note that this problem exists because of a technical decision to bake into the IRI directly the ontology it originates from e.g. obo:FOODON_12345670, rather than at the community level (e.g. obo:OBOLIB_000012345670) where a community considers a term a part of its language, and makes consensual decisions about which ontology team curates it over time. Some day a curation platform will provide a purl resolver that returns not just the semantics of a term, but also the current ontology curation team that manages it; this just requires a trustworthy centralized dispenser of new ids on request by curators, like DOI or ISBN do. (A future fantasy is that OBO could be transitioned to this via an overlay.)
from obofoundry.github.io.
Following up on the proposal (in the example) to:
GO takes ownership of OMIT:1234. The term is moved to the GO edit. It gets a rdfs:isDefinedBy with value GO
Perhaps we should automatically do this for every ontology class as part of the release process?
from obofoundry.github.io.
(I have not read all in detail) but on this
In this hypothetical scenario, we say GO "adopts" OMIT:1234, and OMIT:1234 was "adopted by" GO (or "donated to" GO)
Be sure to check PROV-O and/or PAV properties that could be relevant to represent this.
from obofoundry.github.io.
from obofoundry.github.io.
It's shortsighted to legislate this. We're building for the long run, longer than the current developers are going to be involved. This is an unnecessary invitation to exercise power unwisely. If there's a need to adopt or to give up terms that should be left to the developers of the time. The guiding principles are that we want good management and orthogonal ontologies and stability of identifiers. During the development of ontologies its not infrequent that one has to define a term in a domain that isn't developed yet. Or, an ontology may become large enough that it's profitable to delegate management of some branch to another group. Once can imagine a variety of scenarios.
I fail to see how this would even be useful under any circumstances.
from obofoundry.github.io.
It seems this is one of the practices across OBO that causes significant disagreement - wouldn't it be good to provide a way to simply name, from the perspective of an ontology, which practice they follow so that we have some grounds to start a conversation? This is not normative or anything, just capturing the current practice, and if future owners of the ontology will change their strategy, that is no problem at all? While I am also against legistlating anything, I think capturing the different strategies in the metadata is a useful basis for a future workshop on the subject.
from obofoundry.github.io.
This proposal would ends the conversation before it starts, instead of considering the issue on its merits.
from obofoundry.github.io.
Getting everyone to document their position publicly would end the conversation? How?
from obofoundry.github.io.
So we license any bad practice as long as it's disclosed? It's bad practice to change IRIs and it's bad practice to duplicate IRIs. These are principles that were there from the beginning of the effort. This sort of thing shouldn't be a matter of opinion.
from obofoundry.github.io.
I don't know Alan. It's pretty clearly a trade-off. Bad practice according to you, good practice according to others. There is no universal truth here. I respect your opinion, but please provide an alternative path to further this discussion in a constructive way.
from obofoundry.github.io.
from obofoundry.github.io.
Ok, how do we proceed? Everyone adopting your position?
from obofoundry.github.io.
In general, I am apprehensive about changing IRIs unless the semantics have been changed.
That being said, do we have an metrics on the scope of the problem?
- How many ontologies (or ontology groups) are affected?
- What is the cost of leaving things as is vs. adopting a new policy?
from obofoundry.github.io.
Thanks @wdduncan!
To clarify, my proposal was not to make the field a required field in json schema. Like most of the metadata fields we have, this would be optional. I was not proposing to create any new policies (except insofar as a statement that not having a policy is a statement of policy)
If an ontology doesn't adopt the metadata tags, is there a default interpretation?
An absence of a value would mean that we have no information on whether the ontology is willing to donate or accept terms. Perhaps the information is not curated, perhaps the ontology does not wish to declare this, perhaps they are still discussing it internally, perhaps the maintainers are even unaware that adoption/donating is a thing.
Is it mission critical?
I suppose not (I am not sure how many of our current 48 fields are).
However, I think the entire OBO community would vociferously agree that identifiers, PURLs, and identifier lifecycle are important issues and deserving of the attention of OBO operations.
Unfortunately, we do not all agree what that means in practice when it comes to transferring IDs across ontologies. This can be seen in the same discussions that repeatedly crop up in different issue trackers. In the absence of any one best practice across OBO, we owe it to our users, to developers of existing ontologies, and to developers of new ontologies to be as clear and transparent as we can be.
from obofoundry.github.io.
@ddooley I've been thinking the same thing. When we started up I had colleagues who suggested following how handles work. There's less emotional attachment to a number than a meaningful string. What this discussion has reinforced is that if you give an identifier even a smidgen of semantics, that bit will be a magnet for making unnecessary changes. If I had to do it over again, knowing what I do now, I would do as you suggest.
I'm not keen on the idea of an overlay, but there's no technical reason that starting today we switch to the scheme you suggest. It's not like its rocket science to represent and use an association between identifier and manager.
from obofoundry.github.io.
do we have an metrics on the scope of the problem?
I second that question.
And relatedly:
There is no new information that has entered the picture that is even close to worth considering compared to the damage this practice causes.
I’ve got a glimpse first-hand of the problems caused by adoption (more than enough for my taste), but I have not experienced (yet!) any issue caused by obsolete-and-replace. Any pointers where I could learn more about said damages? Discussions about past cases or things like that?
The only case I know about is the one mentioned in the ticket (GO:00005623 -> CL:0000000), and I am not aware that it has caused huge issues (but admittedly, this happened before my time, so maybe I just don’t know where the bodies are buried!).
from obofoundry.github.io.
Related Issues (20)
- Principle #13 "Notification" <ENTER ISSUE TITLE>
- Quick access button should provide access to all products HOT 2
- Adding adoption declaration as a requirement to principle 8 (original suggestion: P3) HOT 4
- Request for new ontology [COVID-19 Epidemiology and Monitoring Ontology] HOT 9
- Typo: "Resouces" instead of "Resources" HOT 3
- using IRIs as URLs -- http:// in a world that wants https:// HOT 4
- New metadata tag: "defective" (ontology status) HOT 14
- NCIT (national cancer institute thesaurus) OBO Edition Links are broken for Chrome HOT 3
- Game plan: What should happen on 01.01.2024 when passing Dashboard becomes mandatory? HOT 8
- Formally registering the COC committee HOT 17
- Links to OntoBee fail to land at appropriate page HOT 6
- How to contact OBO Operations?
- Add action to automatically update PRs with tox -e lint HOT 2
- Add proper check for version IRI error HOT 1
- Request for new ontology [Graphic Notation and Descriptor Ontology] HOT 10
- Principle #20 "Responsiveness"
- Do we differentiate checks for ontology metadata based on their activity status HOT 2
- Question about MIREOT and two closely related domain ontologies HOT 4
- Bug in display of newsletter HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from obofoundry.github.io.