Suggestion from Alex Bateman, SAB member. He finds it frustrating that the syncing occurs on a mouse-over event-- if you move the mouse around a bit on the pathway over different nodes in the pathway graph, the activity-unit panel on the right changes very rapidly (and vice versa), which was not intuitive to him. I agree.

He suggested instead that the syncing should occur on a mouse-click event instead of a mouse-over. A user has to click on a pathway node (or, in the activity-unit panel, a "gene activity card") in order to highlight and/or scroll to sync between the two panels.

Next step is to discuss on an Alliance pathways call. @dustine32 @tmushayahama

Currently it's not entirely clear what has changed between releases. Having tagged releases in GitHub allows automatic release notes that show which PRs were merged since the last release. This is a lot better than nothing for very low effort. Additionally workflows can be triggered on release creation which could automate releases to NPM.

This came up in an email thread with PaulT and Chris. Basically, one would expect the GO-CAM models represented on https://amigo.geneontology.org/amigo/gene_product/WB:WBGene00004055 and https://www.alliancegenome.org/gene/WB:WBGene00004055 to be the same. However, the Alliance one turns up "0" models. Odd.

Looking at the queries, we see:
https://api.geneontology.org/api/gp/WB:WBGene00004055/models?causalmf=2
vs:
https://api.geneontology.xyz/gp/http%3A%2F%2Fidentifiers.org%2Fwormbase%2FWBGene00004055/models?causalmf=2

So there are a couple of questions here: "how is http://identifiers.org getting in there" and "why does switching back to the WB namespace still not work"?

I know there have been issues with the release of Alliance 6.0.0(?) this week. Could this be related? Is this otherwise expected for some reason? Is it time to switch over to api.geneontology.org, instead of api.geneontology.xyz, for consistency either way?

The current layout of the Alliance Pathway Preview places entities with no connections between them too close together, as this example model shows:

The Pathway View workbench for same model shows ideal spacing between disconnected entities:

@tmushayahama Would you be able to see how difficult this is to fix?

Shadowing for our accounting: https://agr-jira.atlassian.net/browse/KANBAN-126

Currently the README only provides an example showing how to use the widget when the custom elements are defined via <script> tags pointing to scripts hosted on unpkg.com. This is fine for very simple static pages, but most clients would probably expect to add @geneontology/wc-gocam-viz as a project dependency and then import something from the @geneontology/wc-gocam-viz package in the client code to define the custom components. It's not clear from the existing documentation what that something would be.

In looking at the test model for checking 'provides input for', I noticed that 'causally upstream of, positive effect' is translated into 'indirect positive regulation' according to the legend.

This isn't correct, since 'indirectly positively regulates' is a child of 'causally upstream of, positive effect' so we are adding a more granular relation than what the curator put into their model.

For an example, see the relation between ERG29 and ERG25 in this model:

http://noctua-dev.berkeleybop.org/workbench/noctua-alliance-pathway-preview/?model_id=gomodel%3A61f34dd300001044

Let me know if you want to take a look at this together.

When I attempt to define the custom components via importing the NPM package (as opposed to using a <script> tag with a prebuilt script) the images used in the legend cause errors.

I have a very simple application with this source file:

// src/main.ts
import { defineCustomElements } from '@geneontology/wc-gocam-viz/dist/custom-elements'

function init() {
  defineCustomElements(window)
  document.querySelector<HTMLDivElement>('#app')!.innerHTML = `
    <wc-gocam-viz 
      id="gocam-1"
      gocam-id="568b0f9600000284"
      show-go-cam-selector=true
      show-has-input=false
      show-has-output=false
      show-gene-product=true
      show-activity=false
      show-legend=true
    ></wc-gocam-viz>
  `
}

init()

I bundle with esbuild:

esbuild src/main.ts --bundle --outfile=dist/index.js

And I include the output in this page:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>gocam widget test page</title>
  </head>
  <body>
    <div id="app"></div>
    <script src="/dist/index.js"></script>
  </body>
</html>

At runtime the following error is thrown:

index.js:2179 TypeError: Failed to construct 'URL': Invalid base URL
    at getAssetPath (index.js:462:22)
    at index.js:53750:137
    at Array.map (<anonymous>)
    at index.js:53749:138
    at Array.map (<anonymous>)
    at GoCamViz.renderLegend (index.js:53748:262)
    at GoCamViz.render (index.js:53744:714)
    at callRender (index.js:1628:80)
    at updateComponent (index.js:1578:7)
    at index.js:1562:33 
index.js:2179 TypeError: Cannot set properties of null (setting 'innerHTML')
    at GoCamViz.loadGoCam (index.js:53271:21)
    at GoCamViz.componentDidLoad (index.js:53725:12)
    at safeCall (index.js:1735:32)
    at postUpdateComponent (index.js:1677:9)
    at updateComponent (index.js:1618:7)
    at index.js:1562:33
    at then (index.js:1743:64)
    at dispatchHooks (index.js:1562:12)
    at Array.dispatch (index.js:1531:28)
    at consume (index.js:2266:19) undefined

This error goes away if I change show-legend=true to show-legend=false.

I think this points to something incorrect about the way the legend images are bundled or referenced.

The metabolic pathways are very hard to consume when they display all of the small molecules.
It would be better if there was a toggle to "collapse small molecules" so that you could see only the entities.

e.g
http://noctua.geneontology.org/workbench/noctua-alliance-pathway-preview/?model_id=gomodel%3AYeastPathways_TCA-EUK-PWY

http://noctua.geneontology.org/workbench/noctua-alliance-pathway-preview/?model_id=gomodel%3A633b013300000306

From Alliance Pathways 2021-11-02 call, suggested by @cmungall.

Add a little toggle to the pathway viewer widget so that devs and curators can look at models in either prod or dev minerva instances. The toggle would likely go here:

This toggle should only be accessible on the sandbox instance available at http://proto.geneontology.xyz/

Tagging @kltm @tmushayahama

Right-hand panel contents.
The contents of the entity sections aren’t an optimal use of space, and there is some redundancy.

1. we find there is a bit of unnecessary information in the menu

a) it would be better not to repeat the species name every time (this only needs to be once at the top if at all because it will be obvious from the context/location- also these abbreviations are not commonly used). This would also free up this space to report specific entities like PRO modifications etc
b) I'm not sure why the name is repeated as an annotation with evidence , or what the evidence refers to (is it the evidence for the MF term? in which case it should. be on the row above).
c) Many of the entity widget boxes have has_input in them. Is this helpful? This is clear in the model, it doesn’t add anything to repeat this in the widget (i.e perhaps this panel should only be for additional information that is not obvious from the model (or a configuration option)
d) It would be really nice if the widget extensions appeared in a standard order:
i) MF
ii) part of BP
iii) occurs_in
it is feels a bit odd and make reading more difficult with a random ordering

As more radical improvementwe thought that we didn’t always need to see ALL of the entities and it would look much cleaner if only the ‘clicked//highlighted had details displayed. and user just click on a different node to change the data), because you can only really read one entity at a time. This would also help with the fact that the order of the entities is alphabetical ,(which isn't biologically meaningful and makes it difficult to locate genes via scrolling). Or at least have an option to collapse the list so it shows only the one you are viewing with the option to "uncollapse".

Currently the widget always fetches its own data and then opaquely manages that data. While prototyping a standalone GO-CAM model page in AmiGO we ran into the situation where the host page itself already had all the necessary data and so having the widget fetch its own data was redundant. Ideally we would have been able to pass the data we had to the widget. Alternatively I could imagine another scenario where a client would want the widget to fetch the data but then also have that data shared back to the host page.

It seems like these two use cases could be accounted for if:

1. Data could be provided through an object prop in lieu of the gocamId prop, in which case no fetch would occur.
2. If the gocamId prop is provided, the fetch occurs. But additionally the host application is allowed to access that data either via an event triggered on a successful fetch or some other mechanism.

Currently there are a number of elements that are assigned an ID and then either getElementById or querySelector are used to get access to the element. This can cause some confusion because it's quite easy for a host application to define elements with the ID gocam-viz or gocam-viz-container which the widget itself also uses. It also precludes having two instances of the widget on the same page (although that might not be a huge use case).

Instead, the widget's internal elements should not have IDs and JSX refs should be used to access them.

The gocam widget fetch data through barista (http only). Https websites such as the Alliance can only fetch data from https origins for security reasons.

To allow the gocam widget to be integrated in the alliance website (or any https origin), one of these actions needs to be done:

• make barista https; this would help other projects and go a long way towards progressively transitioning all of resources as https (GOLr next in line). As long as those steps are not done, both the go website and all the Noctua suite can not be secured. Requires @kltm time as no access.

• use the GO API, only https endpoint to date, as a proxy to query barista. IMO, it's a workaround, but depending of longer term vision, this could be a first step towards centralizing all queries through a unique API, which I would be in favor. Requires @lpalbou time.

We're currently working with version 0.0.48 of the widget in AmiGO because that version doesn't include Bootstrap 5. Using that version we were able to get the widget to "look more at home" within AmiGO using a combination of CSS variables and style overrides on various CSS classes. Comparing that to what's in version 0.0.51 it seems like the widget has taken a bit of a step backwards in terms of style customization (CSS variables not used anymore, less specific CSS classes in some components).

Taking a look at Stencil's documentation, they seem to recommend using CSS variables and CSS parts to enable customized styling.

Here,
http://noctua.geneontology.org/workbench/noctua-alliance-pathway-preview/?model_id=gomodel%3A665912ed00000015

I am clicking on "kgd1"

but Kgd1" is not resolved in the right-hand scroll bar ( I can only see the bottom of it, brown bar).

@vanaukenk

I have made a model with a protein complex (this will become the respiratory chain once the other complexes are curated in complex portal)

I expected to be able to expand the complex in the widget to see the individual subunits but I can't:

Is this a problem with the viewer or with our input file?

Also, is there a way to get the label of the complex display as the name rather than the identifier? (I guess we probably need to do similar to what we did for PRO IDs)

CC @kimrutherford

In conversation with @tmushayahama and @pkalita-lbl, there will be some small code tidying for parts of the code that deal with defunct APIs.

I noticed that interactions of types "indirectly positively/negatively regulates" and "constitutively upstream of" are not rendered in the Alliance pathway preview.

When you uncollapse a complex, you see

Is it possible to display all members ?

In our glycolysis model,
http://noctua.geneontology.org/workbench/noctua-visual-pathway-editor/?model_id=gomodel:663d668500002302

hexose is annotated as input_of hxk1 & hxk2(the only option in Noctua)

but in the widget, this comes out as has_input

I don't object to the inversion of the relation, but the "arrow" appears to be the wrong way around.
I would read this diagram as "D-hexose" has_input hxk2 rather than hxk2 has_input hexose

Has_output at the end of the model is fine.

Metabolic pathways are currently displayed as disconnected gene products because the relations used are not causal. Instead these pathways are connected via chains of MF1 -has_output-> small_molecule <-has_input- MF2. The pathway viewer should display these connections.

@tmushayahama What was your great example GO-CAM that you showed at our meeting this morning?

Tagging @thomaspd for any additional detail.

The hard dependency on Bootstrap 5 makes this challenging to integrate the widget into downstream projects. Some scenarios:

1. Host application doesn't use Bootstrap at all. Once the widget is loaded, Bootstrap styles are injected. Even though the host application doesn't use any Bootstrap CSS classes its global styling could alter the appearance of the host application.
2. Host application uses an older version of the Bootstrap. This is the case with AmiGO and the Alliance site, which both use Bootstrap 4. Once the widget is loaded the existing Bootstrap 4 style definitions are overridden with Bootstrap 5 definitions. This has all sorts of unpredictable side effects. For example, before loading the widget:

And after:

3. Host application also uses Bootstrap 5. This is the best case scenario because there won't be any style conflicts. But in this case the application still ends up with two copies of Bootstrap 5, increasing the size of the host application bundle.

At the very least it seems like Bootstrap should be a peer dependency. This would fix the third scenario, but not the first two. To help the first two scenarios I'd suggest seeing if:

• Bootstrap could be a peer dependency and the requirement relaxed to be something like >=4.x
• Bootstrap could be dropped altogether. Could a few custom CSS classes suffice instead?

Currently, there are references to internal interfaces to the code. I.e.:
./src/components/gocam-viz/gocam-viz.tsx

    apiUrl = "https://api.geneontology.xyz/gocam/";
    devBaristaUrl = 'http://barista-dev.berkeleybop.org/search/stored?id=';
    localDevBaristaUrl = 'http://localhost:3400/search/stored?id=';
    productionBaristaUrl = 'http://barista.berkeleybop.org/search/stored?id=';

    noctuaGraphURL = {
        prod: "http://noctua.geneontology.org/editor/graph/",
        dev: "http://noctua-dev.berkeleybop.org/editor/graph/",
        release: "http://noctua.geneontology.org/editor/graph/",
    };

    /**
     * Used to connect to a barista instance. By default, always access production (prod) server
     * prod = http://barista.berkeleybop.org
     * dev  = http://barista-dev.berkeleybop.org
     */

The only (default) public endpoint should be api.geneontology.org. Other non-standard endpoints should be available as a runtime argument to override the default (and allowing internal use).

In this GO-CAM (DLG4 Alliance), there is an edge (circled) that's not in the legend so it's unclear what the edge means:

Looking in the Editor, I can see this edge relation is "is small molecule activator of":

Note: "is_small_mol_activator" is NOT a descendant of positively_regulates in RO

In this GO-CAM model for Mouse Itpr1, the has_input and has_output relations (circled) are not shown in the legend, making their meaning ambiguous to the viewer:

We should add these two relation symbols to the legend.

Reported by Paul Sternberg and @thomaspd. Tagging @tmushayahama and @kltm to determine who should make the code change.

Our model
http://noctua.geneontology.org/workbench/noctua-visual-pathway-editor/?model_id=gomodel%3A66187e4700001781

has
dicer (dcr1) provides input for argonaut (ago1)

but in the gocam-viz this becomes dcr1 has_input ago1
(so even the direction is changed)

This one is a bit of a blocker , we wont be able to make out models public until this one is fixed

cc @PCarme