RFC Name : Implement local (per-network) attributes

Editor(s): DanielAbel

<<TableOfContents: execution failed [Argument "maxdepth" must be an integer value, not "[2]"] (see also the log)>>

About this document

This is an official Request for Comment (RFC) about implementing local attributes.

For details on RFCs in general, check out the Wikipedia Entry: Request for Comments (RFCs)

Status

Open for public comment

How to Comment

To view/add comments, click on any of 'Comment' links below. By adding your ideas to the Wiki directly, we can more easily organize everyone's ideas, and keep clear records. Be sure to include today's date and your name for each comment. Here is an example to get things started: /Comment.

Try to keep your comments as concrete and constructive as possible. For example, if you find a part of the RFC makes no sense, please say so, but don't stop there. Take the extra step and propose alternatives.

Proposal

Network-specific attributes is a long-standing whishlist feature (see, for example Network_specific_node_and_edge_attributes). According to CytoscapeRetreat2006/Hackathon/HackathonNotes: "Decision: don't need to implement this. The workaround to create multiple edges with different edge types is fine. It would be very complex to create network specific node and edge attributes."

However, implementing such local attributes is easy. The really difficult part is switching from a "all attributes are global" mentality to a "attributes can be local or global" one.

Use Cases

General Notes

Note that it is possible to use workarounds for each of the use cases mentioned above. (Perhaps the best one is MikeSmoot's suggestion to prefix the name of the attribute with the name of the network e.g. network1.nodeBetweenness, network2.nodeBetweenness, etc., where network1.nodeBetweenness only makes sense for network1.) However, implementing local attributes natively would be much cleaner. All the possible workarounds get ugly if the there are a lot of local attributes. (A lot of networks which have a local attribute with the same name.)

Due to the above-mentioned mentality change, all current uses of attributes need to be checked. This makes this change especially disruptive.

Open Issues

Backward Compatibility

As attributes will be created as global by default, no backward-incompatible changes should result (unless bugs are introduced).

References

Implementation Plan

I (DanielAbel) have a patch against Cytoscape 2.4 (available at http://abeld.web.elte.hu/local_attributes_patch.tar.gz ) This path should work (it is used internally by us), but it ignores some plugins, and should be reviewed more extensively. See the included readme file for more info.

Comments

(MikeSmoot) I think that the plan for this is to support attribute namespaces so that networks, plugins, and other interested parties can have their own attributes. It's possible that this will be part of 2.6. The backend data structures will be easy for this, but getting the UI to behave sensibly and refactoring all of the code that relies on attributes to support this will be the trick.

Yup, this will be done as part of the AttributeNamespaces RFC.

LocalAttributes (last edited 2009-02-12 01:03:01 by localhost)

Funding for Cytoscape is provided by a federal grant from the U.S. National Institute of General Medical Sciences (NIGMS) of the Na tional Institutes of Health (NIH) under award number GM070743-01. Corporate funding is provided through a contract from Unilever PLC.

MoinMoin Appliance - Powered by TurnKey Linux