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

There are multiple terms that have "." as definition #2129

Closed
shawntanzk opened this issue Oct 25, 2021 · 35 comments · Fixed by #2200 or #2964
Closed

There are multiple terms that have "." as definition #2129

shawntanzk opened this issue Oct 25, 2021 · 35 comments · Fixed by #2200 or #2964
Assignees
@anitacaron
Labels
tech

Comments

@shawntanzk
Copy link
Collaborator

shawntanzk commented Oct 25, 2021 •
edited
Loading

There are multiple terms that have "." as definition - this seems super weird, it is triggering duplicate_definition. Will investigate. Examples include:

First 5 violations:
ERROR duplicate_definition UBERON:0000089 IAO:0000115 .
ERROR duplicate_definition UBERON:0000219 IAO:0000115 .
ERROR duplicate_definition UBERON:0000444 IAO:0000115 .
ERROR duplicate_definition UBERON:0001430 IAO:0000115 .
ERROR duplicate_definition UBERON:0001431 IAO:0000115 .

Note: this does have xrefs attached to it, so it seems it might have been accidentally removed or something?

Btws, found this when running sh run.sh make reports/uberon-edit.obo-obo-report.tsv
@cmungall
Copy link
Member

cmungall commented Oct 25, 2021 via email

@shawntanzk
Copy link
Collaborator Author

there are 131 duplicate definitions (not sure if all of them are these issues) so not an impossible amount to get defs for, but it will take awhile. Ideally would like the spread this out to the community if possible. The one that might be more difficult to address is the 2000+ entries with missing defs >.<
Perhaps given they already have xrefs attached to them, we can tackle the 131 defs among the community (like im happy to take the brain regions and all, and whoever else can get involved in whatever their area of expertise is), and in the meantime we can change duplicate_definition to WARN instead of ERROR till we address it? thoughts?

@matentzn
Copy link
Contributor

Can we put discussing the ROBOT report on the agenda for next time? I will explain how some of it works and how to interpret these definitions with .

@shawntanzk
Copy link
Collaborator Author

already on the board :)

@shawntanzk shawntanzk reopened this Nov 22, 2021
@shawntanzk
Copy link
Collaborator Author

shawntanzk commented Nov 22, 2021 •
edited by gouttegd
Loading

  • @gouttegd to look into this in makefile to see where this should come from
  • @shawntanzk will follow up if we can't figure this out

@gouttegd
Copy link
Collaborator

The “.” definitions are not injected from anywhere in the pipeline, they come straight from the -edit file.

Contrary to what we have in FBbt, in Uberon it does not seem that there is anything in place in the pipeline to deal with “dot-definitions“.

For reference, what happens in FBbt is that terms with “dot-definitions” are extracted (using this SPARQL query), and processed by a custom Java program (apparently specifically written for FlyBase) to generate textual definitions from the logical definitions.

Not sure if we want to apply the FlyBase approach in Uberon (of note, some Uberon terms with a “dot-definition” don’t have a logical definition, so that approach would not work anyway for them)… For 131 terms, I am inclined to say the FlyBase approach is overkill and that it would be easier and faster to have the curators manually add a proper definitions to all those terms…

@shawntanzk
Copy link
Collaborator Author

@cmungall @dosumis might need help with this

@cmungall
Copy link
Member

cmungall commented Nov 22, 2021 via email

@matentzn
Copy link
Contributor

@cmungall the question is, what exactly are they placeholders for? Where is the pipeline that fills them in with actual definitions?

@gouttegd
Copy link
Collaborator

My understanding is that they are just placeholders waiting to be replaced by an actual definition by a human editor. They are not intended to be automatically transformed into something (contrary to what we do in FBbt), they are just here to remind the editors that a real definition will need to be put here sometimes in the future (with the xref giving a clue about where to find the information to create the definition).

@matentzn
Copy link
Contributor

Usually they are placeholders for some kind of pattern based replacement strategy. If it is to remind humans, I would vote to ditch them.

@uberon
Copy link

uberon commented Nov 22, 2021 via email

@uberon
Copy link

uberon commented Nov 22, 2021 via email

@cmungall
Copy link
Member

cmungall commented Nov 22, 2021 via email

@anitacaron
Copy link
Collaborator

I'll check if it was fixed in the new release.

@anitacaron anitacaron mentioned this issue Nov 29, 2021
Merged
@shawntanzk shawntanzk mentioned this issue Dec 13, 2021
Closed
@shawntanzk shawntanzk reopened this Dec 13, 2021
@shawntanzk
Copy link
Collaborator Author

shawntanzk commented Dec 13, 2021 •
edited
Loading

There still seems to be some "." defs - eg UBERON:0004133 or UBERON:0001606

@shawntanzk
Copy link
Collaborator Author

@anitacaron to relook at this

@anitacaron
Copy link
Collaborator

From the OWL artefacts, this issue is still present only in uberon-base.owl,uberon-full.owl and basic.owl files.

@shawntanzk
Copy link
Collaborator Author

the . defs are not in uberon.owl which is good, however, we might need to look into implementing this on -base file if these are going to be used for imports

@matentzn
Copy link
Contributor

Can someone figure out where they come from, i.e. from withing uberon-edit.obo? I am assuming these are from some import?

@shawntanzk
Copy link
Collaborator Author

just checked uberon-edit.obo - the . defs are there

@matentzn
Copy link
Contributor

In an import or the actual file?

@matentzn
Copy link
Contributor

ah sorry.. of course.. I am stupid. I meant, the . definitions that are still in uberon-base.owl, are they from uberon-edit or an import?

@shawntanzk
Copy link
Collaborator Author

I assume edit file given that I checked UBERON:0004133 and both edit and base file has the . def

@matentzn
Copy link
Contributor

ok so it is an @anitacaron issue. Thanks for checking!

@anitacaron
Copy link
Collaborator

anitacaron commented Jan 17, 2022 •
edited
Loading

I read Chris' comment carefully and first need to modify uberon-edit file before deleting the 'dot definitions'.

  • The phenoscape ones should be replaced by created-by dcterms:contributor
  • GO and MP provide some kind of provenance
  • The issues xrefs could be demoted to seeAlso
  • the wikipedias could be turned to class xrefs but may as well just go
    through and add defs quickly

Also, I checked uberon.Makefile and it seems not taking uberon-edit.obo, but uberon-edit.owl that is in the temporary folder.

@matentzn
Copy link
Contributor

Also, I checked uberon.Makefile and it seems not taking uberon-edit.obo, but uberon-edit.owl that is in the temporary folder.

tmp/uberon-edit.owl comes from uberon-edit.obo :)

Thanks @anitacaron for the breakdown!

@anitacaron
Copy link
Collaborator

The delete-dot-definition SPARQL query is only used in tmp/uberon-edit.owl; that's why they're still in the uberon-edit.obo file.

@matentzn
Copy link
Contributor

Yeah the question is, how do they end up in uberon-base, or basic.owl? These are all derived from tmp/uberon-edit.owl..

@anitacaron
Copy link
Collaborator

After look the graph generated from the makefiles, they all came from uberon-edit.obo defined on the main Makefile. They're not overridden on uberon.makefile.

@matentzn
Copy link
Contributor

That is the problem. its also a bit of a general problem with makefiles.. Ideally, we have

  • Nothing in the makefile dependent on uberon-edit.obo, except tmp/uberon-edit.owl
  • Everything that previously dependent on uberon-edit.obo ($(SRC)) now depending on tmp/uberon-edit.owl.

This is going to be hard, but if it works for Uberon, we can generalise this for ODK.

@paolaroncaglia paolaroncaglia mentioned this issue Feb 23, 2022
Closed
@paolaroncaglia
Copy link
Contributor

Also see #2053

@matentzn
Copy link
Contributor

After this is solved than uberon-base will depend on tmp/uberon-edit and then the dot removal will work.

@matentzn matentzn added the blocked blocked by another issue label Feb 28, 2022
@shawntanzk shawntanzk mentioned this issue Oct 27, 2022
Closed
@github-actions
Copy link

github-actions bot commented Feb 8, 2023

This issue has not seen any activity in the past 6 months; it will be closed automatically one year from now if no action is taken.

@github-actions github-actions bot added the Stale label Feb 8, 2023
@anitacaron
Copy link
Collaborator

We'll have a new ODK release soon that will fix the issue only in the release artefact. The 'dot definitions' will still be present in the edit file.

@github-actions github-actions bot removed the Stale label Feb 15, 2023
@anitacaron anitacaron mentioned this issue Jul 10, 2023
Merged
@matentzn matentzn removed their assignment Jul 24, 2023
@gouttegd gouttegd mentioned this issue Nov 27, 2023
Merged
@anitacaron anitacaron removed the blocked blocked by another issue label Dec 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@anitacaron anitacaron

Labels
tech
Projects
None yet
Milestone
No milestone
7 participants
@cmungall @uberon @anitacaron @paolaroncaglia @matentzn @gouttegd @shawntanzk