geneontology / noctua Goto Github PK

Sometimes I want more real estate for the nice graph views. The left panel and bottom panel aren't always required. It would be nice to have a button to pop this out to fullscreen

Like in the main app.
May need to create new manager for this.

Would like to start a general framework for adding things like this on startup, scan plugins namespace and add things found to the plugins found, eg:

bbop.mme.plugin.foo = function([???]){
this.name = "Bar";
...
};

Would have the option of adding tab to lower area.
Would be one of these types: always on, toggleable, clickable.

Chris's dl query ( #1 ) would be the clickable type--operating incrementally on that event, likely having the ability to add classes to the display to accomplish the activity. Plugins would be able to store their own state.

I think that with this, several of the things in tabs now could be rewritten as plugins, improving code structure.

Add a view option to show only boxes that have an enabed_by assertion. Low priority

Looks like just plugins and overrides. Started already with:

connectors-sugiyama.js

There are stubs to start prototyping this.
Basic.js
basic_content.tmpl

The current "system" is a rather lame: just a poor hardcoded list. We need to replace this with something more flexible delivered from some source over the wire.

Currently, the evidence model is too simple and needs to be reworked to contain references, etc.

As well, it needs to be applied to embedded instance edges.

(file under non-urgent)

col1: molecular entities (things that are the subject of enabled bys, possibly the leaves in the class expression if a complex/class expression)
col2: ontology classes (targets of direct type assertions, plus targets of occurs in)
col3: publication(s). The first one listed should be any annotation assertion at the level of the model

For look and feel, see:
http://curation.pombase.org/genotypetest/curs/23297b95cc45755a

Might also by nice to eventually have a user page like this:
http://curation.pombase.org/genotypetest/

We would like to be able to add metadata at the level of the model.

On the server, this would be implemented as a collection of OWLAnnotations, where each OWLAnnotation is essentially a property-value pair: http://owlapi.sourceforge.net/javadoc/org/semanticweb/owlapi/model/OWLAnnotation.html - an annotation is either URI or an XSD literal (number, string, etc)

The set of properties are open ended, drawn from vocabularies such as rdfs, dublin core. Of particular interest:

• dc:title - e.g. "wnt signaling in epithelial crypts in mouse"
• dc:description - similar to an abstract in a paper
• dc:author - auto-filled using persona?
• dc:created - auto-filled
• rdfs:comment - zero or more per model
• dc:source - e.g. pubmed URL
• ?:status - e.g. in-progress, in-review, completed.

The client code should not care about any property in particular, it should be generic. We may want the server to provide the list on request; or it could be in the client config. The exception may be some kind of status field that determines whether the model is persisted on the server.

The metadata interface would be a simple form-like interface; properties could be autocompletes or pulldowns. We may want to allow users to enter an arbritrary URI for a property.

Some of the metadata could be exposed on the front page for model selection (but this functionality will likely be subsumed by amigo)

Consider merging launcher and messenger into a unified server. Client sends to moderator, moderator checks and passes to MMM, gets response from MMM, passes back to all clients (with intention?).

• message queue to prevent races, etc. could catch conflicts early
• would also mean that a&a could be entirely on the client, with the MMM server just listening to whitelist addresses or something.
• could also mean that the layout is stored by the messenger server, allowing people a more sane way to interact without conflict (by going all-in on shared)

Possibly need to add intentions to the server calls.

Need temporary reminder to users that they are dealing with alpha software.

Probably a dismissible modal.

Consider plugin architecture, maybe as part of refactor.
Would like to start a general framework for adding things like this on startup, scan plugins namespace and add things found to the plugins found, e.g.:

bbop.mme.plugin.foo = function([???]){
  this.name = "Bar";
  // ...
};

Has option of adding tab below.

Is one of these types: always on, toggleable, clickable.

Chris's DL query (#1) would be the clickable type--operating incrementally on that event, likely having the ability to add classes to the display to accomplish the activity.
Plugins would be able to store their own state.

I think that with this, several of the things in tabs now could be rewritten as plugins, improving code structure.

This will be a gather involved enhancement.
Should go after other refactors.

Pipeline from Reactome. Ideally, the user is able to just input an ID somewhere and have the converted model loaded/merged in.

Questions about exactly when in the process this would be best.

Tasks to be completed by the GO meeting in Texas, at College Station.

Using the Jenkins pipeline to seed LEGO from GAFs?
Possibly for Chris.

It should be impossible to make this model. Note: the implementation needs to happen in the ontology before we can do anything in the UI here.

Prefix: owl: <http://www.w3.org/2002/07/owl#>
Prefix: rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
Prefix: xml: <http://www.w3.org/XML/1998/namespace>
Prefix: xsd: <http://www.w3.org/2001/XMLSchema#>
Prefix: rdfs: <http://www.w3.org/2000/01/rdf-schema#>



Ontology: <http://purl.obolibrary.org/obo/gomodel_pombase-52fa621d0000002>

Import: <http://purl.obolibrary.org/obo/ro.owl>
Import: <http://purl.obolibrary.org/obo/go/extensions/ro_pending.owl>
Import: <http://purl.obolibrary.org/obo/go.owl>

ObjectProperty: <http://purl.obolibrary.org/obo/RO_0002211>


Class: <http://purl.obolibrary.org/obo/GO_0048018>


Class: <http://purl.obolibrary.org/obo/GO_0004707>


Individual: <http://purl.obolibrary.org/obo/gomodel_pombase-52fa621d0000002-GO-0004707-52fa621d0000004>

 Types:
 <http://purl.obolibrary.org/obo/GO_0004707>


Individual: <http://purl.obolibrary.org/obo/gomodel_pombase-52fa621d0000002-GO-0048018-52fa621d0000003>

 Types:
 <http://purl.obolibrary.org/obo/GO_0048018>

 Facts:
 <http://purl.obolibrary.org/obo/RO_0002211> <http://purl.obolibrary.org/obo/gomodel_pombase-52fa621d0000002-GO-0004707-52fa621d0000004>

There should no HTML in App.js--everything display should be through a widget or an API.
Need to simplify codebase and enforce separation.

@cmungall As discussed, I've re-added the separate templates for BP and MF. Just to have it on hand, what are the autocomplete field constraints that you're interested in? If necessary, dynamic could be a possibility.

Use the Jenkins pipeline to produce GAFs from LEGO. Probably for Heiko.
Questions:

• annotation extensions?
• should we use BP and CC in the extension column?
• should it go to GPAD-1?

The ability to export global(!) data for viewing.
Flat?
XGMML?
How do we link?
Webcytoscape or desktop?

Use MyGene?

http://localhost:8910/seed/model/gomodel:wb-GO_0043053

It appears that chrome and ff have different opinions about where "nuclear import" should be might be confusing (although, if telekinesis is allowed, they would almost immediately align with a jump).

See how serious this is.

Currently using /getRelations in bootstrap, need to switch to the new handler.
Talk to Heiko if you forget (again).

This touches on issues of metadata, versioning, and what to do in the long run with the backend.
Like #33 and #34

Allow the display/manipulation of comments.

When editing model level annotations, we want:

• open-ended properties
• don't show evidence type
  • Really? What if the model as a whole comes from a single source, like a textbook?

server should now return separate top level list of facts (ObjectPropertyAssertions) keyed under "facts". This is redundant with with the OPAs returned within individuals, keyed by property shortId, which is now deprecated, and will be removed in future.

{
  // USE ME
  "facts": [
    {
      "object": "gomodel:52f19a000000001-GO-0004872-52f19a000000002",
      "property": "part_of",
      "subject": "gomodel:52f19a000000001-GO-0007166-52f19a000000003"
    }
  ],
  "properties": [
    {
      "id": "part_of",
      "type": "ObjectProperty",
      "label": "part_of"
    }
  ],
  "individuals": [
    {
      // IGNORE ME
      "part_of": [
        {
          "id": "gomodel:52f19a000000001-GO-0004872-52f19a000000002",
          "type": "NamedIndividual"
        }
      ],
      // END OF IGNORE ME

      "id": "gomodel:52f19a000000001-GO-0007166-52f19a000000003",
      "type": [
        {
          "id": "GO:0007166",
          "type": "Class",
          "label": "cell surface receptor signaling pathway"
        }
      ]
    },
    {
      "id": "gomodel:52f19a000000001-GO-0004872-52f19a000000002",
      "type": [
        {
          "id": "GO:0004872",
          "type": "Class",
          "label": "receptor activity"
        }
      ]
    }
  ]
}

Richer and nested evidence. What should the end model look like? Obviously more than the current annotation model.

This will relate to:

• what metadata we store and how it operates with a&a for model recovery
• what is permissible and what remote sources we have for initial generation

It should be possible to attach any OWLAnnotation (prop-value pair: not an annotation in the GO sense) to any individual. We may want to provide a shortcut for some like rdfs:comment, and have special default (but customizable) behavior in the plumb view.

A user should be able to click on a box, select "add comment", and then type in free text.

We may want this to be visible on a mouseover.

Will need to finish merge's gut-and-redraw code.

Graph addition templates need to have easier and more independent configuration options.

Possibly change in screen color, etc.

authentication and authorization

Depends, is related to, #14

Feature request by David when trying a more complicated example.

The take away from the request is that there is an option at the [model] level that says something like [Add PMID to all instances] -> pop-up with single input, and then batch request for all additions.

Time saver in larger models.

activate - arrow ->
inhibition - bar -|
neutral, such as upstream - diamond -<>

A proposed draft of a save agent. Chris believes that just a cron job would be easier, if less powerful.

#/!bin/bash
set -e
# Any subsequent commands which fail will cause the shell script to exit immediately

# Default values
DO_UPDATE="FALSE"
DO_COMMIT="FALSE"
WORK_FOLDER="$(pwd)"

## Command line parsing
while [[ $# > 0 ]]
do
key="$1"
shift

case $key in
    -u|--update)
    DO_UPDATE="TRUE"
    ;;
    -c|--commit)
    DO_COMMIT="TRUE"
    ;;
    -f|--folder)
    WORK_FOLDER="$1"
    shift
    ;;
    *)
      # unknown option
    ;;
esac
done

#echo "DO UPDATE   = $DO_UPDATE"
#echo "DO COMMIT   = $DO_COMMIT"
#echo "WORK FOLDER = $WORK_FOLDER"

if [ "$DO_UPDATE" = "TRUE" ]; then
  echo "UPDATE Folder: $WORK_FOLDER"
  svn update --accept mine-full $WORK_FOLDER
fi

if [ "$DO_COMMIT" = "TRUE" ]; then
  echo "ADD unversioned files to SVN in folder: $WORK_FOLDER"
  svn st $WORK_FOLDER | grep "^\?" | awk "{print \$2}" | xargs svn add $1

  echo "COMMIT folder: $WORK_FOLDER"
  echo svn commit -m"automatic updated of models" $WORK_FOLDER
fi

Add a new tab in the bottom div (e.g. to the right of EMPTY)

The tab should contain a simple textbox, in which advanced users can type DL expressions such as one of the following:

• 'kinase activity'
• 'part_of' some 'dauer entry'
• 'regulates' some 'dauer entry'
• 'occurs_in' some 'cell'
• 'occurs_in' some 'extracellular region' and 'regulates' some 'kinase activity'
• 'enabled_by' some 'gene123'

In future this could be assisted by autocomplete, but this is
non-trivial; for now the assumption the user is an ontologist familiar
with both OWL and the GO, and is capable of typing the correct string.

The user then clicks 'submit'; the string is passed as-is to a
server method that wraps MMM.getIndividualsByQuery(modelId, queryString)
(I just committed this)

(this method parses the manchester string to an expression and uses
the reasoner to find the individuals).

This returns a list of individuals which should be a subset of
individuals in the model. These individuals are then highlighted
somehow in the main display. Alternatively, they may be shown in some
kind of list view.

Note that this mimics the DL query tab in Protege, with the
"individuals" selection.

Optional future enhancements include

• ability to build a library of multiple queries
• query builder
• add the query to the ontology as an equivalence axiom

Add import features from BEL:
http://neurolex.org/wiki/Category:Resource:Biological_Expression_Language_Framework

Need to have a better way of saving files permanently.
Use GO SVN?

Try and get ECO up front in initial load, like the other up front loads.

The JSON currently uses the key "type" in two different ways - one to list all types in a model, another to list types for an individual. This results in an odd nesting.

(this is perhaps more of an owltools request but easier to include here, change will need coordinate with client)

Essentially a page and a service for remote clients to figure out the facts of the person who logged in. Not a directory since we don't want to be spiderable, but if you have a token you can get identity information.

Example: enabled_by some C

Where C is a class expression such as

('foo complex' and has_part some X and has_part some Y)

Eventually this will be superseded by something like a pluggable cell component editor. For now we need a way for power users who understand OWL to get this in.

Currently enabled_by assumes it's a named class (that has been loaded into golr)

Allow user to enter free text. Server will figure out how to interpret. E.g. We will try to parse using manchester syntax tool. @hdietze and me to implement

See also #1

Example:

User has created an instance of a molecular function. The interface allows them to add two additional SomeValuesFrom class expressions,

• occurs_in some L
• enabled_by some M

The user would like add arbitrary additional someValuesFrom expressions

• R some Y

Particular example:

• has_direct_input some GeneProduct123

But any relation from the RO can be used.

This could be at the time of initial box creation, or a post-create edit on the box

Currently the server returns the asserted type of an individual.

The server is capable of returning the direct inferred type (via Elk). It will be useful to show this, but it's not clear the best way to communicate this from the server, and to show it to the user.

Choices

1. leave as-is
2. server only returns direct inferred type in json payload. Client code requires no modification. Disadvantage: user may be confused as the original source assertion is no longer visible.
3. server returns both asserted and inferred type. Client code is modified to show inferred type in main plumb view. Both asserted and inferred types could be shown in more detailed view (e.g. when a user edits a node, or views a node in the bottom tab). Subchoices here are:
   • both direct inferred and asserted are in the payload but not distinguished; not ideal, client can't distinguish these
   • as above, but additional metadata provided (e.g. is_inferred:true). Not ideal, as this is not the property of the class; it's the property of the relationship between individual and class
   • we have two separate keys: type and inferred_type with appropriate values. I think this may be best

Example

occurs in

User creates "signal transducer activity" individual, with an additional anon class type assertion, "occurs_in some cytoplasm"

Currently user sees this:

We may also want to show the direct inferred type "intracellular signal transducer activity"

part of

User creates an MF instance of "receptor activity". Then creates a BP instance of some subtype of "signal transduction" (e.g. cell surface receptor signaling pathway). Adds a part of. The former should have a direct inferred type to the more specific "signaling receptor activity"

Currently sees this:

Note: MolecularModelManagerTest.testInferredType() is a stub test that performs this set up, but has no junit assertions until we decide what to do here

Allow evidence to be handled in the model.