local attributes

[Abel Daniel]

As far as I could tell, local, i.e., network-specific attributes is a
long-standing "maybe we will do it someday" whishlist feature.

According to
http://cytoscape.org/cgi-bin/moin.cgi/CytoscapeRetreat2006/Hackathon/HackathonNotesundirected:
"It would be very complex to create network specific node and edge
attributes."

I have an implementation of local attributes isn't very complex at
all. It looks like this:

- Create a CyAttributesReflectionProxy class that uses java's
reflection capabilities to proxy method calls to one of two
CyAttribute instances.
- add a Cytoscape.getNodeAttributes(CyNetwork network) method that
creates an instance of that class, using the global CyAttribute
object, and a newly created one.

This means, that from an API standpoint, one simply needs to do
CyAttributes attrs = Cytoscape.getNodeAttributes(network) ;
instead of
CyAttributes attrs = Cytoscape.getNodeAttributes() ;
attrs can be used the same way as before. all newly-created attributes
will be global, and
both local and global attributes are visible. local attributes can be
created with
attrs.createLocalAttribute(String attrName);
which simply tells the proxy object to pass on all calls related to
attrName to the local-attribute storing CyAttribute instance.

This scheme might not be terribly efficient, but its simple, it works,
and can be optimized, if needed. (And it didn't look slow to me.) I
can provide diffs against the 2.4 release sourcecode.

The biggest part of the work was not actually implementing local
attributes, but reworking the rest of the framework to use them. Some
parts of the code assume that all attributes are global. (For example
the browser, QuickFind plugins, the VizMapper, etc.)

Is there any chance that an implementation of this feature gets
accepted into core cytoscape?

Thanks in advance,
Abel Daniel

[Mike Smoot]

Hi Abel,

One of the reasons that we haven't implemented local attributes is that I'm not aware of any strong use-cases that can't be accomodated using normal global attributes.  If you could describe the problem you're trying to solve, I think it would help.  In any case, we're happy to consider patches.

thanks,
Mike

On 3/22/07, Abel Daniel <ab...@freemail.hu> wrote:

As far as I could tell, local, i.e., network-specific attributes is a
long-standing "maybe we will do it someday" whishlist feature.

According to
http://cytoscape.org/cgi-bin/moin.cgi/CytoscapeRetreat2006/Hackathon/HackathonNotesundirected:
"It would be very complex to create network specific node and edge
attributes."

I have an implementation of local attributes isn't very complex at
all. It looks like this:

- Create a CyAttributesReflectionProxy class that uses java's
reflection capabilities to proxy method calls to one of two
CyAttribute instances.

- add a Cytoscape.getNodeAttributes (CyNetwork network) method that

creates an instance of that class, using the global CyAttribute
object, and a newly created one.

This means, that from an API standpoint, one simply needs to do
CyAttributes attrs = Cytoscape.getNodeAttributes(network) ;
instead of
CyAttributes attrs = Cytoscape.getNodeAttributes() ;
attrs can be used the same way as before. all newly-created attributes
will be global, and
both local and global attributes are visible. local attributes can be
created with
attrs.createLocalAttribute(String attrName);
which simply tells the proxy object to pass on all calls related to
attrName to the local-attribute storing CyAttribute instance.

This scheme might not be terribly efficient, but its simple, it works,
and can be optimized, if needed. (And it didn't look slow to me.) I
can provide diffs against the 2.4 release sourcecode.

The biggest part of the work was not actually implementing local
attributes, but reworking the rest of the framework to use them. Some
parts of the code assume that all attributes are global. (For example
the browser, QuickFind plugins, the VizMapper, etc.)

Is there any chance that an implementation of this feature gets
accepted into core cytoscape?

Thanks in advance,
Abel Daniel

--
____________________________________________________________
Michael Smoot, Ph.D.               Bioengineering Department
tel: 858-822-4756         University of California San Diego

[Abel Daniel]

On Mar 22, 10:32 pm, "Mike Smoot" <msm...@ucsd.edu> wrote:
> One of the reasons that we haven't implemented local attributes is that I'm
> not aware of any strong use-cases that can't be accomodated using normal
> global attributes.

My use case is about topology-specific numerical quantities (like
degree, node betweenness, and similar things). The ability to store
them in local attributes opens up all sorts of possiblities: using
them in vizmapper, quickfind, in the attributes browser, etc. They
_need_ to be local attributes since trying to store them as global
would break in all sorts of disastrous ways (for example import a
network, select part of it, create new network from that part, then
try to calculate quantities in both networks.)

> In any case, we're happy to consider patches.

Ok, I'll prepare one.

--
Abel Daniel

[Mike Smoot]

Sure, topological attributes make a lot of sense.  However, the common solution is to have multiple attributes of the same type e.g. network1.nodeBetweenness, network2.nodeBetweenness, etc., where network1.nodeBetweenness only makes sense for network1.   The difficulty with that strategy occurs when a user is forced to differentiate between the attributes.   For plugin writers the effort wouldn't me much different.  Instead of:

CyAttributes net1Attrs = Cytoscape.getNodeAttributes(net1);
net1Attrs.getIntegerAttribute(nodeId,"nodeBetweenness");

you would have:

CyAttributes nodeAttrs = Cytoscape.getNodeAttributes();
nodeAttrs.getIntegerAttribute(nodeId,net1.getIdentifier()+".nodeBetweenness");

Would that work for you?

thanks,
Mike

On 3/22/07, Abel Daniel <ab...@freemail.hu> wrote:

[Abel Daniel]

On Mar 22, 11:08 pm, "Mike Smoot" <msm...@ucsd.edu> wrote:
> Sure, topological attributes make a lot of sense. However, the common
> solution is to have multiple attributes of the same type e.g.
> network1.nodeBetweenness, network2.nodeBetweenness, etc., where
> network1.nodeBetweenness only makes sense for network1. The difficulty
> with that strategy occurs when a user is forced to differentiate between the
> attributes.

[...]

> Would that work for you?

Its a nice idea, but it would make the interface harder to use:

- user has to remember the network name, and needs to pay special
attention to
avoid mixing up the different types of nodeBetweenness.
- it makes it harder for plugins to automatically apply vizmapper
styles: with
local attributes one can define a style which contains something like
"map nodeBetweenness to node size", and apply it automatically after
calculating
nodeBetweeness. Using the network1.nodeBetweenness type workaround,
the visual
style would need to be redefined.

(This, of course, applies to interactive usage, too; A usecase:
I setup a special visual styles to show some local attributes, and
apply it to some network. Now I want to try out how that other network
looks like
with that visualization: with the workaround, I would need to go and
change every
"local" attribute. If I miss some, the visualization will show
something really
different from what I think it shows.)

[Mike Smoot]

All good points.  I eagerly await your patch!


Mike

On 3/22/07, Abel Daniel <ab...@freemail.hu> wrote:

On Mar 22, 11:08 pm, "Mike Smoot" < msm...@ucsd.edu> wrote:
> Sure, topological attributes make a lot of sense.  However, the common
> solution is to have multiple attributes of the same type e.g.

> network1.nodeBetweenness, network2.nodeBetweenness , etc., where

--
____________________________________________________________

[Abel Daniel]

On Mar 23, 1:47 am, "Mike Smoot" <msm...@ucsd.edu> wrote:
> All good points. I eagerly await your patch!

I prepared one against the sources of Cytoscape 2.4
It is at http://abeld.web.elte.hu/local_attributes_patch.tar.gz
(I hope I prepared it right and it applies cleanly.)

In addition, I have some questions / suggestions:

- why does http://chianti.ucsd.edu/svn/coreplugins/tags/Cyto-2.4.0/
have a trunk/ directory in it? (which has all the plugin directories
inside, again) Last time I accidentally created something like that
was when I did a "svn copy" instead of an "svn merge". (i.e. an
"svn merge" into an empty directory, which would create no merge
conflicts)

- remove the following from svn, they should be ignored by svn, as
they are automatically generated during the build process:

cytoscape/src/cytoscape/bookmarks
cytoscape/src/cytoscape/generated
cytoscape/src/cytoscape/generated2

- the build process could use some cleanup / integration. For example
currently it appears to be non-trivial to create a clean build from
everything. (i.e. build corelibs, cytoscape, coreplugins, then
create a release.) internal dependencies, for example between
cytoscape and coreplugins don't seem to be handled, .jars need to be
copied by hand.

--
Abel Daniel