Add github_date_added field to ontology metadata
#1969
Conversation
Note, the script failed to add a few that I had to go and do manually: ERROR AISM added: 'added' is a required property ERROR APOLLO_SV added: 'added' is a required property ERROR EPIO added: 'added' is a required property ERROR FIDEO added: 'added' is a required property ERROR NCIT added: 'added' is a required property ERROR OMO added: 'added' is a required property ERROR OOSTT added: 'added' is a required property ERROR XLMOD added: 'added' is a required property
matentzn
left a comment
matentzn
left a comment
There was a problem hiding this comment.
You are absolutely nuts and I love this PR. Big approve.
I will circle it to operations now via email, but I don't see how there should be an issue.
|
Tentative merge date: Friday 24th June. |
There was a problem hiding this comment.
I think these ones with 2015-07-28 are wrong/misleading (also some ones marked a month or so after that). That is the date when I created the first version of the registry in github which is purely a technical detail. Many of the ontologies were part of the first OBO in 2003.
Let's leave any field we don't know the answer for blank. If anyone has the inclination to do the archaeology they can do it in a separate PR
ontology/peco.md
Outdated
| repository: https://github.com/Planteome/plant-experimental-conditions-ontology | ||
| preferredPrefix: PECO | ||
| depicted_by: http://planteome.org/sites/default/files/garland_logo.PNG | ||
| added: 2017-06-05 |
There was a problem hiding this comment.
this isn't correct. This was a prefix move from OE. PECO/EO have been in OBO for over a decade
There was a problem hiding this comment.
Well let's say that this is indeed the first date that the peco.md file was committed to this git repository. I think we can save quite a bit of time (and still accomplish the original goal of adding it) if we change the communication about this field rather than the content itself
|
To make it even more scary, you could https://web.archive.org/web/*/obofoundry.org |
cthoyt
changed the title
added field to ontologiesgithub_date_added field to ontology metadata
|
From my understanding, the two requests for changes were either to
The problem with Option 1 is that the file Chris attached in #1969 (comment) is very difficult to read through and after trying unsuccessful to download the OBO Sourceforge with SVN, I determined that this option was too much effort. The problem with Option 2 is that making this field optional means that there is no way to test its integrity - new ontologies would simply omit the field, then we would not be any further than before. What I explicitly want to capture is the date on which the file was created on GitHub. This is a good enough proxy for date added to OBO Foundry for the purposes of enabling us to apply potential new metadata standards based on the date the ontology is added, i.e., exert stricter standards on new ontologies while not forcing old ones to make updates. Rather than making a technical solution based on options 1 and 2, I opted to update the way this improvement is communicated. In 9ee8179, I renamed the field Nico mentioned that this could be calculated on-the-fly using the same git command that I encoded in https://github.com/cthoyt/OBOFoundry.github.io/blob/7fdface2c60757ee680f63264adb35aaff980df5/util/add_dates.py#L20, but this would only work if the data from the repository is in a git context (i.e., what if we want to consume the data directly, what if it gets put into a python package..), so I think that having this explicit is still important. |
matentzn
left a comment
matentzn
left a comment
There was a problem hiding this comment.
I am fine with this, but lets make sure we get at least one or two others to chime in.
Remember all: this information is purely for technical purposes, not for display on the website.
|
As long as the documentation goes to great pains to make this clear, so no
one is out there assuming it means date ontology added (as opposed to the
date some file was added to some repo), then I suppose I am ok with that.
…On Wed, Jun 22, 2022 at 5:49 AM Nico Matentzoglu ***@***.***> wrote:
***@***.**** commented on this pull request.
I am fine with this, but lets make sure we get at least one or two others
to chime in.
Remember all: this information is purely for technical purposes, not for
display on the website.
—
Reply to this email directly, view it on GitHub
<#1969 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJR55QZVRYNT5GQNVHMABTVQLOTJANCNFSM5ZCS3WOQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***
com>
|
|
Damion: Being part of OBO involves some work over the years. I like an annotation that indicates when their ontology was added to the OBO Library. Allowance for ontologies that can't use GitHub (But Charlie's aim: when was metadata record to OBO Library). |
|
Want to salvage anything from this PR @cthoyt ? |
|
as of #2277, there's a more simple way of adding new checks that only apply to new ontologies going forward, so I'm abandoning this PR. |
5 participants
Closes #1967
What: This PR crawls the git history from this repo to figure out when each ontology metadata file was created, then annotates it into the frontmatter of the ontology metadata. This is applicable to inactive, active, orphaned, and obsolete ontologies. This information is purely for technical purposes, and not meant to be displayed on the website. This PR also adds the corresponding field to the metadata JSON schema for validation purposes.
Why: In order to exert more strict standards on new ontologies, it makes sense to have a way to not have to retroactively apply them to old ontologies (which might not be able to update in a timely manner before imposing new standards). Therefore, all new OBO Foundry standards can be optionally tagged with the date when they go active, and ontologies added before that date don't necessarily have to conform.
How
Note, for some reason, this script failed to add the metadata for a few ontologies, which I then did manually: