procedural attributes

[jbilcke]

Hi,

this is an idea I got today.
I was trying to implement a dynamic layout algorithm, and got stuck at the design phase: which layout algorithm should I extend? ForceAtlas? OpenOrd?
They all could benefit from dynamic weight, but it would be a bit awkward to create 10 additional versions of these layouts, always copying and pasting the same portion of my code. Also, my code could have infinite variations, thus creating even more combinations.

After a bit of thinking, I think this could be done in an elegant, generic, and modular way. Here is it:

This would be interesting to have procedural attributes inside Gephi.

Here how it would work. It is easy to understand:

One could go in the Data Laboratory, select a column, and choose how the corresponding value
must be computed by, say, selecting a function name in a list.

Plugins implementing the right API would define their own additional functions, all accessible from the same menu.

What the procedure should do (count Facebook friends in real-time, compute the logarithm of another attribute, a dynamic weight for the layout, a color corresponding to a router's ping status in a local network, search a Pony on Amazon and return the shipping costs..) is left to the plugin developer's imagination.

The idea is really to let the user cherry pick it's procedure from various plugins, and use them for things like sorting data in the data laboratory, or more interestingly, in layouts.

Behind the scene, a background process would call the function, maybe asynchronously, and wait for the result, updating the cached value when possible, minimizing the blocking of Gephi.

That's the idea. What do you think about it?

[admin]

I think you start on the wrong way about the layouts: why don't you just implement a new one, maybe based one one that could be adapted in that sense, and see what happens?

Like metrics vs dynamic metrics, we could do better than extending and existing static layout. The temporal dimension appeals to new ways to design algorithms which intrinsically take the time into account, and not just as an input parameter.

Hence the current Layout API is probably not adapted to compute such algorithms...


But your proposal is on a different thing: executing a code taking one column in parameter, depending I guess on the column type. It could be useful in a certain limits that should be defined, because getting a poney could be done with a generic plug-in.

[jbilcke]

Hi Sebastien,

This system may be a generic way to allow the concept of real-time attributes updates inside Gephi.

It may indeed collides with the very notion of what an attribute is, notion which has never been discussed publicly - Why not discuss about it now?

I gave the dynamic layout as an example among other, but I can understand this can be confusing - maybe I should have talk about it later!

[admin]

Can you provide a real-world example when such updates could be useful?

[mbastian]

Hi Julian, I get your Idea I think. The aim is to have a framework to compute attribute values on the fly, having for instance a formula that uses other attributes or data. The dynamic weight is indeed a good example, as the real value is obtained by getting the current interval in the interval tree. That is always the same portiion of code and it's true that it gets messy by just copy-paste this code.

As you metion, it would'nt be too difficult to implement a SPI for this.

However I would consider this idea low priority because:
- It firstly helps the developer, not really the user
- Attributes API would need to be refactored
- Core evolution - Attributes API Future needs to be done first before touching Attribute API. Did you had a look at this projet?