RFC Name : Supporting "namespaces" for attributes

Editor(s): ScooterMorris

Status: Not yet completely written

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


The proposal is to extend the CyAttributes API to add "namespaces" that would provide some way to scope a name. This is particularly important now that plugin authors are being encouraged to use attributes as the primary way to store information related to a node, edge, or network. Plugin authors are wondering how to make sure their attribute names will be unique. In addition, namespaces would allow us to restrict attributes to specific networks, nodes, or edges, thus simplifying the presentation of attributes to users.

Biological Questions / Use Cases

Backward Compatibility

By default, there could be a "null" namespace, which would be inferred when the existing CyAttributes API is used. In this manner, the existing functionality will be preserved, both in terms of the user expectations and in terms of the API.

Implementation Plan

The plan is to extend the existing APIs as follows:

  1. Cytoscape.getNodeAttributes and Cytoscape.getEdgeAttributes will get additional signatures:
    • Cytoscape.getNodeAttributes(String namespace)
    • Cytoscape.getEdgeAttributes(String namespace)
    The existing signatures will return all node and edge attributes as they currently do.
  2. All get and set routines will get additional signatures to by adding a String namespace argument that will indicate the namespace to be used.

  3. Internal representations of namespaces will need to be determined. Initially, I would imagine that a namespace will simply be some form of prefix or suffix added to the attribute name. This would be scanned as appropriate when setting or getting namespaced attributes. If this turns out to be a bottleneck, we can examine setting up internal maps to the namespaced attributes.


KarlForner - 6/27/2007

I have one question about the "null" namespace and backward compatibility: if the attributes under a namespace are not visible under the "null" one, that implies that a tool as the nodes attributes browser will not show them, at least without a modification allowing to see/select namespaces. And what if we want to display and use attributes belonging to several namespaces ? The consequence is that a lot of tools will need to be updated : vizmapper, attributes browser etc...

So instead if we turn the internal representation of prefixing by a String prefix into a feature : suppose that we could forbid a given character/separator in the attributes names, say ":" or "|", or a substring like "://", this way by using the backward API we can list and read all the attributes, but not create new ones in namespaces. By using the new namespace-aware API, attributes names would be automatically preprended with the namespace prefix followed by the "forbidden" separator.

So to sum up :


ScooterMorris - 6/27/2007

I'm assuming that core plugins should (and will) be modified to support the new API. That's one reason we're looking at a 2.6 implementation. The idea with the "null" namespace is that it would mimic the current behavior -- that is, it would provide access to all attributes. We might also need to have a "default" namespace of some sort in the future.

As far as the internal representation, I suspect we'll come up with some sort of syntax like what you've proposed, but I think we should focus on the API and future functionality first, then we can discuss how to implement backwards compatibility.

MikeSmoot - 8/8/07

A couple of thoughts:

AttributeNamespaces (last edited 2009-02-12 01:03:29 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