Feature: Show resource after it is known.

[fosterlynn]

Right now, we show the ResourceSpecification as a placeholder visual object for the resource-y (ResourceSpecification or EconomicResource) node in the graph. We have discussed showing resources as they are created, but not recently. And now we actually have resources, so we can do that.

Suggested UI: When an event creates a resource, it will take the place of the placeholder visually. Perhaps a resource could be a slightly different color. It could show: The conformsTo name as now, the name if it has one, and the accountingQuantity. And the primaryAccountable agent. Let's see what we can fit. (Discussion: If we do have agents on both the process nodes and the resource-y nodes, then we could consider removing them from the flow labels, which are too long anyhow. This relates to #156.)

Related, we can also see in this screenshot of a transfer drawn from a node that is actually a resource already, that it could know the provider agent and the provider resource, but it is not defaulted in. It would be helpful to add that too.

[adaburrows]

I like it. But I want to think about this a little bit more to massage it with some visual language principles. I also never made a visual representation of the ResourceSpecification in my most recent visual description and I know I need one. Maybe I could just make a ghostly dashed outline version of the hexagon I was using for the EconomicResource. That would convey it's just a category and not an actual resource stockpile.

[fosterlynn]

I'm fine with the hexagon, if it can be done to contain enough info. Maybe a stretched out hexagon?

Also, we should keep in mind that not everything will become an actual resource, so a ghostly one should look not like an error or something missing.

Another option might be to plunk a resource hexagon into or next to the resource spec rectangle? Or maybe better and easier to keep the rectangle resource spec and change it to a stretched out hexagon when it knows an actual resource. Could be the same color then.

But if we prioritize this, let's do something that is fairly quick.

[adaburrows]

Aside from the visual language, which I'm fine with putting aside for now, there's the issue of wiring this data through to the visual node along with the other bits of domain data we have access to. We know through the wiring diagram which event precedes this particular resource specification, but that's not something that Valueflows knows (it just sees a bunch of Commitments and EconomicEvents all referencing the same ResourceSpecification). It just knows we have a set of potential resources that conform to the ResourceSpecification. However, since we know what the EconomicResource is from the EconomicEvent in the DisplayEdge, we can create a mapping between our DisplayNodes and EconomicEvents through the DisplayEdge that let us update the Node. We'd also need to do the same with the input to the Commitments and EconomicEvents connecting to the DisplayNode.

This is just a little more complex than I thought and I want to double check my assumptions.

DisplayNode(Process) ⭢ DisplayEdge(EconomicEvent) ⭢ DisplayNode(ResourceSpecification) ⭢ DisplayEdge(EconomicEvent) ⭢ DisplayNode(Process)
          ⭣                        ⭣                               ⭣                               ⭣                            ⭣
DisplayNode(Process) ⭢ DisplayEdge(EconomicEvent) ⭢    DisplayNode(EconomicResource)   ⭢ DisplayEdge(EconomicEvent) ⭢ DisplayNode(Process)

[fosterlynn]

I want to double check my assumptions.

That looks right to me.

If it is easier, you could have a "resourcey thingy" as the node, and it could know what it really is. (I speak from ignorance, the thought just came to mind.)

We know through the wiring diagram which event precedes this particular resource specification, but that's not something that Valueflows knows (it just sees a bunch of Commitments and EconomicEvents all referencing the same ResourceSpecification)

Actually VF is meant to know the graph, that is what makes it "flows". :) It defines optional but standardly named methods (queries) for previous and next, and trace and track. Here is some definition: https://www.valueflo.ws/algorithms/track/. FabCity is working on this now (so far a reasonably working trace). That VF page is being updated as that work is being done, actually there are some updates that aren't yet up to the website.

[adaburrows]

I guess I didn't convey the mismatch between the way I see the UI and the way the Valueflows graph is formed. There's actually more to it than we see on the screen, because there could be other plans that generate resources or draw from resources that effect the stock availability because resources are just sources and sinks between commitments/events/processes. The only reason we can see a linear topology between them is because we hope that our plan only includes one reference to a particular resource at each commitment/event. If it had more than one reference to the same object, then we couldn't tell which one came first if we tried generating the visual graph from the plan data.

For instance, which comes first in this diagram, the transfer or the consume for the beans? It only makes sense linearly if there's a separate resource at each point (one with a different primary accountable, stage, state, location, or id). https://github.com/lightningrodlabs/rea-playspace/issues/164#issuecomment-1262585122