Team:METU Turkey Software

From 2010.igem.org

(Difference between revisions)

Latest revision as of 11:40, 16 April 2011

Abstract

As Synthetic Biology field is on the rise, iGEM also grows up and number of parts in parts registry increase with submission of more complex constructs each year. Our first milestone was to perform more efficient standardization on parts entry due to facing some difficulty while running our algorithms on the parts registry. We also used Software Requirements Specification, Software Design Description and Quality Plan approaches to define requirements for each part and building blocks, risks and design art elements of the designed software program.

Next, we have used graph theoretic modeling to visualize relations between parts and to standardize representation of the parts as much as possible. It will help us when we try to find input-output relations between either biobrick parts or constructs. By this way, our program BIOGUIDE will act as a guide for searhing biobricks and will provide alternative pathway choices to users for construction of the most reliable devices with respect to given inputs and expected outputs.

Team

METU Turkey Software is an interdisciplinary team of 7 students and 4 advisors from various backgrounds such as Molecular Biology, Bioinformatics, Computer Engineering and Computer Education and Instructional Technology. We have put our knowledge and experience in our fields together to bring a much needed solution to a daily problem in field of synthetic biology for iGEM 2010

Tolga Can

Tolga Can received his PhD in Computer Science at the University of California at Santa Barbara in 2004. He is currently an Assistant Professor of the Department of Computer Engineering, Middle East Technical University, Ankara, Turkey. His main research interests are in bioinformatics, especially prediction and analysis of protein-protein interaction networks, and statistical methods such as graphical models and kernel methods.

Yeşim Aydın-Son

Yeşim, has received her M.D in 1999 from HÜTF, Ankara and completed her Ph.D at University of TN, Knoxville on Genome Science and Technology in 2006. After working as a research fellow at City of Hope National Medical Center, Duarte,CA , she has recently accepted her current position at METU Informatics Institute as an Assistant Professor of Medical Informatics. She is also the acting coordinator of the Bioinformatics Graduate Program in METU. Main focus of her research is Genomic Biomarker discovery and applications of biomarker research in Personalized Medicine . Her research group is working on building a new integrated application for genome wide association of SNP biomarkers and discovery of genes and pathways related to diseases, where SNP genotyping data from both microarray and next generation sequencing experiments can be analyzed in all-in-one step.

Ömer Nebil Yaveroğlu

Ömer Nebil Yaveroğlu is currently a PhD Student in Imperial College, London. He has worked as a teaching assistant between 2008 – 2010 in the Computer Engineering Department of Middle East Turkey. Throughout his MSc studies, he tried to understand the orthological similarities between the protein interaction networks of different species using graph theory. He helped the group as an advisor in the computing related discussions

Burak Yılmaz

I am a recent graduate of METU Molecular Biology and Genetics department and now studying towards my masters degree on Molecular Bioengineering at METU. My interest in synthetic biology did start during my undergraduate years and after graduation I started up the Sentegen company which is the first biotechnology based company focused on synthetic biology in Turkey. I continue my research and training in synthetic biology while also contributing to the development of the field in my country. We need new scientific revolutions to solve huge problems of life and emerging field of synthetic biology is best candidate for biotechnological revolution. I am interested in synthetic biology applications, along with Lab-on-a-Chip devices for molecular biology techniques, and we are designing gene synthesis chips to produce biobricks - raw materials of synthetic garage biology- faster and cheaper. I enjoy snowboarding, cycling and write poems.

Muhammed Akif Ağca

In bachelor he has worked on Software Development, Database Management, Instructional Technologies, and Bioinformatics. He was developing the software and leading the team. A new page to his life is starting at 2011 after becoming a graduate of Computer Education and Instructional Technologies. He says that " If we can use technology and science efficiently we can solve too many problems in the world, but if can use. That is if we can manage those we can solve the problems and organize the world with minimum problems " which is a study field Science Technology and Management ( STM ) which is the field he will start to work in 2011 ".

Cihan Taştan

2010 is the last year for me as B.S degree at Molecular Biology and Genetics department. Moreover, I am studying at Computer Engineering as my minor department. My research will be on Scientist position at Cancer and Virology Relationship (Let's say Viral Oncology) by integrating novel technices of Bioinformatics and Synthetic Biology approaches. This is my second year at iGEM.

Hassan Salehe Matar

Ascended up the hills of Kilimanjaro, crossed over the savannah of Serengeti and finally landed on the country of Istanbul my name is Hassan Salehe. I'm a final year undergraduate student at the Department of Computer Engineering, Middle East Technical University. In Metu Turkey Software I'm a database administrator and a core Software developer. I'm interested in software development, database management, Computer networks and Bioiformatics I do marathon, I like swimming and I'm fond of action movies.Oh, I was about to forget to tell you that I also like traveling. Thanks!

Ayub Rokhman Wakhid

From the country of thousand islands, across the ocean he came to Ankara. Now he is finishing his undergraduate study at the Department of Computer Education and Instructional Technology, Middle East Technical University. This is the first time he joined IGEM. He is in design team in Metu Turkey Software. He has interest in animation, web development, and instructional technologies.

Muhammad Fakhry Syauqy

A senior undergraduate student of Computer Education and Instructional Technology at Middle East Technical University. He came far away from Indonesia to Ankara, Turkey, to make a great leap on his life. His role in this team is designer. Together with Ayub, they designs the team's wiki, poster. He is interested in 2D and 3D designing, web developing and animation. He loves playing football and working with computer. His motto is "Possibilities are limitless"

Saygın Karaaslan

Our multimedia support and the core of our design and animation team. Saygın, is a senior in Biology department at METU and about to launch his own scientific animation company. After graduation he will be continuing his academic studies on medical informatics, scientific data visualization and 3D molecular animations. He has recently completed the production of OCW for molecular biology laboratory lectures as video-notes. Never says no to a good soccer game or mafia II. We look forward for the day for the premier of his documentary on "History of Science"

Yener Tuncel

I have graduated from METU Molecular Biology and Genetics department and just started the Bioinformatics Graduate Program this fall. My main research interests is in systems biology, and its applications. Currently I am focused on genome wide association of SNP biomarkers, where we will utilize systems biology approaches for discovering disease gene and pathway associations after highthrough-put genotyping studies. During the course of our research on the iGEM project this summer as a Molecular Biologist I worked on the standardization of the parts information for our applicaiton database. Also, as a Bioinformatician in training, contributed to the development of the algorithms for the BioGuide software. Besides research, I develop educational tools for biology and bioinformatics education and getting used to do couples dancing.

Motivation

Since 2008, we have been participating in iGEM as METU ( Middle East Technical University) wet-lab team, and each year we have noticed the increasing number of teams participating, along with an increase in biobricks entries at partregistry.org. While having more choices of biobricks to choose from is incredible, searching for and choosing the appropriate parts is becoming a challenge. This year during the construction process of iGEM biobrick parts for our new project, we felt the need for an application to find interacting parts based on an input/output model to design the genetic constructs. Using a specialized software for searching the parts registry to find possible biobricks to include into our construct would be much easy, fast and accurate than manual. We have shared our need with a group of friends who are software engineers, and initiated the METU_Turkey_SOFTWARE team where we worked together over this summer to build the BIO-Guide software.

Scope and Future Aspects

The partregistry.org is a continuously growing collection of standard genetic parts that can be mixed and matched to build synthetic biology devices and systems. The Registry is based on the principle of "get some, give some". Registry users benefit from using the parts and information available in the Registry for designing their own genetically engineered biological systems. In exchange, the expectation is that Registry users will contribute back to the information and the data on existing parts and will submit new parts they have designed in order to improve this community resource.

As an expanding database partregistry.org needs to be more organized and the standardization template needs to be improved. Additionally, the potential of multiple ways of using each part in different construct combination brings out the necessity for an application to search through the database. BioGuide is the first designed software that organizes over 1000 parts in partregistry.org as possible atomics parts to build new biological device and systems for specific input and outputs based on graph theory. The requirement of similar applications and software tools are now inevitable in the emerging field of synthetic biology. The innovative approach that makes the partregistry.org easy to use for synthetic biology applications is the collection of standardized parts that can be used in any combination with minimal effort under one database. But while working on our algorithm to search for possible combinations of parts depending on the given input and output, we have realized that present standards are inadequate and parts registry form must be improved.

In very near future a new format for parts registry form is needed and few additional features should be implemented to have more control on the database. We are planning to suggest a new format and features for the parts registry based on the survey results we have received. And planning to build the next version of Bioguide based on the revised parts registry form. Along with using new parts registry standards we will be improving the algorithm, so that the software can search through more complex relations and returns all possible functional constructs.

Project Introduction

As the field of Synthetic Biology is on the rise, iGEM is growing up very fast and the number of parts in the parts registry is increasing with the addition of more complex parts each day. After facing some difficulty while running our algorithms on the parts registry, the need for more effective standardization of parts entry was apparent. We have investigated the information on parts in iGEM’s 2010 distribution and reorganized the information on the parts registry forms according to the needs of our algorithm. Then we have used graph theoretic modeling to visualize the relations between iGEM Parts and to standardize the representation of the parts as much as possible by graph theoretical methods. This helped us to find input output relations between the parts. Furthermore, our program BioGuide is now able to provide alternative pathways to construct the most reliable and functional Biobrick devices with respect to given inputs and expected outputs as a guide to Biobricks parts registry.

Notebook

January

Brain Storming about the iGEM.

What is iGEM.
Previous Wet-Lab Projects developed at METU.
What kind of projects can be developed as a software team.

NOTE: The first software team in Turkey...

February

Reading articles about iGEM WetLab and Software team projects.
Looking for the members of the team.
Looking for the instructors who can consult the team.

March

Employing a member to team interested in Synthetic Biology.
Reading articles about Synthetic Biology, Bioinformatics and Bio Engineering.
Founding the team [ An instructor, and student members ]

April

At this month we have started regular workshop about Synthetic Biology, Bioengineering, and Bioinformatics.

This month biologists in the team telling the needed basics to software group.

Week 1

Workshop -1

[Biology basics, What is Synthetic Biology?, and the works in this field ]

Week 2

Workshop -2

[What is Synthetic Biology?, and the works in this field ]

Week 3

Workshop -3

[iGEM, Parts, Biobricks, and Devices ]

Week 4

Workshop – 4

[iGEM, Parts, Biobricks, and Devices ]

May

At this month we have completed our workshops, and as the masters in this field started meeting with instructors. /

Meanwhile, looking for sponsors [We have designed a document telling the iGEM, previous project and our project generally and started to send it private companies who can found us.]
This month it is turn to software group; they are transferring the basics of software concepts to biologists in the team.
Furthermore, we are discussing about how we can apply the basics of computer engineering to synthetic biology and iGEM parts.

Week 1

Meeting -1

[First, discussion on articles that have been selected by consulters. Then, brain storming about the selected iGEM projects from previous years and our project ]

Week 2

Meeting -2[with consulters ]

[Tellingtheprevious projects to consulters and telling our initial idea about project. Then, brainstorming about our project. ]

Week 3

Meeting -3

[Basic databaseconcepts and iGEM parts. ]

Week 4

Meeting -4

[What is ER Diagram and How we can develop a database model for iGEM parts with ER Model. ]

June

At this month software group is going on to tell the basics of software development and programming and computer engineering, discussions about the computer engineering approaches are continuing.

Furthermore, we have constructed the design group for web page, poster, presentation, and an attractive animation telling us.

Week 1

Meeting – 5

[Graph theory, Graph theoretic modeling, and graphical modeling of iGEM parts. Using Input Output loops on iGEM parts. ]

Week 2

Meeting – 6 [ With Consulters ]

Project Description.
Our tasks on holiday.
Telling our project and basic concepts to design team.
Discussion on storyboard for animation.

Week 3 and Week 4

HAVE a NICE HOLIDAY

SEE YOU ON JULY 1 as a POWERFUL TEAM; “METU TURKEY SOFTWARE”.

July

At this month we have started to develop application. And divided the team to 3 groups [ Software - Gene – Design ].

Gene group is providing row data to software group by extracting it from the part registery and other resources.
Software group is developing application.
Designers are learning new design tools, and applying those to our project [Not all Members of the group working actively for the team].

NOTE: Members are not strictly assigned to a group; this is just for organization of tasks.

Week 1

Meeting-7

Take stock for current situation.
Discussion on web, poster, animation design.
Discussion on storyboard for animation.
Task analyses for each group [ Software, Gene, Design ].

Week 2

Meeting – 8

Checking the tasks of each group.

· Software Group

Database Design
Interface for DB.
Designing a basic SRS and SDD to be able to state the requirements of application exactly .

· Gene Group

Extracting I/O information for each part in part registry according to specified standards by Gene group.
Discussion about expectation from the software.

· Design Group

Team Logo
Web site
Poster
Animation
Presentation

Week 3 and Week 4

DOING THE TASKS.

August

At this month we have started to apply graph theory on iGEM parts. We have specified nodes, edges, graph types. Furthermore, we have started to develop a new “ Part Registery Form ” to be able to more standardize the part entry to be able to apply some algorithms on the parts more efficiently.

Week 1

Meeting -8

/

Node data extraction algorithm.
Node description.
Visualization of nodes.
Pathway finding according to specified I/O properties.
Representing the nodes with original images.

Week 2

Meeting -9

Whichone is node part or subparts or both are nodes in different graphs?
Part Combination rules.
Web site, Poster Content
Animation storyboard.
Survey for new “Part Registery Standarts”.
NewPart Registery Form.

Week 3

Meeting -10

/

Extraction of Part Combination Rules
Web, poster, presentation contents generally.

Week 4

Meeting -11

USTC and Berkeley projects.[ https://2009.igem.org/Team:USTC_Software and https://2009.igem.org/Team:Berkeley_Software
Graphical representation of node relations.
Part Combination Rules
Subpart Combinations Rules
Expectations from the software (SRS: Functional; Requirements)

September

At this time all bases for application were nearly to finish, the software group was waiting row data from the gene group. Meanwhile, they were working on code bases.

Week 1

DOING THE TASKS.

Week 2

Meeting -12

Final Database
Final Graphs
GUI
Expectations from the software (SRS: Functional Requirements) (Suggestions)
Survey details

Week 3

Meeting -13

Animation (Storyboard, timeline)
Web site (Suggestions to web site)
Poster (How we can use 3D stereoscopic image, How we can tell the development progress and our concepts by 3D effect etc...)
Presentation ( Suggestions about presentation )

Week 4

Meeting -14

Final Graphs
GUI ( about 70 % is over )
How to send the software to other teams for collaboration ( just general ideas, details will be talked later ).
With survey or not , can it shade the software?
What to ask to teams while sending?

October

Now everything is nearly over, it is time to put everything together.

Gene group explaining the methods that we have used during project.
Software group finalizing, software, testing it importing new function according to collaboration results with METU TURKEY wet lab team., trying to solve infinite bugs…
Design group putting all together…
Meanwhile, all team is writing the content for web, poster, and presentation.

Week 1

Meeting -15

BioGuide Application, missing points.
Content writing
Web, poster, animation

Week 2, Week 3, & Week 4

GOOD NEWS Infinite meetings started :)

Writing content [shared it, tasks assigned to members according to their fields.]
Software; debugging, testing, adding functions…
Designers web, poster, presentation, animation, importing content…

November

November 1 – 12 is our ticket dates,

See you in BOSTON …

METU TURKEY SOFTWARE

Follow our discussion topic at our googlegroups

Download Executable and Code

You can download BioGUIDE at http://sourceforge.net/projects/bioguide

Download & install it and feel it's power!!

Collaboration

Part Registry Survey

Click here to go to survey page..

Results

(including responses between 10th -22nd of Oct 2010)

General Profile of Participants

The following teams are dedicated as collaborators with more than 60% team participation are

INSA-Lyon
Lethbridge
WashU

Out of 244 participants between 10 to 22.10.2010, 57% of the participant had scientific degrees from B.Sc to Professor and 18% had graduate degrees. 18% of participants are enrolled in their teams as either Instructors or Advisors.
95 teams have responded to the survey while we are still waiting to hear from 33 teams. 74% teams participated with one or more members to the survey.
75% of participants were interested with synthetic biology field for academic purposes.

Browsing the Registry of Standard Parts

56% of participants think that it is not easy to search for the parts in Registry of Standard Parts. Many comments indicate a need for a better search engine and more flexible keyword search options, especially excepting aliases. Also many are longing for recognizable parts names, which will ease searching with keyword.

Partnership with Google and enforcing standardized parts names are suggested

As a global organization iGEM can offer the Parts Registry in different languages and more illustrations describing how the system works.

Content of Registry of Standard Parts

57% of participants agree that the number of parts registered in the Registry of Standard Parts is not enough for their projects.
55% of participants think that there are enough and useful parts distributed in iGEM Plates that we can use in our projects.

Even though most agree the number of parts in the registry is impressive, still they find it limited when it comes to design different devices for diverse applications especially in different species other than E. Coli. Participants believe that if there are more functional standardized parts, especially protein coding sequences and promoter-RBS , they can design devices according to the needs of the community instead of designing what can simply be assembled into a device.

Encouraging development of vectors and standards for new species and new standardized parts in different research areas is suggested.

Enforcing submission of right DNA sequences and working conditions for each part is suggested.

Few recommend expanding iGEM into a collaborative effort rather than an undergraduate tournament, which will increase the number and the diversity of the parts designed and submitted all throughout the year.

Submission to the Parts Registry

52% of participants said that they have not encountered difficulties during submitting parts. Even though participants are satisfied with the web interface of the registry, most complains about the pSB1C3 as the new standard plasmid to submit DNA.
71% of participants are like minded with our team's opinion, which is that The nomenclature of part IDs such as construct, device, composite parts, protein generator, is confusing as there is no consensus on how to use them correctly.

Terminology and categorization used on iGEM’s Parts Registry should be re-described and correct use of terminology should be enforced during the submission process.

75% of participants agree that different, specified submission interfaces should be designed for contructs, promoter, RBS, CDS and terminals is needed during Registry of Standard Parts. But, there are very strong and valid arguments against it such as, losing the flexibility of the registry will not allow future submission of unclassified parts.

We suggest keeping the parts submission interface as is, until these concerns are addressed.

75% of participants agree that Out-dated, un-available and not-characterized parts in the Registry of Standard Parts should be removed to an archive after the consent of the designer.

“It would be great to see some sort of organization like this! I agree that unavailable parts should be followed up on and removed if necessary. I also think that parts which are not sufficiently documented should be highlighted in some way. Once these parts are identified, teams can actively characterize them as part of their projects or as side projects.”

“Think about these things: (i) who decides when a part is out-dated, and how can that person know that an old part cannot have a novel use in the future? (ii) likewise, an uncharacterized part may be both characterized and used in the future”

We suggest building a backup system, such as an archive, to sort out the rarely used, un-available and un-categorized parts until they are in line with the enforced standards.

91% of participants have same opinion with us, which is that standardization of the nomenclatures used for each different composition of parts is necessary.

Standards that should be enforced and Additional New Standards

According to our survey, from high rated to low, these standards have been rated which has been used while assigning a name to parts

33% Type of part
17% Input
17% Output
14% Version
10% Year
9% Group

Along with above, having short recognizable part names along with function and performance , Genbank/EMBL link and organism information is important.

93% of participants have said that for the parts that are marked as “WORKS” distinguishing the parts with quantitative experimental validation vs parts without this information is important. Most participants have encountered with similar problems about parts that don’t work under their lab conditions or works but not they were claimed for.
89% of participants have same opinion with us, which is that iGEM should sub-categorize the “WORKS” comment into 1) “Quantitative” for parts which are characterized with experiments and 2) “Qualitative” for parts which are not characterized will be an appropriate measure for standardization of Biobrick database.

In order to overcome these problems we suggest enforcing the working conditions title for the registry entrance, in order to collect quantitative experimental details on submitted parts, which might slow down the registration process but will definitely increase the quality of the database.

61% of participants agree that POPS (Polymerase Per Second) should be assigned to every part or biobricks with a promoter, where appropriate. - 57% of participants have been agree that RIPS (Ribosome per Second) should be assigned to every part or biobricks with a RBS brick.

Though most participants agree the need for POPS and RBS information , they are concerned about the workload it would bring to individual labs.

“To do this, the Registry need to define a reliable and easy method of determining the PoPS for teams to use. However, I would say that there are better systems for quantifying promoter output than PoPS, and they should be used instead, if possible”.

67% of participants have thought that entering POPS information should not be mandatory while submitting new parts. Similarly, 65% of participants disagree that entering RIBS information should be mandatory while submitting new parts

Even though the researchers feeling the need for this information they are shying away from requesting it as a mandatory title for parts registry as it would be difficult for underfunded and inexperienced groups to perform these measurements.

We strongly suggest starting a forum on how to quantify the performance of promoters and genes to bring an easy to measure standard for the efficiency of the parts. Additionally iGEM should the responsibility and provide the measurements for the each promoter and gene included in the distributions. The second choice would be even better in terms of standardization as all the measurement will be performed by one center under similar conditions and with experienced researchers, which will allow user to compare and contrast the efficiencies of the parts more accurately.

82% of participants have thought that information on working conditions of the parts should be mandatory while submitting new parts. Most find submiting the detailed experimental information and working conditions is crucial and even easier than submitting measurements of POPS or RBS.

Definitions you would like to see at the Registry of Standard Parts

Transcriptional efficiency 13%
Protein lifetime 10%
Ribosome binding efficiency 10%
mRNA lifetime 9%
Translation initiation and efficiency 9%
Protein concentration 9%
Cooperative effects with other molecules 9%
Protein-DNA binding rates and efficiencies 8%
RNA polymerase affects 8%
System copy count 8%
Protein multimerization 6%

Additional titles includes: Catalytic rates and affinities for substrates, leakiness of promoter in lack of stimulus, POPS at various inducer/repressor concentrations.

Efficiency of the Database Entries

86% of participants would like to see a ranking/rating system for the parts by the other iGEM users which will be one indication of if a part is working and how well in different laboratories. Few had concerns about how well the rating system will work for rarely used parts while the widely used parts would even more popular due the the rating system. Still many believes this would be one futher towards a peer-reviewed quality control system for the parts.
61% of participants agreed that parts should be updated regularly by the designers, where most agreed at least when there is new information on the parts. It has also been suggested to give permission to all the users of that part for updating information.
73% of participants have been agree with us that excluding the low ranking parts or the parts with negative feedback from the future plates will increase efficiency of the system. The major concern about excluding any part is losing the variety of parts in the database. Few recommends excluding only the parts that are not working.

“Efficiency shouldn't be top priority in a database. First and foremost, data is the top priority. Excluding those parts would make the system more efficient”

“Some parts may be rare or new and have low efficiency, but can be very important! Getting rid of them would eliminate any chance of improvement to these parts, which not only a qualifier for an iGEM gold medal, but also one of the focuses of biobricks.”

We suggest excluding the parts not-working, low rated or with negative feedbacks from the annual distribution plates but still archive them and make their data available through the parts registry. So the while the individuals labs are receiving plates with higher rated, fully working parts for their projects, anyone who wants to work on a more exotic part can search through the achieves and re-vitalize the parts stored there. The challenge of re-vitalization of parts can be encouraged as an collaborative effort.

New Options for the Parts Registry Database

96% of participants are like minded with us that it will be useful to have a link out to the gene/protein information of the parts and - %97 of participants have been agree that they would like to know if a part is also involved in known biological pathways.

For receiving pathway information more participants have voted for NCBI Cog (59%) than KEGG pathways (38%) when the responses for both has been distributed among the choices according to response rates. Adding the blast option to the parts registry has also been suggested to locate parts of interest. We are sure all of us would like to see gene-protein and pathway information if these information was integrated into the database and offered automatically for each entry in the database.

We are planning to provide this information about the parts to all parts registry users as a build-in option in the next version of BioGuide in iGEM 2011.

New Parts Registry Form Suggested for The New Standards

Description

Warning Boxes:

If Out-dated, un-available and not-characterized parts exist in the Registry of Standard Parts, bring to an archive after the consent of the designer. Divide archive into three title: Out-dated, un-available and not-characterized parts
Besides shown as “works”, in the works box there should be explanation whether the part is characterized or non-characterized.
Parts should be updated regularly by the designers
Excluding the low ranking parts or the parts with negative feedback from the future plates

Characterization Boxes:

transcriptional efficiency
mRNA lifetime
ribosome binding efficiency
translation initiation and efficiency
protein lifetime
protein concentration
protein multimerization
protein-DNA binding rates and efficiencies
cooperative effects with other molecules
RNA polymerase effects
system copy count

Desription

Search box

with click options
options: searched parts are:
- Available
- Length OK
- Building
- Planning
- Missing
- Unavailable

according to the clicks of above options, search is modified

Description

Assume on the part image;

part DNA sequence is not confirmed, then tag with "non-confirmed DNA sequence"
non-characterized parts in the Parts Registry are not characterized further, then it will be tagged as "deprecated"

also:

comment box stated that any team can make comment about experiences with the part is opened
boxes which had been not filled with the data are highlighted;
- transcriptional efficiency
- mRNA lifetime
- ribosome binding efficiency
- translation initiation and efficiency
- protein lifetime
- protein concentration
- protein multimerization
- protein-DNA binding rates and efficiencies
- cooperative effects with other molecules
- RNA polymerase effects
- system copy count
if the part is not characterized but "works" then a "Qualitative part" tag is added
besides "works", "Characterized" or "non-characterized" box is added
ranking/rating stars for the parts voted by the other iGEM users which indicate how well the parts perform in different laboratories is added. For example 4.5 star voted by 27 teams (number of stars and number of votes)

Design

User Guide

For new users whom want to interest with synthetic biology and for experienced scientists, in our program you have two options for Input Output properties ;

To find input-output related biobrick parts or larger constructs! If you want to provide specific chemical or physical inputs from external environment, you may choose these inputs from the list. if you want other specific inputs which will be expressed from a coding sequence, the list can provide these specified protein names.

Wanted features of outputs can be selected by either from list or entering individually into text boxes.

Then click on the “Show Parts ” button.

Then the program will show you the parts have specified I/O properties

To see the properties of a part just click on it.

After clicking, you will see a highlighted pathway on the 2nd graph. Which are the subparts of the clicked part. Showing the sub graph in network.

Human Practices

iGEM’s parts registry is the only current database that holds information and DNA for over 3000 standard parts for the use of synthetic biology community. BioGUIDE is the first designed software that organizes the parts in iGEM spring 2010 distribution as possible atomics parts to build new biological device and systems for specific input and outputs based on graph theory. We are the first group who has applied a novel algorithm to search for input/output relations between the parts to reveal possible construct assemblies. This new approach will chance how the parts registry is used by the scientific community. And the availability of software implementing our algorithm with a very user friendly graphical user interface will allow all the users of the parts registry to explore new and novel constructs according to their parameter with ease. Additionally as the BioGUIDE software is an open source ware , any user can contribute to the development of the application. So, BioGUIDE will be improving with a collaborative effort, which will make it even more widely used among the synthetic biologists.

We also had many collabrations with the teams such as, INSA-Lyon, Lethbridge, WashU through our survey and WARSAW as we have participated in their survey. Also our sister team METU_TURKEY is our main collaborator. They have provided feedback BioGUIDE at different stages of the development. And they had the chance to analyze their constructs input/output relations throughout this collaboration.

ALL TEAMS: The Parts Registry Survey that has been developed by METU_TURKEY_SOFTWARE got response from 253 of participant from 94 teams. Analysis of the survey results we have received so far indicates that we were able outreach to the iGEM community and help them verbalize their concerns and suggestions for the parts registry standards and the maintenance of the database.

WARSAW: Our team members have participated in their survey abour iGEM participants profile.

METU_TURKEY: Beta testing of the algorithm developed and the BioGUIDE software has been performed by METU_TURKEY on few case studies. Additionally they have tested their construct for 2010 competition with our algorithm.

Material

Our main data source for BIO Guide Software Program was the available background information of parts distributed in 2010 iGEM plates (Total of three384-well plates of dried DNA) to the wetlab teams. This data was available through both the parts registry main website (http://partsregistry.org/Main_Page) in XML format and parts registry libraries (http://partsregistry.org/assembly/libraries.cgi?id=31) in Excel format. Data from parts with specific part IDs have been parsed with a custom code developed to modify SAX Parser. Then, the rest of the data which needs to be standardized according to biological importance have been extracted from the Registry of Parts Page manually. The chemical (IPTG, galactose etc.) or physical (UV irradiation, temperature etc) external inputs and proteins synthesized from a biobrick coding sequence can affect promoters on the parts. These effectors are identified under the title “Input”. And the “Output” s of these effectors are classified as inducers (a molecule that starts gene expression), repressors (blocker of attachment of RNA polymerase to promoter), activators (increasing the rate of transcription) and inhibitor s(decreasing the rate of transcription). These standardizations on the database helped us to build the algorithm based on input/output relationships. MySQL Server is used for Database development and organization. All of our illustrations for ER and algorithm is created in SmartDraw (trial version). Java Programming Language, and NetBeans Development environment is used or for software development. The graphical visualization of the software is done with Cyctoscape and yfiles libraries (trial version) are used for the presentation of graphical events. We have utilized css Javascripts for our webdesign. Autodesk Maya 2011 with Academic Licence, Adobe Creative Suite 5 Master Collection (Trial Version) have been used for animations and illustrations. Video tutorial for the BioGUIDE has been created by camstudio and trial versions of Flash and After Effects are also used for the videos.

Supporting Tools

SAX Parser ( modified )to parse XML files
Java ProramingLanguage, NetBeans Developement environment for software developement
MySQL Server for DataBase
cystoscape for graph visualization
yfiles library for graph events
SmartDraw for illutration of ER and Algorithm
maya & Cinema 4D for 3D animation, Adobe Master Collection and Microsoft Expression Studio for design
CSS, Java Script for web

Safety

Synthetic biology has the potential to impact many areas of society. Synthetic biologists may use artificial molecules to reproduce emergent behavior from natural biology, with the goal of creating artificial life or seeking interchangeable biological parts to assemble them into devices and systems that function in a manner not found in nature (Benner and Sismour 2005, Endy 2005, Heinemann and Panke 2006, Luisi 2007, Serrano 2007).There is possibility of causing intentional or accidental harm to humans, agriculture or the environment. While deliberate damage is dealt with under the heading biosecurity, the potential unintended consequences have to be considered under the term biosafety. As a software developer , we have to consider all possible maliciously use of synthetic biology tools. However, it is diffucult to understand for which purposesour tools will be used, bestway avoiding garage bioterrorism is all parts before adding to partsregistry must be checked , looked for toxic affect and any environmental or human harmness. After scanning possible candidate parts, a committe should decide whether novel part can be added parts registry or not.And we can only warn the user about our intention while building the application:

“BioGUIDE v1.0 software is FOR RESEARCH USE ONLY, no medical or diagnostic use for applications of the novel Biobrick constructs generated through our software has been described “

“No military (defense or combat) applications will be allowed in future”

Methods

Part Extraction Standards

All information about the parts that are essential in experimental setup of iGEM projects has been utilized. The information for the parts available provided with all three 384 well plates in Spring 2010 distribution have been standardized. Our standardization criteria have been discussed in detail under Database Standardization. ER diagram has been generated which simply describes the organization of the data. Around 70% of the parts information has been fetched by the custom parsing code from XML and Excel files provided by iGEM. Rest of the data had to be collected and organized manually as the organization of these data cannot be standardized to generate an algorithm. This step was one of the most time consuming steps in our project. For each construct and Biobrick the information collected was; Activity, Inducer, Activator, Repressor and Inhibitor for promoters and Inducer, Activator, Repressor and Inhibitor information valid for synthesized molecules (mostly proteins and RNA fragments etc.)

Combination

Rules (Image Combinations) In order to build our input/output relations graphs first we run our algorithm on the real combination dataset which contains all few thousand different possible combinations of the biobricks. But after performing all combinations for the first few hundred biobricks application’s rate slowed downed tremendously, which also become very time consuming for displaying biobricks graphs. To overcome this bottleneck we have developed a new strategy, where we have only used the construct combinations of the biobricks distributed within the plates. Moreover, according to information gathered from the subparts of the constructs distrubuted, we also collected the subpart assembly order, such as 1st: promoter, 2nd:rbs, 3rd:coding seq, any internal parts and the Last: terminator. Each specific Biobrick type has been assigned a number as a unique image ID from 1 to 19. Gathering the information on subparts was not a direct forward process. ImageID assembly orders for each construct has been used to extract the type information for each subpart with that construct. This innovative approach helped us to reveal 400 possible brick combinations present within the 3x384 well plates distributed by iGEM in Spring 2010.

Contact

For critics, suggestion, or appraisal, you can contact us on software_metuturkey@googlegroups.com

Future Plan

The application we have developed can be used by all iGEM members. As the iGEMs database expands and the recognition of the field of Synthetic Biology increases, data resources from other biological databases such as NCBI might be needed to be integrated to the application. In such a situation, extendibility of the application is vital. New data resources and new functions should be added easily.

Before planning ahead, feedback from other teams and iGEM headquarters about the BioGuide 1.0 will be collected. That will help us to fill in the missing features of the application and check the theories which are basis of our algorithms.

As our application is not geared towards any commercial use and will stay as an academic application, keeping track of the weekly developmental process on the wiki notebook environment was satisfactory. If the need for a commercial application emerges, we should be utilizing professional software development approaches to determine the exact requirements and to facilitate the use of a common language between interdiciplinary members in the team.

For constructing BioGuide 2.0 we have some plans.

Short Term plan:

Next year we are planning to generate BioGuide 2.0 by using all parts data but inorder to do this we will update our part database but easyway is standardization and reorganizing all parts in partsregistrty.org according to our suggestion because re-organizing and normalization are crucial. We are planning to add new tools to improve graphs.Our ultimate aim is finding best pathway based on automated construction and input-output relation. BioGuide 2.0 will be more faster because we are planning to use OODBMS and all all platform will support BioGuide 2.0.

Long term plan:

We want to improve our algoritm and add more parameter to make graphs more effective. Our dream is embeding our software into partsregistry.org so no mere iGEMers will choose parts in real time by using our software.

Suggestions based on PartsRegistry Survey Results

First suggesiton is offering fartnership with Google for easy search and founding a committe to enforce a standardized nomenclature for terminology and parts registry entries.

We strongly suggest starting a forum on how to quantify the performance of promoters and genes to bring an easy to measure standard for the efficiency of the parts. Additionally iGEM should assume the responsibility and provide the measurements for the each promoter and gene included in the distributions. The second choice would beeven better in terms of standardization as all the measurement will be performed by one center under similar conditions and with experienced researchers, which will allow user to compare and contrast the efficiencies of the parts more accurately. We suggest excluding the parts not-working, low rated or with negative feedbacks from the annual distribution plates but still archive them and make their data available through the parts registry. So the while the individuals labs are receiving plates with higher rated, fully working parts for their projects, anyone who wants to work on a more exotic part can search through the achieves and re-vitalize the parts stored there. The challenge of re-vitalization of parts can be encouraged as an collaborative effort. We are sure, all of us would like to see gene-protein and pathway information if these information was integrated into the database and offered automatically for each entry in the database. We are planning to provide this information about the parts to all parts registry users as a build-in option in the next version of BioGuide in iGEM 2011.

Database Standardization

Two main focuses of our project was the organization of the available information about Biobricks on iGEM’s website and development of a software application to help synthetic biologists at the experimental set-up level by providing all available construct combinations for any given input and output relations ,which they can utilize for their own project.

Normalization and re-organization of the part information at iGEM’s web site was needed in order to develop our application, which will automatically search the possible construct combinations. For the organization and analysis of the Biobricks, we used part info for Spring 2010 distribution. The information on all three 384 well plates distributed by iGEM scrutinized and checked individually to specify the standards available and needed. iGEM is providing so many parts within a hierarchical way, but there is no order in the information flow and no common standards. Furthermore, the information bulk is being used in an ineffective manner. Some of the parts distributed are known to be nonfunctional. Web pages for parts contain lots of information, but majority of them, are again not ordered. Moreover, some additional information had to be removed or replaced in such a way that the information for parts can be used effectively. And removal of the redundant bulk information related with parts at iGEM’s web site had been recommended for future.

Although, the final standardization, which we have suggested is not for general public use and it was urgently needed in order to satisfy the needs of our algorithm. But, still it will be a valuable resource, since it summarizes the basic information about the parts.

As the first step to build the proposed standardization template, the headings selected related to parts are listed on Table 1. Submission of part IDs for individual parts is an accepted and quite valuable way of tracking information. Although, every part has unique partID, for every part there is a need to assign unique part names as official iGEM names. Part names will have an important role as they will be providing the short description about the part, which synthetic biologists can immediately recognize and utilize during the construction of unique Biobricks. Additionally unique part names will be helpful to identify the devices with more than one Biobrick in their constructs. Assignment of unique and distinct names for parts describing their nature and content will be helpful to researchers for the recognition of and search for the parts.

Headings Selected From Previous Entry Forms for Indication of Standardized Information

=========================================

PartID:

PartName:

Bricks:

BrickIDs:

ImageIDs:

RFC10:

RFC21:

RFC23:

RFC25:

=========================================

Table 1: The table above basically describes and designates qualities of parts which identifies their compositions and demonstrates the status of previously assigned standards. PartID refers to the unique ID number for parts including atomic parts and assemblies. PartName refers to the given unique names to parts. Bricks, refers to the shortcut names which specifies atomic parts. ImageIDs, refers to individual or combination of numbers that are assigned by us. RFCs refers to the states of parts based on RFC standards.

iGEM both provides individual, atomic parts and pre-combined constructs such as devices and systems. Availability of combined constructs is important to the researchers as combining individual bio-bricks one at a time will be very time consuming. These previously merged constructs, serve as the repository for puzzle and they can be used for different purposes. Up to date the largest and most trustworthy source, for synthetic biology and its components, is iGEM’s parts registry. In 2010, iGEM provided over 1000 parts that have initiated many projects. Having more atomic parts available in the iGEM’s repository, will lead to the design of more complex and robust constructs, and we would have a better chance to design different constructs for unique purposes. Also, for the parts that are already available, extra steps needs to be taken for the quality control and surveillance of these products. The quality control of the information for the parts is essential for the future of iGEM and synthetic biology. Even though we have found pre-determined RFC standards useful and included those to our standardized template, some individual parts still requires re-organization of the information as RFC standards alone for the functionality of parts, does not satisfy the needs for wet lab biologists.

Without a question there is an urgent need to build a distinct and specific database well organized with its own standards for synthetic biology; however, development of such a database is not an easy task.

Contact Information of Part Owners and Qualitative Group Comments about Parts

=========================================

Designers: Mail:

GroupFavorite:

StarRating:

Parameters:

=========================================

Table 2: The above table simply depicts information about possessors of parts and their contact information and the popularity of the parts for groups. Parameters heading, refers distinctive experimental details unique to the usage of parts which should be decided by groups.

Second step for building the standardized template was to get the phylogenic information about the parts development process which includes the name of the group, designer and contact information, along with the comments from the group on the parts they have submitted. Contact information is especially important for iGEM as other groups who need extra information about the available part can reach to the required information. Even though contacting with the designers of the individual parts which are available is highly encouraged by iGEM, unavailability of contact information points at out the fact that iGEM’s parts registry needs strong re-organization in order to serve to the synthetic biology community properly.

Additionally, the “group favorite” and “starRating” fields are also important for individual evaluation of the parts, which doesn’t get the deserved attention from the iGEM groups. “Group Favorite” defines the confidence on the part by the designer group. “StarRating” defines the related part in terms of popularity and usage efficiency among the groups. According to our observations, most groups are not aware of either of the fields or they are used incorrectly or ineffectively. For example for a part with a full reporter which is known to be functional and gives precise and expected results the StarRating should be at least 2 stars, but for most of the parts in 2010 distribution, it is very difficult to observe a part whose “StarRating” is above one. For quick determination of functionality of the parts these two evaluations are important so they have been included in the proposed standardization template. But, as they were not properly used up to now for the re-organization of the parts information during the development of our software application we had to include all parts to our queries regardless of their evaluations based on “Group Favorites” and “ StarRatings”

Second step for building the standardized template was to get the phylogenic information about the parts development process which includes the name of the group, designer and contact information, along with the comments from the group on the parts they have submitted. Contact information is especially important for iGEM as other groups who need extra information about the available part can reach to the required information. Even though contacting with the designers of the individual parts which are available is highly encouraged by iGEM, unavailability of contact information points at out the fact that iGEM’s parts registry needs strong re-organization in order to serve to the synthetic biology community properly.

Additionally, the “group favorite” and “starRating” fields are also important for individual evaluation of the parts, which doesn’t get the deserved attention from the iGEM groups. “Group Favorite” defines the confidence on the part by the designer group. “StarRating” defines the related part in terms of popularity and usage efficiency among the groups. According to our observations, most groups are not aware of either of the fields or they are used incorrectly or ineffectively. For example for a part with a full reporter which is known to be functional and gives precise and expected results the StarRating should be at least 2 stars, but for most of the parts in 2010 distribution, it is very difficult to observe a part whose “StarRating” is above one. For quick determination of functionality of the parts these two evaluations are important so they have been included in the proposed standardization template. But, as they were not properly used up to now for the re-organization of the parts information during the development of our software application we had to include all parts to our queries regardless of their evaluations based on “Group Favorites” and “ StarRatings”

Input and Output Characteristics of Parts

=========================================

Parameters:

-Input:

• Promoter:

• Activity:

• Inducer:

• Activator:

• Repressor:

• Inhibitor:

• Promoter2:

• Activity:

• Inducer:

• Activator:

• Repressor:

• Inhibitor:

-Output:

• Reporter:

• Reporter2:

• Regulator:

• Inducer:

• Activator:

• Repressor:

• Inhibitor:

• Regulator2:

• Inducer:

• Activator:

• Repressor:

• Inhibitor:

-Working Condition:

=========================================

Table 3: The table above elaborately describes the input relations based on promoters and the output products based on the functional genes and RNAs which are included within the parts. Working condition simply describes any influencing factor or circumstance which is directly related with the functional properties of parts.

Third part of our standardization template includes parameters of contingent input and output elements. These parameters are classified into two groups for simplicity as presented on Table 3. This final part of the standardization template includes the upmost important information about the Biobricks that are required for the BioGuide Software to run its searching algorithm.

Briefly, BioGuide application is designed to catch the input and output relations of individual parts to examine possible Biobricks pathways for specific input and output queries. In other words, at pre-experimental stage, it helps wet lab biologists to design their unique constructs by revealing possible alternative options for pre-determined purposes, along with the primary paths. Our ultimate goal is to improve the algorithm designed for iGEM 2010 and present a new version of the BioGuide in iGEM 2011, which will provide optimum design of constructs for predetermined parameters.

Most of the parts are composed of functional and nonfunctional constructs which are formed by atomic parts. And every part should carry the information for all of its atomic parts within itself. The “input” heading actually stands for promoters. Parts with one or more promoters can be found at iGEM’s Parts Registry. Along with the information on which and how many promoters a part might have, the activity level of promoters are also important to distinguish between a constitutively active promoter or a promoter activated by specific physiological processes or states etc. This information was crucial for us to dissect in order to run our algorithm as it directly affects which inputs can activate the devices or the systems.

Throughout our investigations on the Parts Registry, we found out that much of the terminology was being used ambiguously. Although this might not be vital for synthetic biologists, it is still endeavoring to understand the function of certain regulatory elements which also becomes a time consuming task for the researcher. Thus, we recommend that the explanations of certain regulatory elements should be redefined and fixed especially for synthetic biology for easy communication, sharing and searching of information.

Common misuses of the terminology can guide us to figure out how to construct a standard nomenclature for synthetic biology. We claim that a standard nomenclature is urgently needed for synthetic biology for the following reasons. First of all, synthetic biology is an emerging research discipline and an industrial application area which is highly promising. Secondly, redefinition of the terminology to build a standard nomenclature is needed as some of the terms are prone to be used instead of another causing problems related to misuse for the global communication about synthetic biology. Lastly, the nomenclature has major importance for the construction of a persistent and trustworthy database for synthetic biology which serves for the information exhibition and exchange globally. For instance, there are obvious misunderstandings about the words which are predominantly used for regulation process. We have noticed that, the terms “inhibitor” and “repressor” are being used as equivocally in the part information pages. Like the lactose inhibitor protein, a widely used DNA-binding transcriptional repressor, that have been labeled both as “inhibitor” and “repressor” at iGEM’s Parts Registry. Similar problems resulting from ambiguous use of terminology also observed with regulatory elements. To sum up, we investigated all input elements for promoters and classify these elements in terms of their function, affect and required input element for them. So, we suggest that terminology used for regulation of transcription should be defined clearly on iGEM’s website and correct use of terminology should be enforced.

The second group of parameters was collected under the title “Output”, which refers to products of functional genes. In contradiction, the term “reporter” has also been described within the same list. Reporters are also genes whose products, can be used for screening as an output. According to our group, the usage of the term “reporter” for genes is unnecessary and cause extra complexity for information distribution and gives rise to discrepancies. Instead of using the term “reporter”, predefined “gene” description should be used for genes, which can function as reporters. The special information which is related with the characteristic of that gene should also be presented on part info web page.

Furthermore, the same terminology “reporter” was used for both atomic parts and composite bio-bricks. Also the overall image descriptions for these were defined as “reporters”. We want to point out that using same nomenclature for both atomic genes and for whole functional constructs contributes to the complexity and makes specific explorations difficult through the Parts Registry. So, assigning “reporter” for both atomic parts and for whole constructs is not a good practice. Instead, we are suggesting the usage of other available terminology for the parts listed as reporters, which most of the constructs, now known as reporters, can be grouped into, such as “protein generators”, “composite parts” or “inverters”.

Devices are whole constructs which are functional and have specific and distinct functions. But, as we have observed, unfortunately, the term “device” is also being used for parts which are not functional and do not have specific functional at all. Moreover, within the classification of devices, we argue that some terms are also being used unnecessarily and ambiguously. Devices are classified into five types which are protein generators, reporters, inverters, receivers and senders, measurement devices. For example iGEM defines protein generators as:

Protein generator = promoter + rbs +gene + terminator

Though we accept the definition for protein generators, we observed that there exist numerous parts which are defined as protein generators but actually most of them do not fit to the definition provided above. Although some parts are not functional and do not generate proteins at all, they are classified as protein generators, which makes searching for the parts difficult in the registry. Furthermore, there are also numerous parts which are defined as “composite parts” but actually they fit to the same definition with protein generators. In order to overcome the problem of misuse of device type we have extracted related image ID information for the composite parts. Image ID information helped us to correctly categorize composite parts depending on its individual atomic parts and identify the ones with more than one function, such as being both inhibitor and activator. In other words, we used image and part IDs in order to merge an input for its outputs.

Subtitle working conditions, includes all the detailed information about the experimental properties of parts, and the details about the working process of individual parts and complete devices. Additionally, we marked the subtitle “Working Condition” in our standardization template as potentially the most important title that helps synthetic biologist to better understand the parts functions at iGEM’s part registry database. The main problem we have encounter with the subtitle “working condition” is within most of the parts the details about working process is not enough and not provided regularly.

Examples of Misuse of Terminology:

For Composite Parts:

PartID: BBa_S04055

PartName: Synthetic lacYZ operon

This part is functional and responsible for the production of LacY and LacZ proteins. This part partially fits the definition for “composite part” but actually should be a protein generator as it fits fully to the definition of “protein generators”.

For Protein Generators:

PartID: BBa_J45299

PartName: PchA & PchB enzyme generator

The part which is illustrated above actually fits the definition for “composite part” but in part registry it is classified as protein generator. This part can be functional but it needs a promoter. Even though this part is not functional and is not capable of producing protein, part registry assigns this product as protein generator. We suggest that all parts in the registry, which are composed of more than one atomic part and which are not functional on their own but can be functional, should be classified as “composite parts”.

For Reporters:

PartID: BBa_J04451

PartName: RFP Coding Device with an LVA tag

This functional part is classified as “Reporter” in the parts registry database. It is very clear that this part fits the same description as Protein Generator in Biobrick part registry standards. Although, this part has specific and known functional role, characterizing this part as a reporter is unnecessary and contributes to the level of complexity of information provided. Instead, we suggest that this part should be classified as “protein generator” and related detailed information about the specific function of this part, should be provided in the part information page.

In conclusion, as mentioned above we tried to reorganize and normalize the information about parts which is provided in part registry for 2010 in order to develop our algorithm for the BioGuide application. During this process, we encountered some inconsistencies and misuses of the terminology being used and also inadequacies about the information provided about parts. First of all, we claim that a standard nomenclature should be constituted for future use in the field of synthetic biology. Based on the information gathered according to new nomenclature a professional database should be constructed to address the needs of synthetic biology. This will enable easy information exchange and exhibition globally. Secondly, although there are enough information about parts exists on parts registry database, the information which is provided for parts need to be ordered urgently. Furthermore, there should be new experimental standards which must be introduced to groups in the part submission process for the subtitle “working condition”. These experimental standards will be important because the experimental details about parts are not satisfying the needs of wet-lab biologists for the design and the construction of new Biobricks.

Algorithm

In this section, the step by step functioning of our application, along with the encapsulation of the algorithmic concepts of ‘standardization’ of functional iGEM devices are depicted in pictorial forms called flowcharts. Rectangular boxes represent the encapsulation of implementations of the computer programs to perform the particular tasks stated in that box on the flowcharts. These boxes are sometimes called subprograms, objects or packages in Object Oriented software Engineering context. The diamonds represent decision branching and they are found between two rectangular boxes. The arrows show the direction in which subprograms work and communicate. The subprogram at the head of the arrow starts executing after the termination of the subprogram at the tail of the arrow. Following flowcharts are the high level representations of our algorithms developed for the BioGuide software.

1

Diagram 1. Flowchart of collection, formatting and storage of devices data algorithm

Information about the iGEM parts had to be collected in a standardized format for our application to function properly. Following data collection custom subprograms is needed to parse and forward the data the application’s database. In order to achieve this we have designed and implemented the algorithm shown in diagram 1. In this algorithm, the first stage was to find the list of part IDs of devices which were supplied by iGEM in Spring 2010 distribution. This information has been collected from two sources 1) plate files in excel format which was available online 2) device data provided in xml format, both provided by iGEM. The last step in the algorithm was to send the collected partID data to the application’s database.

2.

Diagram 2. Flowchart for BioGuide execution before and during user interaction

Diagram 2 presents the main algorithm, which shows how BioGuide application works. In BioGuide the major components are device and Biobrick graphs. While the device graph represents input-output (promoter-regulator) compatibility combination of iGEM devices, the Biobrick graph represents combinations of atomic parts assembled in a device or system. The flowchart shows how these graphs are created and embedded into the program, which displays both of the graphs to the user when launched. Application presents few interactive options to the user when started, which were shown on the flowchart under the horizontal, bolded line. As shown on the diagram 2, there are four interactive tasks BioGuide can do, where the device and Biobricks graphs are utilized. Upon clicking a node on a devices or Biobricks graph, that node changes in size and color and the various functions shown on the flowchart can be performed then after.

Graph Modeling

Graphical Modeling for Bio-Guide

Introduction

Graphical Modeling Theory has been applied to construct four different graphs where relations of atomic parts, devices and systems and the functional combinations that can build new constructs are presented for the iGEMs parts registry database. Three graphs are composed of iGEM devices and one graph is based on Biobricks. Each graph comprises a set of vertices or nodes and a set of edges. In the set of nodes each node represents a device, while in the set of edges each edge represents the input-output combination of the nodes. These graphs are directed graphs as the edges are created according to input-output combination. All compatibilities between a regulator and a promoter of an edge is created, where the source of this edge is the device with the corresponding regulator and target of the edge is the device with the promoter in concern.

Fig. 1: A node representing a device

Fig. 2: Arrow representing an edge between two nodes

The atomic structures used in our graphical model have been represented in Figures 1 and 2. A node is represented with a solid circle where the label, the part/device ID according to iGEM standards, of the device is marked on the foreground. The blue arrows between nodes connect the related devices, representing the input-output connectivity. End style of the arrow helps us to determine the direction of the node, like in Figure 2 where the node labeled BBa_S03520 is the source and BBa_JO9250 is the target.

Directivity

All the four constructed graphs build for BioGuide are directed graphs. So that, for every edge there must be a single source and a target. There is no single edge which is bidirectional. In mathematical form this can be represented as:

If an edge e has node v as source and node w as target then the edge can be expressed as

For a directed graph the combination (v, w) is totally different from (w, v). Therefore,

The direction of the edges has been represented with the arrows, as explained in Figure 2.

Connectivity

The nodes forming their own sub-graphs disconnected from the rest of the nodes have been recognized, which showed us the presence of incompatibility between few regulators and promoters of the devices. We have observed this disconnection in all four of our graphs. The basis of the disconnection has been shown in Figure 3, where the two sub-graphs without any edge that connects them to the main graph has been presented on the right hand side of the diagram. These features classify our graphs as disconnected graphs [1].

Fig. 3: A zoomed in screenshot showing two sub-graphs within the disconnected graph.

"Semi-Simplicity"

A simple graph is a graph in which no more than one edge contains the same set of nodes. So, in a simple graph it is not possible to find more than one edge with the same source and the same target. Additionally, an edge with the same source and target, forming a loop is not allowed. But, in synthetic biology it is possible to construct a device consisting of devices or bio bricks of the same species or type. Accordingly, our graphs are simple graphs with an exception of possible self-containing loops, where the edge starts from and ends on the same node. Our graphs have an exception of having loops and due to this permitted flexibility our graphs are "semi-simple".

For general information about graphs refer to:

[1] http://en.wikipedia.org/wiki/Graph_(mathematics)

Results

In order to develop BioGuide algorithm, there was a need to reorganize and normalize parts information database in partsregistry.org. Information of the parts was processed and developed from partsregistry.org which includes the PartID, PartName, RFC values, etc , designer and contact information and parameters to build a standardized template for our algorithm to run smoothly.
Database standardization is done by analyzing iGEM Spring 2010 distribution and collecting information needed for the standardized parts. Also new parameters are assigned according to parts input-output model like : Inducer, Activator, Repressor, Inhibitor
For each promoter we have assigned their inducers or repressors as input and for protein generator parts we have assigned generated proteins as output which maybe activator or repressor of other devices.
iGEM devices are depicted in pictorial forms called flowcharts, encapsulation of implementations , decision branching and direction are milestones of our algorithm. Following flowcharts are the high level representations of our algorithms developed for the BioGuide software.
We run our algorithm on the real combination dataset in order to build our input/output relations graphs. We also collected the subpart assembly order, such as 1st: promoter, 2nd:rbs, 3rd:coding seq, any internal parts and the Last: terminator. Each specific Biobrick type has been assigned a number as a unique image ID from 1 to 19.
ImageID assembly orders for each construct have been used to extract the type information for each subpart with that construct. This innovative approach helped us to reveal 400 possible brick combinations present within the 3x384 well plates distributed by iGEM in Spring 2010
Four different graphs were constructed based on graphical modeling theory where relations of atomic parts, devices and systems and the functional combinations that can build new constructs are presented for the iGEMs parts registry database. Three graphs are composed of iGEM devices and one graph is based on Biobricks.
Each graph comprises a set of vertices or nodes and a set of edges. In the set of nodes each node represents a device, while in the set of edges each edge represents the input-output combination of the nodes.
We arrange a survey to analyze user needs and response, According to our survey results, 244 participants are completed our survey between 10 to 22.10.2010, 57% of the participant had scientific degrees from B.Sc to Professor and 18% had graduate degrees. 18% of participants are enrolled in their teams as either Instructors or Advisors.INSA-Lyon, Lethbridge, WashU are dedicated as collaborators with more than 60% team participation. You can learn more on survey results on our collaboration page

Attribution and Contributions

The BioGUIDE software is a proud product of METU_TURKEY_SOFTWARE group where the students have presented the problem and come up with the solution with minor advising. This project was not a part of an ongoing project in any of the advisors.

The biologist of the team have done the preliminary database standardization by analyzing and collected data from the iGEM Spring 2010 distribution. All the algorithms have been developed by the soon-to-be computer scientist in the group. The Parts registry survey and standardization of the database information on parts have been developed through a colloborotative effort within the group.

Additionally all the logo, illustrations, animations, video and other visual media and web design has been created by the design team in the group.

Development Plans and Project Management

The application we are developing can be used by all iGEM members and it’s data is increasing very fast as the iGEM becomes a bigger organization. Moreover, other data resources like NCBI can be imported to this application, hence the user group of application is gets bigger and bigger. In such a situation, extendibility of the application is vital. New data resources and new functions should be added easily.

Before starting to think about those, first we have to ask to other teams and iGEM headquarters about the BioGuide 1.0 to see the missing points in our idea, and to check our theories. Until developing this idea we were not using professional software approaches. We were planning our weekly tasks and doing those as in the notebook.

After finding a novel software project we have to change our approach. We have to use professional software development approaches to develop such an application to be able to state the requirements exactly and to use a common language between software oriented and biology oriented members in the team.

As we mentioned above, our software can be extended, and new data resources can be imported. The requirements are changing and the problem can be understood better in time. Extreme Programming Approach is developed for such software projects. That is the approach we are going to use in BioGuide2.0

@@ Line 1: / Line 1: @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
-	"http://www.w3.org/TR/html4/strict.dtd">
 <html lang="en">
 <head>
-<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
+<link href="https://2010.igem.org/Team:METU_Turkey_Software/slidercss?action=raw&amp;ctype=text/css" media="screen" rel="stylesheet" type="text/css" />
-<title>METU Turkey Software</title>
+<link href="https://2010.igem.org/Team:METU_Turkey_Software/menucss?action=raw&amp;ctype=text/css" media="screen" rel="stylesheet" type="text/css" />
+<script src="https://2010.igem.org/Team:Groningen/files/slider.js?action=raw&amp;ctype=text/javascript" type="text/javascript"></script>
+<script src="https://2010.igem.org/Team:METU_Turkey_Software/scrollto?action=raw&amp;ctype=text/javascript" type="text/javascript"></script>
 <script type="text/javascript">
-(function(){var l=this,g,y=l.jQuery,p=l.$,o=l.jQuery=l.$=function(E,F){return new o.fn.init(E,F)},D=/^[^<]*(<(.|\s)+>)[^>]*$|^#([\w-]+)$/,f=/^.[^:#\[\.,]*$/;o.fn=o.prototype={init:function(E,H){E=E||document;if(E.nodeType){this[0]=E;this.length=1;this.context=E;return this}if(typeof E==="string"){var G=D.exec(E);if(G&&(G[1]||!H)){if(G[1]){E=o.clean([G[1]],H)}else{var I=document.getElementById(G[3]);if(I&&I.id!=G[3]){return o().find(E)}var F=o(I||[]);F.context=document;F.selector=E;return F}}else{return o(H).find(E)}}else{if(o.isFunction(E)){return o(document).ready(E)}}if(E.selector&&E.context){this.selector=E.selector;this.context=E.context}return this.setArray(o.makeArray(E))},selector:"",jquery:"1.3.1",size:function(){return this.length},get:function(E){return E===g?o.makeArray(this):this[E]},pushStack:function(F,H,E){var G=o(F);G.prevObject=this;G.context=this.context;if(H==="find"){G.selector=this.selector+(this.selector?" ":"")+E}else{if(H){G.selector=this.selector+"."+H+"("+E+")"}}return G},setArray:function(E){this.length=0;Array.prototype.push.apply(this,E);return this},each:function(F,E){return o.each(this,F,E)},index:function(E){return o.inArray(E&&E.jquery?E[0]:E,this)},attr:function(F,H,G){var E=F;if(typeof F==="string"){if(H===g){return this[0]&&o[G||"attr"](this[0],F)}else{E={};E[F]=H}}return this.each(function(I){for(F in E){o.attr(G?this.style:this,F,o.prop(this,E[F],G,I,F))}})},css:function(E,F){if((E=="width"||E=="height")&&parseFloat(F)<0){F=g}return this.attr(E,F,"curCSS")},text:function(F){if(typeof F!=="object"&&F!=null){return this.empty().append((this[0]&&this[0].ownerDocument||document).createTextNode(F))}var E="";o.each(F||this,function(){o.each(this.childNodes,function(){if(this.nodeType!=8){E+=this.nodeType!=1?this.nodeValue:o.fn.text([this])}})});return E},wrapAll:function(E){if(this[0]){var F=o(E,this[0].ownerDocument).clone();if(this[0].parentNode){F.insertBefore(this[0])}F.map(function(){var G=this;while(G.firstChild){G=G.firstChild}return G}).append(this)}return this},wrapInner:function(E){return this.each(function(){o(this).contents().wrapAll(E)})},wrap:function(E){return this.each(function(){o(this).wrapAll(E)})},append:function(){return this.domManip(arguments,true,function(E){if(this.nodeType==1){this.appendChild(E)}})},prepend:function(){return this.domManip(arguments,true,function(E){if(this.nodeType==1){this.insertBefore(E,this.firstChild)}})},before:function(){return this.domManip(arguments,false,function(E){this.parentNode.insertBefore(E,this)})},after:function(){return this.domManip(arguments,false,function(E){this.parentNode.insertBefore(E,this.nextSibling)})},end:function(){return this.prevObject||o([])},push:[].push,find:function(E){if(this.length===1&&!/,/.test(E)){var G=this.pushStack([],"find",E);G.length=0;o.find(E,this[0],G);return G}else{var F=o.map(this,function(H){return o.find(E,H)});return this.pushStack(/[^+>] [^+>]/.test(E)?o.unique(F):F,"find",E)}},clone:function(F){var E=this.map(function(){if(!o.support.noCloneEvent&&!o.isXMLDoc(this)){var I=this.cloneNode(true),H=document.createElement("div");H.appendChild(I);return o.clean([H.innerHTML])[0]}else{return this.cloneNode(true)}});var G=E.find("*").andSelf().each(function(){if(this[h]!==g){this[h]=null}});if(F===true){this.find("*").andSelf().each(function(I){if(this.nodeType==3){return}var H=o.data(this,"events");for(var K in H){for(var J in H[K]){o.event.add(G[I],K,H[K][J],H[K][J].data)}}})}return E},filter:function(E){return this.pushStack(o.isFunction(E)&&o.grep(this,function(G,F){return E.call(G,F)})||o.multiFilter(E,o.grep(this,function(F){return F.nodeType===1})),"filter",E)},closest:function(E){var F=o.expr.match.POS.test(E)?o(E):null;return this.map(function(){var G=this;while(G&&G.ownerDocument){if(F?F.index(G)>-1:o(G).is(E)){return G}G=G.parentNode}})},not:function(E){if(typeof E==="string"){if(f.test(E)){return this.pushStack(o.multiFilter(E,this,true),"not",E)}else{E=o.multiFilter(E,this)}}var F=E.length&&E[E.length-1]!==g&&!E.nodeType;return this.filter(function(){return F?o.inArray(this,E)<0:this!=E})},add:function(E){return this.pushStack(o.unique(o.merge(this.get(),typeof E==="string"?o(E):o.makeArray(E))))},is:function(E){return !!E&&o.multiFilter(E,this).length>0},hasClass:function(E){return !!E&&this.is("."+E)},val:function(K){if(K===g){var E=this[0];if(E){if(o.nodeName(E,"option")){return(E.attributes.value||{}).specified?E.value:E.text}if(o.nodeName(E,"select")){var I=E.selectedIndex,L=[],M=E.options,H=E.type=="select-one";if(I<0){return null}for(var F=H?I:0,J=H?I+1:M.length;F<J;F++){var G=M[F];if(G.selected){K=o(G).val();if(H){return K}L.push(K)}}return L}return(E.value||"").replace(/\r/g,"")}return g}if(typeof K==="number"){K+=""}return this.each(function(){if(this.nodeType!=1){return}if(o.isArray(K)&&/radio|checkbox/.test(this.type)){this.checked=(o.inArray(this.value,K)>=0||o.inArray(this.name,K)>=0)}else{if(o.nodeName(this,"select")){var N=o.makeArray(K);o("option",this).each(function(){this.selected=(o.inArray(this.value,N)>=0||o.inArray(this.text,N)>=0)});if(!N.length){this.selectedIndex=-1}}else{this.value=K}}})},html:function(E){return E===g?(this[0]?this[0].innerHTML:null):this.empty().append(E)},replaceWith:function(E){return this.after(E).remove()},eq:function(E){return this.slice(E,+E+1)},slice:function(){return this.pushStack(Array.prototype.slice.apply(this,arguments),"slice",Array.prototype.slice.call(arguments).join(","))},map:function(E){return this.pushStack(o.map(this,function(G,F){return E.call(G,F,G)}))},andSelf:function(){return this.add(this.prevObject)},domManip:function(K,N,M){if(this[0]){var J=(this[0].ownerDocument||this[0]).createDocumentFragment(),G=o.clean(K,(this[0].ownerDocument||this[0]),J),I=J.firstChild,E=this.length>1?J.cloneNode(true):J;if(I){for(var H=0,F=this.length;H<F;H++){M.call(L(this[H],I),H>0?E.cloneNode(true):J)}}if(G){o.each(G,z)}}return this;function L(O,P){return N&&o.nodeName(O,"table")&&o.nodeName(P,"tr")?(O.getElementsByTagName("tbody")[0]||O.appendChild(O.ownerDocument.createElement("tbody"))):O}}};o.fn.init.prototype=o.fn;function z(E,F){if(F.src){o.ajax({url:F.src,async:false,dataType:"script"})}else{o.globalEval(F.text||F.textContent||F.innerHTML||"")}if(F.parentNode){F.parentNode.removeChild(F)}}function e(){return +new Date}o.extend=o.fn.extend=function(){var J=arguments[0]||{},H=1,I=arguments.length,E=false,G;if(typeof J==="boolean"){E=J;J=arguments[1]||{};H=2}if(typeof J!=="object"&&!o.isFunction(J)){J={}}if(I==H){J=this;--H}for(;H<I;H++){if((G=arguments[H])!=null){for(var F in G){var K=J[F],L=G[F];if(J===L){continue}if(E&&L&&typeof L==="object"&&!L.nodeType){J[F]=o.extend(E,K||(L.length!=null?[]:{}),L)}else{if(L!==g){J[F]=L}}}}}return J};var b=/z-?index|font-?weight|opacity|zoom|line-?height/i,q=document.defaultView||{},s=Object.prototype.toString;o.extend({noConflict:function(E){l.$=p;if(E){l.jQuery=y}return o},isFunction:function(E){return s.call(E)==="[object Function]"},isArray:function(E){return s.call(E)==="[object Array]"},isXMLDoc:function(E){return E.nodeType===9&&E.documentElement.nodeName!=="HTML"||!!E.ownerDocument&&o.isXMLDoc(E.ownerDocument)},globalEval:function(G){G=o.trim(G);if(G){var F=document.getElementsByTagName("head")[0]||document.documentElement,E=document.createElement("script");E.type="text/javascript";if(o.support.scriptEval){E.appendChild(document.createTextNode(G))}else{E.text=G}F.insertBefore(E,F.firstChild);F.removeChild(E)}},nodeName:function(F,E){return F.nodeName&&F.nodeName.toUpperCase()==E.toUpperCase()},each:function(G,K,F){var E,H=0,I=G.length;if(F){if(I===g){for(E in G){if(K.apply(G[E],F)===false){break}}}else{for(;H<I;){if(K.apply(G[H++],F)===false){break}}}}else{if(I===g){for(E in G){if(K.call(G[E],E,G[E])===false){break}}}else{for(var J=G[0];H<I&&K.call(J,H,J)!==false;J=G[++H]){}}}return G},prop:function(H,I,G,F,E){if(o.isFunction(I)){I=I.call(H,F)}return typeof I==="number"&&G=="curCSS"&&!b.test(E)?I+"px":I},className:{add:function(E,F){o.each((F||"").split(/\s+/),function(G,H){if(E.nodeType==1&&!o.className.has(E.className,H)){E.className+=(E.className?" ":"")+H}})},remove:function(E,F){if(E.nodeType==1){E.className=F!==g?o.grep(E.className.split(/\s+/),function(G){return !o.className.has(F,G)}).join(" "):""}},has:function(F,E){return F&&o.inArray(E,(F.className||F).toString().split(/\s+/))>-1}},swap:function(H,G,I){var E={};for(var F in G){E[F]=H.style[F];H.style[F]=G[F]}I.call(H);for(var F in G){H.style[F]=E[F]}},css:function(G,E,I){if(E=="width"||E=="height"){var K,F={position:"absolute",visibility:"hidden",display:"block"},J=E=="width"?["Left","Right"]:["Top","Bottom"];function H(){K=E=="width"?G.offsetWidth:G.offsetHeight;var M=0,L=0;o.each(J,function(){M+=parseFloat(o.curCSS(G,"padding"+this,true))||0;L+=parseFloat(o.curCSS(G,"border"+this+"Width",true))||0});K-=Math.round(M+L)}if(o(G).is(":visible")){H()}else{o.swap(G,F,H)}return Math.max(0,K)}return o.curCSS(G,E,I)},curCSS:function(I,F,G){var L,E=I.style;if(F=="opacity"&&!o.support.opacity){L=o.attr(E,"opacity");return L==""?"1":L}if(F.match(/float/i)){F=w}if(!G&&E&&E[F]){L=E[F]}else{if(q.getComputedStyle){if(F.match(/float/i)){F="float"}F=F.replace(/([A-Z])/g,"-$1").toLowerCase();var M=q.getComputedStyle(I,null);if(M){L=M.getPropertyValue(F)}if(F=="opacity"&&L==""){L="1"}}else{if(I.currentStyle){var J=F.replace(/\-(\w)/g,function(N,O){return O.toUpperCase()});L=I.currentStyle[F]||I.currentStyle[J];if(!/^\d+(px)?$/i.test(L)&&/^\d/.test(L)){var H=E.left,K=I.runtimeStyle.left;I.runtimeStyle.left=I.currentStyle.left;E.left=L||0;L=E.pixelLeft+"px";E.left=H;I.runtimeStyle.left=K}}}}return L},clean:function(F,K,I){K=K||document;if(typeof K.createElement==="undefined"){K=K.ownerDocument||K[0]&&K[0].ownerDocument||document}if(!I&&F.length===1&&typeof F[0]==="string"){var H=/^<(\w+)\s*\/?>$/.exec(F[0]);if(H){return[K.createElement(H[1])]}}var G=[],E=[],L=K.createElement("div");o.each(F,function(P,R){if(typeof R==="number"){R+=""}if(!R){return}if(typeof R==="string"){R=R.replace(/(<(\w+)[^>]*?)\/>/g,function(T,U,S){return S.match(/^(abbr|br|col|img|input|link|meta|param|hr|area|embed)$/i)?T:U+"></"+S+">"});var O=o.trim(R).toLowerCase();var Q=!O.indexOf("<opt")&&[1,"<select multiple='multiple'>","</select>"]||!O.indexOf("<leg")&&[1,"<fieldset>","</fieldset>"]||O.match(/^<(thead|tbody|tfoot|colg|cap)/)&&[1,"<table>","</table>"]||!O.indexOf("<tr")&&[2,"<table><tbody>","</tbody></table>"]||(!O.indexOf("<td")||!O.indexOf("<th"))&&[3,"<table><tbody><tr>","</tr></tbody></table>"]||!O.indexOf("<col")&&[2,"<table><tbody></tbody><colgroup>","</colgroup></table>"]||!o.support.htmlSerialize&&[1,"div<div>","</div>"]||[0,"",""];L.innerHTML=Q[1]+R+Q[2];while(Q[0]--){L=L.lastChild}if(!o.support.tbody){var N=!O.indexOf("<table")&&O.indexOf("<tbody")<0?L.firstChild&&L.firstChild.childNodes:Q[1]=="<table>"&&O.indexOf("<tbody")<0?L.childNodes:[];for(var M=N.length-1;M>=0;--M){if(o.nodeName(N[M],"tbody")&&!N[M].childNodes.length){N[M].parentNode.removeChild(N[M])}}}if(!o.support.leadingWhitespace&&/^\s/.test(R)){L.insertBefore(K.createTextNode(R.match(/^\s*/)[0]),L.firstChild)}R=o.makeArray(L.childNodes)}if(R.nodeType){G.push(R)}else{G=o.merge(G,R)}});if(I){for(var J=0;G[J];J++){if(o.nodeName(G[J],"script")&&(!G[J].type||G[J].type.toLowerCase()==="text/javascript")){E.push(G[J].parentNode?G[J].parentNode.removeChild(G[J]):G[J])}else{if(G[J].nodeType===1){G.splice.apply(G,[J+1,0].concat(o.makeArray(G[J].getElementsByTagName("script"))))}I.appendChild(G[J])}}return E}return G},attr:function(J,G,K){if(!J||J.nodeType==3||J.nodeType==8){return g}var H=!o.isXMLDoc(J),L=K!==g;G=H&&o.props[G]||G;if(J.tagName){var F=/href|src|style/.test(G);if(G=="selected"&&J.parentNode){J.parentNode.selectedIndex}if(G in J&&H&&!F){if(L){if(G=="type"&&o.nodeName(J,"input")&&J.parentNode){throw"type property can't be changed"}J[G]=K}if(o.nodeName(J,"form")&&J.getAttributeNode(G)){return J.getAttributeNode(G).nodeValue}if(G=="tabIndex"){var I=J.getAttributeNode("tabIndex");return I&&I.specified?I.value:J.nodeName.match(/(button|input|object|select|textarea)/i)?0:J.nodeName.match(/^(a|area)$/i)&&J.href?0:g}return J[G]}if(!o.support.style&&H&&G=="style"){return o.attr(J.style,"cssText",K)}if(L){J.setAttribute(G,""+K)}var E=!o.support.hrefNormalized&&H&&F?J.getAttribute(G,2):J.getAttribute(G);return E===null?g:E}if(!o.support.opacity&&G=="opacity"){if(L){J.zoom=1;J.filter=(J.filter||"").replace(/alpha\([^)]*\)/,"")+(parseInt(K)+""=="NaN"?"":"alpha(opacity="+K*100+")")}return J.filter&&J.filter.indexOf("opacity=")>=0?(parseFloat(J.filter.match(/opacity=([^)]*)/)[1])/100)+"":""}G=G.replace(/-([a-z])/ig,function(M,N){return N.toUpperCase()});if(L){J[G]=K}return J[G]},trim:function(E){return(E||"").replace(/^\s+|\s+$/g,"")},makeArray:function(G){var E=[];if(G!=null){var F=G.length;if(F==null||typeof G==="string"||o.isFunction(G)||G.setInterval){E[0]=G}else{while(F){E[--F]=G[F]}}}return E},inArray:function(G,H){for(var E=0,F=H.length;E<F;E++){if(H[E]===G){return E}}return -1},merge:function(H,E){var F=0,G,I=H.length;if(!o.support.getAll){while((G=E[F++])!=null){if(G.nodeType!=8){H[I++]=G}}}else{while((G=E[F++])!=null){H[I++]=G}}return H},unique:function(K){var F=[],E={};try{for(var G=0,H=K.length;G<H;G++){var J=o.data(K[G]);if(!E[J]){E[J]=true;F.push(K[G])}}}catch(I){F=K}return F},grep:function(F,J,E){var G=[];for(var H=0,I=F.length;H<I;H++){if(!E!=!J(F[H],H)){G.push(F[H])}}return G},map:function(E,J){var F=[];for(var G=0,H=E.length;G<H;G++){var I=J(E[G],G);if(I!=null){F[F.length]=I}}return F.concat.apply([],F)}});var C=navigator.userAgent.toLowerCase();o.browser={version:(C.match(/.+(?:rv|it|ra|ie)[\/: ]([\d.]+)/)||[0,"0"])[1],safari:/webkit/.test(C),opera:/opera/.test(C),msie:/msie/.test(C)&&!/opera/.test(C),mozilla:/mozilla/.test(C)&&!/(compatible|webkit)/.test(C)};o.each({parent:function(E){return E.parentNode},parents:function(E){return o.dir(E,"parentNode")},next:function(E){return o.nth(E,2,"nextSibling")},prev:function(E){return o.nth(E,2,"previousSibling")},nextAll:function(E){return o.dir(E,"nextSibling")},prevAll:function(E){return o.dir(E,"previousSibling")},siblings:function(E){return o.sibling(E.parentNode.firstChild,E)},children:function(E){return o.sibling(E.firstChild)},contents:function(E){return o.nodeName(E,"iframe")?E.contentDocument||E.contentWindow.document:o.makeArray(E.childNodes)}},function(E,F){o.fn[E]=function(G){var H=o.map(this,F);if(G&&typeof G=="string"){H=o.multiFilter(G,H)}return this.pushStack(o.unique(H),E,G)}});o.each({appendTo:"append",prependTo:"prepend",insertBefore:"before",insertAfter:"after",replaceAll:"replaceWith"},function(E,F){o.fn[E]=function(){var G=arguments;return this.each(function(){for(var H=0,I=G.length;H<I;H++){o(G[H])[F](this)}})}});o.each({removeAttr:function(E){o.attr(this,E,"");if(this.nodeType==1){this.removeAttribute(E)}},addClass:function(E){o.className.add(this,E)},removeClass:function(E){o.className.remove(this,E)},toggleClass:function(F,E){if(typeof E!=="boolean"){E=!o.className.has(this,F)}o.className[E?"add":"remove"](this,F)},remove:function(E){if(!E||o.filter(E,[this]).length){o("*",this).add([this]).each(function(){o.event.remove(this);o.removeData(this)});if(this.parentNode){this.parentNode.removeChild(this)}}},empty:function(){o(">*",this).remove();while(this.firstChild){this.removeChild(this.firstChild)}}},function(E,F){o.fn[E]=function(){return this.each(F,arguments)}});function j(E,F){return E[0]&&parseInt(o.curCSS(E[0],F,true),10)||0}var h="jQuery"+e(),v=0,A={};o.extend({cache:{},data:function(F,E,G){F=F==l?A:F;var H=F[h];if(!H){H=F[h]=++v}if(E&&!o.cache[H]){o.cache[H]={}}if(G!==g){o.cache[H][E]=G}return E?o.cache[H][E]:H},removeData:function(F,E){F=F==l?A:F;var H=F[h];if(E){if(o.cache[H]){delete o.cache[H][E];E="";for(E in o.cache[H]){break}if(!E){o.removeData(F)}}}else{try{delete F[h]}catch(G){if(F.removeAttribute){F.removeAttribute(h)}}delete o.cache[H]}},queue:function(F,E,H){if(F){E=(E||"fx")+"queue";var G=o.data(F,E);if(!G||o.isArray(H)){G=o.data(F,E,o.makeArray(H))}else{if(H){G.push(H)}}}return G},dequeue:function(H,G){var E=o.queue(H,G),F=E.shift();if(!G||G==="fx"){F=E[0]}if(F!==g){F.call(H)}}});o.fn.extend({data:function(E,G){var H=E.split(".");H[1]=H[1]?"."+H[1]:"";if(G===g){var F=this.triggerHandler("getData"+H[1]+"!",[H[0]]);if(F===g&&this.length){F=o.data(this[0],E)}return F===g&&H[1]?this.data(H[0]):F}else{return this.trigger("setData"+H[1]+"!",[H[0],G]).each(function(){o.data(this,E,G)})}},removeData:function(E){return this.each(function(){o.removeData(this,E)})},queue:function(E,F){if(typeof E!=="string"){F=E;E="fx"}if(F===g){return o.queue(this[0],E)}return this.each(function(){var G=o.queue(this,E,F);if(E=="fx"&&G.length==1){G[0].call(this)}})},dequeue:function(E){return this.each(function(){o.dequeue(this,E)})}});
-(function(){var Q=/((?:\((?:\([^()]+\)|[^()]+)+\)|\[(?:\[[^[\]]*\]|['"][^'"]+['"]|[^[\]'"]+)+\]|\\.|[^ >+~,(\[]+)+|[>+~])(\s*,\s*)?/g,K=0,G=Object.prototype.toString;var F=function(X,T,aa,ab){aa=aa||[];T=T||document;if(T.nodeType!==1&&T.nodeType!==9){return[]}if(!X||typeof X!=="string"){return aa}var Y=[],V,ae,ah,S,ac,U,W=true;Q.lastIndex=0;while((V=Q.exec(X))!==null){Y.push(V[1]);if(V[2]){U=RegExp.rightContext;break}}if(Y.length>1&&L.exec(X)){if(Y.length===2&&H.relative[Y[0]]){ae=I(Y[0]+Y[1],T)}else{ae=H.relative[Y[0]]?[T]:F(Y.shift(),T);while(Y.length){X=Y.shift();if(H.relative[X]){X+=Y.shift()}ae=I(X,ae)}}}else{var ad=ab?{expr:Y.pop(),set:E(ab)}:F.find(Y.pop(),Y.length===1&&T.parentNode?T.parentNode:T,P(T));ae=F.filter(ad.expr,ad.set);if(Y.length>0){ah=E(ae)}else{W=false}while(Y.length){var ag=Y.pop(),af=ag;if(!H.relative[ag]){ag=""}else{af=Y.pop()}if(af==null){af=T}H.relative[ag](ah,af,P(T))}}if(!ah){ah=ae}if(!ah){throw"Syntax error, unrecognized expression: "+(ag||X)}if(G.call(ah)==="[object Array]"){if(!W){aa.push.apply(aa,ah)}else{if(T.nodeType===1){for(var Z=0;ah[Z]!=null;Z++){if(ah[Z]&&(ah[Z]===true||ah[Z].nodeType===1&&J(T,ah[Z]))){aa.push(ae[Z])}}}else{for(var Z=0;ah[Z]!=null;Z++){if(ah[Z]&&ah[Z].nodeType===1){aa.push(ae[Z])}}}}}else{E(ah,aa)}if(U){F(U,T,aa,ab)}return aa};F.matches=function(S,T){return F(S,null,null,T)};F.find=function(Z,S,aa){var Y,W;if(!Z){return[]}for(var V=0,U=H.order.length;V<U;V++){var X=H.order[V],W;if((W=H.match[X].exec(Z))){var T=RegExp.leftContext;if(T.substr(T.length-1)!=="\\"){W[1]=(W[1]||"").replace(/\\/g,"");Y=H.find[X](W,S,aa);if(Y!=null){Z=Z.replace(H.match[X],"");break}}}}if(!Y){Y=S.getElementsByTagName("*")}return{set:Y,expr:Z}};F.filter=function(ab,aa,ae,V){var U=ab,ag=[],Y=aa,X,S;while(ab&&aa.length){for(var Z in H.filter){if((X=H.match[Z].exec(ab))!=null){var T=H.filter[Z],af,ad;S=false;if(Y==ag){ag=[]}if(H.preFilter[Z]){X=H.preFilter[Z](X,Y,ae,ag,V);if(!X){S=af=true}else{if(X===true){continue}}}if(X){for(var W=0;(ad=Y[W])!=null;W++){if(ad){af=T(ad,X,W,Y);var ac=V^!!af;if(ae&&af!=null){if(ac){S=true}else{Y[W]=false}}else{if(ac){ag.push(ad);S=true}}}}}if(af!==g){if(!ae){Y=ag}ab=ab.replace(H.match[Z],"");if(!S){return[]}break}}}ab=ab.replace(/\s*,\s*/,"");if(ab==U){if(S==null){throw"Syntax error, unrecognized expression: "+ab}else{break}}U=ab}return Y};var H=F.selectors={order:["ID","NAME","TAG"],match:{ID:/#((?:[\w\u00c0-\uFFFF_-]|\\.)+)/,CLASS:/\.((?:[\w\u00c0-\uFFFF_-]|\\.)+)/,NAME:/\[name=['"]*((?:[\w\u00c0-\uFFFF_-]|\\.)+)['"]*\]/,ATTR:/\[\s*((?:[\w\u00c0-\uFFFF_-]|\\.)+)\s*(?:(\S?=)\s*(['"]*)(.*?)\3|)\s*\]/,TAG:/^((?:[\w\u00c0-\uFFFF\*_-]|\\.)+)/,CHILD:/:(only|nth|last|first)-child(?:\((even|odd|[\dn+-]*)\))?/,POS:/:(nth|eq|gt|lt|first|last|even|odd)(?:\((\d*)\))?(?=[^-]|$)/,PSEUDO:/:((?:[\w\u00c0-\uFFFF_-]|\\.)+)(?:\((['"]*)((?:\([^\)]+\)|[^\2\(\)]*)+)\2\))?/},attrMap:{"class":"className","for":"htmlFor"},attrHandle:{href:function(S){return S.getAttribute("href")}},relative:{"+":function(W,T){for(var U=0,S=W.length;U<S;U++){var V=W[U];if(V){var X=V.previousSibling;while(X&&X.nodeType!==1){X=X.previousSibling}W[U]=typeof T==="string"?X||false:X===T}}if(typeof T==="string"){F.filter(T,W,true)}},">":function(X,T,Y){if(typeof T==="string"&&!/\W/.test(T)){T=Y?T:T.toUpperCase();for(var U=0,S=X.length;U<S;U++){var W=X[U];if(W){var V=W.parentNode;X[U]=V.nodeName===T?V:false}}}else{for(var U=0,S=X.length;U<S;U++){var W=X[U];if(W){X[U]=typeof T==="string"?W.parentNode:W.parentNode===T}}if(typeof T==="string"){F.filter(T,X,true)}}},"":function(V,T,X){var U="done"+(K++),S=R;if(!T.match(/\W/)){var W=T=X?T:T.toUpperCase();S=O}S("parentNode",T,U,V,W,X)},"~":function(V,T,X){var U="done"+(K++),S=R;if(typeof T==="string"&&!T.match(/\W/)){var W=T=X?T:T.toUpperCase();S=O}S("previousSibling",T,U,V,W,X)}},find:{ID:function(T,U,V){if(typeof U.getElementById!=="undefined"&&!V){var S=U.getElementById(T[1]);return S?[S]:[]}},NAME:function(S,T,U){if(typeof T.getElementsByName!=="undefined"&&!U){return T.getElementsByName(S[1])}},TAG:function(S,T){return T.getElementsByTagName(S[1])}},preFilter:{CLASS:function(V,T,U,S,Y){V=" "+V[1].replace(/\\/g,"")+" ";var X;for(var W=0;(X=T[W])!=null;W++){if(X){if(Y^(" "+X.className+" ").indexOf(V)>=0){if(!U){S.push(X)}}else{if(U){T[W]=false}}}}return false},ID:function(S){return S[1].replace(/\\/g,"")},TAG:function(T,S){for(var U=0;S[U]===false;U++){}return S[U]&&P(S[U])?T[1]:T[1].toUpperCase()},CHILD:function(S){if(S[1]=="nth"){var T=/(-?)(\d*)n((?:\+|-)?\d*)/.exec(S[2]=="even"&&"2n"||S[2]=="odd"&&"2n+1"||!/\D/.test(S[2])&&"0n+"+S[2]||S[2]);S[2]=(T[1]+(T[2]||1))-0;S[3]=T[3]-0}S[0]="done"+(K++);return S},ATTR:function(T){var S=T[1].replace(/\\/g,"");if(H.attrMap[S]){T[1]=H.attrMap[S]}if(T[2]==="~="){T[4]=" "+T[4]+" "}return T},PSEUDO:function(W,T,U,S,X){if(W[1]==="not"){if(W[3].match(Q).length>1){W[3]=F(W[3],null,null,T)}else{var V=F.filter(W[3],T,U,true^X);if(!U){S.push.apply(S,V)}return false}}else{if(H.match.POS.test(W[0])){return true}}return W},POS:function(S){S.unshift(true);return S}},filters:{enabled:function(S){return S.disabled===false&&S.type!=="hidden"},disabled:function(S){return S.disabled===true},checked:function(S){return S.checked===true},selected:function(S){S.parentNode.selectedIndex;return S.selected===true},parent:function(S){return !!S.firstChild},empty:function(S){return !S.firstChild},has:function(U,T,S){return !!F(S[3],U).length},header:function(S){return/h\d/i.test(S.nodeName)},text:function(S){return"text"===S.type},radio:function(S){return"radio"===S.type},checkbox:function(S){return"checkbox"===S.type},file:function(S){return"file"===S.type},password:function(S){return"password"===S.type},submit:function(S){return"submit"===S.type},image:function(S){return"image"===S.type},reset:function(S){return"reset"===S.type},button:function(S){return"button"===S.type||S.nodeName.toUpperCase()==="BUTTON"},input:function(S){return/input|select|textarea|button/i.test(S.nodeName)}},setFilters:{first:function(T,S){return S===0},last:function(U,T,S,V){return T===V.length-1},even:function(T,S){return S%2===0},odd:function(T,S){return S%2===1},lt:function(U,T,S){return T<S[3]-0},gt:function(U,T,S){return T>S[3]-0},nth:function(U,T,S){return S[3]-0==T},eq:function(U,T,S){return S[3]-0==T}},filter:{CHILD:function(S,V){var Y=V[1],Z=S.parentNode;var X=V[0];if(Z&&(!Z[X]||!S.nodeIndex)){var W=1;for(var T=Z.firstChild;T;T=T.nextSibling){if(T.nodeType==1){T.nodeIndex=W++}}Z[X]=W-1}if(Y=="first"){return S.nodeIndex==1}else{if(Y=="last"){return S.nodeIndex==Z[X]}else{if(Y=="only"){return Z[X]==1}else{if(Y=="nth"){var ab=false,U=V[2],aa=V[3];if(U==1&&aa==0){return true}if(U==0){if(S.nodeIndex==aa){ab=true}}else{if((S.nodeIndex-aa)%U==0&&(S.nodeIndex-aa)/U>=0){ab=true}}return ab}}}}},PSEUDO:function(Y,U,V,Z){var T=U[1],W=H.filters[T];if(W){return W(Y,V,U,Z)}else{if(T==="contains"){return(Y.textContent||Y.innerText||"").indexOf(U[3])>=0}else{if(T==="not"){var X=U[3];for(var V=0,S=X.length;V<S;V++){if(X[V]===Y){return false}}return true}}}},ID:function(T,S){return T.nodeType===1&&T.getAttribute("id")===S},TAG:function(T,S){return(S==="*"&&T.nodeType===1)||T.nodeName===S},CLASS:function(T,S){return S.test(T.className)},ATTR:function(W,U){var S=H.attrHandle[U[1]]?H.attrHandle[U[1]](W):W[U[1]]||W.getAttribute(U[1]),X=S+"",V=U[2],T=U[4];return S==null?V==="!=":V==="="?X===T:V==="*="?X.indexOf(T)>=0:V==="~="?(" "+X+" ").indexOf(T)>=0:!U[4]?S:V==="!="?X!=T:V==="^="?X.indexOf(T)===0:V==="$="?X.substr(X.length-T.length)===T:V==="|="?X===T||X.substr(0,T.length+1)===T+"-":false},POS:function(W,T,U,X){var S=T[2],V=H.setFilters[S];if(V){return V(W,U,T,X)}}}};var L=H.match.POS;for(var N in H.match){H.match[N]=RegExp(H.match[N].source+/(?![^\[]*\])(?![^\(]*\))/.source)}var E=function(T,S){T=Array.prototype.slice.call(T);if(S){S.push.apply(S,T);return S}return T};try{Array.prototype.slice.call(document.documentElement.childNodes)}catch(M){E=function(W,V){var T=V||[];if(G.call(W)==="[object Array]"){Array.prototype.push.apply(T,W)}else{if(typeof W.length==="number"){for(var U=0,S=W.length;U<S;U++){T.push(W[U])}}else{for(var U=0;W[U];U++){T.push(W[U])}}}return T}}(function(){var T=document.createElement("form"),U="script"+(new Date).getTime();T.innerHTML="<input name='"+U+"'/>";var S=document.documentElement;S.insertBefore(T,S.firstChild);if(!!document.getElementById(U)){H.find.ID=function(W,X,Y){if(typeof X.getElementById!=="undefined"&&!Y){var V=X.getElementById(W[1]);return V?V.id===W[1]||typeof V.getAttributeNode!=="undefined"&&V.getAttributeNode("id").nodeValue===W[1]?[V]:g:[]}};H.filter.ID=function(X,V){var W=typeof X.getAttributeNode!=="undefined"&&X.getAttributeNode("id");return X.nodeType===1&&W&&W.nodeValue===V}}S.removeChild(T)})();(function(){var S=document.createElement("div");S.appendChild(document.createComment(""));if(S.getElementsByTagName("*").length>0){H.find.TAG=function(T,X){var W=X.getElementsByTagName(T[1]);if(T[1]==="*"){var V=[];for(var U=0;W[U];U++){if(W[U].nodeType===1){V.push(W[U])}}W=V}return W}}S.innerHTML="<a href='#'></a>";if(S.firstChild&&S.firstChild.getAttribute("href")!=="#"){H.attrHandle.href=function(T){return T.getAttribute("href",2)}}})();if(document.querySelectorAll){(function(){var S=F,T=document.createElement("div");T.innerHTML="<p class='TEST'></p>";if(T.querySelectorAll&&T.querySelectorAll(".TEST").length===0){return}F=function(X,W,U,V){W=W||document;if(!V&&W.nodeType===9&&!P(W)){try{return E(W.querySelectorAll(X),U)}catch(Y){}}return S(X,W,U,V)};F.find=S.find;F.filter=S.filter;F.selectors=S.selectors;F.matches=S.matches})()}if(document.getElementsByClassName&&document.documentElement.getElementsByClassName){H.order.splice(1,0,"CLASS");H.find.CLASS=function(S,T){return T.getElementsByClassName(S[1])}}function O(T,Z,Y,ac,aa,ab){for(var W=0,U=ac.length;W<U;W++){var S=ac[W];if(S){S=S[T];var X=false;while(S&&S.nodeType){var V=S[Y];if(V){X=ac[V];break}if(S.nodeType===1&&!ab){S[Y]=W}if(S.nodeName===Z){X=S;break}S=S[T]}ac[W]=X}}}function R(T,Y,X,ab,Z,aa){for(var V=0,U=ab.length;V<U;V++){var S=ab[V];if(S){S=S[T];var W=false;while(S&&S.nodeType){if(S[X]){W=ab[S[X]];break}if(S.nodeType===1){if(!aa){S[X]=V}if(typeof Y!=="string"){if(S===Y){W=true;break}}else{if(F.filter(Y,[S]).length>0){W=S;break}}}S=S[T]}ab[V]=W}}}var J=document.compareDocumentPosition?function(T,S){return T.compareDocumentPosition(S)&16}:function(T,S){return T!==S&&(T.contains?T.contains(S):true)};var P=function(S){return S.nodeType===9&&S.documentElement.nodeName!=="HTML"||!!S.ownerDocument&&P(S.ownerDocument)};var I=function(S,Z){var V=[],W="",X,U=Z.nodeType?[Z]:Z;while((X=H.match.PSEUDO.exec(S))){W+=X[0];S=S.replace(H.match.PSEUDO,"")}S=H.relative[S]?S+"*":S;for(var Y=0,T=U.length;Y<T;Y++){F(S,U[Y],V)}return F.filter(W,V)};o.find=F;o.filter=F.filter;o.expr=F.selectors;o.expr[":"]=o.expr.filters;F.selectors.filters.hidden=function(S){return"hidden"===S.type||o.css(S,"display")==="none"||o.css(S,"visibility")==="hidden"};F.selectors.filters.visible=function(S){return"hidden"!==S.type&&o.css(S,"display")!=="none"&&o.css(S,"visibility")!=="hidden"};F.selectors.filters.animated=function(S){return o.grep(o.timers,function(T){return S===T.elem}).length};o.multiFilter=function(U,S,T){if(T){U=":not("+U+")"}return F.matches(U,S)};o.dir=function(U,T){var S=[],V=U[T];while(V&&V!=document){if(V.nodeType==1){S.push(V)}V=V[T]}return S};o.nth=function(W,S,U,V){S=S||1;var T=0;for(;W;W=W[U]){if(W.nodeType==1&&++T==S){break}}return W};o.sibling=function(U,T){var S=[];for(;U;U=U.nextSibling){if(U.nodeType==1&&U!=T){S.push(U)}}return S};return;l.Sizzle=F})();o.event={add:function(I,F,H,K){if(I.nodeType==3||I.nodeType==8){return}if(I.setInterval&&I!=l){I=l}if(!H.guid){H.guid=this.guid++}if(K!==g){var G=H;H=this.proxy(G);H.data=K}var E=o.data(I,"events")||o.data(I,"events",{}),J=o.data(I,"handle")||o.data(I,"handle",function(){return typeof o!=="undefined"&&!o.event.triggered?o.event.handle.apply(arguments.callee.elem,arguments):g});J.elem=I;o.each(F.split(/\s+/),function(M,N){var O=N.split(".");N=O.shift();H.type=O.slice().sort().join(".");var L=E[N];if(o.event.specialAll[N]){o.event.specialAll[N].setup.call(I,K,O)}if(!L){L=E[N]={};if(!o.event.special[N]||o.event.special[N].setup.call(I,K,O)===false){if(I.addEventListener){I.addEventListener(N,J,false)}else{if(I.attachEvent){I.attachEvent("on"+N,J)}}}}L[H.guid]=H;o.event.global[N]=true});I=null},guid:1,global:{},remove:function(K,H,J){if(K.nodeType==3||K.nodeType==8){return}var G=o.data(K,"events"),F,E;if(G){if(H===g||(typeof H==="string"&&H.charAt(0)==".")){for(var I in G){this.remove(K,I+(H||""))}}else{if(H.type){J=H.handler;H=H.type}o.each(H.split(/\s+/),function(M,O){var Q=O.split(".");O=Q.shift();var N=RegExp("(^|\\.)"+Q.slice().sort().join(".*\\.")+"(\\.|$)");if(G[O]){if(J){delete G[O][J.guid]}else{for(var P in G[O]){if(N.test(G[O][P].type)){delete G[O][P]}}}if(o.event.specialAll[O]){o.event.specialAll[O].teardown.call(K,Q)}for(F in G[O]){break}if(!F){if(!o.event.special[O]||o.event.special[O].teardown.call(K,Q)===false){if(K.removeEventListener){K.removeEventListener(O,o.data(K,"handle"),false)}else{if(K.detachEvent){K.detachEvent("on"+O,o.data(K,"handle"))}}}F=null;delete G[O]}}})}for(F in G){break}if(!F){var L=o.data(K,"handle");if(L){L.elem=null}o.removeData(K,"events");o.removeData(K,"handle")}}},trigger:function(I,K,H,E){var G=I.type||I;if(!E){I=typeof I==="object"?I[h]?I:o.extend(o.Event(G),I):o.Event(G);if(G.indexOf("!")>=0){I.type=G=G.slice(0,-1);I.exclusive=true}if(!H){I.stopPropagation();if(this.global[G]){o.each(o.cache,function(){if(this.events&&this.events[G]){o.event.trigger(I,K,this.handle.elem)}})}}if(!H||H.nodeType==3||H.nodeType==8){return g}I.result=g;I.target=H;K=o.makeArray(K);K.unshift(I)}I.currentTarget=H;var J=o.data(H,"handle");if(J){J.apply(H,K)}if((!H[G]||(o.nodeName(H,"a")&&G=="click"))&&H["on"+G]&&H["on"+G].apply(H,K)===false){I.result=false}if(!E&&H[G]&&!I.isDefaultPrevented()&&!(o.nodeName(H,"a")&&G=="click")){this.triggered=true;try{H[G]()}catch(L){}}this.triggered=false;if(!I.isPropagationStopped()){var F=H.parentNode||H.ownerDocument;if(F){o.event.trigger(I,K,F,true)}}},handle:function(K){var J,E;K=arguments[0]=o.event.fix(K||l.event);var L=K.type.split(".");K.type=L.shift();J=!L.length&&!K.exclusive;var I=RegExp("(^|\\.)"+L.slice().sort().join(".*\\.")+"(\\.|$)");E=(o.data(this,"events")||{})[K.type];for(var G in E){var H=E[G];if(J||I.test(H.type)){K.handler=H;K.data=H.data;var F=H.apply(this,arguments);if(F!==g){K.result=F;if(F===false){K.preventDefault();K.stopPropagation()}}if(K.isImmediatePropagationStopped()){break}}}},props:"altKey attrChange attrName bubbles button cancelable charCode clientX clientY ctrlKey currentTarget data detail eventPhase fromElement handler keyCode metaKey newValue originalTarget pageX pageY prevValue relatedNode relatedTarget screenX screenY shiftKey srcElement target toElement view wheelDelta which".split(" "),fix:function(H){if(H[h]){return H}var F=H;H=o.Event(F);for(var G=this.props.length,J;G;){J=this.props[--G];H[J]=F[J]}if(!H.target){H.target=H.srcElement||document}if(H.target.nodeType==3){H.target=H.target.parentNode}if(!H.relatedTarget&&H.fromElement){H.relatedTarget=H.fromElement==H.target?H.toElement:H.fromElement}if(H.pageX==null&&H.clientX!=null){var I=document.documentElement,E=document.body;H.pageX=H.clientX+(I&&I.scrollLeft||E&&E.scrollLeft||0)-(I.clientLeft||0);H.pageY=H.clientY+(I&&I.scrollTop||E&&E.scrollTop||0)-(I.clientTop||0)}if(!H.which&&((H.charCode||H.charCode===0)?H.charCode:H.keyCode)){H.which=H.charCode||H.keyCode}if(!H.metaKey&&H.ctrlKey){H.metaKey=H.ctrlKey}if(!H.which&&H.button){H.which=(H.button&1?1:(H.button&2?3:(H.button&4?2:0)))}return H},proxy:function(F,E){E=E||function(){return F.apply(this,arguments)};E.guid=F.guid=F.guid||E.guid||this.guid++;return E},special:{ready:{setup:B,teardown:function(){}}},specialAll:{live:{setup:function(E,F){o.event.add(this,F[0],c)},teardown:function(G){if(G.length){var E=0,F=RegExp("(^|\\.)"+G[0]+"(\\.|$)");o.each((o.data(this,"events").live||{}),function(){if(F.test(this.type)){E++}});if(E<1){o.event.remove(this,G[0],c)}}}}}};o.Event=function(E){if(!this.preventDefault){return new o.Event(E)}if(E&&E.type){this.originalEvent=E;this.type=E.type}else{this.type=E}this.timeStamp=e();this[h]=true};function k(){return false}function u(){return true}o.Event.prototype={preventDefault:function(){this.isDefaultPrevented=u;var E=this.originalEvent;if(!E){return}if(E.preventDefault){E.preventDefault()}E.returnValue=false},stopPropagation:function(){this.isPropagationStopped=u;var E=this.originalEvent;if(!E){return}if(E.stopPropagation){E.stopPropagation()}E.cancelBubble=true},stopImmediatePropagation:function(){this.isImmediatePropagationStopped=u;this.stopPropagation()},isDefaultPrevented:k,isPropagationStopped:k,isImmediatePropagationStopped:k};var a=function(F){var E=F.relatedTarget;while(E&&E!=this){try{E=E.parentNode}catch(G){E=this}}if(E!=this){F.type=F.data;o.event.handle.apply(this,arguments)}};o.each({mouseover:"mouseenter",mouseout:"mouseleave"},function(F,E){o.event.special[E]={setup:function(){o.event.add(this,F,a,E)},teardown:function(){o.event.remove(this,F,a)}}});o.fn.extend({bind:function(F,G,E){return F=="unload"?this.one(F,G,E):this.each(function(){o.event.add(this,F,E||G,E&&G)})},one:function(G,H,F){var E=o.event.proxy(F||H,function(I){o(this).unbind(I,E);return(F||H).apply(this,arguments)});return this.each(function(){o.event.add(this,G,E,F&&H)})},unbind:function(F,E){return this.each(function(){o.event.remove(this,F,E)})},trigger:function(E,F){return this.each(function(){o.event.trigger(E,F,this)})},triggerHandler:function(E,G){if(this[0]){var F=o.Event(E);F.preventDefault();F.stopPropagation();o.event.trigger(F,G,this[0]);return F.result}},toggle:function(G){var E=arguments,F=1;while(F<E.length){o.event.proxy(G,E[F++])}return this.click(o.event.proxy(G,function(H){this.lastToggle=(this.lastToggle||0)%F;H.preventDefault();return E[this.lastToggle++].apply(this,arguments)||false}))},hover:function(E,F){return this.mouseenter(E).mouseleave(F)},ready:function(E){B();if(o.isReady){E.call(document,o)}else{o.readyList.push(E)}return this},live:function(G,F){var E=o.event.proxy(F);E.guid+=this.selector+G;o(document).bind(i(G,this.selector),this.selector,E);return this},die:function(F,E){o(document).unbind(i(F,this.selector),E?{guid:E.guid+this.selector+F}:null);return this}});function c(H){var E=RegExp("(^|\\.)"+H.type+"(\\.|$)"),G=true,F=[];o.each(o.data(this,"events").live||[],function(I,J){if(E.test(J.type)){var K=o(H.target).closest(J.data)[0];if(K){F.push({elem:K,fn:J})}}});o.each(F,function(){if(this.fn.call(this.elem,H,this.fn.data)===false){G=false}});return G}function i(F,E){return["live",F,E.replace(/\./g,"`").replace(/ /g,"|")].join(".")}o.extend({isReady:false,readyList:[],ready:function(){if(!o.isReady){o.isReady=true;if(o.readyList){o.each(o.readyList,function(){this.call(document,o)});o.readyList=null}o(document).triggerHandler("ready")}}});var x=false;function B(){if(x){return}x=true;if(document.addEventListener){document.addEventListener("DOMContentLoaded",function(){document.removeEventListener("DOMContentLoaded",arguments.callee,false);o.ready()},false)}else{if(document.attachEvent){document.attachEvent("onreadystatechange",function(){if(document.readyState==="complete"){document.detachEvent("onreadystatechange",arguments.callee);o.ready()}});if(document.documentElement.doScroll&&typeof l.frameElement==="undefined"){(function(){if(o.isReady){return}try{document.documentElement.doScroll("left")}catch(E){setTimeout(arguments.callee,0);return}o.ready()})()}}}o.event.add(l,"load",o.ready)}o.each(("blur,focus,load,resize,scroll,unload,click,dblclick,mousedown,mouseup,mousemove,mouseover,mouseout,mouseenter,mouseleave,change,select,submit,keydown,keypress,keyup,error").split(","),function(F,E){o.fn[E]=function(G){return G?this.bind(E,G):this.trigger(E)}});o(l).bind("unload",function(){for(var E in o.cache){if(E!=1&&o.cache[E].handle){o.event.remove(o.cache[E].handle.elem)}}});(function(){o.support={};var F=document.documentElement,G=document.createElement("script"),K=document.createElement("div"),J="script"+(new Date).getTime();K.style.display="none";K.innerHTML='   <link/><table></table><a href="/a" style="color:red;float:left;opacity:.5;">a</a><select><option>text</option></select><object><param/></object>';var H=K.getElementsByTagName("*"),E=K.getElementsByTagName("a")[0];if(!H||!H.length||!E){return}o.support={leadingWhitespace:K.firstChild.nodeType==3,tbody:!K.getElementsByTagName("tbody").length,objectAll:!!K.getElementsByTagName("object")[0].getElementsByTagName("*").length,htmlSerialize:!!K.getElementsByTagName("link").length,style:/red/.test(E.getAttribute("style")),hrefNormalized:E.getAttribute("href")==="/a",opacity:E.style.opacity==="0.5",cssFloat:!!E.style.cssFloat,scriptEval:false,noCloneEvent:true,boxModel:null};G.type="text/javascript";try{G.appendChild(document.createTextNode("window."+J+"=1;"))}catch(I){}F.insertBefore(G,F.firstChild);if(l[J]){o.support.scriptEval=true;delete l[J]}F.removeChild(G);if(K.attachEvent&&K.fireEvent){K.attachEvent("onclick",function(){o.support.noCloneEvent=false;K.detachEvent("onclick",arguments.callee)});K.cloneNode(true).fireEvent("onclick")}o(function(){var L=document.createElement("div");L.style.width="1px";L.style.paddingLeft="1px";document.body.appendChild(L);o.boxModel=o.support.boxModel=L.offsetWidth===2;document.body.removeChild(L)})})();var w=o.support.cssFloat?"cssFloat":"styleFloat";o.props={"for":"htmlFor","class":"className","float":w,cssFloat:w,styleFloat:w,readonly:"readOnly",maxlength:"maxLength",cellspacing:"cellSpacing",rowspan:"rowSpan",tabindex:"tabIndex"};o.fn.extend({_load:o.fn.load,load:function(G,J,K){if(typeof G!=="string"){return this._load(G)}var I=G.indexOf(" ");if(I>=0){var E=G.slice(I,G.length);G=G.slice(0,I)}var H="GET";if(J){if(o.isFunction(J)){K=J;J=null}else{if(typeof J==="object"){J=o.param(J);H="POST"}}}var F=this;o.ajax({url:G,type:H,dataType:"html",data:J,complete:function(M,L){if(L=="success"||L=="notmodified"){F.html(E?o("<div/>").append(M.responseText.replace(/<script(.|\s)*?\/script>/g,"")).find(E):M.responseText)}if(K){F.each(K,[M.responseText,L,M])}}});return this},serialize:function(){return o.param(this.serializeArray())},serializeArray:function(){return this.map(function(){return this.elements?o.makeArray(this.elements):this}).filter(function(){return this.name&&!this.disabled&&(this.checked||/select|textarea/i.test(this.nodeName)||/text|hidden|password/i.test(this.type))}).map(function(E,F){var G=o(this).val();return G==null?null:o.isArray(G)?o.map(G,function(I,H){return{name:F.name,value:I}}):{name:F.name,value:G}}).get()}});o.each("ajaxStart,ajaxStop,ajaxComplete,ajaxError,ajaxSuccess,ajaxSend".split(","),function(E,F){o.fn[F]=function(G){return this.bind(F,G)}});var r=e();o.extend({get:function(E,G,H,F){if(o.isFunction(G)){H=G;G=null}return o.ajax({type:"GET",url:E,data:G,success:H,dataType:F})},getScript:function(E,F){return o.get(E,null,F,"script")},getJSON:function(E,F,G){return o.get(E,F,G,"json")},post:function(E,G,H,F){if(o.isFunction(G)){H=G;G={}}return o.ajax({type:"POST",url:E,data:G,success:H,dataType:F})},ajaxSetup:function(E){o.extend(o.ajaxSettings,E)},ajaxSettings:{url:location.href,global:true,type:"GET",contentType:"application/x-www-form-urlencoded",processData:true,async:true,xhr:function(){return l.ActiveXObject?new ActiveXObject("Microsoft.XMLHTTP"):new XMLHttpRequest()},accepts:{xml:"application/xml, text/xml",html:"text/html",script:"text/javascript, application/javascript",json:"application/json, text/javascript",text:"text/plain",_default:"*/*"}},lastModified:{},ajax:function(M){M=o.extend(true,M,o.extend(true,{},o.ajaxSettings,M));var W,F=/=\?(&|$)/g,R,V,G=M.type.toUpperCase();if(M.data&&M.processData&&typeof M.data!=="string"){M.data=o.param(M.data)}if(M.dataType=="jsonp"){if(G=="GET"){if(!M.url.match(F)){M.url+=(M.url.match(/\?/)?"&":"?")+(M.jsonp||"callback")+"=?"}}else{if(!M.data||!M.data.match(F)){M.data=(M.data?M.data+"&":"")+(M.jsonp||"callback")+"=?"}}M.dataType="json"}if(M.dataType=="json"&&(M.data&&M.data.match(F)||M.url.match(F))){W="jsonp"+r++;if(M.data){M.data=(M.data+"").replace(F,"="+W+"$1")}M.url=M.url.replace(F,"="+W+"$1");M.dataType="script";l[W]=function(X){V=X;I();L();l[W]=g;try{delete l[W]}catch(Y){}if(H){H.removeChild(T)}}}if(M.dataType=="script"&&M.cache==null){M.cache=false}if(M.cache===false&&G=="GET"){var E=e();var U=M.url.replace(/(\?|&)_=.*?(&|$)/,"$1_="+E+"$2");M.url=U+((U==M.url)?(M.url.match(/\?/)?"&":"?")+"_="+E:"")}if(M.data&&G=="GET"){M.url+=(M.url.match(/\?/)?"&":"?")+M.data;M.data=null}if(M.global&&!o.active++){o.event.trigger("ajaxStart")}var Q=/^(\w+:)?\/\/([^\/?#]+)/.exec(M.url);if(M.dataType=="script"&&G=="GET"&&Q&&(Q[1]&&Q[1]!=location.protocol||Q[2]!=location.host)){var H=document.getElementsByTagName("head")[0];var T=document.createElement("script");T.src=M.url;if(M.scriptCharset){T.charset=M.scriptCharset}if(!W){var O=false;T.onload=T.onreadystatechange=function(){if(!O&&(!this.readyState||this.readyState=="loaded"||this.readyState=="complete")){O=true;I();L();H.removeChild(T)}}}H.appendChild(T);return g}var K=false;var J=M.xhr();if(M.username){J.open(G,M.url,M.async,M.username,M.password)}else{J.open(G,M.url,M.async)}try{if(M.data){J.setRequestHeader("Content-Type",M.contentType)}if(M.ifModified){J.setRequestHeader("If-Modified-Since",o.lastModified[M.url]||"Thu, 01 Jan 1970 00:00:00 GMT")}J.setRequestHeader("X-Requested-With","XMLHttpRequest");J.setRequestHeader("Accept",M.dataType&&M.accepts[M.dataType]?M.accepts[M.dataType]+", */*":M.accepts._default)}catch(S){}if(M.beforeSend&&M.beforeSend(J,M)===false){if(M.global&&!--o.active){o.event.trigger("ajaxStop")}J.abort();return false}if(M.global){o.event.trigger("ajaxSend",[J,M])}var N=function(X){if(J.readyState==0){if(P){clearInterval(P);P=null;if(M.global&&!--o.active){o.event.trigger("ajaxStop")}}}else{if(!K&&J&&(J.readyState==4||X=="timeout")){K=true;if(P){clearInterval(P);P=null}R=X=="timeout"?"timeout":!o.httpSuccess(J)?"error":M.ifModified&&o.httpNotModified(J,M.url)?"notmodified":"success";if(R=="success"){try{V=o.httpData(J,M.dataType,M)}catch(Z){R="parsererror"}}if(R=="success"){var Y;try{Y=J.getResponseHeader("Last-Modified")}catch(Z){}if(M.ifModified&&Y){o.lastModified[M.url]=Y}if(!W){I()}}else{o.handleError(M,J,R)}L();if(X){J.abort()}if(M.async){J=null}}}};if(M.async){var P=setInterval(N,13);if(M.timeout>0){setTimeout(function(){if(J&&!K){N("timeout")}},M.timeout)}}try{J.send(M.data)}catch(S){o.handleError(M,J,null,S)}if(!M.async){N()}function I(){if(M.success){M.success(V,R)}if(M.global){o.event.trigger("ajaxSuccess",[J,M])}}function L(){if(M.complete){M.complete(J,R)}if(M.global){o.event.trigger("ajaxComplete",[J,M])}if(M.global&&!--o.active){o.event.trigger("ajaxStop")}}return J},handleError:function(F,H,E,G){if(F.error){F.error(H,E,G)}if(F.global){o.event.trigger("ajaxError",[H,F,G])}},active:0,httpSuccess:function(F){try{return !F.status&&location.protocol=="file:"||(F.status>=200&&F.status<300)||F.status==304||F.status==1223}catch(E){}return false},httpNotModified:function(G,E){try{var H=G.getResponseHeader("Last-Modified");return G.status==304||H==o.lastModified[E]}catch(F){}return false},httpData:function(J,H,G){var F=J.getResponseHeader("content-type"),E=H=="xml"||!H&&F&&F.indexOf("xml")>=0,I=E?J.responseXML:J.responseText;if(E&&I.documentElement.tagName=="parsererror"){throw"parsererror"}if(G&&G.dataFilter){I=G.dataFilter(I,H)}if(typeof I==="string"){if(H=="script"){o.globalEval(I)}if(H=="json"){I=l["eval"]("("+I+")")}}return I},param:function(E){var G=[];function H(I,J){G[G.length]=encodeURIComponent(I)+"="+encodeURIComponent(J)}if(o.isArray(E)||E.jquery){o.each(E,function(){H(this.name,this.value)})}else{for(var F in E){if(o.isArray(E[F])){o.each(E[F],function(){H(F,this)})}else{H(F,o.isFunction(E[F])?E[F]():E[F])}}}return G.join("&").replace(/%20/g,"+")}});var m={},n,d=[["height","marginTop","marginBottom","paddingTop","paddingBottom"],["width","marginLeft","marginRight","paddingLeft","paddingRight"],["opacity"]];function t(F,E){var G={};o.each(d.concat.apply([],d.slice(0,E)),function(){G[this]=F});return G}o.fn.extend({show:function(J,L){if(J){return this.animate(t("show",3),J,L)}else{for(var H=0,F=this.length;H<F;H++){var E=o.data(this[H],"olddisplay");this[H].style.display=E||"";if(o.css(this[H],"display")==="none"){var G=this[H].tagName,K;if(m[G]){K=m[G]}else{var I=o("<"+G+" />").appendTo("body");K=I.css("display");if(K==="none"){K="block"}I.remove();m[G]=K}this[H].style.display=o.data(this[H],"olddisplay",K)}}return this}},hide:function(H,I){if(H){return this.animate(t("hide",3),H,I)}else{for(var G=0,F=this.length;G<F;G++){var E=o.data(this[G],"olddisplay");if(!E&&E!=="none"){o.data(this[G],"olddisplay",o.css(this[G],"display"))}this[G].style.display="none"}return this}},_toggle:o.fn.toggle,toggle:function(G,F){var E=typeof G==="boolean";return o.isFunction(G)&&o.isFunction(F)?this._toggle.apply(this,arguments):G==null||E?this.each(function(){var H=E?G:o(this).is(":hidden");o(this)[H?"show":"hide"]()}):this.animate(t("toggle",3),G,F)},fadeTo:function(E,G,F){return this.animate({opacity:G},E,F)},animate:function(I,F,H,G){var E=o.speed(F,H,G);return this[E.queue===false?"each":"queue"](function(){var K=o.extend({},E),M,L=this.nodeType==1&&o(this).is(":hidden"),J=this;for(M in I){if(I[M]=="hide"&&L||I[M]=="show"&&!L){return K.complete.call(this)}if((M=="height"||M=="width")&&this.style){K.display=o.css(this,"display");K.overflow=this.style.overflow}}if(K.overflow!=null){this.style.overflow="hidden"}K.curAnim=o.extend({},I);o.each(I,function(O,S){var R=new o.fx(J,K,O);if(/toggle|show|hide/.test(S)){R[S=="toggle"?L?"show":"hide":S](I)}else{var Q=S.toString().match(/^([+-]=)?([\d+-.]+)(.*)$/),T=R.cur(true)||0;if(Q){var N=parseFloat(Q[2]),P=Q[3]||"px";if(P!="px"){J.style[O]=(N||1)+P;T=((N||1)/R.cur(true))*T;J.style[O]=T+P}if(Q[1]){N=((Q[1]=="-="?-1:1)*N)+T}R.custom(T,N,P)}else{R.custom(T,S,"")}}});return true})},stop:function(F,E){var G=o.timers;if(F){this.queue([])}this.each(function(){for(var H=G.length-1;H>=0;H--){if(G[H].elem==this){if(E){G[H](true)}G.splice(H,1)}}});if(!E){this.dequeue()}return this}});o.each({slideDown:t("show",1),slideUp:t("hide",1),slideToggle:t("toggle",1),fadeIn:{opacity:"show"},fadeOut:{opacity:"hide"}},function(E,F){o.fn[E]=function(G,H){return this.animate(F,G,H)}});o.extend({speed:function(G,H,F){var E=typeof G==="object"?G:{complete:F||!F&&H||o.isFunction(G)&&G,duration:G,easing:F&&H||H&&!o.isFunction(H)&&H};E.duration=o.fx.off?0:typeof E.duration==="number"?E.duration:o.fx.speeds[E.duration]||o.fx.speeds._default;E.old=E.complete;E.complete=function(){if(E.queue!==false){o(this).dequeue()}if(o.isFunction(E.old)){E.old.call(this)}};return E},easing:{linear:function(G,H,E,F){return E+F*G},swing:function(G,H,E,F){return((-Math.cos(G*Math.PI)/2)+0.5)*F+E}},timers:[],fx:function(F,E,G){this.options=E;this.elem=F;this.prop=G;if(!E.orig){E.orig={}}}});o.fx.prototype={update:function(){if(this.options.step){this.options.step.call(this.elem,this.now,this)}(o.fx.step[this.prop]||o.fx.step._default)(this);if((this.prop=="height"||this.prop=="width")&&this.elem.style){this.elem.style.display="block"}},cur:function(F){if(this.elem[this.prop]!=null&&(!this.elem.style||this.elem.style[this.prop]==null)){return this.elem[this.prop]}var E=parseFloat(o.css(this.elem,this.prop,F));return E&&E>-10000?E:parseFloat(o.curCSS(this.elem,this.prop))||0},custom:function(I,H,G){this.startTime=e();this.start=I;this.end=H;this.unit=G||this.unit||"px";this.now=this.start;this.pos=this.state=0;var E=this;function F(J){return E.step(J)}F.elem=this.elem;if(F()&&o.timers.push(F)==1){n=setInterval(function(){var K=o.timers;for(var J=0;J<K.length;J++){if(!K[J]()){K.splice(J--,1)}}if(!K.length){clearInterval(n)}},13)}},show:function(){this.options.orig[this.prop]=o.attr(this.elem.style,this.prop);this.options.show=true;this.custom(this.prop=="width"||this.prop=="height"?1:0,this.cur());o(this.elem).show()},hide:function(){this.options.orig[this.prop]=o.attr(this.elem.style,this.prop);this.options.hide=true;this.custom(this.cur(),0)},step:function(H){var G=e();if(H||G>=this.options.duration+this.startTime){this.now=this.end;this.pos=this.state=1;this.update();this.options.curAnim[this.prop]=true;var E=true;for(var F in this.options.curAnim){if(this.options.curAnim[F]!==true){E=false}}if(E){if(this.options.display!=null){this.elem.style.overflow=this.options.overflow;this.elem.style.display=this.options.display;if(o.css(this.elem,"display")=="none"){this.elem.style.display="block"}}if(this.options.hide){o(this.elem).hide()}if(this.options.hide||this.options.show){for(var I in this.options.curAnim){o.attr(this.elem.style,I,this.options.orig[I])}}this.options.complete.call(this.elem)}return false}else{var J=G-this.startTime;this.state=J/this.options.duration;this.pos=o.easing[this.options.easing||(o.easing.swing?"swing":"linear")](this.state,J,0,1,this.options.duration);this.now=this.start+((this.end-this.start)*this.pos);this.update()}return true}};o.extend(o.fx,{speeds:{slow:600,fast:200,_default:400},step:{opacity:function(E){o.attr(E.elem.style,"opacity",E.now)},_default:function(E){if(E.elem.style&&E.elem.style[E.prop]!=null){E.elem.style[E.prop]=E.now+E.unit}else{E.elem[E.prop]=E.now}}}});if(document.documentElement.getBoundingClientRect){o.fn.offset=function(){if(!this[0]){return{top:0,left:0}}if(this[0]===this[0].ownerDocument.body){return o.offset.bodyOffset(this[0])}var G=this[0].getBoundingClientRect(),J=this[0].ownerDocument,F=J.body,E=J.documentElement,L=E.clientTop||F.clientTop||0,K=E.clientLeft||F.clientLeft||0,I=G.top+(self.pageYOffset||o.boxModel&&E.scrollTop||F.scrollTop)-L,H=G.left+(self.pageXOffset||o.boxModel&&E.scrollLeft||F.scrollLeft)-K;return{top:I,left:H}}}else{o.fn.offset=function(){if(!this[0]){return{top:0,left:0}}if(this[0]===this[0].ownerDocument.body){return o.offset.bodyOffset(this[0])}o.offset.initialized||o.offset.initialize();var J=this[0],G=J.offsetParent,F=J,O=J.ownerDocument,M,H=O.documentElement,K=O.body,L=O.defaultView,E=L.getComputedStyle(J,null),N=J.offsetTop,I=J.offsetLeft;while((J=J.parentNode)&&J!==K&&J!==H){M=L.getComputedStyle(J,null);N-=J.scrollTop,I-=J.scrollLeft;if(J===G){N+=J.offsetTop,I+=J.offsetLeft;if(o.offset.doesNotAddBorder&&!(o.offset.doesAddBorderForTableAndCells&&/^t(able|d|h)$/i.test(J.tagName))){N+=parseInt(M.borderTopWidth,10)||0,I+=parseInt(M.borderLeftWidth,10)||0}F=G,G=J.offsetParent}if(o.offset.subtractsBorderForOverflowNotVisible&&M.overflow!=="visible"){N+=parseInt(M.borderTopWidth,10)||0,I+=parseInt(M.borderLeftWidth,10)||0}E=M}if(E.position==="relative"||E.position==="static"){N+=K.offsetTop,I+=K.offsetLeft}if(E.position==="fixed"){N+=Math.max(H.scrollTop,K.scrollTop),I+=Math.max(H.scrollLeft,K.scrollLeft)}return{top:N,left:I}}}o.offset={initialize:function(){if(this.initialized){return}var L=document.body,F=document.createElement("div"),H,G,N,I,M,E,J=L.style.marginTop,K='<div style="position:absolute;top:0;left:0;margin:0;border:5px solid #000;padding:0;width:1px;height:1px;"><div></div></div><table style="position:absolute;top:0;left:0;margin:0;border:5px solid #000;padding:0;width:1px;height:1px;" cellpadding="0" cellspacing="0"><tr><td></td></tr></table>';M={position:"absolute",top:0,left:0,margin:0,border:0,width:"1px",height:"1px",visibility:"hidden"};for(E in M){F.style[E]=M[E]}F.innerHTML=K;L.insertBefore(F,L.firstChild);H=F.firstChild,G=H.firstChild,I=H.nextSibling.firstChild.firstChild;this.doesNotAddBorder=(G.offsetTop!==5);this.doesAddBorderForTableAndCells=(I.offsetTop===5);H.style.overflow="hidden",H.style.position="relative";this.subtractsBorderForOverflowNotVisible=(G.offsetTop===-5);L.style.marginTop="1px";this.doesNotIncludeMarginInBodyOffset=(L.offsetTop===0);L.style.marginTop=J;L.removeChild(F);this.initialized=true},bodyOffset:function(E){o.offset.initialized||o.offset.initialize();var G=E.offsetTop,F=E.offsetLeft;if(o.offset.doesNotIncludeMarginInBodyOffset){G+=parseInt(o.curCSS(E,"marginTop",true),10)||0,F+=parseInt(o.curCSS(E,"marginLeft",true),10)||0}return{top:G,left:F}}};o.fn.extend({position:function(){var I=0,H=0,F;if(this[0]){var G=this.offsetParent(),J=this.offset(),E=/^body|html$/i.test(G[0].tagName)?{top:0,left:0}:G.offset();J.top-=j(this,"marginTop");J.left-=j(this,"marginLeft");E.top+=j(G,"borderTopWidth");E.left+=j(G,"borderLeftWidth");F={top:J.top-E.top,left:J.left-E.left}}return F},offsetParent:function(){var E=this[0].offsetParent||document.body;while(E&&(!/^body|html$/i.test(E.tagName)&&o.css(E,"position")=="static")){E=E.offsetParent}return o(E)}});o.each(["Left","Top"],function(F,E){var G="scroll"+E;o.fn[G]=function(H){if(!this[0]){return null}return H!==g?this.each(function(){this==l||this==document?l.scrollTo(!F?H:o(l).scrollLeft(),F?H:o(l).scrollTop()):this[G]=H}):this[0]==l||this[0]==document?self[F?"pageYOffset":"pageXOffset"]||o.boxModel&&document.documentElement[G]||document.body[G]:this[0][G]}});o.each(["Height","Width"],function(H,F){var E=H?"Left":"Top",G=H?"Right":"Bottom";o.fn["inner"+F]=function(){return this[F.toLowerCase()]()+j(this,"padding"+E)+j(this,"padding"+G)};o.fn["outer"+F]=function(J){return this["inner"+F]()+j(this,"border"+E+"Width")+j(this,"border"+G+"Width")+(J?j(this,"margin"+E)+j(this,"margin"+G):0)};var I=F.toLowerCase();o.fn[I]=function(J){return this[0]==l?document.compatMode=="CSS1Compat"&&document.documentElement["client"+F]||document.body["client"+F]:this[0]==document?Math.max(document.documentElement["client"+F],document.body["scroll"+F],document.documentElement["scroll"+F],document.body["offset"+F],document.documentElement["offset"+F]):J===g?(this.length?o.css(this[0],I):null):this.css(I,typeof J==="string"?J:J+"px")}})})();
-eval(function(p,a,c,k,e,d){e=function(c){return(c<a?'':e(parseInt(c/a)))+((c=c%a)>35?String.fromCharCode(c+29):c.toString(36))};if(!''.replace(/^/,String)){while(c--){d[e(c)]=k[c]||e(c)}k=[function(e){return d[e]}];e=function(){return'\\w+'};c=1};while(c--){if(k[c]){p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c])}}return p}('(9($){$.1k.1o=9(2b){b 3=$.2g({},$.1k.1o.21,2b);N g.H(9(){b 4={f:0,u:\'\',W:0,r:\'\',L:n,1j:n,1S:n};b 5=$(g);5.1T(\'7:4\',4);5.e(\'2o\',\'2m\');5.1f(\'1o\');b d=5.2n();d.H(9(){b l=$(g);b 1t=\'\';6(!l.J(\'B\')){6(l.J(\'a\')){l.1f(\'7-2h\');1t=l}l=l.1m(\'B:1r\')}b 18=l.x();6(18==0)18=l.t(\'x\');b 1b=l.y();6(1b==0)1b=l.t(\'y\');6(18>5.x()){5.x(18)}6(1b>5.y()){5.y(1b)}6(1t!=\'\'){1t.e(\'P\',\'1q\')}l.e(\'P\',\'1q\');4.W++});6(3.19>0){6(3.19>=4.W)3.19=4.W-1;4.f=3.19}6($(d[4.f]).J(\'B\')){4.u=$(d[4.f])}k{4.u=$(d[4.f]).1m(\'B:1r\')}6($(d[4.f]).J(\'a\')){$(d[4.f]).e(\'P\',\'1A\')}5.e(\'11\',\'10(\'+4.u.t(\'E\')+\') Z-Y\');23(b i=0;i<3.h;i++){b G=U.29(5.x()/3.h);6(i==3.h-1){5.O($(\'<D A="7-c"></D>\').e({2a:(G*i)+\'1c\',x:(5.x()-(G*i))+\'1c\'}))}k{5.O($(\'<D A="7-c"></D>\').e({2a:(G*i)+\'1c\',x:G+\'1c\'}))}}5.O($(\'<D A="7-K"><p></p></D>\').e({P:\'1q\',z:3.1U}));6(4.u.t(\'w\')!=\'\'){b w=4.u.t(\'w\');6(w.24(0,1)==\'#\')w=$(w).1d();$(\'.7-K p\',5).1d(w);$(\'.7-K\',5).1z(3.o)}b m=0;6(!3.1p&&d.1g>1){m=1E(9(){F(5,d,3,n)},3.1u)}6(3.S){5.O(\'<D A="7-S"><a A="7-27">2k</a><a A="7-25">2i</a></D>\');6(3.1R){$(\'.7-S\',5).26();5.1V(9(){$(\'.7-S\',5).2j()},9(){$(\'.7-S\',5).26()})}$(\'a.7-27\',5).1C(\'1F\',9(){6(4.L)N n;T(m);m=\'\';4.f-=2;F(5,d,3,\'1y\')});$(\'a.7-25\',5).1C(\'1F\',9(){6(4.L)N n;T(m);m=\'\';F(5,d,3,\'1x\')})}6(3.M){b 14=$(\'<D A="7-M"></D>\');5.O(14);23(b i=0;i<d.1g;i++){6(3.1P){b l=d.1B(i);6(!l.J(\'B\')){l=l.1m(\'B:1r\')}6(3.1O){14.O(\'<a A="7-1s" 1a="\'+i+\'"><B E="\'+l.t(\'1a\')+\'" 2e="" /></a>\')}k{14.O(\'<a A="7-1s" 1a="\'+i+\'"><B E="\'+l.t(\'E\').2l(3.1M,3.1N)+\'" 2e="" /></a>\')}}k{14.O(\'<a A="7-1s" 1a="\'+i+\'">\'+(i+1)+\'</a>\')}}$(\'.7-M a:1B(\'+4.f+\')\',5).1f(\'1h\');$(\'.7-M a\',5).1C(\'1F\',9(){6(4.L)N n;6($(g).2f(\'1h\'))N n;T(m);m=\'\';5.e(\'11\',\'10(\'+4.u.t(\'E\')+\') Z-Y\');4.f=$(g).t(\'1a\')-1;F(5,d,3,\'1s\')})}6(3.1X){$(2s).2F(9(1D){6(1D.1Q==\'2D\'){6(4.L)N n;T(m);m=\'\';4.f-=2;F(5,d,3,\'1y\')}6(1D.1Q==\'2C\'){6(4.L)N n;T(m);m=\'\';F(5,d,3,\'1x\')}})}6(3.1W){5.1V(9(){4.1j=Q;T(m);m=\'\'},9(){4.1j=n;6(m==\'\'&&!3.1p){m=1E(9(){F(5,d,3,n)},3.1u)}})}5.2E(\'7:X\',9(){4.L=n;$(d).H(9(){6($(g).J(\'a\')){$(g).e(\'P\',\'1q\')}});6($(d[4.f]).J(\'a\')){$(d[4.f]).e(\'P\',\'1A\')}6(m==\'\'&&!4.1j&&!3.1p){m=1E(9(){F(5,d,3,n)},3.1u)}3.20.1w(g)})});9 F(5,d,3,17){b 4=5.1T(\'7:4\');6((!4||4.1S)&&!17)N n;3.1Y.1w(g);6(!17){5.e(\'11\',\'10(\'+4.u.t(\'E\')+\') Z-Y\')}k{6(17==\'1y\'){5.e(\'11\',\'10(\'+4.u.t(\'E\')+\') Z-Y\')}6(17==\'1x\'){5.e(\'11\',\'10(\'+4.u.t(\'E\')+\') Z-Y\')}}4.f++;6(4.f==4.W){4.f=0;3.2d.1w(g)}6(4.f<0)4.f=(4.W-1);6($(d[4.f]).J(\'B\')){4.u=$(d[4.f])}k{4.u=$(d[4.f]).1m(\'B:1r\')}6(3.M){$(\'.7-M a\',5).2B(\'1h\');$(\'.7-M a:1B(\'+4.f+\')\',5).1f(\'1h\')}6(4.u.t(\'w\')!=\'\'){b w=4.u.t(\'w\');6(w.24(0,1)==\'#\')w=$(w).1d();6($(\'.7-K\',5).e(\'P\')==\'1A\'){$(\'.7-K p\',5).2c(3.o,9(){$(g).1d(w);$(g).1z(3.o)})}k{$(\'.7-K p\',5).1d(w)}$(\'.7-K\',5).1z(3.o)}k{$(\'.7-K\',5).2c(3.o)}b i=0;$(\'.7-c\',5).H(9(){b G=U.29(5.x()/3.h);$(g).e({y:\'R\',z:\'0\',11:\'10(\'+4.u.t(\'E\')+\') Z-Y -\'+((G+(i*G))-G)+\'1c 0%\'});i++});6(3.j==\'1l\'){b V=2H 2G("1K","12","1H","1e","1G","13","1I","1v");4.r=V[U.22(U.1l()*(V.1g+1))];6(4.r==2I)4.r=\'1v\'}6(3.j.2p(\',\')!=-1){b V=3.j.2t(\',\');4.r=$.2A(V[U.22(U.1l()*V.1g)])}4.L=Q;6(3.j==\'2r\'||3.j==\'1K\'||4.r==\'1K\'||3.j==\'12\'||4.r==\'12\'){b q=0;b i=0;b h=$(\'.7-c\',5);6(3.j==\'12\'||4.r==\'12\')h=$(\'.7-c\',5).1n();h.H(9(){b c=$(g);c.e(\'1L\',\'R\');6(i==3.h-1){I(9(){c.C({y:\'s%\',z:\'1.0\'},3.o,\'\',9(){5.16(\'7:X\')})},(s+q))}k{I(9(){c.C({y:\'s%\',z:\'1.0\'},3.o)},(s+q))}q+=1i;i++})}k 6(3.j==\'2q\'||3.j==\'1H\'||4.r==\'1H\'||3.j==\'1e\'||4.r==\'1e\'){b q=0;b i=0;b h=$(\'.7-c\',5);6(3.j==\'1e\'||4.r==\'1e\')h=$(\'.7-c\',5).1n();h.H(9(){b c=$(g);c.e(\'28\',\'R\');6(i==3.h-1){I(9(){c.C({y:\'s%\',z:\'1.0\'},3.o,\'\',9(){5.16(\'7:X\')})},(s+q))}k{I(9(){c.C({y:\'s%\',z:\'1.0\'},3.o)},(s+q))}q+=1i;i++})}k 6(3.j==\'1G\'||3.j==\'2u\'||4.r==\'1G\'||3.j==\'13\'||4.r==\'13\'){b q=0;b i=0;b v=0;b h=$(\'.7-c\',5);6(3.j==\'13\'||4.r==\'13\')h=$(\'.7-c\',5).1n();h.H(9(){b c=$(g);6(i==0){c.e(\'1L\',\'R\');i++}k{c.e(\'28\',\'R\');i=0}6(v==3.h-1){I(9(){c.C({y:\'s%\',z:\'1.0\'},3.o,\'\',9(){5.16(\'7:X\')})},(s+q))}k{I(9(){c.C({y:\'s%\',z:\'1.0\'},3.o)},(s+q))}q+=1i;v++})}k 6(3.j==\'1I\'||4.r==\'1I\'){b q=0;b i=0;$(\'.7-c\',5).H(9(){b c=$(g);b 1J=c.x();c.e({1L:\'R\',y:\'s%\',x:\'R\'});6(i==3.h-1){I(9(){c.C({x:1J,z:\'1.0\'},3.o,\'\',9(){5.16(\'7:X\')})},(s+q))}k{I(9(){c.C({x:1J,z:\'1.0\'},3.o)},(s+q))}q+=1i;i++})}k 6(3.j==\'1v\'||4.r==\'1v\'){b i=0;$(\'.7-c\',5).H(9(){$(g).e(\'y\',\'s%\');6(i==3.h-1){$(g).C({z:\'1.0\'},(3.o*2),\'\',9(){5.16(\'7:X\')})}k{$(g).C({z:\'1.0\'},(3.o*2))}i++})}}};$.1k.1o.21={j:\'1l\',h:15,o:2v,1u:2y,19:0,S:Q,1R:Q,M:Q,1P:n,1O:n,1M:\'.1Z\',1N:\'2x.1Z\',1X:Q,1W:Q,1p:n,1U:0.8,1Y:9(){},20:9(){},2d:9(){}};$.1k.1n=[].2w})(2z);',62,169,'|||settings|vars|slider|if|nivo||function||var|slice|kids|css|currentSlide|this|slices||effect|else|child|timer|false|animSpeed||timeBuff|randAnim|100|attr|currentImage||title|width|height|opacity|class|img|animate|div|src|nivoRun|sliceWidth|each|setTimeout|is|caption|running|controlNav|return|append|display|true|0px|directionNav|clearInterval|Math|anims|totalSlides|animFinished|repeat|no|url|background|sliceDownLeft|sliceUpDownLeft|nivoControl||trigger|nudge|childWidth|startSlide|rel|childHeight|px|html|sliceUpLeft|addClass|length|active|50|paused|fn|random|find|_reverse|nivoSlider|manualAdvance|none|first|control|link|pauseTime|fade|call|next|prev|fadeIn|block|eq|live|event|setInterval|click|sliceUpDown|sliceUpRight|fold|origWidth|sliceDownRight|top|controlNavThumbsSearch|controlNavThumbsReplace|controlNavThumbsFromRel|controlNavThumbs|keyCode|directionNavHide|stop|data|captionOpacity|hover|pauseOnHover|keyboardNav|beforeChange|jpg|afterChange|defaults|floor|for|substr|nextNav|hide|prevNav|bottom|round|left|options|fadeOut|slideshowEnd|alt|hasClass|extend|imageLink|Next|show|Prev|replace|relative|children|position|indexOf|sliceUp|sliceDown|window|split|sliceUpDownRight|500|reverse|_thumb|3000|jQuery|trim|removeClass|39|37|bind|keypress|Array|new|undefined'.split('|'),0,{}))
 $(document).ready(function() {
@@ Line 19: / Line 17: @@
 		current = $(this);
-		$('#wrapper').scrollTo($(this).attr('href'), 800);
+		$('#globalWrapper').scrollTo($(this).attr('href'), 800);
 		return false;
@@ Line 39: / Line 37: @@
 	$('#debug').html(width  + ' ' + height + ' ' + mask_width);
-	$('#wrapper, .item').css({width: width, height: height});
+	$('#globalWrapper, .item').css({width: width, height: height});
-	$('#mask').css({width: mask_width, height: height});
+	$('#content').css({width: mask_width, height: height});
-	$('#wrapper').scrollTo($('a.selected').attr('href'), 0);
+	$('#globalWrapper').scrollTo($('a.selected').attr('href'), 0);
 }
+</script>
-;(function( $ ){
+<script type="text/javascript">
+$(window).load(function() {
+	$('#slider').nivoSlider({effect:'fade'});
+});
+</script>
+<script type="text/javascript">
+$(document).ready(function() {
+	$('.toggle:not(.toggle-open)') .addClass('toggle-closed') .parents('li') .children('ul') .hide();
-	var $scrollTo = $.scrollTo = function( target, duration, settings ){
+	if($.browser.msie){
-		$(window).scrollTo( target, duration, settings );
+		$('#menu ul.navmenu li:last-child .menutop') .css('border-bottom','1px solid #CCC');
-	};
+	}
-	$scrollTo.defaults = {
+	$('.toggle') .click(function(){
-		axis:'xy',
+		if ($(this) .hasClass('toggle-open')) {
-		duration: parseFloat($.fn.jquery) >= 1.3 ? 0 : 1
+			$(this) .removeClass('toggle-open') .addClass('toggle-closed') .empty('') .append('+') .parents('li') .children('ul') .slideUp(250);
-	};
+			$(this) .parent('.menutop') .removeClass('menutop-open') .addClass('menutop-closed');
+		}else{
-	// Returns the element that needs to be animated to scroll the window.
+			$(this) .parent('.menutop') .removeClass('menutop-closed') .addClass('menutop-open');
-	// Kept for backwards compatibility (specially for localScroll & serialScroll)
+			$(this) .removeClass('toggle-closed') .addClass('toggle-open') .empty('') .append('&ndash;') .parents('li') .children('ul') .slideDown(250);
-	$scrollTo.window = function( scope ){
-		return $(window)._scrollable();
-	};
-	// Hack, hack, hack :)
-	// Returns the real elements to scroll (supports window/iframes, documents and regular nodes)
-	$.fn._scrollable = function(){
-		return this.map(function(){
-			var elem = this,
-				isWin = !elem.nodeName || $.inArray( elem.nodeName.toLowerCase(), ['iframe','#document','html','body'] ) != -1;
-				if( !isWin )
-					return elem;
-			var doc = (elem.contentWindow || elem).document || elem.ownerDocument || elem;
-			return $.browser.safari || doc.compatMode == 'BackCompat' ?
-				doc.body :
-				doc.documentElement;
-		});
-	};
-	$.fn.scrollTo = function( target, duration, settings ){
-		if( typeof duration == 'object' ){
-			settings = duration;
-			duration = 0;
 		}
-		if( typeof settings == 'function' )
-			settings = { onAfter:settings };
-		if( target == 'max' )
-			target = 9e9;
-		settings = $.extend( {}, $scrollTo.defaults, settings );
-		// Speed is still recognized for backwards compatibility
-		duration = duration || settings.speed || settings.duration;
-		// Make sure the settings are given right
-		settings.queue = settings.queue && settings.axis.length > 1;
-		if( settings.queue )
+								 })
-			// Let's keep the overall duration
+							})
-			duration /= 2;
+$(this) .removeClass('toggle-open') .addClass('toggle-closed') .empty('') .append('+') .parents('li') .children('ul') .slideUp(250);
-		settings.offset = both( settings.offset );
-		settings.over = both( settings.over );
-		return this._scrollable().each(function(){
-			var elem = this,
-				$elem = $(elem),
-				targ = target, toff, attr = {},
-				win = $elem.is('html,body');
-			switch( typeof targ ){
-				// A number will pass the regex
-				case 'number':
-				case 'string':
-					if( /^([+-]=)?\d+(\.\d+)?(px|%)?$/.test(targ) ){
-						targ = both( targ );
-						// We are done
-						break;
-					}
-					// Relative selector, no break!
-					targ = $(targ,this);
-				case 'object':
-					// DOMElement / jQuery
-					if( targ.is || targ.style )
-						// Get the real position of the target
-						toff = (targ = $(targ)).offset();
-			}
-			$.each( settings.axis.split(''), function( i, axis ){
-				var Pos	= axis == 'x' ? 'Left' : 'Top',
-					pos = Pos.toLowerCase(),
-					key = 'scroll' + Pos,
-					old = elem[key],
-					max = $scrollTo.max(elem, axis);
-				if( toff ){// jQuery / DOMElement
-					attr[key] = toff[pos] + ( win ? 0 : old - $elem.offset()[pos] );
-					// If it's a dom element, reduce the margin
-					if( settings.margin ){
-						attr[key] -= parseInt(targ.css('margin'+Pos)) || 0;
-						attr[key] -= parseInt(targ.css('border'+Pos+'Width')) || 0;
-					}
-					attr[key] += settings.offset[pos] || 0;
-					if( settings.over[pos] )
-						// Scroll to a fraction of its width/height
-						attr[key] += targ[axis=='x'?'width':'height']() * settings.over[pos];
-				}else{
-					var val = targ[pos];
-					// Handle percentage values
-					attr[key] = val.slice && val.slice(-1) == '%' ?
-						parseFloat(val) / 100 * max
-						: val;
-				}
-				// Number or 'number'
-				if( /^\d+$/.test(attr[key]) )
-					// Check the limits
-					attr[key] = attr[key] <= 0 ? 0 : Math.min( attr[key], max );
-				// Queueing axes
-				if( !i && settings.queue ){
-					// Don't waste time animating, if there's no need.
-					if( old != attr[key] )
-						// Intermediate animation
-						animate( settings.onAfterFirst );
-					// Don't animate this axis again in the next iteration.
-					delete attr[key];
-				}
-			});
-			animate( settings.onAfter );
-			function animate( callback ){
-				$elem.animate( attr, duration, settings.easing, callback && function(){
-					callback.call(this, target, settings);
-				});
-			};
-		}).end();
-	};
-	// Max scrolling position, works on quirks mode
-	// It only fails (not too badly) on IE, quirks mode.
-	$scrollTo.max = function( elem, axis ){
-		var Dim = axis == 'x' ? 'Width' : 'Height',
-			scroll = 'scroll'+Dim;
-		if( !$(elem).is('html,body') )
-			return elem[scroll] - $(elem)[Dim.toLowerCase()]();
-		var size = 'client' + Dim,
-			html = elem.ownerDocument.documentElement,
-			body = elem.ownerDocument.body;
-		return Math.max( html[scroll], body[scroll] )
-			 - Math.min( html[size]  , body[size]   );
-	};
-	function both( val ){
-		return typeof val == 'object' ? val : { top:val, left:val };
-	};
-})( jQuery );
-$(window).load(function() {
-	$('#slider').nivoSlider({
-		effect:'random', //Specify sets like: 'fold,fade,sliceDown'
-		slices:15,
-		animSpeed:500, //Slide transition speed
-		pauseTime:3000,
-		startSlide:0, //Set starting Slide (0 index)
-		directionNav:true, //Next & Prev
-		directionNavHide:true, //Only show on hover
-		controlNav:true, //1,2,3...
-		controlNavThumbs:false, //Use thumbnails for Control Nav
-      controlNavThumbsFromRel:false, //Use image rel for thumbs
-		controlNavThumbsSearch: '.jpg', //Replace this with...
-		controlNavThumbsReplace: '_thumb.jpg', //...this in thumb Image src
-		keyboardNav:true, //Use left & right arrows
-		pauseOnHover:true, //Stop animation while hovering
-		manualAdvance:false, //Force manual transitions
-		captionOpacity:0.8, //Universal caption opacity
-		beforeChange: function(){},
-		afterChange: function(){},
-		slideshowEnd: function(){} //Triggers after all slides have been shown
-	});
-});
 </script>
 <style type="text/css">
 body {
-	height: 100%;
 	width: 100%;
 	margin: 0 auto;
@@ Line 240: / Line 79: @@
 	font: trebuchet, verdana, arial, times new roman;
 }
-#wrapper {
+#globalWrapper {
 	width: 100%;
 	height: 100%;
+	padding-right: 0pt;
+	padding-left: 0pt;
+	padding-bottom: 10px;
+	background-color: black;
+	background-image: url('https://static.igem.org/mediawiki/2010/d/de/Metu-bg3.jpg');
+	background-attachment: fixed;
+	background-position:center top;
+        background-repeat:no-repeat;
+	font: 13px Tahoma, Arial, Helvetica, sans-serif;
 	position: absolute;
-	top: 0;
-	left: 0;
-	background-color: #ccc;
 	overflow: hidden;
 	margin: 0 auto;
-}
+	color: white;
-div#header {
-	position: fixed;
-	top: 0;
-	left: 5%;
-	right: 5%;
-	width: 995px;
-	height: 50px;
-	background-color: #000;
-}
 }
 * html body {
 	overflow: hidden;
 }
-#mask {
+#content {
+	border-left: none;
+	border-right: none;
+	height: 100%;
 	width: 900%;
 	height: 100%;
-	background-color: #eee;
+	background-color: transparent;
+	padding: 0;
 }
 .item {
-	width: 12%;
+	width: 12.5%;
-	height: 100%;
+	height: auto;
 	float: left;
-	background-color: #ddd;
+	padding-bottom: 50px;
-	background-image: url('images/bg.jpg');
+	z-index: 10;
+	color: white;
 }
-.content {
+.content2 {
 	width: 900px;
-	height: 500px;;
+	height: 500px;
 	top: 50px;
 	margin: 0 auto;
-	background: url('images/content2.png') no-repeat;
 	position: relative;
-	font-size: .8em;
+	padding: 0;
 }
-.content .text {
+.content2 .text {
-	width: 800px;
-	margin: 0 auto;
-	padding-top: 50px;
-	text-align: justify;
-}
-.homepage {
 	width: 900px;
+	bottom: 0px;
 	height: 500px;
-	top: 50px;
 	margin: 0 auto;
-	background: url('images/home.png') no-repeat;
+	padding: 0px 30px 0px 20px;
-	position: relative;
+	text-align: justify;
+	overflow: auto;
+	background-color: black;
+	opacity: 0.85;
 }
-.selected {
+.content2 .text p span {
-	color: red;
+	font-size: 11px;
-	font-weight: 300;
+	line-height: 1em;
+	color: navy;
 }
-.clear {
+.content2 .text a{
-	clear: both;
+	color:#A4C4EB;
 }
-#slider {
+.content2 .text strong {
-	min-height: 300px;
+	font-size: 12px;
-	width: 404px;
+	color: aqua;
-	border: 4px solid #b4c8c4;
+}
-	background: #000;
+.homepage {
-	background: url(images/loading.gif) no-repeat 50% 50%;
+	width: 900px;
+	height: 365px;
 	margin: 0 auto;
-}
+	background: url('1https://static.igem.org/mediawiki/2010/1/13/Metu-home.png') no-repeat;
-#slider img {
-	position: absolute;
-	top: 0px;
-	left: 0px;
-	display: none;
-}
-#slider a {
-	border: 0;
-	display: block;
-}
-.nivoSlider {
 	position: relative;
 }
-.nivoSlider img {
+#homecontainer{
+	padding: 10px 30px 10px 20px;
+	width:800px;
+	height:300px;
 	position: absolute;
-	top: 0px;
+	bottom: 40px;
-	left: 0px;
+	left:40px;
+	text-align:justify;
+	opacity:0.85;
+background-color:#000;
 }
-.nivoSlider a.nivo-imageLink {
+#smallwrap {
-	position: absolute;
-	top: 0px;
-	left: 0px;
-	width: 100%;
-	height: 100%;
-	border: 0;
-	padding: 0;
-	margin: 0;
-	z-index: 60;
-	display: none;
-}
-.nivo-slice {
-	display: block;
-	position: absolute;
-	z-index: 50;
-	height: 100%;
-}
-.nivo-caption {
-	position: absolute;
-	left: 0px;
-	bottom: 0px;
-	background: #000;
-	color: #fff;
 	width: 880px;
-	z-index: 89;
+	margin: 0 auto;
 }
-.nivo-caption p {
+.smallbox {
+	width: 410px;
+	float: left;
 	padding: 5px;
-	margin: 0;
+	height: 350px;
+	background-color: silver;
+	margin: 10px;
+	text-align: center;
 }
-.nivo-directionNav a {
+h1, h2, h3, h4, h5 {
-	position: absolute;
+	color: white;
-	top: 45%;
-	z-index: 99;
-	cursor: pointer;
 }
-.nivo-prevNav {
+.smallbox .img {
-	left: 0px;
+	height: 105px;
+	width: 80px;
+	margin: 0 0 5px 0;
+	-moz-box-shadow: 0px 0px 10px #333;
+	-webkit-box-shadow: 0px 0px 10px #333;
+	box-shadow: 0px 0px 10px #333;
+	background: white;
 }
-.nivo-nextNav {
+.smalltext {
-	right: 0px;
+	height: 120px;
+	text-align: justify;
+	padding: 5px;
+	font-size: 11px;
+	overflow: auto;
+	color: black;
 }
-.nivo-controlNav a {
+.month {
-	position: relative;
+	width: 120px;
-	z-index: 99;
+	float: left;
-	cursor: pointer;
+	font-size: 15px;
-}
-.nivo-controlNav a.active {
 	font-weight: bold;
+	padding: 10px;
+	background-color: #fc3c3c;
+	clear: both;
 }
-/*-----------------------------------------*/
+.general {
-.nivo-controlNav {
+	width: 800px;
-	position: absolute;
-	left: 47%;
-	bottom: -30px;
-}
-.nivo-controlNav a {
-	display: none;
-	width: 10px;
-	height: 10px;
-	background: none;
-	text-indent: -9999px;
-	border: 0;
-	margin-right: 3px;
 	float: left;
+	font-size: 12px;
+	text-transform: none;
+	font-weight: normal;
+	padding: 10px;
+	background-color: orange;
+	clear: both;
 }
-.nivo-controlNav a.active {
+.week1, .week3 {
-	background-position: -10px 0;
+	width: 180px;
-}
-.nivo-directionNav a {
-	display: block;
-	width: 32px;
-	height: 34px;
-	background: url(images/arrows.png) no-repeat;
-	text-indent: -9999px;
-	border: 0;
-}
-a.nivo-nextNav {
-	background-position: -32px 0;
-	right: 10px;
-}
-a.nivo-prevNav {
-	left: 10px;
-}
-/*-----------------------------------------*/
-.nivo-controlNav {
-	position: absolute;
-	left: 47%;
-	bottom: -30px;
-}
-.nivo-controlNav a {
-	display: none;
-	width: 10px;
-	height: 10px;
-	background: none;
-	text-indent: -9999px;
-	border: 0;
-	margin-right: 3px;
 	float: left;
+	font-size: 12px;
+	padding-right: 5px;
+	font-weight: normal;
+	background-color: #1e6dd4;
+	padding: 10px;
 }
-.nivo-controlNav a.active {
+.week2, .week4 {
-	background-position: -10px 0;
+	width: 180px;
-}
-.nivo-directionNav a {
-	display: block;
-}
-.mainmenu {
-	width: 130px;
-	position: fixed;
-	height: auto;
-	top: 50px;
-	text-align: right;
 	float: left;
-	z-index: 100;
+	font-size: 12px;
-}
-.mainmenu ul {
 	padding-right: 5px;
-	float: left;
-	list-style: none;
-	line-height: 1;
-	color: #FFFF00;
-	background: #fff;
-	opacity: .7;
-}
-.mainmenu a, .mainmenu a:visited {
-	display: block;
-	width: 100px;
-	font-style: normal;
-	text-decoration: none;
-	color: #000;
-	margin-top: 5px;
-	margin-bottom: 5px;
-}
-.mainmenu li li a {
-	text-indent: 2px;
-}
-.mainmenu ul ul a {
-	width: 140px;
-	height: 100%;
-}
-.mainmenu ul a {
-	width: 140px;
-}
-.mainmenu li {
-	width: 140px;
-	margin: 0;
-	padding: 0;
-	text-indent: -20px;
-}
-.mainmenu ul li {
-	position: relative;
-	width: 100%;
-}
-.mainmenu ul li a.selected {
-	color: blue;
-}
-/* !!!!! */
-.mainmenu li ul {
-	position: absolute;
-	padding: 0px 5px 0 5px;
-	left: -999em;
-	height: auto;
-	width: 100px;
-	background: #fff;
 	font-weight: normal;
-	text-align: left;
+	background-color: #3fff72;
+	padding: 10px;
 }
-.mainmenu li li {
+.lower {
-	width: 100%;
+	width: 800px;
+	clear: both;
 }
-.mainmenu li a {
+#notebook2 {
-	width: 90px;
+	width: 900px;
+	color: black;
+	margin: 0 auto 20 auto;
 }
-.mainmenu li li a {
+#week {
-	width: 100%;
+	font-size: 14px;
+	font-weight: bold;
 }
-.mainmenu li ul {
+#sponsorlist li{float:left; text-decoration:none; margin:20px;}
-	margin: -55px 0 0 0px;
+.black {
+	color: black;
 }
-.ul_ch, .mainmenu li:hover ul ul, .mainmenu li li:hover ul ul, .mainmenu li li li:hover ul ul, .mainmenu li li li li:hover ul ul, .mainmenu li li li li li:hover ul ul {
+.selected {
-	left: -999em;
-}
-.mainmenu li:hover ul, .mainmenu li li:hover ul, .mainmenu li li li:hover ul, .mainmenu li li li li:hover ul, .mainmenu li li li li li:hover ul {
-	left: 100%; /* !!! */
-}
-.mainmenu li:hover > ul.ul_ch {
-	left: 100%; /* !!! */
-}
-.mainmenu li:hover a, .mainmenu li:hover a:visited, .mainmenu li:hover a:hover, .mainmenu li a:hover {
 	color: red;
+	font-weight: 300;
 }
-.mainmenu li:hover li a, .mainmenu li li:hover li a, .mainmenu li li li:hover li a, .mainmenu li li li li:hover li a, .mainmenu li:hover li a:visited, .mainmenu li li:hover li a:visited, .mainmenu li li li:hover li a:visited, .mainmenu li li li li:hover li a:visited {
+.clear {
-	color: #000;
+	clear: both;
 }
-.mainmenu ul ul a:hover, .mainmenu li:hover li:hover a, .mainmenu li:hover li:hover a:visited, .mainmenu li:hover li:hover li:hover a, .mainmenu li:hover li:hover li:hover a:visited, .mainmenu li:hover li:hover li:hover li:hover a, .mainmenu li:hover li:hover li:hover li:hover a:visited, .mainmenu li:hover li:hover li:hover li:hover li:hover a, .mainmenu li:hover li:hover li:hover li:hover li:hover a:visited, .mainmenu li:hover li:hover li:hover li:hover li:hover li:hover a, .mainmenu li:hover li:hover li:hover li:hover li:hover li:hover a:visited {
+#contentSub {
-	color: red;
+	display: none;
 }
-/*-------------------final----------------------------*/
+#siteSub {
-#menu {
+	display: none;
-	text-align: left;
-	position:fixed;
-	top:50px;
-	height:auto;
-	width:auto;
-	z-index:999;
-	height:500px;
 }
-#menu ul li a.selected{
+#search-controls {
-	color:red;
+	display: none;
-	background:silver;
 }
-/*Toggle Area*/
+.firstHeading {
-#menu .toggle {
+	display: none;
-	float: right;
-	width: 9px;
-	padding: 5px;
-	cursor: pointer;
-	border-top: 1px solid white;
-	border-left: 1px solid #E0E0E0;
-	color: #999;
 }
-#menu ul.navmenu li:first-child .toggle {
+#search-controls {
-	border-width: 0 0 0 1px;
+	margin-top: 30px;
 }
-/*Menu Setup*/
+#footer-box {
-#menu ul {
+	display: none;
-	padding: 0;
-	margin: 0;
-	width: 150px;
 }
-#menu ul ul {
+#top-section {
-	border: 1px solid #CCC;
+	height: 25px;
-	overflow: hidden;
+	width: 100%;
+	position: fixed;
+	border-left: none;
+	border-right: none;
 }
-#menu ul.navmenu li {
+.left-menu {
-	margin: 0;
+	margin-top: -15px;
-	list-style: none;
-	float: left;
 }
-#menu ul.navmenu li li {
+.left-menu ul {
-	float: none;
+	border: none;
 }
-/*Links*/
+#menubar li a {
-#menu ul.navmenu a, #menu ul.navmenu a:visited {
+	color: white;
-	text-decoration: none;
-	padding: 5px;
-	display: block;
-	color: #008FDD;
 }
-#menu ul.navmenu ul.submenu a:hover {
+#menubar.right-menu {
-	background: #FFF4D2;
+	margin-top: -15px;
-	color: #333;
 }
-/*Heading Outer div*/
+.right-menu ul {
-#menu ul.navmenu .menutop {
+	border: none;
-	border: 1px solid #CCC;
-	border-width: 0 1px;
-	overflow: hidden;
-	width: 150px;
-	background: #F9F9F9;
 }
-/*Header Links*/
+#menubar {
-#menu ul.navmenu .menutop a {
+	top: 22px;
-	width: 120px;
+	z-index: 25;
-	float: left;
-	margin: 0 0 1px 0;
-	border-top: 1px solid white;
 }
-/*Header Link Hover*/
+#metutop {
-#menu ul.navmenu .menutop a:hover {
+	width: 350;
-	color: #333;
+	height: 90px;
+	position: fixed;
+	top: 0;
+	background: transparent url(https://static.igem.org/mediawiki/2010/9/94/Metu-igem.png) top left no-repeat;
+	z-index: 20;
 }
-/*Removes white border for the first header*/
+#introvideo {width:480px; length:360px; margin:20px auto; margin-bottom:0;}
-#menu ul.navmenu li:first-child .menutop a {
+#home {overflow:auto;}
-	border-width: 0px;
+img[src*="/wiki/skins/common/images/wiki.png"] {
+	width: 0;
+	height: 40px;
 }
-/*Single Menu Width Fix*/
+</style>
-#menu ul.navmenu .menusingle a {
-	width: 140px;
-}
-/*Border Radius and Special Border Width*/
-#menu ul.navmenu li:first-child .menutop {
-	border-width: 1px 1px 0 1px;
-	-moz-border-radius: 5px 5px 0 0;
-	-webkit-border-top-left-radius: 5px;
-	-webkit-border-top-right-radius: 5px;
-}
-#menu ul.navmenu li:last-child .menutop {
-	border-width: 0px 1px 1px 1px;
-	-moz-border-radius: 0 0 5px 5px;
-	-webkit-border-bottom-left-radius: 5px;
-	-webkit-border-bottom-right-radius: 5px;
-}
-#menu ul.navmenu li:last-child ul.submenu {
-	-moz-border-radius: 0 0 5px 5px;
-	-webkit-border-bottom-left-radius: 5px;
-	-webkit-border-bottom-right-radius: 5px;
-}
-#menu ul.navmenu li:last-child .menutop-open {
-	-moz-border-radius: 0;
-	-webkit-border-radius: 0px;
-	border-width: 0 1px;
-}
-</style>
 </head>
-<script type="text/javascript">
-$(document).ready(function() {
-	$('.toggle:not(.toggle-open)') .addClass('toggle-closed') .parents('li') .children('ul') .hide();
-	if($.browser.msie){
-		$('#menu ul.navmenu li:last-child .menutop') .css('border-bottom','1px solid #CCC');
-	}
-	$('.toggle') .click(function(){
-		if ($(this) .hasClass('toggle-open')) {
-			$(this) .removeClass('toggle-open') .addClass('toggle-closed') .empty('') .append('+') .parents('li') .children('ul') .slideUp(250);
-			$(this) .parent('.menutop') .removeClass('menutop-open') .addClass('menutop-closed');
-		}else{
-			$(this) .parent('.menutop') .removeClass('menutop-closed') .addClass('menutop-open');
-			$(this) .removeClass('toggle-closed') .addClass('toggle-open') .empty('') .append('&ndash;') .parents('li') .children('ul') .slideDown(250);
-		}
-								 })
-							})
-$(this) .removeClass('toggle-open') .addClass('toggle-closed') .empty('') .append('+') .parents('li') .children('ul') .slideUp(250);
-</script>
 <body>
-<div id="wrapper">
+<div id="metutop">
-	<div id="menu">
+</div>
-		<ul class="navmenu">
+<div id="home" class="item">
-			<li><div class="menutop menusingle"><a class="panel" href="#home">Home</a></div></li>
+	<div id="introvideo">
-			<li><div class="menutop menusingle panel"><a class="panel" href="#team">Team</a></div></li>
+<embed width="480" height="360" quality="high" bgcolor="#000000" name="main" id="main" allowfullscreen="true" allowscriptaccess="always" src="http://www.dnatube.com/nvlab/player/player.swf?config=http://www.dnatube.com/nvlab/econfig.php?key=ddbdf3eff0f505975b6a" type="application/x-shockwave-flash" /></div><div class="homepage">
-            <li><div class="menutop menusingle panel"><a class="panel" href="#motivation">Motivation</a></div></li>
+	<div id="homecontainer"><h3>Abstract</h3>
- 			<li><div class="menutop menusingle panel"><a class="panel" href="#scope">Scope</a></div></li>
+	<p>As Synthetic Biology field is on the rise, iGEM also grows up and number of parts in parts registry increase with submission of more complex constructs each year. Our first milestone was to perform more efficient standardization on parts entry due to facing some difficulty while running our algorithms on the parts registry. We also used Software Requirements Specification, Software Design Description and Quality Plan approaches to define requirements for each part and building blocks, risks and design art elements of the designed software program.</p>
-			<li><div class="menutop"><a class="panel" href="#project">Project</a><div class="toggle">+</div></div>
+	<p>Next, we have used graph theoretic modeling to visualize relations between parts and to standardize representation of the parts as much as possible. It will help us when we try to find input-output relations between either biobrick parts or constructs. By this way, our program BIOGUIDE will act as a guide for searhing biobricks and will provide alternative pathway choices to users for construction of the most reliable devices with respect to given inputs and expected outputs.</p>
-            	<ul class="submenu">
-                	<li><a class="panel" href="#project">Introduction</a></li>
-                    <li><a class="panel" href="#project2">Material and Methods</a></li>
-                    <li><a class="panel" href="#project3">Database Standardization</a></li>
-                    <li><a class="panel" href="#project4">Modelling</a></li>
-                    <li><a class="panel" href="#project5">Algorithm</a></li>
-                    <li><a class="panel" href="#project6">Results</a></li>
-                </ul>
-            </li>
-            <li><div class="menutop menusingle panel"><a class="panel" href="#notebook">Notebook</a></div></li>
-            <li><div class="menutop panel"><a class="panel" href="#download">Download</a><div class="toggle">+</div></div>
-            	<ul class="submenu">
-                	<li><a class="panel" href="#download">Executable</a></li>
-                    <li><a class="panel" href="#download2">Code</a></li>
-                	<li><a class="panel" href="#download3">User Guide</a></li>
-                	<li><a class="panel" href="#download4">Support</a></li>
-                	<li><a class="panel" href="#download5">Contact</a></li>
-                </ul>
-            </li>
-             <li><div class="menutop panel"><a class="panel" href="#miscellaneous">Miscellaneous</a><div class="toggle">+</div></div>
-            	<ul class="submenu">
-                	<li><a class="panel" href="#miscellaneous">Collaboration</a></li>
-                    <li><a class="panel" href="#miscellaneous2">Human Practices</a></li>
-                	<li><a class="panel" href="#miscellaneous3">Safety</a></li>
-                	<li><a class="panel" href="#miscellaneous4">Future Plan</a></li>
-                </ul>
-            </li>
-			</ul>
 	</div>
-	<div id="mask">
+	</div>
+</div>
-		<!-- 1st row -->
+<div id="team" class="item">
-		<div id="home" class="item"><div class="homepage"></div></div>
+	<div class="content2">
-		<div id="team" class="item">
+		<div class="text">
-			<div class="content">Team
+			<h2>Team</h2>
-			<div class="text">
 			<div id="slider">
-					<img src="images/slide1.jpg" alt="">
+				<img alt="" src="https://static.igem.org/mediawiki/2010/f/f3/Metu-team1.jpg">
-					<img src="images/slide2.jpg" alt="">
+				<img alt="" src="https://static.igem.org/mediawiki/2010/d/d4/Metu-team2.jpg">
-					<img src="images/slide3.jpg" alt="">
+				<img alt="" src="https://static.igem.org/mediawiki/2010/3/34/Metu-team3.jpg">
+				<img alt="" src="https://static.igem.org/mediawiki/2010/d/d8/Metu-team4.jpg">
+				<img alt="" src="https://static.igem.org/mediawiki/2010/0/03/Metu-team5.jpg">
+				<img alt="" src="https://static.igem.org/mediawiki/2010/b/be/Metu-team6.jpg">
 			</div>
+			<p>METU Turkey Software is an interdisciplinary team of 7 students and
-			<p>
+advisors from various backgrounds such as Molecular Biology, Bioinformatics,
-			METU Turkey Software is an interdisciplinary team of 8 students and 3 advisors
-			from various backgrounds such as Molecular Biology, Bioinformatics,
 			Computer Engineering and Computer Education and Instructional Technology.
-			We have put our knowledge and experience in our fields together to bring a much
+			We have put our knowledge and experience in our fields together to bring
-			needed solution to a daily problem in field of synthetic biology for iGEM 2010
+			a much needed solution to a daily problem in field of synthetic biology
-			</p>
+			for iGEM 2010</p>
+			<div id="smallwrap">
 			</div>
+			<div class="smallbox">
+				<h2 class="black">Tolga Can</h2>
+				<img src="https://static.igem.org/mediawiki/2010/c/c3/Metu-tolgahoca.jpg">
+				<div class="smalltext">
+					<p>Tolga Can received his PhD in Computer Science at the University
+					of California at Santa Barbara in 2004. He is currently an Assistant
+					Professor of the Department of Computer Engineering, Middle
+					East Technical University, Ankara, Turkey. His main research
+					interests are in bioinformatics, especially prediction and analysis
+					of protein-protein interaction networks, and statistical methods
+					such as graphical models and kernel methods.</p>
+				</div>
+			</div>
+			<div class="smallbox">
+				<h2 class="black">Yeşim Aydın-Son</h2>
+				<img src="https://static.igem.org/mediawiki/2010/d/d5/Metu-yesimhoca.jpg">
+				<div class="smalltext">
+					<p>Yeşim, has received her M.D in 1999 from HÜTF, Ankara and
+					completed her Ph.D at University of TN, Knoxville on Genome
+					Science and Technology in 2006. After working as a research
+					fellow at City of Hope National Medical Center, Duarte,CA ,
+					she has recently accepted her current position at METU Informatics
+					Institute as an Assistant Professor of Medical Informatics.
+					She is also the acting coordinator of the Bioinformatics Graduate
+					Program in METU. Main focus of her research is Genomic Biomarker
+					discovery and applications of biomarker research in Personalized
+					Medicine . Her research group is working on building a new integrated
+					application for genome wide association of SNP biomarkers and
+					discovery of genes and pathways related to diseases, where SNP
+					genotyping data from both microarray and next generation sequencing
+					experiments can be analyzed in all-in-one step. </p>
+				</div>
+			</div>
+			<div class="smallbox">
+				<h2 class="black">Ömer Nebil Yaveroğlu</h2>
+				<img src="https://static.igem.org/mediawiki/2010/5/53/Metu-omerhoca.jpg">
+				<div class="smalltext">
+					<p>Ömer Nebil Yaveroğlu is currently a PhD Student in Imperial
+					College, London. He has worked as a teaching assistant between
+– 2010 in the Computer Engineering Department of Middle
+					East Turkey. Throughout his MSc studies, he tried to understand
+					the orthological similarities between the protein interaction
+					networks of different species using graph theory. He helped
+					the group as an advisor in the computing related discussions</p>
+				</div>
+			</div>
+			<div class="smallbox">
+				<h2 class="black">Burak Yılmaz</h2>
+				<img src="https://static.igem.org/mediawiki/2010/a/a2/Metu-burak.jpg">
+				<div class="smalltext">
+					<p>I am a recent graduate of METU Molecular Biology and Genetics
+					department and now studying towards my masters degree on Molecular
+					Bioengineering at METU. My interest in synthetic biology did
+					start during my undergraduate years and after graduation I started
+					up the Sentegen company which is the first biotechnology based
+					company focused on synthetic biology in Turkey. I continue my
+					research and training in synthetic biology while also contributing
+					to the development of the field in my country. We need new scientific
+					revolutions to solve huge problems of life and emerging field
+					of synthetic biology is best candidate for biotechnological
+					revolution. I am interested in synthetic biology applications,
+					along with Lab-on-a-Chip devices for molecular biology techniques,
+					and we are designing gene synthesis chips to produce biobricks
+					- raw materials of synthetic garage biology- faster and cheaper.
+					I enjoy snowboarding, cycling and write poems.</p>
+				</div>
+			</div>
+			<div class="clear">
+			</div>
+			<div class="smallbox" style="margin: 0 auto; float: none">
+				<h2 class="black">Muhammed Akif Ağca</h2>
+				<img src="https://static.igem.org/mediawiki/2010/1/10/Metu-akif2.jpg">
+				<div class="smalltext">
+					<p>In bachelor he has worked on Software Development, Database Management,  Instructional Technologies, and Bioinformatics. He was developing the software and leading the team.
+A new page to his life is starting at 2011 after becoming a graduate of Computer Education and Instructional Technologies. He says that " If we can use technology and science efficiently we can solve too many problems in the world, but if can use. That is if we can manage those we can solve the problems and organize the world with minimum problems " which is a study field Science Technology and Management ( STM )  which is the field he will start to work in 2011 ".</p>
+				</div>
+			</div>
+			<div class="clear">
+			</div>
+			<div class="smallbox">
+				<h2 class="black">Cihan Taştan</h2>
+				<img src="https://static.igem.org/mediawiki/2010/d/d8/Metu-cihan.jpg">
+				<div class="smalltext">
+					<p>2010 is the last year for me as B.S degree at Molecular Biology
+					and Genetics department. Moreover, I am studying at Computer
+					Engineering as my minor department. My research will be on Scientist
+					position at Cancer and Virology Relationship (Let&#39;s say Viral
+					Oncology) by integrating novel technices of Bioinformatics and
+					Synthetic Biology approaches. This is my second year at iGEM.</p>
+				</div>
+			</div>
+			<div class="smallbox">
+				<h2 class="black">Hassan Salehe Matar</h2>
+				<img src="https://static.igem.org/mediawiki/2010/3/3c/Metu-hassan.jpg">
+				<div class="smalltext">
+					<p>Ascended up the hills of Kilimanjaro, crossed over the savannah
+					of Serengeti and finally landed on the country of Istanbul my
+					name is Hassan Salehe. I&#39;m a final year undergraduate student
+					at the Department of Computer Engineering, Middle East Technical
+					University. In Metu Turkey Software I&#39;m a database administrator
+					and a core Software developer. I&#39;m interested in software development,
+					database management, Computer networks and Bioiformatics I do
+					marathon, I like swimming and I&#39;m fond of action movies.Oh,
+					I was about to forget to tell you that I also like traveling.
+					Thanks!</p>
+				</div>
+			</div>
+			<div class="smallbox">
+				<h2 class="black">Ayub Rokhman Wakhid</h2>
+				<img src="https://static.igem.org/mediawiki/2010/9/92/Metu-ayub.jpg">
+				<div class="smalltext">
+					<p>From the country of thousand islands, across the ocean he
+					came to Ankara. Now he is finishing his undergraduate study
+					at the Department of Computer Education and Instructional Technology,
+					Middle East Technical University. This is the first time he
+					joined IGEM. He is in design team in Metu Turkey Software. He
+					has interest in animation, web development, and instructional
+					technologies.</p>
+				</div>
+			</div>
+			<div class="smallbox">
+				<h2 class="black">Muhammad Fakhry Syauqy</h2>
+				<img src="https://static.igem.org/mediawiki/2010/f/fd/Metu-fakhry.jpg">
+				<div class="smalltext">
+					<p>A senior undergraduate student of Computer Education and
+					Instructional Technology at Middle East Technical University.
+					He came far away from Indonesia to Ankara, Turkey, to make a
+					great leap on his life. His role in this team is designer. Together
+					with Ayub, they designs the team&#39;s wiki, poster. He is interested
+					in 2D and 3D designing, web developing and animation. He loves
+					playing football and working with computer. His motto is &quot;Possibilities
+					are limitless&quot; </p>
+				</div>
+			</div>
+			<div class="smallbox">
+				<h2 class="black">Saygın Karaaslan</h2>
+				<img src="https://static.igem.org/mediawiki/2010/6/6f/Metu-saygin.jpg">
+				<div class="smalltext">
+					<p>Our multimedia support and the core of our design and animation
+					team. Saygın, is a senior in Biology department at METU and
+					about to launch his own scientific animation company. After
+					graduation he will be continuing his academic studies on medical
+					informatics, scientific data visualization and 3D molecular
+					animations. He has recently completed the production of OCW
+					for molecular biology laboratory lectures as video-notes. Never
+					says no to a good soccer game or mafia II. We look forward for
+					the day for the premier of his documentary on &quot;History of Science&quot;</p>
+				</div>
+			</div>
+			<div class="smallbox">
+				<h2 class="black">Yener Tuncel</h2>
+				<img src="https://static.igem.org/mediawiki/2010/d/dd/Metu-yener.jpg">
+				<div class="smalltext">
+					<p>I have graduated from METU Molecular Biology and Genetics
+					department and just started the Bioinformatics Graduate Program
+					this fall. My main research interests is in systems biology,
+					and its applications. Currently I am focused on genome wide
+					association of SNP biomarkers, where we will utilize systems
+					biology approaches for discovering disease gene and pathway
+					associations after highthrough-put genotyping studies. During
+					the course of our research on the iGEM project this summer as
+					a Molecular Biologist I worked on the standardization of the
+					parts information for our applicaiton database. Also, as a Bioinformatician
+					in training, contributed to the development of the algorithms
+					for the BioGuide software. Besides research, I develop educational
+					tools for biology and bioinformatics education and getting used
+					to do couples dancing. </p>
+				</div>
 			</div>
 		</div>
-		<div id="motivation" class="item"><div class="content">
+	</div>
+</div>
+<div id="motivation" class="item">
+	<div class="content2">
 		<div class="text">
-		Motivation
+			<h2>Motivation</h2>
-		<p>
+			<p>Since 2008, we have been participating in iGEM as METU ( Middle East
-		Since 2008, we have been participating in iGEM as METU ( Middle East Technical University)
+			Technical University) wet-lab team, and each year we have noticed the
-		wet-lab team, and each year we have noticed the increasing number of teams participating,
+			increasing number of teams participating, along with an increase in
-		along with an increase in biobricks entries at partsregistry.org. While having more choices
+			biobricks entries at <a href="http://www.partregistry.org">partregistry.org</a>.
-		of biobricks to choose from is incredible, searching for and choosing the appropriate parts
+			While having more choices of biobricks to choose from is incredible,
-		is becoming a challenge. This year during the construction process of iGEM biobrick parts for
+			searching for and choosing the appropriate parts is becoming a challenge.
-		our new project, we felt the need for an application to find interacting parts based on an
+			This year during the construction process of iGEM biobrick parts for
-		input/output model to design the genetic constructs. Using a specialized software for searching
+			our new project, we felt the need for an application to find interacting
-		the parts registry to find possible biobricks to include into our construct would be much easy,
+			parts based on an input/output model to design the genetic constructs.
-		fast and accurate than manual. We have shared our need with a group of friends who are software
+			Using a specialized software for searching the parts registry to find
-		engineers, and initiated the METU_Turkey_SOFTWARE team where we worked together over this summer
+			possible biobricks to include into our construct would be much easy,
-		to build the BIO-Guide software.
+			fast and accurate than manual. We have shared our need with a group
-		</p>
+			of friends who are software engineers, and initiated the METU_Turkey_SOFTWARE
-		</div></div></div>
+			team where we worked together over this summer to build the BIO-Guide
-		<div id="scope" class="item"><div class="content">
+			software.</p>
+		</div>
+	</div>
+</div>
+<div id="scope" class="item">
+	<div class="content2">
 		<div class="text">
-		Scope and Future Aspects
+			<h2>Scope and Future Aspects</h2>
-		<p>
+			<p>The <a href="http://www.partregistry.org">partregistry.org</a> is
-		The partsregistry.org is a continuously growing collection of standard genetic parts that
+			a continuously growing collection of standard genetic parts that can
-		can be mixed and matched to build synthetic biology devices and systems. The Registry is
+			be mixed and matched to build synthetic biology devices and systems.
-		based on the principle of "get some, give some". Registry users benefit from using the parts
+			The Registry is based on the principle of &quot;get some, give some&quot;. Registry
-		and information available in the Registry for designing their own genetically engineered
+			users benefit from using the parts and information available in the
-		biological systems. In exchange, the expectation is that Registry users will contribute back to
+			Registry for designing their own genetically engineered biological systems.
-		the information and the data on existing parts and will submit new parts they have designed in
+			In exchange, the expectation is that Registry users will contribute
-		order to improve this community resource.
+			back to the information and the data on existing parts and will submit
-		</p>
+			new parts they have designed in order to improve this community resource.
+			</p>
-		<p>
+			<p>As an expanding database <a href="http://www.partregistry.org">partregistry.org</a>
-		As an expanding database partsregistry.org needs to be more organized and the standardization
+			needs to be more organized and the standardization template needs to
-		template needs to be improved. Additionally, the potential of multiple ways of using each part
+			be improved. Additionally, the potential of multiple ways of using each
-		in different construct combination brings out the necessity for an application to search through
+			part in different construct combination brings out the necessity for
-		the database. BIO-Guide is the first designed software that organizes over 1000 parts in partsregistry.org
+			an application to search through the database. BioGuide is the first
-		as possible atomics parts to build new biological device and systems for specific input and outputs based on
+			designed software that organizes over 1000 parts in
-		graph theory. The requirement of similar applications and software tools are now inevitable in the emerging
+			<a href="http://www.partregistry.org">partregistry.org</a> as possible
-		field of synthetic biology. The innovative approach that makes the partsregistry.org  easy to use for synthetic
+			atomics parts to build new biological device and systems for specific
-		biology applications is the collection of standardized parts that can be used in any combination with minimal
+			input and outputs based on graph theory. The requirement of similar
-		effort under one database. But while working on our algorithm to search for possible combinations of parts depending
+			applications and software tools are now inevitable in the emerging field
-		on the given input and output, we have realized that present standards are inadequate and parts registry form must be improved.
+			of synthetic biology. The innovative approach that makes the
-		</p>
+			<a href="http://www.partregistry.org">partregistry.org</a> easy to use
+			for synthetic biology applications is the collection of standardized
-		<p>
+			parts that can be used in any combination with minimal effort under
-		In very near future a new format for parts registry form is needed and few additional features
+			one database. But while working on our algorithm to search for possible
-		should be implemented to have more control on the database. We are planning to suggest a new format
+			combinations of parts depending on the given input and output, we have
-		and features for the parts registry based on the survey results we have received. And planning to
+			realized that present standards are inadequate and parts registry form
-		build the next version of BIO-guide based on the revised parts registry form. Along with using new parts
+			must be improved. </p>
-		registry standards we will be improving the algorithm, so that the software can search through more
+			<p>In very near future a new format for parts registry form is needed
-		complex relations and returns all possible functional constructs.
+			and few additional features should be implemented to have more control
-		</p>
+			on the database. We are planning to suggest a new format and features
+			for the parts registry based on the survey results we have received.
+			And planning to build the next version of Bioguide based on the revised
+			parts registry form. Along with using new parts registry standards we
+			will be improving the algorithm, so that the software can search through
+			more complex relations and returns all possible functional constructs.
+			</p>
 		</div>
-		</div></div>
+	</div>
-		<div id="project" class="item"><div class="content">Project Introduction
+</div>
-			<div class="text">
+<div id="project" class="item">
-			<p>As the field of Synthetic Biology is on the rise, iGEM is growing up very fast and the
+	<div class="content2">
-			number of parts in the parts registry is increasing with the addition of more complex parts each day.
+		<div class="text">
-			After facing some difficulty while running our algorithms on the parts registry, the need for more effective
+			<h2>Project Introduction</h2>
-			standardization of parts entry was apparent. We have investigated the information on parts in iGEM’s 2010 distribution
+			<p>As the field of Synthetic Biology is on the rise, iGEM is growing
-			and reorganized the information on the parts registry forms according to the needs of our algorithm.
+			up very fast and the number of parts in the parts registry is increasing
-			Then we have used graph theoretic modeling to visualize the relations between iGEM Parts and to standardize
+			with the addition of more complex parts each day. After facing some
-			the representation of the parts as much as possible by graph theoretical methods. This helped us to find input
+			difficulty while running our algorithms on the parts registry, the need
-			output relations between the parts. Furthermore, our program BIO-Guide is now able to provide alternative pathways
+			for more effective standardization of parts entry was apparent. We have
-			to construct the most reliable and functional Biobrick devices with respect to given inputs and expected outputs as
+			investigated the information on parts in iGEM’s 2010 distribution and
-			a guide to Biobricks parts registry.</p>
+			reorganized the information on the parts registry forms according to
+			the needs of our algorithm. Then we have used graph theoretic modeling
+			to visualize the relations between iGEM Parts and to standardize the
+			representation of the parts as much as possible by graph theoretical
+			methods. This helped us to find input output relations between the parts.
+			Furthermore, our program BioGuide is now able to provide alternative
+			pathways to construct the most reliable and functional Biobrick devices
+			with respect to given inputs and expected outputs as a guide to Biobricks
+			parts registry.</p>
+		</div>
+	</div>
+</div>
+<div id="notebook" class="item">
+	<div class="content2">
+		<div class="text">
+			<h2>Notebook</h2>
+			<div id="notebook2">
+				<div class="month">
+					January</div>
+				<div class="general">
+					<p>Brain Storming about the iGEM. </p>
+					<ul>
+						<li>What is iGEM.</li>
+						<li>Previous Wet-Lab Projects developed at METU.</li>
+						<li>What kind of projects can be developed as a software
+						team.</li>
+					</ul>
+					<p>NOTE: The first software team in Turkey...</p>
+				</div>
+				<div class="month">
+					February</div>
+				<div class="general">
+					<ul>
+						<li>Reading articles about iGEM WetLab and Software team
+						projects.</li>
+						<li>Looking for the members of the team.</li>
+						<li>Looking for the instructors who can consult the team.
+						</li>
+					</ul>
+				</div>
+				<div class="month">
+					March</div>
+				<div class="general">
+					<ul>
+						<li>Employing a member to team interested in Synthetic Biology.</li>
+						<li>Reading articles about Synthetic Biology, Bioinformatics
+						and Bio Engineering.</li>
+						<li>Founding the team [ An instructor, and student members
+						]</li>
+					</ul>
+				</div>
+				<div class="month">
+					April</div>
+				<div class="general">
+					At this month we have started regular workshop about Synthetic
+					Biology, Bioengineering, and Bioinformatics.
+					<ul>
+						<li>This month biologists in the team telling the needed
+						basics to software group.</li>
+					</ul>
+				</div>
+				<div class="lower">
+					<div class="week1" style="height: 150px;">
+						<div id="week">
+							Week 1</div>
+						<p>Workshop -1</p>
+						<p>[Biology basics, What is Synthetic Biology?, and the
+						works in this field ]</p>
+					</div>
+					<div class="week2" style="height: 150px;">
+						<div id="week">
+							Week 2</div>
+						<p>Workshop -2</p>
+						<p>[What is Synthetic Biology?, and the works in this field
+						]</p>
+					</div>
+					<div class="week3" style="height: 150px;">
+						<div id="week">
+							Week 3</div>
+						<p>Workshop -3</p>
+						<p>[iGEM, Parts, Biobricks, and Devices ]</p>
+					</div>
+					<div class="week4" style="height: 150px;">
+						<div id="week">
+							Week 4</div>
+						<p>Workshop – 4</p>
+						<p>[iGEM, Parts, Biobricks, and Devices ]</p>
+					</div>
+				</div>
+				<div class="month">
+					May</div>
+				<div class="general">
+					At this month we have completed our workshops, and as the masters
+					in this field started meeting with instructors. /
+					<ul>
+						<li>Meanwhile, looking for sponsors [We have designed a
+						document telling the iGEM, previous project and our project
+						generally and started to send it private companies who can
+						found us.] </li>
+						<li>This month it is turn to software group; they are transferring
+						the basics of software concepts to biologists in the team.
+						</li>
+						<li>Furthermore, we are discussing about how we can apply
+						the basics of computer engineering to synthetic biology
+						and iGEM parts. </li>
+					</ul>
+				</div>
+				<div class="lower">
+					<div class="week1" style="height: 180px;">
+						<div id="week">
+							Week 1</div>
+						<p>Meeting -1</p>
+						<p>[First, discussion on articles that have been selected
+						by consulters. Then, brain storming about the selected iGEM
+						projects from previous years and our project ]</p>
+					</div>
+					<div class="week2" style="height: 180px;">
+						<div id="week">
+							Week 2</div>
+						<p>Meeting -2[with consulters ]</p>
+						<p>[Tellingtheprevious projects to consulters and telling
+						our initial idea about project. Then, brainstorming about
+						our project. ]</p>
+					</div>
+					<div class="week3" style="height: 180px;">
+						<div id="week">
+							Week 3</div>
+						<p>Meeting -3</p>
+						<p>[Basic databaseconcepts and iGEM parts. ]</p>
+					</div>
+					<div class="week4" style="height: 180px;">
+						<div id="week">
+							Week 4</div>
+						<p>Meeting -4</p>
+						<p>[What is ER Diagram and How we can develop a database
+						model for iGEM parts with ER Model. ]</p>
+					</div>
+				</div>
+				<div class="month">
+					June</div>
+				<div class="general">
+					<p>At this month software group is going on to tell the basics
+					of software development and programming and computer engineering,
+					discussions about the computer engineering approaches are continuing.</p>
+					<ul>
+						<li>Furthermore, we have constructed the design group for
+						web page, poster, presentation, and an attractive animation
+						telling us.</li>
+					</ul>
+				</div>
+				<div class="lower">
+					<div class="week1" style="height: 250px;">
+						<div id="week">
+							Week 1</div>
+						<p>Meeting – 5</p>
+						<p>[Graph theory, Graph theoretic modeling, and graphical
+						modeling of iGEM parts. Using Input Output loops on iGEM
+						parts. ]</p>
+					</div>
+					<div class="week2" style="height: 250px;">
+						<div id="week">
+							Week 2</div>
+						<p>Meeting – 6 [ With Consulters ]</p>
+						<ul>
+							<li>Project Description. </li>
+							<li>Our tasks on holiday.</li>
+							<li>Telling our project and basic concepts to design
+							team.</li>
+							<li>Discussion on storyboard for animation.</li>
+						</ul>
+					</div>
+					<div style="height: 250px; background-color: #1e6dd4; padding: 10px;">
+						<div id="week">
+							Week 3 and Week 4</div>
+						<p align="center">HAVE a NICE HOLIDAY</p>
+						<p align="center">SEE YOU ON JULY 1 as a POWERFUL TEAM;
+						<em>“METU TURKEY SOFTWARE”</em>.</p>
+					</div>
+				</div>
+				<div class="month">
+					July</div>
+				<div class="general">
+					<p>At this month we have started to develop application. And
+					divided the team to 3 groups [ Software - Gene – Design ].</p>
+					<ul>
+						<li>Gene group is providing row data to software group by
+						extracting it from the part registery and other resources.</li>
+						<li>Software group is developing application.</li>
+						<li>Designers are learning new design tools, and applying
+						those to our project [Not all Members of the group working
+						actively for the team].</li>
+					</ul>
+					<p><u>NOTE: Members are not strictly assigned to a group; this
+					is just for organization of tasks.</u></p>
+				</div>
+				<div class="lower">
+					<div class="week1" style="height: 600px;">
+						<div id="week">
+							Week 1</div>
+						<p>Meeting-7</p>
+						<ul>
+							<li>Take stock for current situation.</li>
+							<li>Discussion on web, poster, animation design.</li>
+							<li>Discussion on storyboard for animation.</li>
+							<li>Task analyses for each group [ Software, Gene, Design
+							].</li>
+						</ul>
+					</div>
+					<div class="week2" style="height: 600px;">
+						<div id="week">
+							Week 2</div>
+						<p>Meeting – 8</p>
+						<p>Checking the tasks of each group. </p>
+						<p>· Software Group</p>
+						<ul>
+							<li>Database Design</li>
+							<li>Interface for DB.</li>
+							<li>Designing a basic SRS and SDD to be able to state
+							the requirements of application exactly .</li>
+						</ul>
+						<p>· Gene Group</p>
+						<ul>
+							<li>Extracting I/O information for each part in part
+							registry according to specified standards by Gene group.</li>
+							<li>Discussion about expectation from the software.
+							</li>
+						</ul>
+						<p>· Design Group</p>
+						<ul>
+							<li>Team Logo</li>
+							<li>Web site</li>
+							<li>Poster</li>
+							<li>Animation</li>
+							<li>Presentation</li>
+						</ul>
+					</div>
+					<div style="height: 600px; background-color: #1e6dd4; padding: 10px">
+						<div id="week">
+							Week 3 and Week 4
+							<p>DOING THE TASKS.</p>
+						</div>
+					</div>
+				</div>
+				<div class="month">
+					August</div>
+				<div class="general">
+					<p>At this month we have started to apply graph theory on iGEM
+					parts. We have specified nodes, edges, graph types. Furthermore,
+					we have started to develop a new “ Part Registery Form ” to
+					be able to more standardize the part entry to be able to apply
+					some algorithms on the parts more efficiently.</p>
+				</div>
+				<div class="lower">
+					<div class="week1" style="height: 350px;">
+						<div id="week">
+							Week 1</div>
+						<p>Meeting -8</p>
+						<p>/ </p>
+						<ul>
+							<li>Node data extraction algorithm.</li>
+							<li>Node description. </li>
+							<li>Visualization of nodes.</li>
+							<li>Pathway finding according to specified I/O properties.</li>
+							<li>Representing the nodes with original images.</li>
+						</ul>
+					</div>
+					<div class="week2" style="height: 350px;">
+						<div id="week">
+							Week 2</div>
+						<p>Meeting -9</p>
+						<ul>
+							<li>Whichone is node part or subparts or both are nodes
+							in different graphs?</li>
+							<li>Part Combination rules.</li>
+							<li>Web site, Poster Content</li>
+							<li>Animation storyboard. </li>
+							<li>Survey for new “Part Registery Standarts”.</li>
+							<li>NewPart Registery Form.</li>
+						</ul>
+					</div>
+					<div class="week3" style="height: 350px;">
+						<div id="week">
+							Week 3</div>
+						<p>Meeting -10</p>
+						<p>/ </p>
+						<ul>
+							<li>Extraction of Part Combination Rules </li>
+							<li>Web, poster, presentation contents generally.
+							</li>
+							<li></li>
+						</ul>
+					</div>
+					<div class="week4" style="height: 350px;">
+						<div id="week">
+							Week 4</div>
+						<p>Meeting -11</p>
+						<ul>
+							<li>USTC and Berkeley projects.[ https://2009.igem.org/Team:USTC_Software
+							and https://2009.igem.org/Team:Berkeley_Software </li>
+							<li>Graphical representation of node relations. </li>
+							<li>Part Combination Rules </li>
+							<li>Subpart Combinations Rules </li>
+							<li>Expectations from the software (SRS: Functional;
+							Requirements) </li>
+						</ul>
+					</div>
+				</div>
+				<div class="month">
+					September</div>
+				<div class="general">
+					At this time all bases for application were nearly to finish,
+					the software group was waiting row data from the gene group.
+					Meanwhile, they were working on code bases.</div>
+				<div class="lower">
+					<div class="week1" style="height: 350px;">
+						<div id="week">
+							Week 1 </div>
+						<p>DOING THE TASKS. </p>
+					</div>
+					<div class="week2" style="height: 350px;">
+						<div id="week">
+							Week 2</div>
+						<p>Meeting -12</p>
+						<ul>
+							<li>Final Database </li>
+							<li>Final Graphs </li>
+							<li>GUI </li>
+							<li>Expectations from the software (SRS: Functional
+							Requirements) (Suggestions)</li>
+							<li>Survey details</li>
+						</ul>
+					</div>
+					<div class="week3" style="height: 350px;">
+						<div id="week">
+							Week 3</div>
+						<p>Meeting -13</p>
+						<ul>
+							<li>Animation (Storyboard, timeline) </li>
+							<li>Web site (Suggestions to web site) </li>
+							<li>Poster (How we can use 3D stereoscopic image, How
+							we can tell the development progress and our concepts
+							by 3D effect etc...) </li>
+							<li>Presentation ( Suggestions about presentation )</li>
+						</ul>
+					</div>
+					<div class="week4" style="height: 350px;">
+						<div id="week">
+							Week 4</div>
+						<p>Meeting -14</p>
+						<ul>
+							<li>Final Graphs </li>
+							<li>GUI ( about 70 % is over ) </li>
+							<li>How to send the software to other teams for collaboration
+							( just general ideas, details will be talked later ).
+							</li>
+							<li>With survey or not , can it shade the software?
+							</li>
+							<li>What to ask to teams while sending?</li>
+						</ul>
+					</div>
+				</div>
+				<div class="month">
+					October</div>
+				<div class="general">
+					<p>Now everything is nearly over, it is time to put everything
+					together.</p>
+					<ul>
+						<li>Gene group explaining the methods that we have used
+						during project.</li>
+						<li>Software group finalizing, software, testing it importing
+						new function according to collaboration results with METU
+						TURKEY wet lab team., trying to solve infinite bugs…</li>
+						<li>Design group putting all together…</li>
+						<li>Meanwhile, all team is writing the content for web,
+						poster, and presentation.</li>
+					</ul>
+				</div>
+				<div class="lower">
+					<div class="week1" style="height: 170px;">
+						<div id="week">
+							Week 1</div>
+						<p>Meeting -15</p>
+						<ul>
+							<li>BioGuide Application, missing points.</li>
+							<li>Content writing</li>
+							<li>Web, poster, animation</li>
+						</ul>
+					</div>
+					<div style="float: left; width: 540px; height: 170px; font-weight: normal; background-color: #3fff72; padding: 10px;">
+						<div id="week">
+							Week 2, Week 3, &amp; Week 4
+							<p>GOOD NEWS Infinite meetings started :) </p>
+							<ul>
+								<li>Writing content [shared it, tasks assigned to
+								members according to their fields.]</li>
+								<li>Software; debugging, testing, adding functions…</li>
+								<li>Designers web, poster, presentation, animation,
+								importing content…</li>
+							</ul>
+						</div>
+					</div>
+				</div>
+				<div class="month">
+					November</div>
+				<div class="general">
+					<p align="center">November 1 – 12 is our ticket dates,</p>
+					<p align="center">See you in BOSTON …</p>
+					<p align="center">METU TURKEY SOFTWARE</p>
+				</div>
 			</div>
-		</div></div>
+		</div><h3>Follow our discussion topic at <a href="http://groups.google.com.tr/group/software_MetuTurkey/topics">our googlegroups</a></h3>
-		<div id="notebook" class="item"><div class="content">Notebook</div></div>
+	</div>
-		<div id="download" class="item"><div class="content">Download</div></div>
+</div>
-		<div id="miscellaneous" class="item"><div class="content">Misc - Collaboration</div></div>
+<div id="download" class="item">
-		<div class="clear"></div>
+	<div class="content2">
-		<!-- 2nd row -->
-		<div class="item"></div>
-		<div class="item"></div>
-		<div class="item"></div>
-		<div class="item"></div>
-		<div id="project2" class="item"><div class="content">
 		<div class="text">
-		Material and Methods
+			<h2>Download Executable and Code</h2>
-		<p>
+			<p>You can download BioGUIDE at <a href="http://sourceforge.net/projects/bioguide">http://sourceforge.net/projects/bioguide</a></p>
-		Our material for B-IO Guide Software Program was the all background
+			<p>Download & install it and feel it's power!!</p>
-		information of parts stated in distributed 2010 iGEM plates to whole
-		wetlab teams. Data of a part having specific part ID has been parsed
-		by writing a parsing code. Then, other data which needs to be standardized
-		according to biological importance which has been get out from the
-		Registry of Parts Page manually. These standardized data are;
-		</p>
-		<ul>
-			<li>working conditions of biobricks involved within the parts</li>
-			<li>properties of inputs and outputs</li>
-		</ul>
-		<p>
-		We named as "Inputs" because an effector which
-		may be chemical(IPTG, galactose etc.) and physical (UV irradiation,
-		temperature etc) external inputs or may be proteins synthesized
-		from a biobrick coding sequence can affect promoters on the parts.
-		The effects of these mentioned inputs have been determined as inducer
-		(a molecule that starts gene expression), repressor (blocker of
-		attachment of RNA polymerase to promoter), activator (increasing
-		the rate of transcription) and inhibitor (decreasing the rate of
-		transcription). Moreover, the promoters may have additional property
-		at which they may become constitutively ON without seen any effect.
-		</p>
-		<p>
-		On the other hand, for output section, we add new approach which
-		is "working condition" parameter because the expressed proteins
-		from biobrick coding sequences may come from different organisms
-		to run mostly in E.coli. However, in some cases these proteins may
-		not work well as expected unless suitable and optimum conditions
-		are provided in the host. Thus, we have thought that natural(in
-		vivo) or experimental(in vitro) working conditions of the synthesized
-		proteins from the certain biobricks or constructs should be stated
-		during submitting to Parts Registry. Nevertheless, our 2010 iGEM
-		Software Program version 1.0 mostly does not have any experimental
-		data since the data had not been added for pages of the parts regularly
-		and true. Therefore, if our advised Parts Registry interfaces are
-		used in iGEM in future and our standards are used, then we will
-		be able to add such an information to the database of the program
-		for better performance.
-		</p>
 		</div>
-		</div></div>
-		<div class="item"></div>
-		<div id="download2" class="item"><div class="content">Code</div></div>
-		<div id="miscellaneous2" class="item"><div class="content">Human Practices</div></div>
-		<div class="clear"></div>
-		<!-- 3rd row -->
-		<div class="item"></div>
-		<div class="item"></div>
-		<div class="item"></div>
-		<div class="item"></div>
-		<div id="project3" class="item"><div class="content">Database</div></div>
-		<div class="item"></div>
-		<div id="download3" class="item"><div class="content">User Guide</div></div>
-		<div id="miscellaneous3" class="item"><div class="content">Safety</div></div>
-		<div class="clear"></div>
-		<!-- 4th row -->
-		<div class="item"></div>
-		<div class="item"></div>
-		<div class="item"></div>
-		<div class="item"></div>
-		<div id="project4" class="item"><div class="content">Modelling</div></div>
-		<div class="item"></div>
-		<div id="download4" class="item"><div class="content">Support</div></div>
-		<div id="miscellaneous4" class="item"><div class="content">Future Plan</div></div>
-		<div class="clear"></div>
-		<!-- 5th row -->
-		<div class="item"></div>
-		<div class="item"></div>
-		<div class="item"></div>
-		<div class="item"></div>
-		<div id="project5" class="item"><div class="content">Algorithm</div></div>
-		<div class="item"></div>
-		<div id="download5" class="item"><div class="content">Contact</div></div>
-		<div class="item"></div>
-		<div class="clear"></div>
-		<!-- 6th row -->
-		<div class="item"></div>
-		<div class="item"></div>
-		<div class="item"></div>
-		<div class="item"></div>
-		<div id="project6" class="item"><div class="content">Results</div></div>
-		<div class="item"></div>
-		<div class="item"></div>
-		<div class="item"></div>
-		<div class="clear"></div>
 	</div>
+</div>
+<div id="miscellaneous" class="item">
+	<div class="content2">
+		<div class="text">
+			<h2>Collaboration</h2>
+			<h3>Part Registry Survey</h3>
+			<p>
+			<a href="http://www.kwiksurveys.com/online-survey.php?surveyID=HIMIGG_469f28c4&amp;ooo=HKDDJHO_95dcbe36">
+			Click here to go to survey page..</a></p>
+			<br>
+			<h3>Results</h3>
+			<p>(including responses between 10th -22nd of Oct 2010)</p>
+			<h4>General Profile of Participants</h4>
+			<ul>
+				<li>The following teams are dedicated as collaborators with more
+				than 60% team participation are </li>
+				<ul>
+					<li>INSA-Lyon</li>
+					<li>Lethbridge</li>
+					<li>WashU</li>
+				</ul>
+				<li>Out of 244 participants between 10 to 22.10.2010, 57% of the
+				participant had scientific degrees from B.Sc to Professor and 18%
+				had graduate degrees. 18% of participants are enrolled in their
+				teams as either Instructors or Advisors. </li>
+				<li>95 teams have responded to the survey while we are still waiting
+				to hear from 33 teams. 74% teams participated with one or more members
+				to the survey. </li>
+				<li>75% of participants were interested with synthetic biology field
+				for academic purposes.</li>
+			</ul>
+			<h4>Browsing the Registry of Standard Parts </h4>
+			<ul>
+				<li><strong>56% of participants think that it is not easy to search
+				for the parts in Registry of Standard Parts.</strong> Many comments
+				indicate a need for a better search engine and more flexible keyword
+				search options, especially excepting aliases. Also many are longing
+				for recognizable parts names, which will ease searching with keyword.
+				</li>
+			</ul>
+			<p><i>Partnership with Google and enforcing standardized parts names
+			are suggested </i></p>
+			<p><i>As a global organization iGEM can offer the Parts Registry in
+			different languages and more illustrations describing how the system
+			works.</i></p>
+			<h4>Content of Registry of Standard Parts </h4>
+			<ul>
+				<li><strong>57% of participants agree that the number of parts registered
+				in the Registry of Standard Parts is not enough for their projects.</strong>
+				</li>
+				<li><strong>55% of participants think that there are enough and
+				useful parts distributed in iGEM Plates that we can use in our projects.
+				</strong></li>
+			</ul>
+			<p>Even though most agree the number of parts in the registry is impressive,
+			still they find it limited when it comes to design different devices
+			for diverse applications especially in different species other than
+			E. Coli. Participants believe that if there are more functional standardized
+			parts, especially protein coding sequences and promoter-RBS , they can
+			design devices according to the needs of the community instead of designing
+			what can simply be assembled into a device. </p>
+			<p><i>Encouraging development of vectors and standards for new species
+			and new standardized parts in different research areas is suggested.
+			</i></p>
+			<p><i>Enforcing submission of right DNA sequences and working conditions
+			for each part is suggested.</i> </p>
+			<p><i>Few recommend expanding iGEM into a collaborative effort rather
+			than an undergraduate tournament, which will increase the number and
+			the diversity of the parts designed and submitted all throughout the
+			year. </i></p>
+			<h4>Submission to the Parts Registry </h4>
+			<ul>
+				<li><strong>52% of participants said that they have not encountered
+				difficulties during submitting parts.</strong> Even though participants
+				are satisfied with the web interface of the registry, most complains
+				about the pSB1C3 as the new standard plasmid to submit DNA. </li>
+				<li><strong>71% of participants are like minded with our team&#39;s
+				opinion, which is that The nomenclature of part IDs such as construct,
+				device, composite parts, protein generator, is confusing as there
+				is no consensus on how to use them correctly.</strong> </li>
+			</ul>
+			<p><i>Terminology and categorization used on iGEM’s Parts Registry should
+			be re-described and correct use of terminology should be enforced during
+			the submission process.</i> </p>
+			<ul>
+				<li><strong>75% of participants agree that different, specified
+				submission interfaces should be designed for contructs, promoter,
+				RBS, CDS and terminals is needed during Registry of Standard Parts.</strong>
+				But, there are very strong and valid arguments against it such as,
+				losing the flexibility of the registry will not allow future submission
+				of unclassified parts. </li>
+			</ul>
+			<p><i>We suggest keeping the parts submission interface as is, until
+			these concerns are addressed.</i> </p>
+			<ul>
+				<li><strong>75% of participants agree that Out-dated, un-available
+				and not-characterized parts in the Registry of Standard Parts should
+				be removed to an archive after the consent of the designer.</strong>
+				</li>
+			</ul>
+			<p>“It would be great to see some sort of organization like this! I
+			agree that unavailable parts should be followed up on and removed if
+			necessary. I also think that parts which are not sufficiently documented
+			should be highlighted in some way. Once these parts are identified,
+			teams can actively characterize them as part of their projects or as
+			side projects.” </p>
+			<p>“Think about these things: (i) who decides when a part is out-dated,
+			and how can that person know that an old part cannot have a novel use
+			in the future? (ii) likewise, an uncharacterized part may be both characterized
+			and used in the future” </p>
+			<p><i>We suggest building a backup system, such as an archive, to sort
+			out the rarely used, un-available and un-categorized parts until they
+			are in line with the enforced standards.</i> </p>
+			<ul>
+				<li><strong>91% of participants have same opinion with us, which
+				is that standardization of the nomenclatures used for each different
+				composition of parts is necessary.</strong></li>
+			</ul>
+			<h4>Standards that should be enforced and Additional New Standards
+			</h4>
+			<p>According to our survey, from high rated to low, these standards
+			have been rated which has been used while assigning a name to parts
+			</p>
+			<ul>
+				<li><strong>33% Type of part</strong> </li>
+				<li><strong>17% Input</strong> </li>
+				<li><strong>17% Output</strong> </li>
+				<li><strong>14% Version</strong> </li>
+				<li><strong>10% Year</strong> </li>
+				<li><strong>9% Group</strong> </li>
+			</ul>
+			<p>Along with above, having short recognizable part names along with
+			function and performance , Genbank/EMBL link and organism information
+			is important. </p>
+			<ul>
+				<li><strong>93% of participants have said that for the parts that
+				are marked as “WORKS” distinguishing the parts with quantitative
+				experimental validation vs parts without this information is important.</strong>
+				Most participants have encountered with similar problems about parts
+				that don’t work under their lab conditions or works but not they
+				were claimed for. </li>
+				<li><strong>89% of participants have same opinion with us, which
+				is that iGEM should sub-categorize the “WORKS” comment into 1) “Quantitative”
+				for parts which are characterized with experiments and 2) “Qualitative”
+				for parts which are not characterized will be an appropriate measure
+				for standardization of Biobrick database.</strong> </li>
+			</ul>
+			<p><i>In order to overcome these problems we suggest enforcing the working
+			conditions title for the registry entrance, in order to collect quantitative
+			experimental details on submitted parts, which might slow down the registration
+			process but will definitely increase the quality of the database.</i>
+			</p>
+			<ul>
+				<li><strong>61% of participants agree that POPS (Polymerase Per
+				Second) should be assigned to every part or biobricks with a promoter,
+				where appropriate. - 57% of participants have been agree that RIPS
+				(Ribosome per Second) should be assigned to every part or biobricks
+				with a RBS brick.</strong> </li>
+			</ul>
+			<p>Though most participants agree the need for POPS and RBS information
+			, they are concerned about the workload it would bring to individual
+			labs. </p>
+			<p>“To do this, the Registry need to define a reliable and easy method
+			of determining the PoPS for teams to use. However, I would say that
+			there are better systems for quantifying promoter output than PoPS,
+			and they should be used instead, if possible”. </p>
+			<ul>
+				<li><strong>67% of participants have thought that entering POPS
+				information should not be mandatory while submitting new parts.
+				Similarly, 65% of participants disagree that entering RIBS information
+				should be mandatory while submitting new parts </strong></li>
+			</ul>
+			<p>Even though the researchers feeling the need for this information
+			they are shying away from requesting it as a mandatory title for parts
+			registry as it would be difficult for underfunded and inexperienced
+			groups to perform these measurements. </p>
+			<p><i>We strongly suggest starting a forum on how to quantify the performance
+			of promoters and genes to bring an easy to measure standard for the
+			efficiency of the parts. Additionally iGEM should the responsibility
+			and provide the measurements for the each promoter and gene included
+			in the distributions. The second choice would be even better in terms
+			of standardization as all the measurement will be performed by one center
+			under similar conditions and with experienced researchers, which will
+			allow user to compare and contrast the efficiencies of the parts more
+			accurately. </i></p>
+			<ul>
+				<li><strong>82% of participants have thought that information on
+				working conditions of the parts should be mandatory while submitting
+				new parts.</strong> Most find submiting the detailed experimental
+				information and working conditions is crucial and even easier than
+				submitting measurements of POPS or RBS. </li>
+			</ul>
+			<h4>Definitions you would like to see at the Registry of Standard Parts
+			</h4>
+			<ul>
+				<li><strong>Transcriptional efficiency 13%</strong> </li>
+				<li><strong>Protein lifetime 10%</strong> </li>
+				<li><strong>Ribosome binding efficiency 10%</strong> </li>
+				<li><strong>mRNA lifetime 9%</strong> </li>
+				<li><strong>Translation initiation and efficiency 9%</strong>
+				</li>
+				<li><strong>Protein concentration 9%</strong> </li>
+				<li><strong>Cooperative effects with other molecules 9%</strong>
+				</li>
+				<li><strong>Protein-DNA binding rates and efficiencies 8%</strong>
+				</li>
+				<li><strong>RNA polymerase affects 8% </strong></li>
+				<li><strong>System copy count 8%</strong> </li>
+				<li><strong>Protein multimerization 6%</strong> </li>
+			</ul>
+			<p>Additional titles includes: Catalytic rates and affinities for substrates,
+			leakiness of promoter in lack of stimulus, POPS at various inducer/repressor
+			concentrations. </p>
+			<h4>Efficiency of the Database Entries </h4>
+			<ul>
+				<li><strong>86% of participants would like to see a ranking/rating
+				system for the parts by the other iGEM users which will be one indication
+				of if a part is working and how well in different laboratories.</strong>
+				Few had concerns about how well the rating system will work for
+				rarely used parts while the widely used parts would even more popular
+				due the the rating system. Still many believes this would be one
+				futher towards a peer-reviewed quality control system for the parts.
+				</li>
+				<li><strong>61% of participants agreed that parts should be updated
+				regularly by the designers, where most agreed at least when there
+				is new information on the parts.</strong> It has also been suggested
+				to give permission to all the users of that part for updating information.
+				</li>
+				<li><strong>73% of participants have been agree with us that excluding
+				the low ranking parts or the parts with negative feedback from the
+				future plates will increase efficiency of the system.</strong> The
+				major concern about excluding any part is losing the variety of
+				parts in the database. Few recommends excluding only the parts that
+				are not working. </li>
+			</ul>
+			<p>“Efficiency shouldn&#39;t be top priority in a database. First and foremost,
+			data is the top priority. Excluding those parts would make the system
+			more efficient” </p>
+			<p>“Some parts may be rare or new and have low efficiency, but can be
+			very important! Getting rid of them would eliminate any chance of improvement
+			to these parts, which not only a qualifier for an iGEM gold medal, but
+			also one of the focuses of biobricks.” </p>
+			<p><i>We suggest excluding the parts not-working, low rated or with
+			negative feedbacks from the annual distribution plates but still archive
+			them and make their data available through the parts registry. So the
+			while the individuals labs are receiving plates with higher rated, fully
+			working parts for their projects, anyone who wants to work on a more
+			exotic part can search through the achieves and re-vitalize the parts
+			stored there. The challenge of re-vitalization of parts can be encouraged
+			as an collaborative effort.</i> </p>
+			<h4>New Options for the Parts Registry Database </h4>
+			<ul>
+				<li><strong>96% of participants are like minded with us that it
+				will be useful to have a link out to the gene/protein information
+				of the parts and - %97 of participants have been agree that they
+				would like to know if a part is also involved in known biological
+				pathways.</strong> </li>
+			</ul>
+			<p><strong>For receiving pathway information more participants have
+			voted for NCBI Cog (59%) than KEGG pathways (38%) when the responses
+			for both has been distributed among the choices according to response
+			rates.</strong> Adding the blast option to the parts registry has also
+			been suggested to locate parts of interest. We are sure all of us would
+			like to see gene-protein and pathway information if these information
+			was integrated into the database and offered automatically for each
+			entry in the database.</p>
+			<p><i>We are planning to provide this information about the parts to
+			all parts registry users as a build-in option in the next version of
+			BioGuide in iGEM 2011. </i></p>
+			<br>
+			<h2>New Parts Registry Form Suggested for The New Standards</h2>
+			<img src="https://static.igem.org/mediawiki/2010/1/17/Metu-form1.png">
+			<h3>Description</h3>
+			<p>Warning Boxes: </p>
+			<ul>
+				<li>If Out-dated, un-available and not-characterized parts exist
+				in the Registry of Standard Parts, bring to an archive after the
+				consent of the designer. Divide archive into three title: Out-dated,
+				un-available and not-characterized parts </li>
+				<li>Besides shown as “works”, in the works box there should be explanation
+				whether the part is characterized or non-characterized. </li>
+				<li>Parts should be updated regularly by the designers </li>
+				<li>Excluding the low ranking parts or the parts with negative feedback
+				from the future plates </li>
+			</ul>
+			<p>Characterization Boxes: </p>
+			<ul>
+				<li>transcriptional efficiency </li>
+				<li>mRNA lifetime </li>
+				<li>ribosome binding efficiency </li>
+				<li>translation initiation and efficiency </li>
+				<li>protein lifetime </li>
+				<li>protein concentration </li>
+				<li>protein multimerization </li>
+				<li>protein-DNA binding rates and efficiencies </li>
+				<li>cooperative effects with other molecules </li>
+				<li>RNA polymerase effects </li>
+				<li>system copy count </li>
+			</ul>
+			<img src="https://static.igem.org/mediawiki/2010/9/91/Metu-form2.png">
+			<h3>Desription</h3>
+			<p>Search box </p>
+			<ul>
+				<li>with click options </li>
+				<li>options: searched parts are:
+				<ul>
+					<li>Available </li>
+					<li>Length OK </li>
+					<li>Building </li>
+					<li>Planning </li>
+					<li>Missing </li>
+					<li>Unavailable </li>
+				</ul>
+				</li>
+			</ul>
+			<p>according to the clicks of above options, search is modified</p>
+			<img src="https://static.igem.org/mediawiki/2010/5/54/Metu-form3.png">
+			<img src="https://static.igem.org/mediawiki/2010/1/1d/Metu-form4.png">
+			<h3>Description</h3>
+			<p>Assume on the part image; </p>
+			<ul>
+				<li>part DNA sequence is not confirmed, then tag with &quot;non-confirmed
+				DNA sequence&quot; </li>
+				<li>non-characterized parts in the Parts Registry are not characterized
+				further, then it will be tagged as &quot;deprecated&quot; </li>
+			</ul>
+			<p>also: </p>
+			<ul>
+				<li>comment box stated that any team can make comment about experiences
+				with the part is opened </li>
+				<li>boxes which had been not filled with the data are highlighted;
+				<ul>
+					<li>transcriptional efficiency </li>
+					<li>mRNA lifetime </li>
+					<li>ribosome binding efficiency </li>
+					<li>translation initiation and efficiency </li>
+					<li>protein lifetime </li>
+					<li>protein concentration </li>
+					<li>protein multimerization </li>
+					<li>protein-DNA binding rates and efficiencies </li>
+					<li>cooperative effects with other molecules </li>
+					<li>RNA polymerase effects </li>
+					<li>system copy count </li>
+				</ul>
+				</li>
+				<li>if the part is not characterized but &quot;works&quot; then a &quot;Qualitative
+				part&quot; tag is added </li>
+				<li>besides &quot;works&quot;, &quot;Characterized&quot; or &quot;non-characterized&quot; box
+				is added </li>
+				<li>ranking/rating stars for the parts voted by the other iGEM users
+				which indicate how well the parts perform in different laboratories
+				is added. For example 4.5 star voted by 27 teams (number of stars
+				and number of votes) </li>
+			</ul>
+		</div>
+	</div>
+</div>
+<div class="clear">
+</div>
+<!-- 2nd row -->
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div id="project2" class="item">
+	<div class="content2">
+		<div class="text">
+			<h2>Design</h2>
+<a href="https://static.igem.org/mediawiki/2010/6/6a/Metu_Turkey_Software_ER3.jpg"><img src="https://static.igem.org/mediawiki/igem.org/7/71/Metu_Software_ER3.png" /></a>
+		</div>
+	</div>
+</div>
+<div class="item">
+</div>
+<div id="download2" class="item">
+	<div class="content2">
+		<div class="text">
+			<h2>User Guide</h2>
+			<object width="425" height="344"><param name="movie" value="http://www.youtube.com/v/Znb1o7cr5dc?hl=en&fs=1"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Znb1o7cr5dc?hl=en&fs=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object><object width="425" height="344"><param name="movie" value="http://www.youtube.com/v/Fk7eJ-Ig_IQ?hl=en&fs=1"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Fk7eJ-Ig_IQ?hl=en&fs=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object><p>For new users whom want to interest with synthetic biology and for experienced scientists, in our program you have two options for Input Output properties ;</p>
+<p>To find input-output related biobrick parts or larger constructs! If you want to provide specific chemical or physical inputs from external environment, you may choose these inputs from the list. if you want other specific inputs which will be expressed from a coding sequence, the list can provide these specified protein names.</p>
+<img src="https://static.igem.org/mediawiki/2010/6/60/Metu-guide1.jpg">
+<p>Wanted features of outputs can be selected by either from list or entering individually into text boxes.</p>
+<img src="https://static.igem.org/mediawiki/2010/c/c0/Metu-guide2.jpg">
+<p>Then click on the “Show Parts ” button.</p>
+<img src="https://static.igem.org/mediawiki/2010/9/95/Metu-guide3.jpg">
+<p>Then the program will show you the parts have specified I/O properties</p>
+<img src="https://static.igem.org/mediawiki/2010/7/7f/Metu-guide4.jpg">
+<p>To see the properties of a part just click on it.</p>
+<img src="https://static.igem.org/mediawiki/2010/3/33/Metu-guide5.jpg">
+<img src="https://static.igem.org/mediawiki/2010/2/27/Metu-guide6.jpg">
+<p>After clicking, you will see a highlighted pathway on the 2nd graph. Which are the subparts of the clicked part. Showing the sub graph in network.</p>
+		</div>
+	</div>
+</div>
+<div id="miscellaneous2" class="item">
+	<div class="content2">
+		<div class="text">
+			<h2>Human Practices</h2>
+			<p>iGEM’s parts registry is the only current database that holds information
+			and DNA for over 3000 standard parts for the use of synthetic biology
+			community. BioGUIDE is the first designed software that organizes the
+			parts in iGEM spring 2010 distribution as possible atomics parts to
+			build new biological device and systems for specific input and outputs
+			based on graph theory. We are the first group who has applied a novel
+			algorithm to search for input/output relations between the parts to
+			reveal possible construct assemblies. This new approach will chance
+			how the parts registry is used by the scientific community. And the
+			availability of software implementing our algorithm with a very user
+			friendly graphical user interface will allow all the users of the parts
+			registry to explore new and novel constructs according to their parameter
+			with ease. Additionally as the BioGUIDE software is an open source ware
+			, any user can contribute to the development of the application. So,
+			BioGUIDE will be improving with a collaborative effort, which will make
+			it even more widely used among the synthetic biologists. </p>
+			<p>We also had many collabrations with the teams such as, INSA-Lyon,
+			Lethbridge, WashU through our survey and WARSAW as we have participated
+			in their survey. Also our sister team METU_TURKEY is our main collaborator.
+			They have provided feedback BioGUIDE at different stages of the development.
+			And they had the chance to analyze their constructs input/output relations
+			throughout this collaboration. </p>
+			<p><strong>ALL TEAMS</strong>: The Parts Registry Survey that has been
+			developed by METU_TURKEY_SOFTWARE got response from 253 of participant
+			from 94 teams. Analysis of the survey results we have received so far
+			indicates that we were able outreach to the iGEM community and help
+			them verbalize their concerns and suggestions for the parts registry
+			standards and the maintenance of the database.</p>
+			<p><strong>WARSAW</strong>: Our team members have participated in their
+			survey abour iGEM participants profile. </p>
+			<p><strong>METU_TURKEY</strong>: Beta testing of the algorithm developed
+			and the BioGUIDE software has been performed by METU_TURKEY on few case
+			studies. Additionally they have tested their construct for 2010 competition
+			with our algorithm. </p>
+		</div>
+	</div>
+</div>
+<div class="clear">
+</div>
+<!-- 3rd row -->
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div id="project3" class="item">
+	<div class="content2">
+		<div class="text">
+			<h2>Material</h2>
+			<p>Our main data source for BIO Guide Software Program was the available
+			background information of parts distributed in 2010 iGEM plates (Total
+			of three384-well plates of dried DNA) to the wetlab teams. This data
+			was available through both the parts registry main website (<a href="http://partsregistry.org/Main_Page">http://partsregistry.org/Main_Page</a>)
+			in XML format and parts registry libraries (http://partsregistry.org/assembly/libraries.cgi?id=31)
+			in Excel format. Data from parts with specific part IDs have been parsed
+			with a custom code developed to modify SAX Parser. Then, the rest of
+			the data which needs to be standardized according to biological importance
+			have been extracted from the Registry of Parts Page manually. The chemical
+			(IPTG, galactose etc.) or physical (UV irradiation, temperature etc)
+			external inputs and proteins synthesized from a biobrick coding sequence
+			can affect promoters on the parts. These effectors are identified under
+			the title “Input”. And the “Output” s of these effectors are classified
+			as inducers (a molecule that starts gene expression), repressors (blocker
+			of attachment of RNA polymerase to promoter), activators (increasing
+			the rate of transcription) and inhibitor s(decreasing the rate of transcription).
+			These standardizations on the database helped us to build the algorithm
+			based on input/output relationships. MySQL Server is used for Database
+			development and organization. All of our illustrations for ER and algorithm
+			is created in SmartDraw (trial version). Java Programming Language,
+			and NetBeans Development environment is used or for software development.
+			The graphical visualization of the software is done with Cyctoscape
+			and yfiles libraries (trial version) are used for the presentation of
+			graphical events. We have utilized css Javascripts for our webdesign.
+			Autodesk Maya 2011 with Academic Licence, Adobe Creative Suite 5 Master
+			Collection (Trial Version) have been used for animations and illustrations.
+			Video tutorial for the BioGUIDE has been created by camstudio and trial
+			versions of Flash and After Effects are also used for the videos.
+			</p>
+		</div>
+	</div>
+</div>
+<div class="item">
+</div>
+<div id="download3" class="item">
+	<div class="content2">
+		<div class="text">
+			<h2>Supporting Tools</h2>
+			<ul>
+				<li>SAX Parser ( modified )to parse XML files</li>
+				<li>Java ProramingLanguage, NetBeans Developement environment for
+				software developement</li>
+				<li>MySQL Server for DataBase</li>
+				<li>cystoscape for graph visualization</li>
+				<li>yfiles library for graph events</li>
+				<li>SmartDraw for illutration of ER and Algorithm</li>
+				<li>maya &amp; Cinema 4D for 3D animation, Adobe Master Collection and
+				Microsoft Expression Studio for design</li>
+				<li>CSS, Java Script for web</li>
+			</ul>
+		</div>
+	</div>
+</div>
+<div id="miscellaneous3" class="item">
+	<div class="content2">
+		<div class="text">
+			<h2>Safety</h2>
+			<p>Synthetic biology has the potential to impact many areas of society.
+			Synthetic biologists may use artificial molecules to reproduce emergent
+			behavior from natural biology, with the goal of creating artificial
+			life or seeking interchangeable biological parts to assemble them into
+			devices and systems that function in a manner not found in nature (Benner
+			and Sismour 2005, Endy 2005, Heinemann and Panke 2006, Luisi 2007, Serrano
+).There is possibility of causing intentional or accidental harm
+			to humans, agriculture or the environment. While deliberate damage is
+			dealt with under the heading biosecurity, the potential unintended consequences
+			have to be considered under the term biosafety. As a software developer
+			, we have to consider all possible maliciously use of synthetic biology
+			tools. However, it is diffucult to understand for which purposesour
+			tools will be used, bestway avoiding garage bioterrorism is all parts
+			before adding to partsregistry must be checked , looked for toxic affect
+			and any environmental or human harmness. After scanning possible candidate
+			parts, a committe should decide whether novel part can be added parts
+			registry or not.And we can only warn the user about our intention while
+			building the application: </p>
+			<p>“BioGUIDE v1.0 software is <strong>FOR RESEARCH USE ONLY</strong>,
+			no medical or diagnostic use for applications of the novel Biobrick
+			constructs generated through our software has been described “</p>
+			<p>“No military (defense or combat) applications will be allowed in
+			future”</p>
+		</div>
+	</div>
+</div>
+<div class="clear">
+</div>
+<!-- 4th row -->
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div id="project4" class="item">
+	<div class="content2">
+		<div class="text">
+			<h2>Methods</h2>
+			<h3>Part Extraction Standards</h3>
+			<p>All information about the parts that are essential in experimental
+			setup of iGEM projects has been utilized. The information for the parts
+			available provided with all three 384 well plates in Spring 2010 distribution
+			have been standardized. Our standardization criteria have been discussed
+			in detail under Database Standardization. ER diagram has been generated
+			which simply describes the organization of the data. Around 70% of the
+			parts information has been fetched by the custom parsing code from XML
+			and Excel files provided by iGEM. Rest of the data had to be collected
+			and organized manually as the organization of these data cannot be standardized
+			to generate an algorithm. This step was one of the most time consuming
+			steps in our project. For each construct and Biobrick the information
+			collected was; Activity, Inducer, Activator, Repressor and Inhibitor
+			for promoters and Inducer, Activator, Repressor and Inhibitor information
+			valid for synthesized molecules (mostly proteins and RNA fragments etc.)</p>
+			<h3>Combination</h3>
+			<p>Rules (Image Combinations) In order to build our input/output relations
+			graphs first we run our algorithm on the real combination dataset which
+			contains all few thousand different possible combinations of the biobricks.
+			But after performing all combinations for the first few hundred biobricks
+			application’s rate slowed downed tremendously, which also become very
+			time consuming for displaying biobricks graphs. To overcome this bottleneck
+			we have developed a new strategy, where we have only used the construct
+			combinations of the biobricks distributed within the plates. Moreover,
+			according to information gathered from the subparts of the constructs
+			distrubuted, we also collected the subpart assembly order, such as 1st:
+			promoter, 2nd:rbs, 3rd:coding seq, any internal parts and the Last:
+			terminator. Each specific Biobrick type has been assigned a number as
+			a unique image ID from 1 to 19. Gathering the information on subparts
+			was not a direct forward process. ImageID assembly orders for each construct
+			has been used to extract the type information for each subpart with
+			that construct. This innovative approach helped us to reveal 400 possible
+			brick combinations present within the 3x384 well plates distributed
+			by iGEM in Spring 2010.</p>
+		</div>
+	</div>
+</div>
+<div class="item">
+</div>
+<div id="download4" class="item">
+	<div class="content2">
+		<div class="text">
+			<h2>Contact</h2>
+			<p>For critics, suggestion, or appraisal, you can contact us on
+			<a href="mailto:software_metuturkey@googlegroups.com">software_metuturkey@googlegroups.com</a></p>
+		</div>
+	</div>
+</div>
+<div id="miscellaneous4" class="item">
+	<div class="content2">
+		<div class="text">
+			<h2>Future Plan</h2>
+			<p>The application we have developed can be used by all iGEM members.
+			As the iGEMs database expands and the recognition of the field of Synthetic
+			Biology increases, data resources from other biological databases such
+			as NCBI might be needed to be integrated to the application. In such
+			a situation, extendibility of the application is vital. New data resources
+			and new functions should be added easily. </p>
+			<p>Before planning ahead, feedback from other teams and iGEM headquarters
+			about the BioGuide 1.0 will be collected. That will help us to fill
+			in the missing features of the application and check the theories which
+			are basis of our algorithms. </p>
+			<p>As our application is not geared towards any commercial use and will
+			stay as an academic application, keeping track of the weekly developmental
+			process on the wiki notebook environment was satisfactory. If the need
+			for a commercial application emerges, we should be utilizing professional
+			software development approaches to determine the exact requirements
+			and to facilitate the use of a common language between interdiciplinary
+			members in the team. </p>
+			<p>For constructing BioGuide 2.0 we have some plans. </p>
+			<h3>Short Term plan:</h3>
+			<p>Next year we are planning to generate BioGuide 2.0 by using all parts
+			data but inorder to do this we will update our part database but easyway
+			is standardization and reorganizing all parts in partsregistrty.org
+			according to our suggestion because re-organizing and normalization
+			are crucial. We are planning to add new tools to improve graphs.Our
+			ultimate aim is finding best pathway based on automated construction
+			and input-output relation. BioGuide 2.0 will be more faster because
+			we are planning to use OODBMS and all all platform will support BioGuide
+.0. </p>
+			<h3>Long term plan:</h3>
+			<p>We want to improve our algoritm and add more parameter to make graphs
+			more effective. Our dream is embeding our software into partsregistry.org
+			so no mere iGEMers will choose parts in real time by using our software.
+			</p>
+			<h3>Suggestions based on PartsRegistry Survey Results</h3>
+			<p>First suggesiton is offering fartnership with Google for easy search
+			and founding a committe to enforce a standardized nomenclature for terminology
+			and parts registry entries. </p>
+			<p>We strongly suggest starting a forum on how to quantify the performance
+			of promoters and genes to bring an easy to measure standard for the
+			efficiency of the parts. Additionally iGEM should assume the responsibility
+			and provide the measurements for the each promoter and gene included
+			in the distributions. The second choice would beeven better in terms
+			of standardization as all the measurement will be performed by one center
+			under similar conditions and with experienced researchers, which will
+			allow user to compare and contrast the efficiencies of the parts more
+			accurately. We suggest excluding the parts not-working, low rated or
+			with negative feedbacks from the annual distribution plates but still
+			archive them and make their data available through the parts registry.
+			So the while the individuals labs are receiving plates with higher rated,
+			fully working parts for their projects, anyone who wants to work on
+			a more exotic part can search through the achieves and re-vitalize the
+			parts stored there. The challenge of re-vitalization of parts can be
+			encouraged as an collaborative effort. We are sure, all of us would
+			like to see gene-protein and pathway information if these information
+			was integrated into the database and offered automatically for each
+			entry in the database. We are planning to provide this information about
+			the parts to all parts registry users as a build-in option in the next
+			version of BioGuide in iGEM 2011. </p>
+		</div>
+	</div>
+</div>
+<div class="clear">
+</div>
+<!-- 5th row -->
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div id="project5" class="item">
+	<div class="content2">
+		<div class="text">
+			<h2>Database Standardization</h2>
+			<p>Two main focuses of our project was the organization of the available
+			information about Biobricks on iGEM’s website and development of a software
+			application to help synthetic biologists at the experimental set-up
+			level by providing all available construct combinations for any given
+			input and output relations ,which they can utilize for their own project.</p>
+			<p>Normalization and re-organization of the part information at iGEM’s
+			web site was needed in order to develop our application, which will
+			automatically search the possible construct combinations. For the organization
+			and analysis of the Biobricks, we used part info for Spring 2010 distribution.
+			The information on all three 384 well plates distributed by iGEM scrutinized
+			and checked individually to specify the standards available and needed.
+			iGEM is providing so many parts within a hierarchical way, but there
+			is no order in the information flow and no common standards. Furthermore,
+			the information bulk is being used in an ineffective manner. Some of
+			the parts distributed are known to be nonfunctional. Web pages for parts
+			contain lots of information, but majority of them, are again not ordered.
+			Moreover, some additional information had to be removed or replaced
+			in such a way that the information for parts can be used effectively.
+			And removal of the redundant bulk information related with parts at
+			iGEM’s web site had been recommended for future. </p>
+			<p>Although, the final standardization, which we have suggested is not
+			for general public use and it was urgently needed in order to satisfy
+			the needs of our algorithm. But, still it will be a valuable resource,
+			since it summarizes the basic information about the parts.</p>
+			<p>As the first step to build the proposed standardization template,
+			the headings selected related to parts are listed on Table 1. Submission
+			of part IDs for individual parts is an accepted and quite valuable way
+			of tracking information. Although, every part has unique partID, for
+			every part there is a need to assign unique part names as official iGEM
+			names. Part names will have an important role as they will be providing
+			the short description about the part, which synthetic biologists can
+			immediately recognize and utilize during the construction of unique
+			Biobricks. Additionally unique part names will be helpful to identify
+			the devices with more than one Biobrick in their constructs. Assignment
+			of unique and distinct names for parts describing their nature and content
+			will be helpful to researchers for the recognition of and search for
+			the parts.</p>
+			<br>
+			<h3>Headings Selected From Previous Entry Forms for Indication of Standardized
+			Information</h3>
+			<p>=========================================</p>
+			<p>PartID:</p>
+			<p>PartName:</p>
+			<p>Bricks:</p>
+			<p>BrickIDs:</p>
+			<p>ImageIDs:</p>
+			<p>RFC10:</p>
+			<p>RFC21:</p>
+			<p>RFC23:</p>
+			<p>RFC25:</p>
+			<p>=========================================</p>
+			<p><span>Table 1: The table above basically describes and designates
+			qualities of parts which identifies their compositions and demonstrates
+			the status of previously assigned standards. PartID refers to the unique
+			ID number for parts including atomic parts and assemblies. PartName
+			refers to the given unique names to parts. Bricks, refers to the shortcut
+			names which specifies atomic parts. ImageIDs, refers to individual or
+			combination of numbers that are assigned by us. RFCs refers to the states
+			of parts based on RFC standards.</span></p>
+			<p>iGEM both provides individual, atomic parts and pre-combined constructs
+			such as devices and systems. Availability of combined constructs is
+			important to the researchers as combining individual bio-bricks one
+			at a time will be very time consuming. These previously merged constructs,
+			serve as the repository for puzzle and they can be used for different
+			purposes. Up to date the largest and most trustworthy source, for synthetic
+			biology and its components, is iGEM’s parts registry. In 2010, iGEM
+			provided over 1000 parts that have initiated many projects. Having more
+			atomic parts available in the iGEM’s repository, will lead to the design
+			of more complex and robust constructs, and we would have a better chance
+			to design different constructs for unique purposes. Also, for the parts
+			that are already available, extra steps needs to be taken for the quality
+			control and surveillance of these products. The quality control of the
+			information for the parts is essential for the future of iGEM and synthetic
+			biology. Even though we have found pre-determined RFC standards useful
+			and included those to our standardized template, some individual parts
+			still requires re-organization of the information as RFC standards alone
+			for the functionality of parts, does not satisfy the needs for wet lab
+			biologists.</p>
+			<p>Without a question there is an urgent need to build a distinct and
+			specific database well organized with its own standards for synthetic
+			biology; however, development of such a database is not an easy task.</p>
+			<br>
+			<h3>Contact Information of Part Owners and Qualitative Group Comments
+			about Parts</h3>
+			<p>=========================================</p>
+			<p>Designers: Mail:</p>
+			<p>GroupFavorite:</p>
+			<p>StarRating:</p>
+			<p>Parameters:</p>
+			<p>=========================================</p>
+			<p><span>Table 2: The above table simply depicts information about possessors
+			of parts and their contact information and the popularity of the parts
+			for groups. Parameters heading, refers distinctive experimental details
+			unique to the usage of parts which should be decided by groups.</span></p>
+			<p>Second step for building the standardized template was to get the
+			phylogenic information about the parts development process which includes
+			the name of the group, designer and contact information, along with
+			the comments from the group on the parts they have submitted. Contact
+			information is especially important for iGEM as other groups who need
+			extra information about the available part can reach to the required
+			information. Even though contacting with the designers of the individual
+			parts which are available is highly encouraged by iGEM, unavailability
+			of contact information points at out the fact that iGEM’s parts registry
+			needs strong re-organization in order to serve to the synthetic biology
+			community properly.</p>
+			<p>Additionally, the “group favorite” and “starRating” fields are also
+			important for individual evaluation of the parts, which doesn’t get
+			the deserved attention from the iGEM groups. “Group Favorite” defines
+			the confidence on the part by the designer group. “StarRating” defines
+			the related part in terms of popularity and usage efficiency among the
+			groups. According to our observations, most groups are not aware of
+			either of the fields or they are used incorrectly or ineffectively.
+			For example for a part with a full reporter which is known to be functional
+			and gives precise and expected results the StarRating should be at least
+stars, but for most of the parts in 2010 distribution, it is very
+			difficult to observe a part whose “StarRating” is above one. For quick
+			determination of functionality of the parts these two evaluations are
+			important so they have been included in the proposed standardization
+			template. But, as they were not properly used up to now for the re-organization
+			of the parts information during the development of our software application
+			we had to include all parts to our queries regardless of their evaluations
+			based on “Group Favorites” and “ StarRatings”</p>
+			<p>Second step for building the standardized template was to get the
+			phylogenic information about the parts development process which includes
+			the name of the group, designer and contact information, along with
+			the comments from the group on the parts they have submitted. Contact
+			information is especially important for iGEM as other groups who need
+			extra information about the available part can reach to the required
+			information. Even though contacting with the designers of the individual
+			parts which are available is highly encouraged by iGEM, unavailability
+			of contact information points at out the fact that iGEM’s parts registry
+			needs strong re-organization in order to serve to the synthetic biology
+			community properly.</p>
+			<p>Additionally, the “group favorite” and “starRating” fields are also
+			important for individual evaluation of the parts, which doesn’t get
+			the deserved attention from the iGEM groups. “Group Favorite” defines
+			the confidence on the part by the designer group. “StarRating” defines
+			the related part in terms of popularity and usage efficiency among the
+			groups. According to our observations, most groups are not aware of
+			either of the fields or they are used incorrectly or ineffectively.
+			For example for a part with a full reporter which is known to be functional
+			and gives precise and expected results the StarRating should be at least
+stars, but for most of the parts in 2010 distribution, it is very
+			difficult to observe a part whose “StarRating” is above one. For quick
+			determination of functionality of the parts these two evaluations are
+			important so they have been included in the proposed standardization
+			template. But, as they were not properly used up to now for the re-organization
+			of the parts information during the development of our software application
+			we had to include all parts to our queries regardless of their evaluations
+			based on “Group Favorites” and “ StarRatings”</p>
+			<br>
+			<h3>Input and Output Characteristics of Parts</h3>
+			<p>=========================================</p>
+			<p>Parameters:</p>
+			<p>-Input:</p>
+			<p>• Promoter:</p>
+			<p>• Activity:</p>
+			<p>• Inducer:</p>
+			<p>• Activator:</p>
+			<p>• Repressor:</p>
+			<p>• Inhibitor:</p>
+			<p>• Promoter2:</p>
+			<p>• Activity:</p>
+			<p>• Inducer:</p>
+			<p>• Activator:</p>
+			<p>• Repressor:</p>
+			<p>• Inhibitor:</p>
+			<p>-Output:</p>
+			<p>• Reporter:</p>
+			<p>• Reporter2:</p>
+			<p>• Regulator:</p>
+			<p>• Inducer:</p>
+			<p>• Activator:</p>
+			<p>• Repressor:</p>
+			<p>• Inhibitor:</p>
+			<p>• Regulator2:</p>
+			<p>• Inducer:</p>
+			<p>• Activator:</p>
+			<p>• Repressor:</p>
+			<p>• Inhibitor:</p>
+			<p>-Working Condition:</p>
+			<p>=========================================</p>
+			<p><span>Table 3: The table above elaborately describes the input relations
+			based on promoters and the output products based on the functional genes
+			and RNAs which are included within the parts. Working condition simply
+			describes any influencing factor or circumstance which is directly related
+			with the functional properties of parts.</span></p>
+			<p>Third part of our standardization template includes parameters of
+			contingent input and output elements. These parameters are classified
+			into two groups for simplicity as presented on Table 3. This final part
+			of the standardization template includes the upmost important information
+			about the Biobricks that are required for the BioGuide Software to run
+			its searching algorithm.</p>
+			<p>Briefly, BioGuide application is designed to catch the input and
+			output relations of individual parts to examine possible Biobricks pathways
+			for specific input and output queries. In other words, at pre-experimental
+			stage, it helps wet lab biologists to design their unique constructs
+			by revealing possible alternative options for pre-determined purposes,
+			along with the primary paths. Our ultimate goal is to improve the algorithm
+			designed for iGEM 2010 and present a new version of the BioGuide in
+			iGEM 2011, which will provide optimum design of constructs for predetermined
+			parameters.</p>
+			<p>Most of the parts are composed of functional and nonfunctional constructs
+			which are formed by atomic parts. And every part should carry the information
+			for all of its atomic parts within itself. The “input” heading actually
+			stands for promoters. Parts with one or more promoters can be found
+			at iGEM’s Parts Registry. Along with the information on which and how
+			many promoters a part might have, the activity level of promoters are
+			also important to distinguish between a constitutively active promoter
+			or a promoter activated by specific physiological processes or states
+			etc. This information was crucial for us to dissect in order to run
+			our algorithm as it directly affects which inputs can activate the devices
+			or the systems.</p>
+			<p>Throughout our investigations on the Parts Registry, we found out
+			that much of the terminology was being used ambiguously. Although this
+			might not be vital for synthetic biologists, it is still endeavoring
+			to understand the function of certain regulatory elements which also
+			becomes a time consuming task for the researcher. Thus, we recommend
+			that the explanations of certain regulatory elements should be redefined
+			and fixed especially for synthetic biology for easy communication, sharing
+			and searching of information.</p>
+			<p>Common misuses of the terminology can guide us to figure out how
+			to construct a standard nomenclature for synthetic biology. We claim
+			that a standard nomenclature is urgently needed for synthetic biology
+			for the following reasons. First of all, synthetic biology is an emerging
+			research discipline and an industrial application area which is highly
+			promising. Secondly, redefinition of the terminology to build a standard
+			nomenclature is needed as some of the terms are prone to be used instead
+			of another causing problems related to misuse for the global communication
+			about synthetic biology. Lastly, the nomenclature has major importance
+			for the construction of a persistent and trustworthy database for synthetic
+			biology which serves for the information exhibition and exchange globally.
+			For instance, there are obvious misunderstandings about the words which
+			are predominantly used for regulation process. We have noticed that,
+			the terms “inhibitor” and “repressor” are being used as equivocally
+			in the part information pages. Like the lactose inhibitor protein, a
+			widely used DNA-binding transcriptional repressor, that have been labeled
+			both as “inhibitor” and “repressor” at iGEM’s Parts Registry. Similar
+			problems resulting from ambiguous use of terminology also observed with
+			regulatory elements. To sum up, we investigated all input elements for
+			promoters and classify these elements in terms of their function, affect
+			and required input element for them. So, we suggest that terminology
+			used for regulation of transcription should be defined clearly on iGEM’s
+			website and correct use of terminology should be enforced.</p>
+			<p>The second group of parameters was collected under the title “Output”,
+			which refers to products of functional genes. In contradiction, the
+			term “reporter” has also been described within the same list. Reporters
+			are also genes whose products, can be used for screening as an output.
+			According to our group, the usage of the term “reporter” for genes is
+			unnecessary and cause extra complexity for information distribution
+			and gives rise to discrepancies. Instead of using the term “reporter”,
+			predefined “gene” description should be used for genes, which can function
+			as reporters. The special information which is related with the characteristic
+			of that gene should also be presented on part info web page.</p>
+			<p>Furthermore, the same terminology “reporter” was used for both atomic
+			parts and composite bio-bricks. Also the overall image descriptions
+			for these were defined as “reporters”. We want to point out that using
+			same nomenclature for both atomic genes and for whole functional constructs
+			contributes to the complexity and makes specific explorations difficult
+			through the Parts Registry. So, assigning “reporter” for both atomic
+			parts and for whole constructs is not a good practice. Instead, we are
+			suggesting the usage of other available terminology for the parts listed
+			as reporters, which most of the constructs, now known as reporters,
+			can be grouped into, such as “protein generators”, “composite parts”
+			or “inverters”.</p>
+			<p>Devices are whole constructs which are functional and have specific
+			and distinct functions. But, as we have observed, unfortunately, the
+			term “device” is also being used for parts which are not functional
+			and do not have specific functional at all. Moreover, within the classification
+			of devices, we argue that some terms are also being used unnecessarily
+			and ambiguously. Devices are classified into five types which are protein
+			generators, reporters, inverters, receivers and senders, measurement
+			devices. For example iGEM defines protein generators as:</p>
+			<p>Protein generator = promoter + rbs +gene + terminator</p>
+			<p>Though we accept the definition for protein generators, we observed
+			that there exist numerous parts which are defined as protein generators
+			but actually most of them do not fit to the definition provided above.
+			Although some parts are not functional and do not generate proteins
+			at all, they are classified as protein generators, which makes searching
+			for the parts difficult in the registry. Furthermore, there are also
+			numerous parts which are defined as “composite parts” but actually they
+			fit to the same definition with protein generators. In order to overcome
+			the problem of misuse of device type we have extracted related image
+			ID information for the composite parts. Image ID information helped
+			us to correctly categorize composite parts depending on its individual
+			atomic parts and identify the ones with more than one function, such
+			as being both inhibitor and activator. In other words, we used image
+			and part IDs in order to merge an input for its outputs.</p>
+			<p>Subtitle working conditions, includes all the detailed information
+			about the experimental properties of parts, and the details about the
+			working process of individual parts and complete devices. Additionally,
+			we marked the subtitle “Working Condition” in our standardization template
+			as potentially the most important title that helps synthetic biologist
+			to better understand the parts functions at iGEM’s part registry database.
+			The main problem we have encounter with the subtitle “working condition”
+			is within most of the parts the details about working process is not
+			enough and not provided regularly. </p>
+			<br>
+			<h3>Examples of Misuse of Terminology:</h3>
+			<h4>For Composite Parts:</h4>
+			<p>PartID: BBa_S04055</p>
+			<p>PartName: Synthetic lacYZ operon</p>
+			<img src="https://static.igem.org/mediawiki/2010/a/ac/Metu-database1.png" />
+			<p>This part is functional and responsible for the production of LacY
+			and LacZ proteins. This part partially fits the definition for “composite
+			part” but actually should be a protein generator as it fits fully to
+			the definition of “protein generators”.</p>
+			<h4>For Protein Generators:</h4>
+			<p>PartID: BBa_J45299</p>
+			<p>PartName: PchA &amp; PchB enzyme generator</p>
+			<img src="https://static.igem.org/mediawiki/2010/2/2c/Metu-database2.png" />
+			<p>The part which is illustrated above actually fits the definition
+			for “composite part” but in part registry it is classified as protein
+			generator. This part can be functional but it needs a promoter. Even
+			though this part is not functional and is not capable of producing protein,
+			part registry assigns this product as protein generator. We suggest
+			that all parts in the registry, which are composed of more than one
+			atomic part and which are not functional on their own but can be functional,
+			should be classified as “composite parts”.</p>
+			<h4>For Reporters:</h4>
+			<p>PartID: BBa_J04451</p>
+			<p>PartName: RFP Coding Device with an LVA tag</p>
+			<img src="https://static.igem.org/mediawiki/2010/0/0a/Metu-database3.png" />
+			<p>This functional part is classified as “Reporter” in the parts registry
+			database. It is very clear that this part fits the same description
+			as Protein Generator in Biobrick part registry standards. Although,
+			this part has specific and known functional role, characterizing this
+			part as a reporter is unnecessary and contributes to the level of complexity
+			of information provided. Instead, we suggest that this part should be
+			classified as “protein generator” and related detailed information about
+			the specific function of this part, should be provided in the part information
+			page.</p>
+			<p>In conclusion, as mentioned above we tried to reorganize and normalize
+			the information about parts which is provided in part registry for 2010
+			in order to develop our algorithm for the BioGuide application. During
+			this process, we encountered some inconsistencies and misuses of the
+			terminology being used and also inadequacies about the information provided
+			about parts. First of all, we claim that a standard nomenclature should
+			be constituted for future use in the field of synthetic biology. Based
+			on the information gathered according to new nomenclature a professional
+			database should be constructed to address the needs of synthetic biology.
+			This will enable easy information exchange and exhibition globally.
+			Secondly, although there are enough information about parts exists on
+			parts registry database, the information which is provided for parts
+			need to be ordered urgently. Furthermore, there should be new experimental
+			standards which must be introduced to groups in the part submission
+			process for the subtitle “working condition”. These experimental standards
+			will be important because the experimental details about parts are not
+			satisfying the needs of wet-lab biologists for the design and the construction
+			of new Biobricks.</p>
+		</div>
+	</div>
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div id="miscellaneous5" class="item">
+<div class="content2">
+<div class="text">
+<h2>Sponsors</h2>
+<ul id="sponsorlist">
+<li><img src="http://tecrubem.net/wp-content/uploads/2009/09/tubitak.jpg" width="200" height="200"></li>
+<li><img src="https://static.igem.org/mediawiki/igem.org/0/06/METU-Surat.jpg"></li>
+<li><img src="https://static.igem.org/mediawiki/igem.org/6/64/Teknokent.jpg"></li>
+<li><img src="https://static.igem.org/mediawiki/igem.org/d/d8/Sentegen.jpg"></li>
+</ul>
+</div>
+</div>
+</div>
+<div class="clear">
+</div>
+<!-- 6th row -->
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div id="project6" class="item">
+	<div class="content2">
+		<div class="text">
+			<h2>Algorithm</h2>
+			<p>In this section, the step by step functioning of our application,
+			along with the encapsulation of the algorithmic concepts of ‘standardization’
+			of functional iGEM devices are depicted in pictorial forms called flowcharts.
+			Rectangular boxes represent the encapsulation of implementations of
+			the computer programs to perform the particular tasks stated in that
+			box on the flowcharts. These boxes are sometimes called subprograms,
+			objects or packages in Object Oriented software Engineering context.
+			The diamonds represent decision branching and they are found between
+			two rectangular boxes. The arrows show the direction in which subprograms
+			work and communicate. The subprogram at the head of the arrow starts
+			executing after the termination of the subprogram at the tail of the
+			arrow. Following flowcharts are the high level representations of our
+			algorithms developed for the BioGuide software.</p>
+			<br>
+			<h3>1</h3>
+			<img src="https://static.igem.org/mediawiki/2010/9/95/Metu-algorithm1.png" />
+			<p><span>Diagram 1. Flowchart of collection, formatting and storage
+			of devices data algorithm</span></p>
+			<p>Information about the iGEM parts had to be collected in a standardized
+			format for our application to function properly. Following data collection
+			custom subprograms is needed to parse and forward the data the application’s
+			database. In order to achieve this we have designed and implemented
+			the algorithm shown in diagram 1. In this algorithm, the first stage
+			was to find the list of part IDs of devices which were supplied by iGEM
+			in Spring 2010 distribution. This information has been collected from
+			two sources 1) plate files in excel format which was available online
+) device data provided in xml format, both provided by iGEM. The last
+			step in the algorithm was to send the collected partID data to the application’s
+			database.</p>
+			<br>
+			<h3>2.</h3>
+			<img src="https://static.igem.org/mediawiki/2010/e/e6/Metu-algorithm2.png" />
+			<p><span>Diagram 2. Flowchart for BioGuide execution before and during
+			user interaction</span></p>
+			<p>Diagram 2 presents the main algorithm, which shows how BioGuide application
+			works. In BioGuide the major components are device and Biobrick graphs.
+			While the device graph represents input-output (promoter-regulator)
+			compatibility combination of iGEM devices, the Biobrick graph represents
+			combinations of atomic parts assembled in a device or system. The flowchart
+			shows how these graphs are created and embedded into the program, which
+			displays both of the graphs to the user when launched. Application presents
+			few interactive options to the user when started, which were shown on
+			the flowchart under the horizontal, bolded line. As shown on the diagram
+, there are four interactive tasks BioGuide can do, where the device
+			and Biobricks graphs are utilized. Upon clicking a node on a devices
+			or Biobricks graph, that node changes in size and color and the various
+			functions shown on the flowchart can be performed then after.</p>
+		</div>
+	</div>
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="clear">
+</div>
+<!-- 7th row -->
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div id="project7" class="item">
+	<div class="content2">
+		<div class="text">
+			<h2>Graph Modeling</h2>
+			<h3>Graphical Modeling for Bio-Guide</h3>
+			<h4>Introduction</h4>
+			<p>Graphical Modeling Theory has been applied to construct four different
+			graphs where relations of atomic parts, devices and systems and the
+			functional combinations that can build new constructs are presented
+			for the iGEMs parts registry database. Three graphs are composed of
+			iGEM devices and one graph is based on Biobricks. Each graph comprises
+			a set of vertices or nodes and a set of edges. In the set of nodes each
+			node represents a device, while in the set of edges each edge represents
+			the input-output combination of the nodes. These graphs are directed
+			graphs as the edges are created according to input-output combination.
+			All compatibilities between a regulator and a promoter of an edge is
+			created, where the source of this edge is the device with the corresponding
+			regulator and target of the edge is the device with the promoter in
+			concern.</p>
+			<img src="https://static.igem.org/mediawiki/2010/3/3f/Metu-node1.png" />
+			<p><span>Fig. 1: A node representing a device</span></p>
+			<img src="https://static.igem.org/mediawiki/2010/1/14/Metu-node2.png" />
+			<p><span>Fig. 2: Arrow representing an edge between two nodes</span></p>
+			<p>The atomic structures used in our graphical model have been represented
+			in Figures 1 and 2. A node is represented with a solid circle where
+			the label, the part/device ID according to iGEM standards, of the device
+			is marked on the foreground. The blue arrows between nodes connect the
+			related devices, representing the input-output connectivity. End style
+			of the arrow helps us to determine the direction of the node, like in
+			Figure 2 where the node labeled BBa_S03520 is the source and BBa_JO9250
+			is the target.</p>
+			<br>
+			<h3>Directivity</h3>
+			<p>All the four constructed graphs build for BioGuide are directed graphs.
+			So that, for every edge there must be a single source and a target.
+			There is no single edge which is bidirectional. In mathematical form
+			this can be represented as:</p>
+			<p>If an edge e has node v as source and node w as target then the edge
+			can be expressed as</p>
+			<img src="https://static.igem.org/mediawiki/2010/6/6c/Metu-equation1.png" />
+			<p>For a directed graph the combination (v, w) is totally different
+			from (w, v). Therefore,</p>
+			<img src="https://static.igem.org/mediawiki/2010/a/ac/Metu-equation2.png" />
+			<p>The direction of the edges has been represented with the arrows,
+			as explained in Figure 2.</p>
+			<br>
+			<h3>Connectivity</h3>
+			<p>The nodes forming their own sub-graphs disconnected from the rest
+			of the nodes have been recognized, which showed us the presence of incompatibility
+			between few regulators and promoters of the devices. We have observed
+			this disconnection in all four of our graphs. The basis of the disconnection
+			has been shown in Figure 3, where the two sub-graphs without any edge
+			that connects them to the main graph has been presented on the right
+			hand side of the diagram. These features classify our graphs as disconnected
+			graphs [1].</p>
+			<img src="https://static.igem.org/mediawiki/2010/8/8b/Metu-node3.png" />
+			<p><span>Fig. 3: A zoomed in screenshot showing two sub-graphs within
+			the disconnected graph.</span></p>
+			<br>
+			<h3>&quot;Semi-Simplicity&quot;</h3>
+			<p>A simple graph is a graph in which no more than one edge contains
+			the same set of nodes. So, in a simple graph it is not possible to find
+			more than one edge with the same source and the same target. Additionally,
+			an edge with the same source and target, forming a loop is not allowed.
+			But, in synthetic biology it is possible to construct a device consisting
+			of devices or bio bricks of the same species or type. Accordingly, our
+			graphs are simple graphs with an exception of possible self-containing
+			loops, where the edge starts from and ends on the same node. Our graphs
+			have an exception of having loops and due to this permitted flexibility
+			our graphs are &quot;semi-simple&quot;.</p>
+			<p>For general information about graphs refer to:</p>
+			<p><span><a href="http://en.wikipedia.org/wiki/Graph_(mathematics)">
+			[1] http://en.wikipedia.org/wiki/Graph_(mathematics)</a></span></p>
+		</div>
+	</div>
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="clear">
+</div>
+<!-- 8th row -->
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div id="project8" class="item">
+	<div class="content2">
+		<div class="text">
+			<h2>Results</h2>
+			<ul>
+				<li>In order to develop BioGuide algorithm, there was a need to
+				reorganize and normalize parts information database in partsregistry.org.
+				Information of the parts was processed and developed from partsregistry.org
+				which includes the PartID, PartName, RFC values, etc , designer
+				and contact information and parameters to build a standardized template
+				for our algorithm to run smoothly. </li>
+				<li>Database standardization is done by analyzing iGEM Spring 2010
+				distribution and collecting information needed for the standardized
+				parts. Also new parameters are assigned according to parts input-output
+				model like : Inducer, Activator, Repressor, Inhibitor</li>
+				<li>For each promoter we have assigned their inducers or repressors
+				as input and for protein generator parts we have assigned generated
+				proteins as output which maybe activator or repressor of other devices.
+				</li>
+				<li>iGEM devices are depicted in pictorial forms called flowcharts,
+				encapsulation of implementations , decision branching and direction
+				are milestones of our algorithm. Following flowcharts are the high
+				level representations of our algorithms developed for the BioGuide
+				software.</li>
+				<li>We run our algorithm on the real combination dataset in order
+				to build our input/output relations graphs. We also collected the
+				subpart assembly order, such as 1st: promoter, 2nd:rbs, 3rd:coding
+				seq, any internal parts and the Last: terminator. Each specific
+				Biobrick type has been assigned a number as a unique image ID from
+to 19. </li>
+				<li>ImageID assembly orders for each construct have been used to
+				extract the type information for each subpart with that construct.
+				This innovative approach helped us to reveal 400 possible brick
+				combinations present within the 3x384 well plates distributed by
+				iGEM in Spring 2010</li>
+				<li>Four different graphs were constructed based on graphical modeling
+				theory where relations of atomic parts, devices and systems and
+				the functional combinations that can build new constructs are presented
+				for the iGEMs parts registry database. Three graphs are composed
+				of iGEM devices and one graph is based on Biobricks.</li>
+				<li>Each graph comprises a set of vertices or nodes and a set of
+				edges. In the set of nodes each node represents a device, while
+				in the set of edges each edge represents the input-output combination
+				of the nodes.</li>
+				<li>We arrange a survey to analyze user needs and response, According
+				to our survey results, 244 participants are completed our survey
+				between 10 to 22.10.2010, 57% of the participant had scientific
+				degrees from B.Sc to Professor and 18% had graduate degrees. 18%
+				of participants are enrolled in their teams as either Instructors
+				or Advisors.INSA-Lyon, Lethbridge, WashU are dedicated as collaborators
+				with more than 60% team participation. You can learn more on survey
+				results on our collaboration page</li>
+			</ul>
+		</div>
+	</div>
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="clear">
+</div>
+<!-- 9th row -->
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div id="project9" class="item">
+	<div class="content2">
+		<div class="text">
+			<h2>Attribution and Contributions</h2>
+<p>The BioGUIDE software is a proud product of METU_TURKEY_SOFTWARE group where the students have presented the problem and come up with the solution with minor advising. This project was not a part of an ongoing project in any of the advisors.</p>
+ <p>The biologist of the team have done the preliminary database standardization by analyzing and collected data from the iGEM Spring 2010 distribution. All the algorithms have been developed by the soon-to-be computer scientist in the group. The Parts registry survey and standardization of the database information on parts have been developed through a colloborotative effort within the group. </p>
+<p>Additionally all the logo, illustrations, animations, video and other visual media and web design has been created by the design team in the group.</p>
+		</div>
+	</div>
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="clear">
+</div>
+<!-- 10th row -->
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div id="project10" class="item">
+	<div class="content2">
+		<div class="text">
+		<h2>Development Plans and Project Management</h2>
+<p>The application we are developing can be used by all iGEM members and it’s data is increasing very fast as the iGEM becomes a bigger organization.  Moreover, other data resources like NCBI can be imported to this application, hence the user group of application is gets bigger and bigger. In such a situation, extendibility of the application is vital. New data resources and new functions should be added easily. </p>
+ <p>Before starting to think about those, first we have to ask to other teams and iGEM headquarters about the BioGuide 1.0 to see the missing points in our idea, and to check our theories. Until developing this idea we were not using professional software approaches. We were planning our weekly tasks and doing those as in the notebook. </p>
+<p>After finding a novel software project we have to change our approach. We have to use professional software development approaches to develop such an application to be able to state the requirements exactly and to use a common language between software oriented and biology oriented members in the team.</p>
+<p>As we mentioned above, our software can be extended, and new data resources can be imported. The requirements are changing and the problem can be understood better in time.  Extreme Programming Approach is developed for such software projects. That is the approach we are going to use in BioGuide2.0</p>
+		</div>
+	</div>
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="clear">
+</div>
+<!-- 9th row -->
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<div class="item">
+</div>
+<script type="text/javascript">if (window.runOnloadHook) runOnloadHook();</script>
+<div id="menu">
+	<ul class="navmenu">
+		<li>
+		<div class="menutop menusingle">
+			<a class="panel" href="#home">Home</a></div>
+		</li>
+		<li>
+		<div class="menutop menusingle panel">
+			<a class="panel" href="#team">Team</a></div>
+		</li>
+		<li>
+		<div class="menutop menusingle panel">
+			<a class="panel" href="#motivation">Motivation</a></div>
+		</li>
+		<li>
+		<div class="menutop menusingle panel">
+			<a class="panel" href="#scope">Scope</a></div>
+		</li>
+		<li>
+		<div class="menutop">
+			<a class="panel" href="#project">Project</a><div class="toggle toggle-closed">
+				+</div>
+		</div>
+		<ul class="submenu">
+			<li><a class="panel" href="#project">Introduction</a></li>
+			<li><a class="panel" href="#project2">Design</a></li>
+			<li><a class="panel" href="#project3">Material</a></li>
+			<li><a class="panel" href="#project4">Methods</a></li>
+			<li><a class="panel" href="#project5">Database Standardization</a></li>
+			<li><a class="panel" href="#project6">Algorithm</a></li>
+			<li><a class="panel" href="#project7">Graph Modeling</a></li>
+			<li><a class="panel" href="#project8">Results</a></li>
+			<li><a class="panel" href="#project9">Attribution and Contributions</a></li>
+			<li><a class="panel" href="#project10">Development Plans</a></li>
+		</ul>
+		</li>
+		<li>
+		<div class="menutop menusingle panel">
+			<a class="panel" href="#notebook">Notebook</a></div>
+		</li>
+		<li>
+		<div class="menutop panel">
+			<a class="panel" href="#download">Download</a><div class="toggle toggle-closed">
+				+</div>
+		</div>
+		<ul class="submenu">
+			<li><a class="panel" href="#download">Executable and Code</a></li>
+			<li><a class="panel" href="#download2">User Guide</a></li>
+			<li><a class="panel" href="#download3">Supporting Tools</a></li>
+			<li><a class="panel" href="#download4">Contact</a></li>
+		</ul>
+		</li>
+		<li>
+		<div class="menutop panel">
+			<a class="panel" href="#miscellaneous">Miscellaneous</a><div class="toggle toggle-closed">
+				+</div>
+		</div>
+		<ul class="submenu">
+			<li><a class="panel" href="#miscellaneous">Collaboration</a></li>
+			<li><a class="panel" href="#miscellaneous2">Human Practices</a></li>
+			<li><a class="panel" href="#miscellaneous3">Safety</a></li>
+			<li><a class="panel" href="#miscellaneous4">Future Plan</a></li>
+			<li><a class="panel" href="#miscellaneous5">Sponsors</a></li>
+		</ul>
+		</li>
+	</ul>
 </div>