local attributes and attribute namespaces
ab...@freemail.hu
I would like to comment on the issue of implementing local attributes
with attribute namespaces, with the view of planning to do implement
local attributes (either with attribute namespaces or without them)
during my planned google summer of code project.
I would like to call attention to the fact that altough the attribute
namespaces RFC
(http://cytoscape.org/cgi-bin/moin.cgi/AttributeNamespaces) notes that
"In addition, namespaces would allow us to restrict attributes to
specific networks, nodes, or edges, thus simplifying the
presentation of attributes to users."
simply implementing attribute namespaces as noted in the RFC will
_not_ be a real implementation of network-specific (aka local)
attributes as noted in the local attributes RFC
(http://cytoscape.org/cgi-bin/moin.cgi/LocalAttributes).
Local attributes will be a required feature in cytoscape: for example
implementing network-specific numeric rankings (for example PageRank,
which is on the list of planned features at
http://cytoscape.org/cgi-bin/moin.cgi/Consolidated_graph_analysis_plugin)
_does_ _not_ make sense without having local attributes.
Using the planned attribute namespaces (as documented in the RFC) for
local attributes has the same problems as the workaround for local
attributes noted in
http://cytoscape.org/cgi-bin/moin.cgi/LocalAttributes#head-f86970889cb0be872dde39b26ce95d341e89f248
Adding namespaces (as I understand it) is basically the same as
enforcing a convention of having attribute names have the
"namespace.attribute" format. This is fine for separating attributes
of different plugins from each other, but the attributes created this
way will still be global, not local.
If this mechanism is to be used for local attributes, the following
needs to be taken into account:
- 'great local attribute change': for local attributes to be really
usable, all of cytoscape, and all plugins must be aware of local
attributes: some parts of cytoscape, and some plugins assume that
all attributes are global. These will have to be checked and
changed, as noted on the Local Attributes RFC. Note that simply
using attribute namespaces is _not_ a way to avoid this: using
namespaces is an implementation detail, while local attributes are
semantic different from global ones.
For example:
Lets try having a local 'A' attribute in two networks. If
attribute namespaces are used for local attributes, this attribute
would stored as, say, network1:A and network2:A (syntax is
irrelevant for this example, I am going to use the
namespace:attribute notation). Let's say the user creates a vizual
mapping or network1 that maps the A attribute to node color. Then,
he wants to use this mapping / visual style for network 2. This,
however, breaks: the mapping is defined with the attribute
network1:A and if vizmapper is not aware of local attributes, it
doesn't get turned into network2:A
This problem can only be solved if the vizmapper is aware that
some attributes are local, and has a special, 'virtual'
current_network namespace which is allways turned into the
namespace of the currently selected network.
Note that in my proposed patch attached to the Local Attributes
RFC, this issue is taken care of by simply having local attributes
shadow global ones. All the code that uses attributes requests the
attributes for a given network (unless it only uses global
attributes) which contain the global attributes.
Basically the locality of attributes and attribute namespaces are
semantically different.
Daniel Abel
ab...@freemail.hu