undirected edges

[Abel Daniel]

Hi!

according to http://cytoscape.org/cgi-bin/moin.cgi/CytoscapeRetreat2006/Hackathon/HackathonNotes

" how/when do we deal with undirected edges?
Answer: we don't - action item: refactor Cytoscape to deprecate
methods that contain boolean directed in the signature (and add a new
method that doesn't have the directed flag to replace them)."

Does this mean that "undirected edges" feature will be removed? What
is the biggest problem with undirected edges?

The way I see it, only the following need to be ensured:

- I/O (i.e. file formats) supporting undirected edges
- VizMapper needs to handle endpoints of undirected edges in the same
way (i.e. not as source and target)

Is there anything elsse apart from these two that would force a
removal of undirected edges? Fixing these sounds like a small price to
pay for allowing undirected edges.

Thanks in advance,
Abel Daniel

[Mike Smoot]

Undirected edges have caused all manner of headaches in the past.  The issue, as I recall, primarily deals with knowing whether or not edges should be considered directed and then maintaining that state consistently across the application.  This isn't hard really, just lots of tedious, error-prone bookkeeping.

So the question is, what are you trying to accomplish that needs undirected edges?  

thanks,
Mike

Michael Smoot, Ph.D.               Bioengineering Department
tel: 858-822-4756         University of California San Diego

[Abel Daniel]

On Mar 22, 10:24 pm, "Mike Smoot" <msm...@ucsd.edu> wrote:
> Undirected edges have caused all manner of headaches in the past. The
> issue, as I recall, primarily deals with knowing whether or not edges should
> be considered directed and then maintaining that state consistently across
> the application. This isn't hard really, just lots of tedious, error-prone
> bookkeeping.

Could you show some examples of this 'bookkeeping'? I don't see how
this would be a problem
if undirected edges were fully supported. CyEdge has a isDirected()
method, so it should be
fairly obvious whether a given edge is directed or undirected.

If, on the other hand one tries to use undirected edges when the
underlying framework doesn't
support them then, _then_ error-prone bookkeeping can be expected.
Which would mean that
removing undirected edges from the framework would make it worse.

> So the question is, what are you trying to accomplish that needs undirected
> edges?

I think using directed vs. undirected edges depends more on the data
that is used, than on
what one tries to do with it. Supporting undirected edges sounds like
a pretty basic feature for
a general framework Cytoscape is becomming.

--
Abel Daniel

[Mike Smoot]

On 3/22/07, Abel Daniel <ab...@freemail.hu > wrote:

Could you show some examples of this 'bookkeeping'? I don't see how
this would be a problem
if undirected edges were fully supported. CyEdge has a isDirected()
method, so it should be
fairly obvious whether a given edge is directed or undirected.

True, there is support for directedness in some parts of Cytoscape, however it doesn't cover everything. The bookkeeping is primarily related to the user expericence.  For example:

• Do sif files get imported as directed or undirected edges?  Do we provide an option that allows a user to specify this?
• Do we support edge arrow visualizations for undirected edges?
• Can networks have mixed directed and undirected edges?  If so, how do we handle importing the line "a pp b" in a directed/undirected graph and then "a pp b" in a mixed graph?
• Can users change whether an edge is directed or undirected within Cytoscape?

> So the question is, what are you trying to accomplish that needs undirected
> edges?
I think using directed vs. undirected edges depends more on the data
that is used, than on
what one tries to do with it. Supporting undirected edges sounds like
a pretty basic feature for
a general framework Cytoscape is becomming.

I was just trying to help.  I'm not (necessarily) opposed to allowing undirected edges. However, since it's easy for visualizations to ignore directedness and without a strong use case demanding undirected edges, it becomes very hard to commit the time and resources necessary to make sure that it gets done correctly. 

Incidentally, the underlying graph libraries (e.g. graph.dynamic) used by cytoscape _do_ have full support for directedness.  You can certainly use those classes in conjunction with normal cytoscape operation if a calculation you're doing only works with undirected edges.


best,
Mike

--
____________________________________________________________

[Manway Liu]

Hi,

I'm wondering if there is a way to run the jActiveModules and Cytoscape
program through a command line interface, without invoking the GUI? I
would like to run the analysis through a computing cluster.

Thank you,
Manway

On Thu, 22 Mar 2007, Mike Smoot wrote:

> On 3/22/07, Abel Daniel <ab...@freemail.hu> wrote:
>>
>>
>> Could you show some examples of this 'bookkeeping'? I don't see how
>> this would be a problem
>> if undirected edges were fully supported. CyEdge has a isDirected()
>> method, so it should be
>> fairly obvious whether a given edge is directed or undirected.
>
>
>
> True, there is support for directedness in some parts of Cytoscape, however
> it doesn't cover everything. The bookkeeping is primarily related to the
> user expericence. For example:
>

> - Do sif files get imported as directed or undirected edges? Do we

> provide an option that allows a user to specify this?

> - Do we support edge arrow visualizations for undirected edges?
> - Can networks have mixed directed and undirected edges? If so, how

> do we handle importing the line "a pp b" in a directed/undirected graph and
> then "a pp b" in a mixed graph?

> - Can users change whether an edge is directed or undirected within

[Abel Daniel]

On Mar 23, 12:43 am, "Mike Smoot" <msm...@ucsd.edu> wrote:
> True, there is support for directedness in some parts of Cytoscape, however
> it doesn't cover everything. The bookkeeping is primarily related to the
> user expericence. For example:
>

> - Do sif files get imported as directed or undirected edges? Do we

> provide an option that allows a user to specify this?

I would make it user-definable. ie. provide a "import sif file as
directed
network" and an import sif file as undirected network. sif isn't the
native
file format of cytoscape, and it can't store a lot of things. (Things
that
xgmml can store)

In fact, it might be as simple as defining an "suf" format, which
would
mean "simple undirected format", look the same as a sif file,
but treated undirected. Such a change would be really simple since
only a new CyFileFilter subclass would be needed, and a boolean
parameter
added to the current sif-importing code.

> - Do we support edge arrow visualizations for undirected edges?
In my opinion, it should be possible to set "edge endings" which would
allow current arrow, etc. I.e. wherever in the current vizmapper code
there is source and target, add and endpoint case. So edge arrow
visualization would be determined by source and target for directed
edges, and by endpoint for undirected edges

> - Can networks have mixed directed and undirected edges?
Yes, why not?

> If so, how
> do we handle importing the line "a pp b" in a directed/undirected graph and
> then "a pp b" in a mixed graph?

When importing the user has to decide how to handle his/her data. But
xgmml
files could store mixed directed / undirected edges fine. (aren't they
currently preserving the directedness of edges?) And sif files
wouldn't be able to store mixed graphs. (and neither would suf files.)

> - Can users change whether an edge is directed or undirected within
> Cytoscape?
Can they change the edge ID? Can they reverse an edge now? I think
simply
having the editor support undirected edges would be fine. Then users
can
remove the edge and replace it with an other type of edge.

> it's easy for visualizations to ignore directedness

right. But cytoscape isn't used only for visualization. Lot of the
plugins
are about analyzing networks, transforming them and computing
interesting
properties. undirected edges will be more important for such usage
than
for visualization.

> it becomes very hard to commit the time and resources necessary to make
> sure that it gets done correctly.

Sure, it might be better to yank something out completely than to
pretend
that it works if it is too buggy. However, how much work would it
really be?
For 3 of the 4 issues you pointed out above, "do nothing" is a fairly
acceptable position. Forcing .sif files to be directed is an easy to
accept limitation, and the ability to treat undirected edge's ends
differently is a bug. But if undirected edges are taken out of the
framework (for example, they can't be created with Cytoscape.getEdge),
then not even plugins can handle undirected edges without resorting
to error-prone hacks.

> Incidentally, the underlying graph libraries (e.g. graph.dynamic) used by
> cytoscape _do_ have full support for directedness. You can certainly use
> those classes in conjunction with normal cytoscape operation if a
> calculation you're doing only works with undirected edges.

Aren't those maintained by cytoscape developers? if cytoscape won't
handle
undirected edges, how long will undirected edges be maintained in
those
libraries?

Are there any other issues apart from those 4 you mentioned? Would my
suggestions for fixes be accepted if I provide diffs?

--
Abel Daniel