yED-exported GraphML imported into GRNsight

[kdahlquist]

Now that I've discovered that I can export GraphML from yED, I could test a yED-export being imported into GRNsight.

Good news:

• The file imports and a graph is loaded with the correct number of nodes, edges, and correct edge connections.

Bad news:

• It is doing the same thing that was happening initially with the Cytoscape GraphML: it is using the node id as the label for the node and is not recognizing the node label (it is obviously encoded differently than the Cytoscape node label).

I think that you could probably fix this and be able to read a yED GraphML file even if we are not going to do the fix to GRNsight GraphML-export for the labels to appear in yED.

The relevant information is in an element called y:NodeLabel. In the line pasted below, the actual label is "Gene1", the rest of it is parameters for the graphical layout, I think.

      <y:NodeLabel alignment="center" autoSizePolicy="content" fontFamily="Dialog" fontSize="12" fontStyle="plain" hasBackgroundColor="false" hasLineColor="false" height="18.701171875" horizontalTextPosition="center" iconTextGap="4" modelName="custom" textColor="#000000" verticalTextPosition="bottom" visible="true" width="40.029296875" x="-5.0146484375" y="5.6494140625">Gene1<y:LabelModel>

I did mess around with trying to edit a GRNsight-exported GraphML file to see if I could make the necessary changes for the labels to appear in yED, but no luck so far. The encoding is a little too complicated for me to isolate what is required by hand.

I think it is worth mentioning that both Cytoscape and yED separate the notion of a node ID with a node label. A node ID is required to be unique, as expected, but a node label is not. At least the way that yED assigns node labels is a little more human readable in the sense it starts with "n0" and goes from there (n1, n2, n3, etc.) as opposed to Cytoscape's SUIDs However, the node ID in yED is not even visible to the user, let alone changeable.

Needless to say that in GRNsight, the node ID and node label are identical. In the GRNsight adjacency matrix format, we require the IDs to be unique, guaranteeing that the labels are going to be unique. However, Cytoscape and yED do not require labels to be unique, so when they are imported and display in GRNsight, you could get two nodes with the same label. I've done it and it loads. I know that is loaded correctly only from the general shape of the network (I've only tried simple 4-node networks for this test).

For the moment, I think I need to document this in the help. For the future, we probably need to test for the non-uniqueness of labels and warn the user to go either let it load or go change their input file.

For what it's worth, yED-GraphML imported into Cytoscape reads the node IDs and has a hyphen as the interaction type.

So, back to the original issue--do you think you could at least read a yED-exported GraphML file with the correct labels for nodes?

[dondi]

Yes, I was able to implement a check for y:NodeLabel and it is up in beta. One question though: if all three keys so far seen are present—shared name, name, and y:NodeLabel—what should be the priority for reading them? (right now, name gets top priority, followed by shared name, then y:NodeLabel, then id)

[kdahlquist]

A manually created network in yED exported to GraphML isn't loading in v1.17.

The text "Object]" is appearing in the upper left corner and no network appears.

The filename is appearing in the menu bar and the correct node and edge count is appearing, just not the graph.

[kdahlquist]

Oh, and to answer your question, I think the priority you have set for reading the names/labels is OK.

[dondi]

I’ll need to see the manual file to troubleshoot this, particularly the data element. I uploaded a test yED GraphML file to test-files/import-samples (taken from http://docs.yworks.com/yfiles/doc/developers-guide/graphml.html). That is the model I used for the import routine.

[kdahlquist]

Here's the file.

4-node_4-edge_manual-yED_20160810.zip

[dondi]

OK, so the issue turns out to be the possibility that a yFiles node label may itself contain subelements. I’ve updated the import code to accommodate this.

[kdahlquist]

Confirmed to work!

[kdahlquist]

I'm not going to reopen this, but I think I've discovered how yED encodes it's weight values in GraphML. I'm working on the response to reviewers and got to the part where I describe opening an Excel file in yED. The import wizard allows you to specify an "Edge Value", which is the weights in our adjacency matrix. These then get encoded as

<key attr.name="Edge Value" attr.type="double" for="edge" id="d8"/>

with an instance looking like

 <edge id="e9" source="n5" target="n6">
  <data key="d8">0.2851557206351617</data>

with, of course, other stuff below it to specify the drawing. I'm attaching the file for future reference, no action is required right now.

15-genes_28-edges-random3_GJ-dHAP4-fam_strains-added_Sigmoid_estimation_output_yED.zip

[dondi]

Interesting, that would have been a no-brainier had they set attr.name="weight" because then, we'd already be handling it! But no they had to change up the vocabulary. Oh well. Yes, conceptually shouldn't be hard, but due to the change in attribute name it will require additional code so yes, save for another day.