This GitHub contains the results from the project of the course 'Visualization of Medical Data 2', Tu Vienna
LaTex files -> https://www.overleaf.com/project/5e716618c1582f00010c61bb not synchonized atm
Citavi files
Graphs, tables, pictures, etc.
the used Data is stored in here
potential source: https://www.rcsb.org/
Molecular Visualization: Principles and Practice: https://www.youtube.com/watch?v=G5FxPdBMUHE&t=664s
State of the Art Guidelines from https://blog.babak.no/2007/05/22/why-and-how-to-write-the-state-of-the-art/:
So how to write a good SoTA? Writing a good SoTA is 110% dependent on having a clear problem definition. If you have failed in defining your problem clearly, you will fail in writing a good SoTA. The reason is that you will not know what related research you should investigate. So if you have problems with your SoTA, please go back and work on your problem definition! Here are some steps/hints on starting to write:
SoTA is not a one-way road. You will not sit down one evening and write your SoTA. You will do it all the time while writing your paper/report. Knowing what other researchers are doing should be a part of your life for all the duration of your research. So an important step is to create a system of registering and summarizing what you read. Use some bibliography software such as Mendeley, BibTeX or EndNode or Zotero, register everything you read, and register your understanding of what you read, in your own words.
Be critical when choosing your literature. Don’t read everything. There is a LOT of garbage out there on the web, and you don’t want to waste your time on garbage. One important criteria for choosing your literature is to make sure that it is peer-reviewed and is already presented/published in well-known conferences/journals. In case of technical IT-related stuff, ACM and IEEE are good places to start (do searches in Engineering Village). It is also a good idea to set up an initial SoTA literature list together with your supervisor.
Stop reading! Make an initial selection of literature (10-20 papers, depending on research problem) and stick to these for a while. Don’t go on finding new papers all the time, or you will never finish your thesis! Spend time on analysis and not on making summaries! A mere summary of 10-20 papers is not a SoTA. There is software out there that can summarize any paper for you, automatically and much faster than you ever will be able to. Your summaries become a SoTA only when you relate the SoTA papers to your own problem analysis.
Always give credit! Not giving credit for others’ research is also called plagiarism.
For more advanced writers: It is always a good practice to document your methodology for doing state-of-the-art survey. This means you should document how you searched for literature, what literature you included and what you excluded, how you did your analysis and so forth. This is called systematic review, and a de facto guide for doing systematic reviews in the field of software engineering is available here. You can also find many useful links on wikipedia.