-
Notifications
You must be signed in to change notification settings - Fork 1
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
FlyBase features not getting 'deprecated' annotation #243
Comments
Re-using a dedicated function sounds ideal. |
There seem to be some features that are only present in pdb and not kb...? Running same example query above finds no results in kb (may be the reason the 'deprecated' annotations are missing?) |
The problem this caused will be solved with #244, when obsolete terms stop coming in with expression curation. We may want to still consider using the update_ids function for image annotations in kb, so that any obsolete features could be updated automatically, but this is lower priority. |
Also - some 'deprecated' annotations are not booleans: |
I think this is because of the conversion of annotation properties axioms to Neo - with a couple of exceptions, the values are lists. This is needed in order to allow for multiple annotation axioms using the same property, e.g. if a term has two comments, a node cannot have two comment properties, so it gets one comment property with a list of two values. MATCH (n) WHERE n.iri="http://flybase.org/reports/FBtp0118395" AND NOT (n.deprecated[0]) RETURN n |
Ok, not what I would have expected (is there any case where a node would have multiple 'deprecated' annotations?), but I guess this is fine if it is consistent. |
It would be odd for an OBO ontology, but would be legal OWL. The owl2neo conversion is designed to be generic OWL loader. |
Example:
MATCH (f:Feature) WHERE f.label="P{β1WHI}" return f
Neither of these results has a 'deprecated' annotation in pdb, but FBtp0006497 is actually obsolete in FlyBase.
I am therefore getting a lot of 'duplicate_label' errors in the robot report for the driver ontology when trying to add FBti and FBtp features, with no easy way to know which class I should be using in each case.
We currently check whether a feature is obsolete in the update_from_flybase function, but for whatever reason, this doesn't seem to be working (and even if it was, it wouldn't tell us the replacement term).
A better way to do this might be to use the built in update_ids Chado function to tell us whether the id is 'current', 'updated' or 'split' and the replacement term(s). We could use this information to automatically transfer relationships from old to new terms as we do for FBbt.
If we do decide to transfer relationships, some FB IDs of features may no longer match the concatenated IDs used for splits.
The text was updated successfully, but these errors were encountered: