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.

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

Document ObjectProperties/patterns for use in TC plugin #2

Open
cmungall opened this issue Sep 28, 2020 · 3 comments
Open

Document ObjectProperties/patterns for use in TC plugin #2

cmungall opened this issue Sep 28, 2020 · 3 comments
Assignees

Comments

@cmungall
Copy link
Member

Which OPs/patterns does the plugin work for?

This is a good opportunity to standardize across OBO

  1. all instances of C must be in T: C SubClassOf in-taxon some T // no need for only-in-taxon if in-taxon is functional
  2. no instances of C are in T: C SubClassOf in-taxon only not T
  3. there exists some instance of C in T (currently only used in Uberon): keep as annotation assertion for now?

Will the PTC plugin would with 1 + 2?

Note for 2 we have historically used an AP. This will still be necessary if ontology maintained in .obo. But we can standardize to the most precise OWL for use with this tool

@matentzn
Copy link

+1

@cmungall
Copy link
Member Author

Modification of the above, allowing for a canonical logical representation and a canonical shortcut

  1. all instances of C must be in T:
    a. Logical: C SubClassOf in-taxon some T // no need for only-in-taxon if in-taxon is functional
    b. Shortcut: no need
  2. no instances of C are in T:
    a. Canonical logical representation: C SubClassOf in-taxon only not T
    b. Alternative EL logical representation: C disjointWith in-taxon some T (depends on injecting GCIs into NCBITaxon)
    c. Canonical Shortcut: AnnotationAssertion: C never-in-taxon T
  3. there exists some instance of C in T
    a. Canonical logical representation: [a C] Type in-taxon some T
    b. Canonical shortcut: C present-in-taxon T

@cmungall
Copy link
Member Author

cmungall commented May 4, 2021

Note: none of the above can be considered to be statements about evolutionary gain or loss

It's important for us in GO to be able to indicate

  • gain in ancestral node X
  • lost in ancestral node X

@thomaspd's proposal here:

https://docs.google.com/presentation/d/1Z3d8SBz-BWHPV5a9oaniPypZIYzV7VzBwVcleLdpk_c/edit#slide=id.p

This essentially adds a qualifier to a TC such that it can be declared GLOBAL strengthening the meaning

  • Only in = Gained at the specified branch in evolution
  • Never in = Lost at the specified branch in evolution

These could be represented by paired statements. cc @balhoff

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants