Comments (8)
@thomaspd The extraneous “enabled_by (protein-containing complex)” statements you see in Noctua aren't actually asserted anywhere or inferred by a reasoner, they are an artifact of how the Noctua display works and the lack of a reference ontology for protein complexes. Noctua really needs the nodes in the models to be annotated with OWL classes and we have no classes for most complexes.
To make this work for new complexes, the converter currently adds 2 rdf:types to each new complex node. It first adds the generic type 'protein-containing complex' which is not incorrect and is needed for downstream reasoning. Next it adds a kind of fake class (in that its not represented in any ontology and not useful for inference) with a name like "WNT:FZD:p5S/T-LRP5/6:DVL:AXIN:GSK3B". The only purpose for this one at the moment is to show a label in Noctua. Noctua shows all direct types in the display, hence you see both.
For proteins, Noctua loads the Neo ontology which instantiates a class for each protein it knows about and allows the display to function. If we want to use Noctua for dealing with complexes we either need to have them represented in something like Neo in advance of going into the editor or we need a way to create the needed classes on the fly or in the models that get imported. Right now any new classes (additions to the 'tbox') in new models are ignored.
from pathways2go.
Moved last point to new issue #20
from pathways2go.
@cmungall what is your take on how to represent complexes in GO-CAMs ? This needs a decision so that my code, curators entering new complexes, and the UI can move forward effectively. Specifically, when a new complex comes into a model that does not have an associated class in neo, (e.g. in the above WNT:FZD:p5S/T-LRP5/6:DVL:AXIN:GSK3B) do we need to generate a new class? If so, how should we approach that? If not, how should we give the entity a visible name in the editor and assure that the system knows what it is for reasoning purposes.
For the short term, I suggest the latter approach. Tag the entity with a generic 'protein complex' class, do not create a new class, have the UI use the RDFS:label to accept and display an informative name, and add the parts of the complex using the has_part relationship such that if and when there are logically defined complex classes in the GO or elsewhere a more specific classification can be inferred automatically. The only code required would be logic in the Noctua UI to show the label instead of 'protein complex' for the nodes in question.
from pathways2go.
s/protein complex/macromolecular complex/
I agree, but I don't know if there is a need to make an rdfs:label (and this adds complexities, e.g. what if a user wants to change this). I would just do a pure post-composition approach.
I can see a use for a generic name-this-individual function (whether for complexes or any other subgraph), perhaps using DOSDPs. But is the immediate need not somewhat subsumed by having the visuals fold/compact these? (which may not always work, but that is something to be fixed separately)
from pathways2go.
There is still a need to refer to the complex individual in the folded view. See for example, the reaction/function 'Autoglucosylation of GYG2 complexed with GYS2-b' http://noctua-dev.berkeleybop.org/editor/graph/gomodel:-670700788
Its more informative and natural for a user to see enabled_by "GYG2:GYS2-b tetramer" than it is to see enabled_by 'protein complex'.
(But yes, this also brings up the problem of folding in complexes with parts into single function nodes which i have added to geneontology/noctua#581 .)
from pathways2go.
I guess if you really want to avoid the label (which the UI already supports to some extent via geneontology/noctua#536 ) UI work could be moved over to the folding/expansion problem. Users could either see the generic complex node and click to expand to see what it was made out of or there could be a way to dynamically compose a name to show based on the names of the parts.
from pathways2go.
Switching off the UI optimizations for Noctua 1.0 flag addresses: "There are extraneous “enabled_by (protein-containing complex)” triplets". There will now only be one type shown for these complexes, but its going to be the generic, but ontologically extant 'protein-containing complex'. The linguistically meaningful but logically useless fake classes are out per discussion above with @cmungall . Showing a name for these new unidentified complexes is now going to be a UI problem (which can be approached based on inspection of their parts which do have names).
from pathways2go.
Closing - data issues resolved, UI issues e.g. geneontology/noctua#581 (comment) remain.
from pathways2go.
Related Issues (20)
- Convert chemicals to ChEBI rather than Reacto HOT 7
- Aspartate and asparagine metabolism (R-HSA-8963693)
- Something is weird about the import of Regulation of glycolysis by fructose 2,6-bisphosphate metabolism - imported from: Reactome HOT 4
- Regulation of glycolysis by fructose 2,6-bisphosphate metabolism (R-HSA-9634600)
- Deprecated or suboptimal UniProtKB accessions referenced in Reactome HOT 7
- Same entity?
- Representation questions (more to add later; didn't want to lose the notes)
- Reaction intermediates: out of scope? HOT 1
- Regulation of ChREBP (MLXIPL) ( R-HSA-163765, R-HSA-163680, R-HSA-163358, R-HSA-163767) HOT 1
- Triglyceride biosynthesis (R-HSA-75109) HOT 1
- Reactome proteoforms that point to deleted UniProt entries HOT 4
- Report for missing ChEBI IDs in release 83 work HOT 9
- Orphan gene products are showing up in pathways HOT 2
- Add starting locations for transported molecules HOT 1
- Analysis of missing ChEBI identifiers
- Cleanup of an ChEBI non pH7.3 chemicals
- fix errors in fructose metabolism R-HSA-5652084 HOT 2
- YeastPathways import: "source: null:*pathway-name" instead of "source: SGD:*pathway-name*" HOT 4
- providedBy: URLs inconsistent between users from same group HOT 3
- Header on the "clone evidence" popup has a gomodel: that doesn't match the model title HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pathways2go.