LocalAttributes

<<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

• topology-specific numerical quantities (like degree, node betweenness, and similar things)
• 3 use-cases mentioned on [CytoscapeRetreat2006/Hackathon/HackathonNotes] (see 2a point)

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

• Network_specific_node_and_edge_attributes

• thread on cytoscape-discuss at http://groups.google.com/group/cytoscape-discuss/browse_thread/thread/badfc47a12feb4bb

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.

• Add support for local attributes to CyAttributes. By applying the above patch or something like it.

• check every part of the code (in the cytoscape and coreplugins tree) that uses attributes due to above mentioned switch from "all attributes are global" to "some attributes are local" switch. In some cases, no change is needed, as having that part of the code only handle global attributes is fine. In other cases, small changes are needed to make that part of the code use the attributes belonging to the current network. A small number of cases need more extensive fixing. (see the above-mentioned patch for examples)
• store locality of attribute when exporting network in xgmml or saving session. (The current patch exports all attributes as global.)

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.