Node Cap Counters for Concept and Mapping Expansions Confused?

[everbeek]

I performed a mapping expansion after doing some sort of concept expansion, and it expanded more term neighbourhood expansions rather than mapping ones. I thought I had entirely prevented this by clearing the queue for expansions.

[everbeek]

Aha! Ok, in the debugger I saw that when expanding mappings, we go through a lot of necessary relation fetches, but the actual fetch behavior is controlled by the type of fetch (mapping in this case). In the ConceptChildrenRelationsCallback, we see that it only expands children if the node we are expanding has itself been cleared for term neighbourhood expansion. Prior to implementing the node cap, whenever there was an expansion, it would go the whole way through, and if a node was cleared for a particular expansion, its associated nodes (children in this case) would be brought into the graph. Now, not all are if the user stops the expansion, but then before the mapping expansions get processed, the children check is done, and those nodes are let in first, using up the mapping expansion's cap, so to speak. Clear as mud, right?

Anyway, this means that when an expansion is stopped, I need to remove the parent node's clearance. Clearance is checked by looking at the undo history and determining if an expansion set corresponding to the expansion type under question exists. Ok...so, if an expansion was stopped, I could check to see if that was the case in this clearance check. I do have a cutShort() method on expansion sets that I created, but forgot the purpose of while implementing the node cap. This is where it may be used. It should be set to true if the expansion set had anything less than all of its nodes allowed through. Re-expansion later should still be made to work.

Or I could revise the rather unclear node expansion clearance concept...thinking...

[everbeek]

It worked out! I track the number of nodes known at the time the user clicks to add more. If the number they add is less than the number expected at that time, the expansion is marked as cut short. In the check for cleared nodes, I check to see if the expansion was cut short, and it prevents child nodes from beating the mapping nodes to the punch.

This is not fail safe, since if the user happens to click to add nodes just as the entered number equals the number of nodes incoming, but then an additional async relation arrives, the expansion will not be marked as cut short, and the same problem will occur. I feel like my solution isn't the right one. Thinking some more...but committing what I have.

[everbeek]

Ok, reconsidering it again. I think that if the user clicks anything in that dialog, it needs to be labelled as cut short. With that property and method renamed, of course. Since it turns out that all of the fetches are prepared prior to the parent/trigger node cap check, then I could always label the expansion as cut short when we reach a certain point. This would be more like "expansion satisfied" rather than cut off.

[everbeek]

I think I have it. At every place that I check for node expansion clearance, I already have an expansion set handy. That set has a parent and an expansion type. I do not need to search the history to see if the parent node is cleared for that expansion. Therefore, I can compare the expansion type that the check is wondering about, to the type in the expansion set provided.

I am verifying that this is true in all cases where I call the method to check for clearance...

The other case where I check for clearance, and the one that needed history rather than a mere registry, was when I am rendering temporary edges. These are the ones that are shown between mappings nodes when those were not explicitly expanded. This was made to prevent too many arcs from cluttering the view every time a mapping expansion was performed, because mappings tend to form cliques. So I might have to keep the clear method as is for this purpose. That's fine, right?

[everbeek]

Have it working in a simpler way. I may be able to get rid of the expansion set and command methods relating to whether it was cut short. I will do that as a separate commit. Look at the ConceptGraph complete() method as a starting point.

[everbeek]

Nope, I cannot get rid of the expansionCutShort() stuff. I was on the right track with that. Good.