#412 In-silico cloning tools
I think Stefan means not only the drawing of plasmid maps but the creation
of new constructs in the computer before doing it at the bench.
This is a field where there are currently only commercial packages
available like VectorNTI and Clone Manager (
http://www.scied.com/pr_cmpro.htm\) etc.
Clone manager is there since the times of MS-DOS but the prices have
increased substantially. They used to advertise the software with the
slogan: "It costs only as much as a cloning kit for the lab" - which was
in the range of 300,-USD.
The most important functions, which I think should be implement first are
the cloning operations.
So e.g.
- take plasmid1, open the multi cloning site with BamHI and EcoRI
- take plasmid2, cut out a fragment with BglII and EcoRI
- ligate the fragment from plasmid2 into plasmid1
(BamHI and BglII have compatible ends which can be ligated, so an
algorithm is needed to check this)
- draw a map of the newly created plasmid3
This is a rather simple example.
There can be more complex procedures like Klenow fill in (blunt end
ligation of incompatible restriction sites) or the use of more than 2
fragments in one ligation.
I think most of the functions needed for this are already present in
EMBOSS.
It shouldn't be so complicated to create an application which uses
functions from restrict, cutseq, pasteseq to accomplish the above
mentioned task.
Although it's probably not so trivial to make this happen before the
release next week ;-)
Discussion
More comments from lists:
I would find this kind of in silico cloning great addition to EMBOSS.
As an example of (a free?) drawing program for plasmids, I use PlasMapper
(http://wishart.biology.ualberta.ca/PlasMapper/ , source code is at least
available on the site). Here is an example I made from their own selection
of plasmids (hopefully valid link for a while still):
http://wishart.biology.ualberta.ca/PlasMapper/jsp/displayPlasmidMap.jsp?fileName=plasMap26_1323082022185.png&fileFormat=png
I like the fact that it includes a number of predefined features in
plasmids as built-ins, so that you only need to include the "unique"
features in your own plasmids (and I am sure the set of built-ins could be
expanded much further). Outputs svg too, which is brilliant for editing
later on.
> "cirdna" and "lindna" are nice and do their job most of the time. In my
> view, the problem is the input file format. Maybe a converter from
> embl/genbank to *.crip or *.linp would be a good start? Or adding the those
> formats to the output options of seqret?
We do already support "draw" an a report output format.
If we add it as a feature output format you can use featcopy (or seqret
-feat) to create a cirdna or lindna input file.
We can then work on the feature format to add extra information by
feature type.
We could also add an application to merge a set of feature inputs so you
could combine genbank/embl files with restriction map output, then use
the results as input.
On Sun, 4 Dec 2011 11:25:56 +0100, Stefan wrote:
> are there any news in plasmid documentation and in-silico cloning
> with
> EMBOSS?
Pierre Lindenbaum wrote a nice little program called "cloneit" for
figuring out cloning
strategies. That is, specifically what series of reactions to use to
insert a particular
piece of DNA into a vector. Not sure if that is what you mean by
"in-silico cloning" or not. There is
a separate cgi version for web use. Here is the paper:
http://www.ncbi.nlm.nih.gov/pubmed/9682060?dopt=Abstract
The original distribution site is long since off line, but the code
says that it may
be redistributed (and incorporated in noncommercial software, but see
the exact wording
for details.) Anyway, if anybody wants to have a look, I packed up our
copies and put
them here:
http://saf.bio.caltech.edu/pub/software/molbio/cloneit.tar.gz
http://saf.bio.caltech.edu/pub/software/molbio/cloneitcgi.tar.gz
This is not a graphics program, it is a reaction planning program.
As for the graphical output of plasmid diagrams, historically none of
the drawing programs
does exactly what the end users want. (These get closer and closer,
but never quite cover
all the bases). For that reason it is really important that the
graphics driver be able to
output to an object format that can then be imported into a drawing
program and edited there.
Modifying an image never turns out as nicely. When going to object
formats it is key that
text remain text and not be converted into line segments or
paths. Users get really frustrated when they can't edit labels or
change fonts or font sizes.
Locally we have a hacked up GCG driver that emits cgm format for the
GCG drawing programs.
Nowadays going to SVG would make more sense.
While it is sometimes possible to read PDF back into a drawing program
like inkscape, text imported
that way is very hit and miss, mostly miss. Often it comes through
with each
letter as a separate text object, which is no fun at all to work with.
Other times it will come in with
each letter separately kerned, and when that kerning is removed, the
text jumps all over the place in
unpredictable ways. Why would you remove the kerning? Because there
is another bug/limitation
in inkscape where kerned text is automatically converted to images when
exporting to emf or wmf format,
as when trying to move that image into a powerpoint document. Moving
rotated text between various
programs is the most unreliable operation, as far as I can tell. For
instance, I have never found
a way to get text which runs at an angle other than 0 degrees from
inskcape into powerpoint with that
angle intact. The text comes through, but the angle is lost.