Support multiple exchanges connected to the same port

[danionita]

Bob, if you get around to this, let me know, as it requires some adaptations in my part of the code to function.

[bobismijnnaam]

It depends... Does it mess with second_connects_ve et al.? :p

On 19 December 2016 at 12:05, danionita notifications@github.com wrote:

Assigned #89 https://github.com/danionita/e3tools/issues/89 to @bobismijnnaam https://github.com/bobismijnnaam.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/danionita/e3tools/issues/89#event-898445480, or mute the thread https://github.com/notifications/unsubscribe-auth/AC8IaAO35Bus4FXAjRbMmW1dH0otdIjGks5rJmUEgaJpZM4LQnBU .

[danionita]

second_connects_ve et al only appear when there are exchanges on both sides of the interface.

In this case, the Value Port with multiple exchanges would simply have mulitple vp_in_connects_ve or vp_out_connects attributes, depending on the direction of port.

Of course, when both cases are present (there are exchanges on both sides and multiple exchanges connected to the same port on one side), then you might end up with multiple vp_first_connects_ve or vp_second_connects_ve .

Is this workable?

[bobismijnnaam]

Well, just tested it with this example:

The RDF export works, and the fraud generation also works, it seems. Maybe @danionita can check if it gives plausible analysis results if you give it meaningful valuation attributes and such?

Also checked it with this model:

It gives an error that a start stimuli entity was found while traveling downstream. Makes sense in some way; it starts at a start stimuli in the top left, and then branches out from the center value interface. Of course it's going to end up at the start stimuli in the top right. I don't immediately see a clear and elegant solution to this (as this is an ambiguity in the e3value ontology, I think). I think we can only document this for the user, and say that structures like these are not allowed (i.e. decide that multiple value exchanges are only allowed on the "downstream" side of a value interface).

[bobismijnnaam]

Also checked the code somewhat. It seems that in most places the exporter doesn't care about the amount of value exchanges, but just checks them all and handles them all in the same way. So that should be fine for now I guess.

[danionita]

I fail to see why the second example, containing the "Cross" is ambiguous. The flow should not travel from the top left to the top right corner but rather first from the top left to the two bottom corners and then from the top-right to the two bottom corners.

Multiple transfers arriving at (or departing from) the same port have the same meaning as if those transfers would merge (or split) via an OR-gate before the port. See also fig 27 on page 26 of the e3manual: http://e3value.few.vu.nl/docs/misc/manual_version2.pdf)

This, of course, implies that one should be able to (1) manually group transfers into transactions and (2) define FRACTION attributed to these transactions, just like in the old editor. Somehow, we completely forgot about the transactions editor (which was supposed to handle cases where transfers could not be grouped into transactions automatically), so I have created Issue #90. (We should also allow dependency paths to cross inner-actor borders, so I created issue #91 too).

Your code should be able generate an RDF from both the models you show. However, for the RDF to be usable by the NCF module from the second "crossed" model, it would need to contain manually defined transactions and fractions.

[bobismijnnaam]

Hmm, okay. The way I implemented it now in some parts of the code is the way you describe it. So aside from the value transaction editors it should work as expected.