Implement vp_second_connects_ve

[bobismijnnaam]

When a value interface is connected to both an outside and an inside value interface, proper RDF attributes should be generated (using vp_second_connects_ve and its inverse. See generated RDF from the old editor for an example). See the image for an example.

[bobismijnnaam]

Hmm, when you create this configuration and export it in the old editor, the old editor also starts using ve_has_first_vp, ve_has_second_vp, and vp_first_connects_ve. What do these attributes mean? I have a hard time figuring it out from the rdf.

[danionita]

No idea... Let's look at this together when I am back.

On Sat, Sep 10, 2016 at 8:12 PM, Bob Rubbens notifications@github.com wrote:

Hmm, when you create this configuration and export it in the old editor, the old editor also starts using ve_has_first_vp, ve_has_second_vp, and vp_first_connects_ve. What do these attributes mean? I have a hard time figuring it out from the rdf.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/danionita/e3tools/issues/53#issuecomment-246108471, or mute the thread https://github.com/notifications/unsubscribe-auth/AKjEpBgFFoDbdGuoBoT09R0LZSzpQ-Piks5qop6ZgaJpZM4Jmj4J .

[danionita]

Deeper investigation seems to have revealed the following: ve_has_first_vp = ve_has_in_po ve_has_second_vp = ve_has_in_po vp_second_connects_ve = vp_in_connects_ve vp_first_connects_ve = vp_out_connects_ve The former seems to replace the latter when the respective VP has VEs on both sides, or when the respective VE connects an internal element (value-activity or sub-actor) to its parent.

[bobismijnnaam]

That seems consistent, altough I have found a case where we get slightly different results.

What seems to happen here the "center" ve (ve1 & ve2) seem to give "normal" (vp_in_connects_ve, vp_out_connects_ve) attributes to the value ports. The "outer" ve (ve3, ve4 on both sides) seem to give "weird" (vp_first_connect_ve, vp_second_connect_ve) attributes to the value ports. So in this case, a value port has "normal" attributes on one side, and "weird" ones on the other. What I'm having trouble with is that in your case, vp3 & vp4 have "weird" attributes on both sides, but in my case, one side has "weird" attributes and one side has "normal" attributes. This is so strange I'm sure I must be missing something. Can you have a look at this situation's RDF as well and see if you agree with me?

[bobismijnnaam]

Annotated picture to illustrate my point more clearly:

As you can see in the center the conventions first/second and in/out are intermingled, while in your case they are not. I'm having trouble deciding when to apply the first and when the second.

[bobismijnnaam]

Hmmm, I annotated your situation as well, and I get a different result:

It seems to resonate with my previous observation/confusion.

[bobismijnnaam]

I think the rule is:

• If the parents of the two containers (actor/market segment/value activity containing the value port) is the same, or both are top level containers, then just use in_connects_ve, ve_has_out_po, etc. (as is the case in the bottom value exchange in the previous example)
• If one of the containers contains the other container (as is the case in the top value exchange in the previous example) use ve_has_first_vp, vp_second_connects_ve, etc.

[bobismijnnaam]

Hey, another funny thing: if you take my last example and try to assign a value object to the inner or outer value exchanges, the editor assigns the value object to both the inner and the outer value exchanges. I guess that makes sense, to some extent, but I'll have to implement that as well.

[bobismijnnaam]

Implemented the correct attributes in RDFExprt line 486-something as of commit 4e267c66241922bfd0fc90ccf82c722773dbd626. The normal example works; I'm not sure how we can test the "doubly value exchanges". Atm the fraud generator does not work with doubly value exchanges.

[danionita]

Working on handling "doubly" exchanges. Will test next week.

On Sun, Dec 11, 2016 at 2:55 PM, Bob Rubbens notifications@github.com wrote:

Implemented the correct attributes in RDFExprt line 486-something as of commit 4e267c6 https://github.com/danionita/e3tools/commit/4e267c66241922bfd0fc90ccf82c722773dbd626. The normal example works; I'm not sure how we can test the "doubly value exchanges". Atm the fraud generator does not work with doubly value exchanges.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/danionita/e3tools/issues/53#issuecomment-266283500, or mute the thread https://github.com/notifications/unsubscribe-auth/AKjEpEeOQtNsvIB3Jyn9m2DiW7Tz4Oozks5rHADdgaJpZM4Jmj4J .

[danionita]

Spotted an error while implementing handling of "doubly" exchanges by fraud generation: Some interfaces (it seems to be the ones at the "bottom end" of a doubly exchange) do not get assigned the correct "de_down_ce" attribute connecting them to the next element. See two examples below (problem interface highlighted in green):

[bobismijnnaam]

@danionita It seems your example works now. The reason was quite stupid: I had not yet implemented doubly ve's in the RDF exporting logic. Let me know if it works correctly now.