Some of the dot examples of the article version 2 are not working

[matthiaskoenig]

Some of the test examples provided in Supplement 2 of https://f1000research.com/articles/5-2543/v2 did not work with Cytoscape 3.5.1 and dot-app 0.9.4 and could not be imported

dot-app_testing/Import/ER/ER.gv : Sorry! File did not comply to dot language syntax dot-app_testing/Import/philo/philo.gv : Sorry! File did not comply to dot language syntax dot-app_testing/Import/unix/unix.gv : target node is not a member of this network

All import examples distributed with the dot-app should work with dot-app (this should be part of the unittests). If the test examples do not work with the app there will be issues with real world examples. It is stated "We verified the dot-app import and export functions separately. All of the files we used in testing are found in ZIP 2 of the Supplementary Material." This seems not to be the case.

[bdtfitts]

Ok. There's a couple of problems that stem from these .gv files. The .gv files that you listed are the ones that the users created themselves before running the neato utility on them. During our import tests, we ran the neato utility on the user-supplied DOT files in order to create a new DOT file (which we suffixed with _layout) that contains the layout information. It's this new DOT file that we import into Cytoscape for testing purposes. You will see that importing the *_layout.gv files work as intended. The user-supplied DOT files contain syntactic sugar that is unreadable by the JPGD parser that we use, but this syntax goes away when a user runs these files through a Graphviz utility to create a new DOT file containing the layout information.

[matthiaskoenig]

I don't understand this. Either the files are valid graphviz files, than they should be rendered in dot-app, or they are not, but than they should not be listed as gz files.

I had no problem displaying the files with something like http://www.webgraphviz.com/ So I assume they are valid files.

As far as I can remember, it was mentioned in the manuscript that one has to run the dot/graphviz files through neato first to be able to use them in dot-app. But after your answer seems to impla that if I have a dot/graphviz file I first have to run it through neato to make sure I can import it with dot-app. Is this correct?

You should communicate this to the user in the error messages of the dot-app reader. I.e. if there are problems reading the graphviz files users should run it through neato first (whatever this is). This should probably be documented somewhere.

[bdtfitts]

You are correct in that they are valid DOT files. I will have to take a look at the files individually to see why JPGD is unable to parse them correctly.

However, I want to point out that those files were not used during the testing of dot-app. Those files were added to the archive so you would be able to see the DOT files that we grabbed from the Graphviz Gallery webpage. We only tested the import process on the files that were outputted by the neato utility (which we suffixed with _layout). We tested the import process only on these files because we believe that the common use case for dot-app would be for users who applied a layout algorithm (that is, ran one of Graphviz's utilities such as neato or dot) to their DOT files.

[matthiaskoenig]

Okay. I understand it now. Thanks for the explanation. This was not really clear from the manuscript and was phrased like all the dot files in the supplement were tested.

On Sun, Jul 30, 2017 at 3:42 AM, Braxton Fitts notifications@github.com wrote:

You are correct in that they are valid DOT files. I will have to take a look at the files individually to see why JPGD is unable to parse them correctly. However, I want to point out that those files were not used during the testing of dot-app. Those files were added to the archive so you would be able to see the DOT files that we grabbed from the Graphviz Gallery webpage. We only tested the import process on the files that were outputted by the neato utility (which we suffixed with _layout). We tested the import process only on these files because we believe that the common use case for dot-app would be for users who applied a layout algorithm (that is, ran one of Graphviz's utilities such as neato or dot) to their DOT files.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/idekerlab/dot-app/issues/15#issuecomment-318871501, or mute the thread https://github.com/notifications/unsubscribe-auth/AA29uqN80N7OwqgEwiADMPsky-BeSEgRks5sS995gaJpZM4Ok7Cl .

-- Dr. Matthias König Junior Group Leader LiSyM - Systems Medicine of the Liver Humboldt-University Berlin, Institute of Biology, Institute for Theoretical Biology https://www.livermetabolism.com konigmatt@googlemail.com Tel: +49 30 20938450 Tel: +49 176 81168480

[bdtfitts]

Hi there, I was looking over this project due to a recent issue that was posted and realized I never got back to you on those 3 files. In case you are curious, using the 0.9.4 release of dot-app with Cytoscape 3.5.1, I wasn't able to reproduce the error with the unix.gv file but I was able to reproduce the error with both ER.gv and philo.gv.

I am unsure why the unix.gv file did not work for you during import and it worked for me (I can't believe that running the code with the same build but a year later would make a difference). I even tried the 0.9.3 release of dot-app and it worked with the import.

With file philo.gv, the problem was with the first two lines. In that file, the creator used "#" to signify comments, which the JPGD parser did not recognize. The JPGD parser only recognized "/ /" and "//" for comments. The DOT Language states that the "#" character signifies output from the C preprocessor and is discarded. I cannot speak for the creator for JPGD, they could've made the assumption that "#" would never be found at the start of a line.

With file ER.gv, it's an issue with how the parser decided to implement the DOT language. In the DOT language specifiication, statements can be optionally ended with a ";". The way JPGD handles this is that statements either end with a ";" or a new line. In that ER.gv file, the node attribute statement "node [label="name"]" is separated by the node declaration statement "name0;" and the JPGD parser fails to parse the two. After that file is ran through the neato utility, all of the statements are terminated by a ";" and that ends up resolving the issue.

I won't be able to resolve the issues that JPGD has with the ER file because it requires modifying the parser to an extent that I am very unfamiliar with. I might be able to make a slight change however so that it recognizes "#" as a comment starter.