Difference between revisions of "Help:Registry 2.0"
m
 
(9 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 +
[[Category:Archive]]
 
The Registry web site is now 3.5 years old - it is time for a rewrite !
 
The Registry web site is now 3.5 years old - it is time for a rewrite !
 +
 +
Registry 2.0 Ideas 4/25/07
 +
 +
 +
[[Registry 2.0:Parts | Parts]]
 +
 +
[[Registry 2.0:Users | Users]]
 +
 +
[[Registry 2.0:Physical DNA | Physical DNA]]
 +
 +
[[Registry 2.0:Databases | Databases]]
 +
 +
 +
 +
  
 
The current version of the Registry web site provides these functions:
 
The current version of the Registry web site provides these functions:
Line 8: Line 24:
 
* Other tools (Blast, Subpart search, assembly lines)
 
* Other tools (Blast, Subpart search, assembly lines)
  
−
Because part data is hidden in the database, other groups cannot build tools that work with these parts. This limits the
+
Because part data is hidden in the database, other groups cannot build tools that need part information. This limits the
 
rate of development and the variety of tools in all these areas. In particular, the user interface to the Registry is set by the
 
rate of development and the variety of tools in all these areas. In particular, the user interface to the Registry is set by the
 
Registry. This problem has an obvious solution:  Provide part information in an XML format (e.g. SBML).  
 
Registry. This problem has an obvious solution:  Provide part information in an XML format (e.g. SBML).  
  
−
consists of a mySQL database, server and user interface code written in PERL,
+
Once parts are in such a format, they can be stored in a long-term data set such as D-Space, or turned over to NCBI.
−
and HTML and Javascript that run on the browser. The Registry provides functions of part display, part modification,
+
We should do this by the end of the year.
−
grouping and display of parts by category such as Terminator or iGEM2006_MIT. The Registry also supports tools
+
−
such as searching, subpart search, superpart search, assembly lines, BioBrick Blast, DNA Repositories, Wiki-like
+
−
comments on parts, user accounts and groups.
+
−
 
+
−
Because of this design, the information about each part is hidden in the database. This prevents others from making
+
−
tools that need part data.
+
−
 
+
−
Three changes to the Registry that would make adding parts much easier and would make the software
+
−
of the Registry much simpler. They would remove current functionality, but would let us move the Registry database to
+
−
NCBI or D-Space. (These changes would be implemented over the summer and we could move the data after the Jamboree)
+
−
Please start thinking about these issues.
+
  
 +
In addition, we could make three changes to the philosophy of the Registry that would make adding parts much easier and
 +
make the change to XML format much easier as well. They would remove current functionality, but this may be acceptable.
  
 
'''Accession Numbers'''
 
'''Accession Numbers'''
Line 43: Line 50:
 
Instead, we would have a list of parts. All the tables would be the same, with rows like:
 
Instead, we would have a list of parts. All the tables would be the same, with rows like:
  
−
    BB_47867    Two promoter screening plasmid v1.1 Parameter1:      10-100 copies
+
BB_47867    Two promoter screening plasmid v1.1 Parameter1:      10-100 copies
 
                              
 
                              
−
Obviously, we would loose the part icons since the types are gone, but perhaps we could let the designer
+
Obviously, we would lose the part icons since the types are gone, but perhaps we could let the designer
 
specify the icon for each part  - even user icons like:  [[Image:Ralphicon.gif]]
 
specify the icon for each part  - even user icons like:  [[Image:Ralphicon.gif]]
  
Line 62: Line 69:
  
 
Obviously, there would be no way for a lab or iGEM team to see all the parts they are working on until they are formally accepted.
 
Obviously, there would be no way for a lab or iGEM team to see all the parts they are working on until they are formally accepted.
 +
 +
'''Design Information and User Comments'''
 +
 +
We are already moving design information and user comments onto the Regsitry Wiki from the Registry database. This seems like
 +
a good transition, but why not let users all over the net make comments as they wish and use Google to find them all?
 +
 +
'''The Registry as a Search Engine'''
 +
 +
Many of the tools in the Registry (like the subpart search or the DNA Repository) could be done by a search engine (perhaps seeded
 +
with a list of labs) that hunted down references to parts. Such a search engine could publish its results in an XML format and also offer
 +
a basic web front end.
  
 
'''Summary'''
 
'''Summary'''
  
 
Summary, these changes would move the contents of the Registry more towards a static resource and away from a set of tools.
 
Summary, these changes would move the contents of the Registry more towards a static resource and away from a set of tools.
−
In my discussions with many people, they think of the Registry in just that way. It is just like Genbank, isn't it?
+
Many people think of the Registry in just that way. It is just like Genbank, isn't it?
 +
 
 
Once we have completed these changes, we can move the Registry information into some RDF/WML format (text not mySQL)
 
Once we have completed these changes, we can move the Registry information into some RDF/WML format (text not mySQL)
 
and put it on D-Space or NCBI. Then, everyone can make tools as they wish and the current Registry activity can become
 
and put it on D-Space or NCBI. Then, everyone can make tools as they wish and the current Registry activity can become
 
more of a Google-like search engine.
 
more of a Google-like search engine.
  
−
Randy
+
-Randy

Latest revision as of 15:05, 14 June 2017

The Registry web site is now 3.5 years old - it is time for a rewrite !

Registry 2.0 Ideas 4/25/07


Parts

Users

Physical DNA

Databases



The current version of the Registry web site provides these functions:

  • Part data
  • User and group accounts
  • Part viewer and editor
  • DNA Repository
  • Other tools (Blast, Subpart search, assembly lines)

Because part data is hidden in the database, other groups cannot build tools that need part information. This limits the rate of development and the variety of tools in all these areas. In particular, the user interface to the Registry is set by the Registry. This problem has an obvious solution: Provide part information in an XML format (e.g. SBML).

Once parts are in such a format, they can be stored in a long-term data set such as D-Space, or turned over to NCBI. We should do this by the end of the year.

In addition, we could make three changes to the philosophy of the Registry that would make adding parts much easier and make the change to XML format much easier as well. They would remove current functionality, but this may be acceptable.

Accession Numbers

We could dramatically simplify Adding Parts to the Registry if we removed the need to select a part name. Instead, we could use Registry-generated accession numbers. We could start with BB_00001 This would eliminate the letters in the part name as well. In the past we have found that the users like to arrange patterns in the part numbers, but I don't know how important that really is now.

No Types or Categories

The second change that would simplify the registry and part management would be the elimination of part types and categories. Instead, we could do a free-text search and build a table of the resulting parts. Of course, the part designer would be able to add key words inside comments or something and we would seed them with things like the group name and current category. We would probably lose the parameter and table formatting we have now (for example RBS strength or terminator efficiency). Instead, we would have a list of parts. All the tables would be the same, with rows like:

BB_47867 Two promoter screening plasmid v1.1 Parameter1: 10-100 copies

Obviously, we would lose the part icons since the types are gone, but perhaps we could let the designer specify the icon for each part - even user icons like: Ralphicon.gif

We would also lose software-enforced consistency in parameter names.

No User Groups and Unchanging Parts

The next change that would simplify adding parts would be the elimination of user groups. Instead, we could give out "Temporary Accession Numbers" freely BB_T841878417937, for example. Anyone on earth could have one. However, these would not show up in any table or any tool in the registry unless specified by number. Each one would be given a password that would be required to make changes in the part. We might (or might not) delete these parts after a month or so.

A temporary accession number could be replaced with a permanent accession number after formal application and receipt of the actual DNA for the part and approval. At that point, the part would not be editable by anyone but the registry staff, or perhaps not by anyone. Each such part would have an associated Wiki Page.

Obviously, there would be no way for a lab or iGEM team to see all the parts they are working on until they are formally accepted.

Design Information and User Comments

We are already moving design information and user comments onto the Regsitry Wiki from the Registry database. This seems like a good transition, but why not let users all over the net make comments as they wish and use Google to find them all?

The Registry as a Search Engine

Many of the tools in the Registry (like the subpart search or the DNA Repository) could be done by a search engine (perhaps seeded with a list of labs) that hunted down references to parts. Such a search engine could publish its results in an XML format and also offer a basic web front end.

Summary

Summary, these changes would move the contents of the Registry more towards a static resource and away from a set of tools. Many people think of the Registry in just that way. It is just like Genbank, isn't it?

Once we have completed these changes, we can move the Registry information into some RDF/WML format (text not mySQL) and put it on D-Space or NCBI. Then, everyone can make tools as they wish and the current Registry activity can become more of a Google-like search engine.

-Randy