Team:Edinburgh UG/Integrated Practices

Collaborations

Integrated Human Practices


DR SZYMANSKI AND DR SCHYFTER

After coming up with a project idea and designing a way to test out our method, we decided it was time to start a discussion about whether or not our project had practical applications. Our first meeting was with Dr Erika Szymanski and Dr Pablo Schyfter of the University of Edinburgh’s Science, Technology and Innovation Studies Department.

Their input really put our project into focus and laid down a track for the rest of our human practices. They told us that we were trying to target too many people with our DNA storage system and that we needed to be practical about who would actually use our product. As reading and writing data in DNA is slower than storing and retrieving something from a USB drive or even downloading a file from the internet, we needed to focus more on long-term, low access data storage. After this meeting we got in contact with local librarians and data experts. Return to the timeline to read more.

Another takeaway point from the meeting was that up until this point we had not thought about the physical storage of our DNA. Were we planning on storing the DNA in some sort of time capsule that was only to be opened at certain times? Or were we going to focus on more practical and accessible storage of DNA in vials? We addressed this when we tested the viability of DNA in different storage conditions.


DR ANDY TURNER AND DR ADAM CARTER FROM ARCHER/EPCC

Following our meeting with Drs Szymanski and Schyfter, we set up a time to talk to Dr Turner and Dr Carter from ARCHER and EPCC. ARCHER is a supercomputer at the University that runs simulations and calculations that are too resource intensive to be performed on a regular computer. EPCC hosts ARCHER along with other computing and data facilities. Drs Turner and Carter have extensive experience with generating and storing large amounts of data.

Though very positive of our idea, they confessed that DNA data storage would not work best for them. The simulations and research they facilitate require data to be generated and stored instantly and in high volumes, whereas DNA has a read and write time that is too slow to accommodate supercomputing. They suggested that we meet with librarians or archivists that store important, historical data for long periods of time. It is important to securely store this kind of data since it is often unique and cannot be regenerated or simulated.

They agreed that using Basic English as a proof of concept was very illustrative of our method, however, they pointed out that we should view the information coded in BabbleBricks to be flexible and that we should stress its arbitrary nature to others. Along with saying that this was one of our strengths, they encouraged us to come up with some sort of cost analysis comparing our assembly method to other storage techniques. They said that defining the ‘workflow’ of our project would help us decide whether we envision a BabbleBlock factory that stores all data in DNA, or whether we could scale down the system to a single machine. See how we investigated this with the Edinburgh Genome Foundry here.


EDINA AND MAIN LIBRARY

We were lucky enough to sit down with 5 librarians and data librarians from the University of Edinburgh Main Library. This big group meeting was great since some of the librarians actually had a background in genetics or biochemistry which meant we were able to get valuable and varying feedback.

The main points they raised were that data hardware and software are getting outdated. Often times data access is restricted by the software used to read the hardware. Though we are confident that our hardware (DNA) will last a long time, this really made us think about the future of DNA sequencing. With the current advancements in sequencing technology (ie. MinION) we also feel confident that the software needed to sequence our DNA will only improve.

One concern they raised was the limitations of how many BabbleBricks we could produce. At the time our 5bp information coding region allowed for 1,024 unique BabbleBricks. They expressed concern that this was not enough combinations to store different types of data. This feedback fed into the creation of BabbleBrick 1.7, read more about it here.

Finally, they again questioned how we planned to physically store the DNA. After explaining to them the different techniques of keeping DNA (dried, in a solution etc.) they offered us the opportunity to test the fidelity of our DNA in their existing storage conditions. This was an amazing opportunity to prove the applicability of our project; if DNA can survive in existing control conditions (and in less controlled conditions), then there is no need to specify special conditions that could consume more energy and money. To read more about our control room and viability experiments, click here.


DR DAVID ASPINALL AND DR MYRTO ARAPINIS

From the outset of our project we wanted to be able to include some form of encryption in our DNA data storage as this is something we had yet to encounter in the literature. At the start of the summer we met with Dr Aspinall and Dr Arapinis to pitch to them our initial ideas and see what feedback they had. Dr Aspinall is the leader of the Security and Privacy research group in our School of Informatics and also leader of the Cyber Security & Privacy Research Network at the University. Dr Arapinis is a lecturer in the School of Informatics with a research focus on verification of cryptographic protocols, such as verification of security properties and detection of attacks.

Upon explaining our initial ideas for encryption, Dr Aspinall suggested that we look into applying a stream cipher method to our DNA data.

Within the next few days we also met with Dr Arapinis, who agreed with Dr Aspinall that a good encryption system would include a stream cipher. However, at this meeting we pitched to her the Vignere cipher method that we had developed and she told us that if we kept this system our encryption could be hacked very easily. She recommended we look into Stream Cipher: SALSA. To see the full development of our stream cipher, click here.


DR KAMI VANIEA AND DR AGGELOS KIAYIAS

Text 3



Follow Us