provides input relationship displays as has_input

[ValWood]

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

[ValWood]

Maybe we need to add the output ds siRNA but I have no idea how to do that because it isn't a CHEBI compound? This will be a common issue for RNA processing

CC @vanaukenk

[ValWood]

We were confusing the colours. I thought the light blue was a rendering of the roayl blue.

But the problem is that this relationship is not included in the key:

example with both http://noctua.geneontology.org/workbench/noctua-visual-pathway-editor/?model_id=gomodel%3A662af8fa00000408

[vanaukenk]

@dustine32 @tmushayahama Can we take a look at this issue on the workbenches call today? I think the legend just needs an update for the 'provides input for' relation.

[dustine32]

@vanaukenk Sure! I can join the call today. Right, 'provides input for' is just not in the legend nor is the light blue, general "causal" relation color that the 'provides input for' edge is currently given.

[dustine32]

@vanaukenk @thomaspd Can either of you test @tmushayahama's change in noctua-dev? A quick link is to the yeast ergosterol model, though any model will do since the legend change affects all of them: http://noctua-dev.berkeleybop.org/workbench/noctua-alliance-pathway-preview/?model_id=gomodel:61f34dd300001044

[vanaukenk]

Thanks @dustine32 @tmushayahama

The new legend looks good.

One question - when I look at the pathway view in Noctua, the width of the line for 'provides input for' between ERG26 and ERG27 is narrower than the width of the other relation lines. I forgot if the width reflects anything about underlying data, e.g. amount of evidence, but that doesn't quite fit with what annotations I see on the model.

I'm a little concerned that the 'provides input for' relation in the example model is getting overshadowed :-)

I'll look at some other models, too. Thx.

[ValWood]

I didn't provide the chemical outputs in this model, but these have been added ( presumably automated from the definitions ) thanks! I was hoping this could be automated we discussed recently on an ontology call. Can you provide more details about this? when and how it is implemented.

This leaves the question of how a a "provides input for" relationship will be displayed... I'm sure we have examples (especially in RNA processing) where we cant add an intermediate. I will look for some once I am back from Elixir on the 16th...

[ValWood]

I just noticed this example is the S. cerevisiae model where the intermediates have been curated. The PomBase models do notcirate the inputs (because these could be inferred, we discussed this recently, it is 'busy work' - it should be possible to automate metabolic intermediates from definitions). This is why we have used "provides input for" instead of "has output" and "has input". The model you are using does not have examples of the "provides input for" relationship.

[vanaukenk]

@ValWood - there is one example of 'provides input for' in the test model on noctua-dev that Dustin provided (between ERG26 and ERG27).

I don't believe any automation has yet been put in place in Noctua to populate inputs and outputs based on participants in a reaction (MF).

[ValWood]

re @ValWood - there is one example of 'provides input for' in the test model on noctua-dev that Dustin provided (between ERG26 and ERG27).

yes, I see it.

I agree with @vanaukenk re: "I'm a little concerned that the 'provides input for' relation in the example model is getting overshadowed :-)"

The arrow is not as wide in pixels. Also the colour isn't great as all of the others are "stronger" colours. PomBase will always use this relation because it shows the directionality (i.e causality) (Although sometimes, we will also add inputs and outputs, we will only add them manually when they are "critical" end points (we won't manually add every intermediate).

Hopefully one day the non critical intermedaits can be automated, but I don't think we would want to display those all the time or the models could get very crowded.

[kltm]

(@pgaudet I filed this under "alliance" for the moment, but we might want a separate service project for things like this at some point.)