Cytoscape 3 Data I/O Layer

(Under Construction)

Data Sources

Cytoscape as a Data Source (Server Version)

Use Cases / Requirements

Open Issues

Design Ideas

Import

The concept is to compose Reader objects using different, independent interfaces that define what gets read. The benefit of this approach is that different Readers can be tailored to work for precisely the right kind of data.

There would be a core interface that would trigger the read (of all data types) and possibly specify the input source.

public interface CyReader {
   public void read();
   public void setInput(URI uri);  // Or something.  There just needs to be a general way that input can be specified
}

The CyReader object could then be supplemented by one or more interfaces that identify what the CyReader will read. The return values of methods indicate what sort of objects will be produced from a given file. If the CyReader is capable of producing a CyNetwork from a given type of input, then it should implement an interface like:

public interface CyNetworkProducer {
   public List<CyNetwork> getReadNetworks();
}

A network reader service would then implement both the CyReader and the CyNetworkProducer interfaces. The getReadNetworks() method could then be called after the read() method has completed.

If the input data contains attribute data in addition to network topology data that we'd like to read, then we could provide an additional interface for the Reader to implement:

public interface CyDataTableProducer {
   public List<CyDataTable> getReadCyDataTables();
}

This separation between a CyNetworkProducer and a CyDataTableProducer is useful because a SIF file doesn't contain any additional attribute data and so it wouldn't make sense for a SIF reader to implement a method like getReadCyDataTable(). However, such a method would be necessary for an XGMML reader.

This approach is extremely flexible because it allows Reader objects to be composed of several different interfaces. If we ever introduce a new data type (e.g. reading a background image) then we would create a new interface to support that data type. Existing readers could then simply add a new method to their implementation.

Import Alternative 1:

Instead of the Reader object producing an object (e.g. a CyNetwork) it could allow for an object to be updated. The parameters of the methods in the interfaces would provide the objects that get updated when CyReader.read() method gets called. So to read a network, you might have an interface that looks like this:

public interface NetworkUpdater {
   public void updateNetwork(CyNetwork n);
}

The updateNetwork() method would be called first to provide the network object (i.e. an empty network) to the reader, then the read() method would be executed which would update the network based on whatever input was provided. A benefit of the update paradigm is that existing networks or tables could be easily supplemented instead of new ones created. A disadvantage is that you'd have to know how many networks would need to be updated beforehand. Perhaps that is a fatal flaw.

Export

Export could use a similar composition strategy to Import. There would be a core Export interface:

public interface CyExporter {
  public void export(File f);
}

Then the CyExporter would be supplemented with other interfaces like CyNetworkExporter that specify which networks to be exported:

public interface CyNetworkExporter {
  public void setNetworks(List<CyNetwork> n);
}

Implementation

Bundles

IO module will be consists of 3 main bundles:

These bundles are available in Core3 SVN repository.

File IO

Outdated_Cytoscape_3.0/IODiscussions (last edited 2011-02-24 15:34:05 by PietMolenaar)

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