DSM 36, ATCC 842, BUCSAV 162, CCM 1459, JCM 2507, LMG 13294, NCIB 8158, NCTC 10343, CCUG 7426
과거에는 StrainInfo라는 사이트에서 특정 균주 번호를 가지고 이것이 표준 균주(type strain)인지, 그리고 다른 균주 번호는 어떤 것이 있는지를 확인할 수가 있었다. 그런데 여기를 최근 방문해 보면 다음과 같은 슬픈 소식이 눈에 뜨인다. 2019년 1월 1일부터 '영업 중단'인 것이다.
StrainInfo has permanently been put out of commission and will no longer be available.
1-januari-2019
이를 대신할 수 있는 웹사이트는 무엇이 있을까? 바로 DSMZ에서 운영하는 BacDive(The Bacterial Diversity Metadatabase)가 이에 해당한다. 이름을 참 잘 지었다고 생각한다. 단, 완벽하지는 않음에 주의해야 한다. 예를 들어서 Clostridium sporogenes의 표준 균주인 NCTC 13202는 Public Health England(NCTC를 관리하는 기관)에서는 ATCC 3584임이 잘 나타나지만(근거), BacDive에는 이 번호로 찾기가 어렵다.
연구자들이 개별적으로 근처에 있는 컬쳐 콜렉션으로부터 어떤 종의 표준 균주를 입수하여 시퀀싱을 하여 등록을 하면 이는 그대로 INSDC(International Nucleotide Sequence Database: DDBJ, EMBL-EBI & NCBI)의 데이터베이스에 등록이 된다. 특정 종의 모든 유전체를 다운로드하여 포괄적인 comparative genomic analysis를 하는 경우 이는 상당한 번거로움을 초래한다. 근본적으로 동일한 균주에 대한 레코드가 중복하여 존재하는 것이기 때문이다. 그래서 보통은 assembly level이 높은 것 하나만 택하여 쓰기도 한다. 시퀀싱 결과가 표준 균주에서 유래했는지의 여부는 RefSeq 혹은 GenBank의 assembly summary 파일(설명 파일)에서는 22번째 컬럼인 "relation_to_type_material"의 값이 'assembly from type material'인지를 이를 참조하면 된다. 그러면 표준 균주가 아니지만 다른 번호를 갖는 동일한 균주의 중복된 서열을 정리하려면? BacDive를 고독하게 들이파는 수밖에...
하지만 동일한 (표준)균주라 해도 각 기탁 기관에 배포된 뒤 유지를 하는 과정에서 조금씩 변이가 생길 수도 있다. 그렇기 때문에 독립적인 기관에서 같은 균주를 시퀀싱한 복수의 결과를 가끔은 진지하게 들여다볼 필요성은 있다. 간단한 사례를 들어보자. 재조합 단백질의 대량 생산에 쓰이는 유명한(?) 대장균인 Escherichia coli BL21(DE)의 유전체 서열은 완성된 것으로서 두 건이 존재한다. Assembly accession으로는 GCF_000022665.2와 GCF_000009565.1이다. 전자는 나의 작품이고(KRIBB) 후자는 오스트리아의 Universität für Bodenkultur Wien에서 등록한 것이다. Journal of Microbiolgy에 논문(PMID 19786035)이 출간된 것이 2009년이니 10주년 기념을 뭔가 해야 되는데...
두 유전체의 길이는 각각 4,558,953 bp와 4,558,947 bp이다. 딱 6 bp의 길이 차이에 해당한다. 서열 내부를 서로 비교하면 SNV 수준의 차이가 있을지도 모른다. 이 정도라면 시퀀싱 결과가 내포하는 오차의 범위 내라고 보아도 무방하고, 어쩌면 실제로 두 샘플 사이에 존재하는 염기의 차이를 반영하는 것일지도 모른다. 이에 대해서 학문적인 관심을 가지고 집중적으로 연구하는 것도 재미있는 일이 될 것이다.
내가 등록한 대장균 BL21(DE3)는 EZBioCloud에서 검색되지 않는다. 반면에 오스트리아에서 시퀀싱한 게놈은 등록이 되어 있다. EZBioCloud는 내가 알기로 한 균주에 대한 유전체 서열이 중복하여 존재하는 경우 어느 하나만 유지한다. 위에서 살펴본 Clostridium sporogenes의 경우도 DSM 795만이 type으로 등록이 되어 있다. 그러면 왜 EZBioCloud에서는 대장균 BL21(DE3)의 유전체 정보에 대해서 시기적으로도 먼저 공개되었고 논문도 출간된 우리 것을 택하지 않고 오스트리아의 것을 선택하였단 말인가. 살짝 자존심이 상하려고 하네~
EZBioCloud에서 찾은 어떤 유전체 정보의 assembly accession, 즉 GCA_000111222.3을 RefSeq에서는 찾지 못할 수도 있다. RefSeq에 있는 것이 최신 버전이라면(GCF_000111222.4) 이는 당연하다. 매일 증가하는 NCBI의 유전체 정보가 EZBioCloud에 실시간으로 반영되지는 못하기 때문이다. 아마 몇 달에 한번 정도의 업데이트가 있을 것이다. 또 다른 가능성으로는 같은 서열이라 해도 RefSeq에서는 reject된 유전체가 종종 존재한다. 즉 GCA_000111222.1(GenBank)는 NCBI에 등록된 상태이나 이와 동등한 RefSeq 레코드인 GCF_000111222.1은 없는 경우이다. Pseudogene이 너무 많거나, contig의 수가 너무 많거나 등이 사유가 있을 때 RefSeq에는 오르지 못한다. RefSeq에서 배제되는 구체적인 이유에 대해서는 다음을 참고하라. 이런 유전체는 위에서 소개한 assembly summary 파일의 21번째 "excluded_from_refseq" 컬럼에 나름대로의 사연을 담게 된다.
Assembly anomalies and other reasons a genome assembly may be excluded from RefSeq
댓글 없음:
댓글 쓰기