Sequencing technology database?

[dan]

Hi all,

I'm planning to build a database of sequencing technologies, companies, instruments (platforms), and capabilities (i.e. run-types), not necessarily limited to NGS, but starting there initially.

An example data-point could be:
* Pyrosequencing
** Roche
*** GS-FLX
**** PE

Before we get bogged down adding data to the database, I'd like to discuss what types of data you think should be collected? i.e. what fields to include in the database?

Some ideas include: machine cost, reads per run, read length (statistics), run time, errors (error types and statistics), ...

This will be a database in the wiki, so once we've settled on a data-model, everyone can contribute to the data, allowing the community to more easily compare platforms and keep track of trends and updates.

I'm thinking simple is best, but please let me know what you think should be included in such a database :-)

[marcowanger]

Hi Dan,

You make me think of this http://www.molecularecologist.com/ne...eldguide-2012/

Hi all,

I'm planning to build a database of sequencing technologies, companies, instruments (platforms), and capabilities (i.e. run-types), not necessarily limited to NGS, but starting there initially.

An example data-point could be:
* Pyrosequencing
** Roche
*** GS-FLX
**** PE

Before we get bogged down adding data to the database, I'd like to discuss what types of data you think should be collected? i.e. what fields to include in the database?

Some ideas include: machine cost, reads per run, read length (statistics), run time, errors (error types and statistics), ...

This will be a database in the wiki, so once we've settled on a data-model, everyone can contribute to the data, allowing the community to more easily compare platforms and keep track of trends and updates.

I'm thinking simple is best, but please let me know what you think should be included in such a database :-)

[marcowanger]

Another thought is,

machine and reagent costs vary from country to country. I think it depends who you are (big institution or small, etc). And throughput depends on how much you can squeeze out..

Put it another way around, I do think it may uncover these hidden marketing strategies, reflect the true costs..

[dan]

Oooh! Nice! What license is that data :-D

[dan]

Another thought is,

machine and reagent costs vary from country to country. I think it depends who you are (big institution or small, etc). And throughput depends on how much you can squeeze out..

Put it another way around, I do think it may uncover these hidden marketing strategies, reflect the true costs..

One way round this would be to allow people to submit estimates. Then we could provide upper and lower bounds, median etc... However, the idea of the wiki is to let that kind of consensus emerge through discussion... Not sure what's best here... I guess we could just have one value, and if people complain bitterly, provide for multiple values to be added?

[marcowanger]

i think multiple values may be better. If only 1 single value is allowed, it might becomes a reference price list by manufacturer (IMHO, is useless and miss the point of community oriented).

[krobison]

I think a key bit for such a database is to timestamp all the entries on price, performance, etc. That way you could pull out trends.

The mix-and-match nature of the technologies can make life more complicated and may be fun modeling. For example, with PacBio there are separate loading and running chemistries, and right now there are two choices for each (sadly, with the same names in each one) -- C3 and XL. So you can load C3 and run XL (but I think nobody does; puts each in its weak spot), load XL and run C3 (longer reads at higher quality), load XL and run XL (longest reads but quality drop) or load C3 run C3 (if you don't have any XL kits).

[dan]

I think a key bit for such a database is to timestamp all the entries on price, performance, etc. That way you could pull out trends.

The mix-and-match nature of the technologies can make life more complicated and may be fun modeling. For example, with PacBio there are separate loading and running chemistries, and right now there are two choices for each (sadly, with the same names in each one) -- C3 and XL. So you can load C3 and run XL (but I think nobody does; puts each in its weak spot), load XL and run C3 (longer reads at higher quality), load XL and run XL (longest reads but quality drop) or load C3 run C3 (if you don't have any XL kits).

Cry...

So ... I guess... I'd call each one of these combinations a different 'capability' of the one machine?

[marcowanger]

Cry...

So ... I guess... I'd call each one of these combinations a different 'capability' of the one machine?

I think that is why we need a database for this ..

[dan]

Any more thoughts on fields to collect? Based on the link from Marco, I currently have this list of fields:
* Instrument
* Run time
* Millions of Reads/run
* Bases / read
* Yield (MB/run)

What about costs? Cost per run, cost per box? Cost of sample prep? Kits?

[marcowanger]

Any more thoughts on fields to collect? Based on the link from Marco, I currently have this list of fields:
* Instrument
* Run time
* Millions of Reads/run
* Bases / read
* Yield (MB/run)

What about costs? Cost per run, cost per box? Cost of sample prep? Kits?

I think all make sense.

[dan]

Thing is, I don't want to implement a LIMS (I don't mind doing it, but I don't have time to do it!)