## page was renamed from RFCTemplate ## This template may be useful for creating new RFC's (Request for comments) ## This is a wiki comment - leave these in so that people can see them when editing the page || '''RFC Name''' : Implement local (per-network) attributes || '''Editor(s)''': DanielAbel || <> == About this document == This is an official Request for Comment (RFC) about implementing local attributes. For details on RFCs in general, check out the [[http://www.answers.com/main/ntquery?method=4&dsid=2222&dekey=Request+for+Comments&gwp=8&curtab=2222_1&linktext=Request%20for%20Comments|Wikipedia Entry: Request for Comments (RFCs)]] == Status == Open for public comment ##Put the date and the status. Status can be e.g. "Not yet completely written", "Open for public comment", "Closed for public comment". There could be some explanation of the status == 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. ##The sections below may be useful when creating an RFC, delete the ones that are not == 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.