Menu
▾
▴
#285 1.100 b7 will not load cell.obo correctly
John,
I tried to load the cell.obo file using OBO-Edit 1.100 b7, but both the
current version (1.20) and the prior version (1.19) loaded incorrectly.
While both files did nominally load, the Ontology Editor panel shows a
large number of high level (root) terms, rather than the single "cell"
term that should only appear. OBO-Edit 1.002 does load the cell.obo
file correctly, so this must be a bug related to 1.1.
Furthermore, OBO-Edit 1.100 b7 loads the current version of the
adult_mouse_anatomy.obo file with a similar error, whereas OBO-Edit
1.002 loads this file correctly. Also the EMAP.obo loads with the same
error in the beta version, but not in 1.002.
In all cases I have restarted the program between ontology loads.
Also, the GO appears to load correctly in both beta and 1.002.
Strangely, in all case the Graph Panel shows a correct DAG structure for
any given term in these ontologies, even when the Ontology Editor
panel show the term as a root term.
(As an aside, I seem to have to reenter the path to the Graphviz
application on every restart of OBO-Edit 1.100b7, which is a bit
tedious.)
Thanks,
Alex
Logged In: YES
user_id=1200675
Alex, try checking your global filter plugin and whether the
relations are marked as transitive. I had the same problem
but was able to correct it.
melissa
Logged In: YES
user_id=1200675
The develops_from relation needs to be marked transitive.
Logged In: YES
user_id=865072
Melissa,
I changed the Link Filters under the Global Filters Plugin to match that in the copy of 1.002 I have running on a laptop next
to my main computer ("Link has NOT Is intersection"). The Term filters setting already was the same ("Is Property AND Is
Built In OR NOT Is Built In"). The change persisted after a restart, but cell.obo still loaded incorrectly.
-- Alex
Logged In: YES
user_id=865072
Melissa,
I added "is_transitive: true" to the end of the cell.obo file and the file loaded. So which behavior is correct: OBO-Edit 1.002
not requiring the "is_transitive: true" statement, or OBO-Edit 1.100 b7 requiring it.
Obviously if the "is_transitive: true" statement is required, then the loading of any number of ontologies by OE 1.100 may
affected by its lack. If it is not required, then OE 1.1 needs to be fixed. I obviously don't know the answer.
-- Alex
Logged In: YES
user_id=865072
I am now going to compound the issue by introducing the second error I found (which was actually the original problem I
noticed), which occurs despite the successful loading of the cell.obo file after the addition of the "is_transitive: true"
statement. When I try to save the file I get a fatal error, saying that term CL:0000055 has definition references, but no
definition. This is simply not true; in fact the opposite is true, namely CL:0000055 has a definition, but no definition
references, which is okay normally. Thus, there may still be a load problem.
I've uploaded a screenshot illustrating the CL:0000055 issue (compressed in an ugly way to fit SF requirements).
-- Alex
Logged In: YES
user_id=376396
Okay, sorry I've been slow on this one:
Issue 1) Melissa is exactly right. As of OBO-Edit beta7 or
so, OBO-Edit no longer shows non-transitive relationships by
default. You can still see non transitive relationships in
the Parent Plugin.
I don't think we should change this behavior.
If an ontology appears to be disconnected because of this
change, it means one of two things:
* The ontology is wrong. This was the case will cell.obo.
develops_from is a transitive relationship, and it should be
marked transitive. If a transitive relationship type isn't
correctly identified, the reasoner won't handle it
correctly, and chaos ensues.
* The ontology is full of terms without an is_a path (bad)
and with no transitive path to the root (really bad).
Either way, this new feature is a good way of alerting users
to these problems.
If you really want to make non-transitive relationships
visible by default, open the Global Filter Plugin and delete
the filter that hides non-transitive relationships.
Issue 2) This is a bug in the verification plugin message.
But definitions always require a reference, with no
exceptions. It's such an old requirement that it's even part
of the old GO flat file specification.
The bug is fixed in beta8.