Помимо BAM файла работа элайнера Subjunc завершается генерацией еще одно важного файла – файла в формате BED, содержащего список
идентифицированных сплайсинговых событий. Формат BED (акроним от англ. Browser
Extensible Data) является специализированным форматом организации и хранения
генетических данных, разбитых на геномные интервалы. Первоначально этот формат
был предложен разработчиками геномного обозревателя UCSC Genome Browser для удобств представления
данных в окне обозревателя, но в последующем получил более широкое
распространение и в настоящее время используется при решении многих
аналитических задач в биоинформатике.
Спецификация формата BED.
BED файлы содержат два раздела: необязательный раздел комментариев и обязательный раздел данных. Все строки раздела комментариев начинаются с символа # и могут содержать любую информацию. Эти строки игнорируются при загрузке файла.
Раздел данных включает множество строк (или “BED записей”)
– по одной на один геномный интервал, содержащий какой-то признак (характеристику или функциональный элемент генома; см.
“Формат файлов GFF”). При просмотре BED файла в геномном обозревателе все эти строки загружаются и отображаются в
окне обозревателя в виде одного трека. Перед строками с данными может находиться
строка с атрибутами (track line), контролирующими графическое отображение данных в обозревателе.
Эта строка начинается словом track, после которого указаны графические атрибуты (один
или несколько) в виде пар attribute=value, разделенных пробелом. Описание всех графических
атрибутов можно найти в разделе “Track lines” на странице геномного обозревателя UCSC Genome Browser, посвященной аннотации
пользовательских данных.
Каждая строка с данными разбита на три обязательных и
девять необязательных полей, разделенных либо пробелом, либо табуляцией. Обязательными
полями являются:
q chromStart – начальная координата признака в хромосоме или скафолде. При этом нужно учитывать, что, согласно оригинальной
спецификации формата BED, первый нуклеотид в хромосоме имеет координату 0;
q chromEnd – конечная координата признака в хромосоме или скафолде. Согласно оригинальной спецификации формата BED нуклеотид, соответствующий chromEnd, не отображается в окне геномного обозревателя.
К необязательным полям относятся:
q name – название признака;
q score – бальная оценка
признака (в балах от 0 до 1000). Если содержимое BED файла
загружено в геномный обозреватель, а в строке атрибутов графическому атрибуту useScore присвоено значение “1”, то это поле используется для
заливки изображений признаков оттенками серого (выше бал – интенсивнее заливка);
q strand – прямая (+) или
обратная (–) цепь, в которой локализован признак;
q thickStart – начальная
координата для графического изображения признака в виде закрашенного
прямоугольника (если отсутствует, то используется значение поля chromStart);
q thickEnd – конечная
координата для графического изображения признака в виде закрашенного
прямоугольника (если отсутствует, то используется значение поля chromEnd);
q itemRgb – RGB кодировка
цвета графического изображения признака (например, код 0,0,255 соответствует синему).
Если содержимое BED файла
загружено в геномный обозреватель, то изображение признака будет цветным при
условии, что в строке атрибутов графическому атрибуту itemRgb присвоено значение “on”. В противном случае признак
будет отображен черно-белым;
q blockCount – количество
под-признаков внутри признака (например, экзонов в транскрипте, считываемом с
геномного интервала);
q blockSizes – линейные размеры под-признаков,
входящих в состав признака. Размеры записываются в одну строку через запятую
без пробелов. Количество цифр в такой строке должно быть равно значению поля blockCount;
q blockStarts – начальная
координата каждого под-признака. Начальная координата рассчитывается
относительно значения поля chromStart. Самый первый под-признак имеет начальную координату,
равную 0, так как его начало совпадает с началом признака. Соответственно,
последний под-признак имеет начальную координату, равную значению поля chromEnd минус
линейный размер под-признака, указанный в поле blockSizes.
Особенности BED файлов,
генерируемых элайнером Subjunc.
Итоговые BED файлы, генерируемые элайнером Subjunc, организованы как
стандартные 12-польные файлы, но с некоторыми отличительными особенностями.
Во-первых, в обязательном порядке в названии таких файлов используется суффикс junction, чтобы отметить,
что они содержат данные о сплайсинговых событиях (под сплайсинговым событием,
или splicing event, подразумевается полностью сформированный экзон-экзонный стык (соединение
или переход; exon-exon junction) в зрелой молекуле РНК).
Во-вторых, в этих
файлах обязательно присутствует одна строка с комментариями. В действительности
она содержит не комментарии, а названия полей файла, причем некоторые из этих
названий отличаются от общепринятых в BED файлах.
В-третьих,
содержание некоторых полей хотя и не отличается глобально от прописанного в
официальной спецификации формата BED, но имеет свою специфику. Поэтому мы рассмотрим эти
поля более подробно.
q Chr – по
значению полностью соответствует полю chrom в официальной спецификации.
q StartLeftBlock – по значению
соответствует полю chromStart в официальной спецификации, однако термин Block, используемый в junction файлах элайнера Subjunc, требует отдельного
пояснения. Как уже обсуждалось в разделе “Парадигма картирования seed-and-vote:глобальное картирование RNA-seq ридов”,
элайнер Subjunc
идентифицирует сплайсинговые события по тем ридам, которые на уровне зрелых РНК
перекрывают стыки экзонов. При сравнении с референс-последовательностью такие
риды необходимо разделить на два (реже три) фрагмента, что бы успешно
картировать, причем разные фрагменты картируются по разным участкам генома
(экзонам гена), как это показано на нижеследующем рисунке. Совокупность перекрывающихся
фрагментов, которые принадлежат ридам одного и того же сплайсингового события и
картируются по одному и тому же экзону и именуются Block. Очевидно, что каждое сплайсинговое событие
представлено двумя блоками фрагментов – левым LeftBlock и правым RightBlock (как это показано, в качестве примера, на рисунке для
сплайсингового события JUNC00004465). Внутренние границы таких блоков совпадают,
соответственно, с 3’- и 5’-концами экзонов, по которым они картированы, внешние
же границы чаще всего находятся внутри экзонов.
q EndRightBlock – по значению
соответствует полю chromEnd в официальной спецификации (с учетом пояснений,
данных для поля StartLeftBlock).
q Junction_Name – по
значению полностью соответствует полю name в официальной спецификации. Название каждого
сплайсингового события состоит из префикса JUNC и восьмизначного
номера.
q nSupport – по значению полностью
соответствует полю score в официальной спецификации и указывает на количество
ридов, подтверждающих данное сплайсинговое событие.
q Strand – по значению полностью
соответствует полю strand в официальной спецификации.
q StartLeftBlock – по значению полностью
соответствует полю thickStart в официальной спецификации.
q EndRigthBlock – по значению полностью
соответствует полю thickEnd в официальной спецификации.
q Color – по
значению полностью соответствует полю itemRgb в официальной спецификации.
q nBlocks – по значению полностью
соответствует полю blockCount в официальной спецификации и всегда равно 2.
q BlockSizes – по значению полностью
соответствует полю blockSizes в официальной спецификации.
q BlockStarts – по значению полностью
соответствует полю blockStarts в официальной спецификации.
Ниже показан
фрагмент итогового BED файла, созданного элайнером Subjunc. В качестве
примера в этом фрагменте приведена запись тех же сплайсинговых событий, что и
на рисунке.
#Chr, StartLeftBlock,
EndRightBlock, Junction_Name, nSupport, Strand, StartLeftBlock, EndRightBlock,
Color, nBlocks, BlockSizes, BlockStarts
chr19
|
10678623
|
10679166
|
JUNC00018320
|
928
|
+
|
10678623
|
10679166
|
255,0,0
|
2
|
80,70
|
0,484
|
chr19
|
10679092
|
10679905
|
JUNC00004465
|
1046
|
+
|
10679092
|
10679905
|
255,0,0
|
2
|
100,90
|
0,723
|
chr19
|
10679827
|
10680430
|
JUNC00004614
|
1093
|
+
|
10679827
|
10680430
|
255,0,0
|
2
|
100,85
|
0,518
|
 |
Рисунок. Графическое пояснение особенностей организации BED файлов,
генерируемых элайнером Subjunc.
|
Комментариев нет:
Отправить комментарий