Processing a genomic data structure with splice information

Abstract

A computer-implemented method for representing a genomic data structure (100) in a memory (630) of a computer system (600), comprising: receiving (202) a read (1202) and a definition of a reference genome, the reference genome being one of: (i) a linear reference genome (920) comprising multiple different linear reference sequences (R01, R02), and (ii) a graph reference genome (700, 800, 900, 902, 904, 906, 930) comprising multiple paths associated with multiple different reference sequences, wherein the read comprises two or more splices (922) aligned to the reference genome; generating (204) extended splice information (106) comprising a parameter to indicate whether the splices are aligned to a graph reference genome or a linear reference genome; encoding (206) the two or more aligned splices and the extended splice information in the genomic data structure; and storing (208) the generated genomic data structure (100) in the memory.

Description

PROCESSING A GENOMIC DATA STRUCTURE WITH SPLICE INFORMATIONField of the Disclosure

[0001] The present disclosure is directed generally to methods and systems for creating and processing a graph data structure comprising genetic information.Background

[0002] The linear reference genome, comprising a single genetic sequence, is the most prevalent model used for processing and analysis, including the alignment of reads and the calling of variants, in next generation sequencing (NGS). A linear reference genome is based on the use of a single, preferred tiling path to produce a single consensus representation of the genome. For example, the linear reference NCBI GRCh38 (Hg38) is a composite genome with approximately 93% of the primary assembly consisting of sequences from 11 individuals.

[0003] However, despite its popularity among scientists due to its ease of reference and lower requirement for computational analysis, the single tiling path of a linear reference genome is insufficient to represent the allelic diversity in complex genomic regions of most mammalian genomes. With so much genomic variation excluded, the linear reference genome introduces a pervasive reference bias. This can adversely affect the accuracy of downstream analysis. For instance, if the genomic region that contains a clinically relevant mutation of a patient is significantly different from the reference genome, then the sequencing reads of the patient in that region will not be correctly mapped to the reference, resulting in a missed call of the variant which could be critical for diagnosis and treatment. The latest human reference genome GRCh38 attempted to improve the representation of allelic diversity by including alternate loci scaffolds in regions with known alternate haplotypes (e.g., the major histocompatibility complex region), high variability (e.g., olfactory receptor regions) and large structural variants greater than 5 Kb. However, this does not adequately encompass or represent the variability found within genomes.

[0004] Over the past decades, the cost of sequencing an entire human genome has decreased dramatically. Today, sequencing the whole genome of a mammal can be less expensive than the subsequent processing and storage of the massive amounts of data generated. Consequently, it isessential to store genomic data in a manner that conserves resources for storage, processing, and transmission, in order to keep overall costs manageable and to maximize the utility of the vast quantities of genomic sequencing data now being produced.

[0005] One of the most effective ways to represent the complex genomic diversity in a reference cohort is through a genome graph, where genomic variations are captured as edges associated with different nucleotide sequences. With the advancement in bioinformatics algorithms and computational power, graph-based genome analysis will become one of the mainstream approaches for genomic studies. However, as with linear reference genomes, existing genome graphs are not designed or structured to adequately encompass or represent the variability found within the genomes of a cohort.

[0006] Many genomic sequence files and databases still store sequence information as linear sequence data. This creates obstacles when comparing such data with more recent genomic data, which are often stored in graph-based formats. Consequently, interoperability between linear and graph-based data remains problematic. In particular, challenges arise in adequately representing alignments of reads comprising concatenated exon sequences. Aligning these reads is technically demanding and represents an obstacle to interoperability between linear and graph-based genomic representations.

[0007] A further issue is that in reference genome graphs, even when all reads have been successfully aligned to a reference sequence, a read’s location within the genome may not be readily available if a graph reference genome is used for aligning the reads. This may impede understanding of the biological function that the read sequence fulfills in the organism.Summary of the Disclosure

[0008] Described herein are methods and systems for creating, processing and / or storing a genomic data structure as specified in the independent claims. Examples of these methods and systems are given in the dependent claims and the specification, and can be freely combined with each other as long as they are not mutually exclusive.

[0009] In one aspect, disclosed herein is a computer-implemented method for representing a genomic data structure in a memory of a computer system. The method comprises:receiving a read and a definition of a reference genome, the reference genome being one of: (i) a linear reference genome comprising multiple different linear reference sequences (e.g. chromosomes), and (ii) a graph reference genome comprising multiple paths associated with multiple different reference sequences (e.g. chromosomes), wherein the read comprises two or more splices aligned to the reference genome such that:■ in the case of (i) the linear reference genome, the two or more splices are aligned to different ones of the multiple different linear reference sequences, and■ in the case of (ii) the graph reference genome, the two or more splices are aligned to different ones of the paths of the graph reference genome;generating extended splice information, the extended splice information comprising a parameter to indicate whether the splices are aligned to a graph reference genome or a linear reference genome;encoding the two or more aligned splices and the extended splice information in the genomic data structure to provide a compressed representation of the two or more aligned splices and the extended splice information; andstoring the generated genomic data structure in the memory.

[0010] Creating and encoding a genomic data structure comprising extended splice information with a parameter as specified above may have the advantage of providing a data structure comprising a signal that allows a decoder to distinguish between linear-aligned splices and graph-aligned splices and to apply the appropriate decoding algorithms. When the parameter indicates graph alignment, the decoder may expect additional descriptors such as gr_path and / or pseudo-linear positions. When the parameter indicates linear alignment, splice positions and / or other data comprised in the data structure may be interpreted differently.

[0011] In existing approaches to store genomic data, the representation of splice events is limited by the underlying assumption that consecutive splice segments are aligned to the same reference sequence of a linear reference genome. This restriction creates problems when dealing with real-world genomic data, where spliced reads frequently span multiple reference sequences or, in the case of graph reference genomes, multiple alternative paths. These limitations may leadto incomplete or inaccurate reconstruction of spliced alignments, increase storage overhead, and reduce interoperability with modern reference models such as graph-based pangenomes.

[0012] In a further aspect, described herein is a computer-implemented method for representing and processing a read aligned to a reference genome in a memory of a computer system. The method comprises:receiving a genomic data structure, the genomic data structure comprising a compressed representation of a read, of a definition of a reference genome and of extended splice information comprising a parameter, the reference genome being one of: (i) a linear reference genome comprising multiple different linear reference sequences (e.g. chromosomes), and (ii) a graph reference genome comprising multiple paths associated with multiple different reference sequences (e.g. chromosomes),wherein the read comprises two or more splices aligned to the reference genome such that:■ in the case of (i) the linear reference genome, the two or more splices are aligned to different ones of the multiple different linear reference sequences, and■ in the case of (ii) the graph reference genome, the two or more splices are aligned to different ones of the paths of the graph reference genome,wherein the parameter indicates whether the splices are aligned to a graph reference genome or a linear reference genome;decoding the extended splice information with the parameter for determining if the reference genome is a graph reference genome or a linear reference genome; reconstructing a de-compressed representation of the two or more aligned splices such that the two or more aligned splices are mapped to different ones of the multiple different linear reference sequences or to different ones of the multiple different paths in the reference genome; andstoring the reconstructed, de-compressed representation of the two or more aligned splices in memory.

[0013] The described method may provide the technical advantage that read alignments spanning multiple reference sequences or multiple paths in a graph reference genome may be represented, compressed, and later reconstructed in a manner that is both accurate and resource efficient. By incorporating a parameter in the extended splice information that explicitly indicates whether the splices relate to a linear reference genome or to a graph reference genome, the decoding process may be simplified and unambiguous. This may reduce computational overhead, as the decoder may not need to infer the reference type from context, and may ensure faster and more reliable reconstruction of the alignments. Moreover, because the alignments are stored in a compressed form and reconstructed only when needed, the method may achieve significant savings in storage space and transmission bandwidth. At the same time, it may reduce CPU and memory usage during decoding by enabling selective reconstruction of only those alignments required for a given task. Overall, the method may improve interoperability, storage efficiency, and decoding performance for both linear and graph-based genomic data.

[0014] In a further aspect, described herein is a system comprising a processor and a memory. The processor is configured to execute instructions that cause the system to perform a method for representing a linear or graph-based genomic data structure in the memory, the method comprising:receiving a read and a definition of a reference genome, the reference genome being one of: (i) a linear reference genome comprising multiple different linear reference sequences (e.g. chromosomes), and (ii) a graph reference genome comprising multiple paths associated with multiple different reference sequences (e.g. chromosomes), wherein the read comprises two or more splices aligned to the reference genome such that:■ in the case of (i) the linear reference genome, the two or more splices are aligned to different ones of the multiple different linear reference sequences, and■ in the case of (ii) the graph reference genome, the two or more splices are aligned to different ones of the paths of the graph reference genome;generating extended splice information, the extended splice information comprising a parameter to indicate whether the splices are aligned to a graph reference genome or alinear reference genome;encoding the two or more aligned splices and the extended splice information in the genomic data structure to provide a compressed representation of the two or more aligned splices, the reference genome, and the extended splice information; andstoring the generated genomic data structure in the memory.

[0015] In a further aspect, a system comprising a processor and a memory is described herein, wherein the processor is configured to execute instructions that cause the system to perform a method for representing and processing a read aligned to a reference genome in the memory. The method comprises:receiving a linear or graph-based genomic data structure, the data structure comprising a compressed representation of a read, of a definition of a reference genome and of extended splice information comprising a parameter, the reference genome being one of: (i) a linear reference genome comprising multiple different linear reference sequences (e.g. chromosomes), and (ii) a graph reference genome comprising multiple paths associated with multiple different reference sequences (e.g. chromosomes), wherein the read comprises two or more splices aligned to the reference genome such that:■ in the case of (i) the linear reference genome, the two or more splices are aligned to different ones of the multiple different linear reference sequences, and■ in the case of (ii) the graph reference genome, the two or more splices are aligned to different ones of the paths of the graph reference genome,wherein the parameter indicates whether the splices are aligned to a graph reference genome or a linear reference genome;decoding the extended splice information with the parameter for determining if the reference genome is a graph reference genome or a linear reference genome; reconstructing a de-compressed representation of the two or more aligned splices such that the two or more splices are mapped to different ones of the multiple different linear reference sequences or to different ones of the multiple different paths in the reference genome; andstoring the reconstructed, de-compressed representation of the two or more aligned splices in memory.

[0016] In a further aspect, described herein is a computer-implemented method for representing a genomic data structure in a memory of a computer system. The method comprises.receiving a definition of a graph reference genome comprising edges (aka. segments or branches) and their connections, the graph reference genome comprising a linear reference sequence with pre-defined linear coordinates;identifying for each of at least some of the edges one or multiple paths that connect the edge to the linear reference sequence, the path comprising the at least one edge and optionally further ones of the edges;computing a pseudo linear position of a point (xA) on the at least one edge (edge A), the computing comprising:■ identifying an upstream and / or downstream anchor point in the path, an anchor point being a point on the path where an edge in the path is linked to one of the predefined linear coordinates of the linear reference sequence;■ identifying a predefined linear coordinate linked to the identified upstream and / or downstream anchor point;■ identifying the one of the predefined linear coordinates (px) that reflects the position of the point (xA) on the path relative to the upstream and / or downstream anchor point; and■ using the identified predefined linear coordinate (px) as the pseudo-linear coordinate of the point (xA) on the at least one aligned edge (edge A); assigning the pseudo linear position to the point (xA) in the graph reference genome; encoding the graph reference genome and the pseudo-linear coordinate in a compressed representation of the graph reference genome; andstoring the compressed representation of the graph reference genome in the genomic data structure in the memory.

[0017] In a further aspect, described herein is a computer-implemented method for representing and processing a graph reference genome in a memory of a computer system. The method comprises:receiving a genomic data structure comprising a compressed representation of a graph reference genome and of pseudo-linear coordinates, the graph reference genome comprising edges and their connections, the graph reference genome comprising a linear reference sequence with pre-defined linear coordinates, wherein each of at least some of the edges is connected to the linear reference sequence via one or multiple paths; receiving at least one linear genomic coordinate defining a genomic region of interest; searching the pseudo-linear coordinates to identify the ones of the edges or other graphbased components associated with pseudo-linear coordinates within the region of interest; selectively decoding only the identified edges or graph-based components for reconstructing a de-compressed representation of only the part of the graph reference genome associated with the genomic region of interest; andstoring the reconstructed, de-compressed representation part of the graph reference genome in the memory.

[0018] In a further aspect, described herein is a system comprising a processor and a memory. The processor is configured to execute instructions that cause the system to perform a method for representing a genomic data structure in the memory. The method comprises:receiving a definition of a graph reference genome comprising edges (aka. segments or branches) and their connections, the graph reference genome comprising a linear reference sequence with pre-defined linear coordinates;identifying for each of at least some of the edges one or multiple paths that connect the edge to the linear reference sequence, the path comprising the at least one edge and optionally further ones of the edges;computing a pseudo linear position of a point (XA) on the at least one edge (edge A), the computing comprising:■ identifying an upstream and / or downstream anchor point in the path, an anchorpoint being a point on the path where an edge in the path is linked to one of the predefined linear coordinates of the linear reference sequence;■ identifying a predefined linear coordinate linked to the identified upstream and / or downstream anchor point;■ identifying the one of the predefined linear coordinates (px) that reflects the position of the point (xA) on the path relative to the upstream and / or downstream anchor point; and■ using the identified predefined linear coordinate (px) as the pseudo-linear coordinate of the point (xA) on the at least one aligned edge (edge A); assigning the pseudo linear position to the point (xA) in the graph reference genome; encoding the graph reference genome and the pseudo-linear coordinate in a compressed representation of the graph reference genome; andstoring the compressed representation of the graph reference genome in a genomic data structure in the memory.

[0019] In a further aspect, described herein is a system comprising a processor and a memory. The processor is configured to execute instructions that cause the system to perform a method for processing a graph reference genome in the memory. The method comprises:receiving a genomic data structure comprising a compressed representation of a graph reference genome and of pseudo-linear coordinates, the graph reference genome comprising edges and their connections, the graph reference genome comprising a linear reference sequence with pre-defined linear coordinates, wherein each of at least some of the edges is connected to the linear reference sequence via one or multiple paths; receiving at least one linear genomic coordinate defining a genomic region of interest; searching the pseudo-linear coordinates to identify the ones of the edges or other graphbased components associated with pseudo-linear coordinates within the region of interest; selectively decoding only the identified edges or graph components for reconstructing a de-compressed representation of only the part of the graph reference genome associated with the genomic region of interest; andstoring the reconstructed, de-compressed representation part of the graph reference genome in the memory.

[0020] In a further aspect, described herein is a computer program enabling a processor to carry out one of the methods described herein.

[0021] In a further aspect, described herein is a computer program product enabling a processor to carry out one of the methods described herein.Brief Description of the Drawings

[0022] In the drawings, like reference characters generally refer to the same parts throughout the different views. Also, the drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of the various examples.

[0023] FIG. 1 is a schematic representation of a hierarchical genomic data structure with dataset groups, datasets, access units, and descriptors.

[0024] FIG. 2 shows a flow chart of an example encoding method for representing genomic data with extended splice information in a data structure.

[0025] FIG. 3 shows a flow chart of an example decoding method for reconstructing aligned splices using extended splice information.

[0026] FIG. 4 illustrates a computer-implemented method for computing pseudo-linear coordinates in a graph reference genome.

[0027] FIG. 5 illustrates a computer-implemented method for selective decoding of graph reference genome components using pseudo-linear coordinates.

[0028] FIG. 6 shows a block diagram of an example data processing system for encoding, processing, and decoding genomic data.

[0029] FIG. 7 illustrates a graph-based reference genome comprising edges obtained from different sources, including edges corresponding to a linear reference.

[0030] FIG. 8 shows a first path highlighted through the graph reference genome of FIG. 7.

[0031] FIG. 9 shows a second path highlighted through the graph reference genome of FIG. 7.

[0032] FIG. 10 illustrates a graph reference genome including different types of connections between edges and a linear reference sequence.

[0033] FIG. 11 illustrates computation of a pseudo-linear coordinate for a position on an edge connected to a linear reference sequence.

[0034] FIG. 12 illustrates computation of a pseudo-linear coordinate for a position on a further edge connected to a linear reference sequence.

[0035] FIG. 13 illustrates a read comprising multiple splices aligned discontinuously to different linear reference sequences.

[0036] FIG. 14 illustrates a read comprising multiple splices aligned discontinuously to different edges and paths in a graph reference genome.Detailed Description of Examples

[0037] The present disclosure describes various examples of a system and method for creating, processing and / or storing a data structure comprising genetic information.

[0038] It should be appreciated that all combinations of the foregoing concepts and additional concepts discussed in greater detail below (provided such concepts are not mutually inconsistent) are contemplated as being part of the inventive subject matter disclosed herein. In particular, all combinations of claimed subject matter appearing at the end of this disclosure are contemplated as being part of the inventive subject matter disclosed herein.

[0039] These and other aspects of the various examples will be apparent from and elucidated with reference to the example(s) described hereinafter.

[0040] In one aspect, disclosed herein is a computer-implemented method for representing a genomic data structure in a memory of a computer system. The method comprises:receiving a read and a definition of a reference genome, the reference genome being one of: (i) a linear reference genome comprising multiple different linear reference sequences (e.g. chromosomes), and (ii) a graph reference genome comprising multiple paths associated with multiple different reference sequences (e.g. chromosomes), wherein the read comprises two or more splices aligned to the reference genome suchthat:■ in the case of (i) the linear reference genome, the two or more splices are aligned to different ones of the multiple different linear reference sequences, and■ in the case of (ii) the graph reference genome, the two or more splices are aligned to different ones of the paths of the graph reference genome;generating extended splice information, the extended splice information comprising a parameter to indicate whether the splices are aligned to a graph reference genome or a linear reference genome;encoding the two or more aligned splices and the extended splice information in the genomic data structure to provide a compressed representation of the two or more aligned splices and the extended splice information; andstoring the generated genomic data structure in the memory.

[0041] According to some examples, a binary parameter is used, where a value of 0 indicates that the splices are aligned to linear reference sequences and a value of 1 indicates that the splices are aligned to paths of a graph reference genome.

[0042] In some examples, the parameter (e.g. a parameter referred to as “extended splice info flag”), is stored within the record syntax of an MPEG-G file, in the same section where other per-record flags and alignment information are encoded.

[0043] Depending on the use case scenario, a linear reference genomes or a graph reference genomes may be specified and / or referred to in the genomic data structure.

[0044] Linear reference genomes are often applied in scenarios where a stable and standardized coordinate system is required. In some examples, linear reference genomes are used in clinical and diagnostic pipelines, for example for variant calling, reporting, and regulatory submissions, where genetic variants must be described relative to a canonical reference sequence. In further examples, linear reference genomes are employed in population genomics and comparative analyses to provide a consistent framework for mapping and comparing sequencing reads across individuals or cohorts. Linear reference genomes are also widely used in functional genomics applications, such as transcriptomics or epigenomics, where experimental data are aligned to a referencesequence annotated with gene and regulatory features. Today, linear reference genomes often form the basis of public databases and genome browsers, bioinformatics tools and workflows.

[0045] However, in a growing number of application scenarios, graph reference genomes are used. The graph reference genome may be constructed at different levels of genomic diversity. For example, the graph reference genome can be constructed from multiple genome assemblies of individuals of the same species in order to generate a pangenome representation that captures single nucleotide polymorphisms, insertions, deletions, structural variants, and haplotypes occurring within the species. In other examples, the graph reference genome may be constructed from the genomes of related individuals, such as members of the same family, for use in medical genetics or inheritance studies. In other examples, the graph reference genome may be generated from genomes of multiple populations or subspecies, for example to represent pathogen or plant variation across geographic regions. In still further examples, the graph reference genome may be constructed across multiple related species to support comparative genomics or metagenomic analysis. Graph reference genomes may also be constructed to represent transcriptomic variation, such as alternative splicing isoforms, or to represent tumor-specific rearrangements in oncology applications.

[0046] According to some examples, the genomic data structure is based on (i) the linear reference genome and the presence of the extended splice information in the genomic data structure is indicated by an extended splice information flag. For example, the extended splice information flag can be or comprises a Boolean flag. For example, a variable like “extended splice info flag” may be set to a first value if extended splice information is available or set to another value otherwise.

[0047] According to some examples, the genomic data structure has a syntax according to which extended splice information has to be comprised in the genomic data structure if the reference genome is a graph reference genome. Hence, no flag is needed in this case, a decoder will, upon determining that the reference genome is a graph reference genome, automatically expect and extract extended splice information from the data structure.

[0048] According to some examples, the genomic data structure is an MPEG-G file.

[0049] According to some examples, the genomic data structure comprises multiple Access Units, and the extended splice information are integrated into Access Units of one or more of Classes P, M, I, N, or HM.

[0050] MPEG-G’s Data Classes (P, M, I, N, HM) separate reads based on how they align (perfect match, mismatch, insertion / deletion, skipped / spliced, hard-clipped). By embedding extended splice information, which may be stored in multiple different descriptors, into the right classes, the compression engine may avoid redundancy (e.g., storing splicing only where it matters), and use tailored coding schemes for each class.

[0051] A further advantage may be that selective decoding may be enabled: MPEG-G allows selective access to AUs (allowing to avoid to decode the whole dataset). If extended splice information is integrated into the AUs of specific classes, a decoder can retrieve only reads with splicing (Class N). Or, if needed, decode reads from P, M, I, HM with extended information. This may support targeted queries like “fetch only spliced reads in chrl: 100k-200k.”

[0052] A further advantage may be backwards compatibility. MPEG-G decoders expect data to be organized by AUs and classes. By extending these structures (instead of introducing a separate container), older decoders can still parse the dataset, while newer decoders interpret the extended splice fields. This may preserve compatibility with existing MPEG-G implementations while enabling richer functionality.

[0053] According to some examples, the extended splice information comprises at least one of: a splices descriptor, a graph path descriptor and a graph path position descriptor. The graph path descriptor and the graph path position descriptor may be present only in case the reference genome is a graph reference genome. Continuously aligned parts of the splices form aligned segments. The genomic data structure comprises the at least one descriptor to store encoded segment alignment information of the aligned segments such that data values stored in each of the at least one descriptors are of the same or of a similar nature. For example, a “similar” nature may mean that they are sufficiently similar that they are suitable for being encoded via the same type of compression algorithm.

[0054] In some examples, the graph path descriptor and the graph path position descriptor are only present in the genomic data structure if the reference genome is a graph reference genome to support graph-based alignments.

[0055] For example, the splices descriptor may define discontinuities in the alignment of the splices, including where and how splices occur. The graph path descriptor (which may have the variable “gr path”) may identify the sequence of paths traversed by a read or splice in a graph reference genome. The graph path position descriptor (which may have the variable “gr_path_pos”) may indicate the precise positions of splices along those graph paths.

[0056] Preferably, different descriptors are stored in the genomic data structure using different compression algorithm selected in dependence on the nature of the data comprised in the descriptors. For example, a descriptor that stores nucleotide sequence data (such as raw reads or reference fragments) is typically compressed using context-adaptive binary arithmetic coding (CABAC) with specialized probability models that exploit base composition biases. Quality scores, which have a broader symbol alphabet and high entropy, may be compressed using entropy-based methods such as arithmetic coding with run-length or differential coding to exploit redundancies. Mapping positions, splice positions, and other coordinate-like fields may be compressed, for example, using delta encoding, since successive values tend to be close together, thereby reducing the number of bits required. This adaptive selection of compression algorithms may ensure that each type of descriptor achieves high compression efficiency while retaining decoding speed and fidelity.

[0057] These descriptors may be stored, for example, as part of the extended splice information in MPEG-G records (inside multiple Access Units). They may be generated by an encoder to compactly represent complex graph- or splice-based alignments. During decoding, a decoder interprets the descriptors to reconstruct full alignments, supporting selective decoding and / or projection to linear coordinates.

[0058] In some examples, the indication whether splices are aligned to linear reference sequences or to one or more path of a reference genome graph is provided through a combination of the above-mentioned parameter and one or more descriptors.

[0059] First, the above-mentioned parameter may be provided e.g. as a variable like “extended splice info flag” to signal the presence of extended splice information. When this parameter is set to a value indicating that extended splice information is available, the splices descriptor is not restricted to a linear reference sequence but can also describe splices aligned across different linear reference sequences or across different paths of a graph reference genome.Second, the parameter dataset type is extended to include a value that identifies graph-aligned datasets. When dataset type is equal to this graph-specific value, the decoder expects that graph-related descriptors such as the gr_path descriptor and the gr_path_pos descriptor will be present together with the splices descriptor. Third, the splices descriptor itself contains fields that indicate the target of the splice: in the case of linear alignment, the field splice_seq_ID specifies the reference sequence; in the case of graph alignment, the field splice_path specifies the path of the graph reference genome. In this way, the examples of the method described herein may provide a clear and unambiguous mechanism for distinguishing whether splices are aligned to linear reference sequences or to graph paths.

[0060] The graph path descriptor and the graph path position descriptor may, according to examples, only be present for graph-based alignment data, i.e., when the reference genome is a graph reference genome.

[0061] According to examples, the extended splice information is stored in one or more of the following descriptors: a splices descriptor, a graph path descriptor, a graph path position descriptor and an rcomp descriptor.

[0062] According to examples, the extended splice information comprises one or more of the following fields and respective variables:a splice length indicating the length of the spliced region;a splice path being indicative of the path to which the splice was aligned;a splice sequence ID being indicative of the reference sequence to which the splice is aligned;a splice position being indicative of an absolute or relative position indicating where within the path or linear reference sequence a splice is aligned;a splice orientation such as forward, reverse, or undirected; andan indication if a splice transits to another one of the splices via cross-sequence / cross- path transition or via an intra-sequence / intra-path transition.

[0063] According to examples, the splices descriptor contains one or more of the following fields: the splice length; the splice sequence ID; the splice position; and the indication if a splicetransits to another one of the splices via cross-sequence / cross-path transition or via an intra-sequence / intra-path transition.

[0064] According to this or other examples, the graph path descriptor comprises the splice path.

[0065] According to this or other examples, the graph path position descriptor comprises pathbased positional coordinates of each read alignment in a graph reference. According to this or other examples, the rcomp descriptor (an existing MPEG-G descriptor) comprises the splice orientation.

[0066] For example, the graph path (gr_path) and graph path position (gr path pos) descriptors may comprise the information stored in the MPEG-G standard in accordance with subclauses 10.4.21 and 10.4.22. In particular, the gr_path descriptor may comprise a same-path flag to indicate whether the current read (or segment) is aligned to the same path in the graph as the previous one; a relative / absolute flag indicating if the current position is given as absolute coordinate from the beginning of the path or as a position relative to the previous read alignment; a delta position indicating the delta (difference) to the previous position (if the relative / absolute flag indicates a relative position); and an absolute path position (if the relative / absolute flag indicates an absolute position).

[0067] Hence, according to some examples, one or more additional descriptors are introduced in the MPEG-G standard: a new splices descriptor (to hold extended splicing information for segment alignments and to support mapping splices to different reference sequences and paths), a new graph path gr path descriptor (to hold the graph path identifier for each alignment, which may be required when dataset type = 4 (graph-aligned data)), and a new graph path position gr path pos descriptor (holding the path-based positional coordinates for each segment alignment which may include flags for same-path, relative / absolute position, delta, and absolute position) may be provided to support inter-sequence and inter-path alignment of consecutive splices of the same read, in addition to intra-sequence and intra-path alignments of the splices. The graph path and the graph path position descriptor may only be present for graph-based read alignments, i.e., for reads and their splices aligned to a graph reference genome.

[0068] In addition, according to some examples, the additional rfte descriptor may extend the existing reference transformation descriptors (rftp, rftt) to support graph reference genomes, by holding the edge IDs associated with substitutions.

[0069] During decoding, output variables are created from the extended splice information that hold the values reconstructed from the above-mentioned fields. For example, in the decoding process of the splices descriptor, the outputs can be arrays such as: splice_len[j][i][k] = length of each splice; splice_seq_ID[j][i][k] = reference sequence ID of the splice; splice_pos[j][i][k] = position of each splice; splice_same_path[j][i][k] = same-path flag.

[0070] This may be advantageous, as in the current MPEG-G standard, splice information is indirectly expressed through mapping positions, which is inadequate for handling more complex splicing scenarios, such as splices of the same read being mapped to different sequences or chromosomes. Since graph-specific identifiers and path-based coordinates are not supported, the current MPEG-G framework cannot faithfully encode splices that traverse graph edges or branch points. These limitations lead to incomplete or inaccurate reconstruction of spliced alignments, increase storage overhead, and reduce interoperability with modern reference models such as graph-based pangenomes.

[0071] In some examples, the extended splice information are used by a decoder to generate an extended CIGAR string and to present this string in an output record. The extended splices information may be part of read alignment information which is descriptive of the alignments of reads to the reference genome, including reads which may not comprise multiple splices.

[0072] For example, the MPEG variable dataset type may be used to indicate, for each dataset, whether the dataset contains linear or graph-based alignment data.

[0073] According to one example, for linear alignment data (e.g., read alignments to one or more linear reference sequences), the splices descriptor is optional and its presence is indicated by setting the extended splice information flag to 1. The extended splice information for linear alignment data may be stored entirely in the splices descriptor. For graph- based alignment data, the splices descriptor, the graph path descriptor and the graph path position descriptor are mandatory, and hence, always present. The information describing the alignment of the splices is contained across all these three descriptors.

[0074] This may be beneficial as an accurate representation of graph alignments may be provided. In a graph reference genome, a read may align to multiple possible paths. Without a graph path descriptor, the splices descriptor alone would not specify which path the splice belongsto. The graph path descriptor explicitly links splices to graph paths, ensuring unambiguous decoding and reconstruction.

[0075] A further benefit may be efficient compression and signaling: Instead of duplicating path information for each splice, a graph path value in the descriptor can be shared across multiple splices in the same read. This may reduce redundancy in storage and improve compression efficiency.

[0076] In addition, by including a graph path descriptor and a graph path position descriptor in the extended splice information, the system may ensure that the splices descriptor, the graph path descriptor, and the graph path position descriptor are or can be decoded together. This allows a decoder to immediately know both: where the splice occurs (splice pos, splice len), and which path it belongs to (gr_path). The result may be a simpler decoding logic and faster reconstruction.

[0077] The graph path descriptor according to some examples contains the path, specified as a ordered sequence of edge identifiers, for each read alignment or splice in graph-aligned data. It may complement the graph path position descriptor, which provides the corresponding coordinates on those paths. For graph-based alignments, the edge-based (local) position of the beginning or the first splice of each segment may be encoded in the graph path position descriptor.

[0078] In this way, the existing pos descriptor, which in the MPEG-G standard normally stores the mapping position of a segment, and the pair descriptor, which normally stores the mate position of a paired-end read, may be repurposed to hold pseudo-linear coordinates when required. The pseudo-linear coordinates provide a linearized view of graph-based alignments that can be directly cross-referenced with conventional linear reference genomes. At the same time, the native edgebased coordinates, also referred herein as “known” or “predefined” linear positions of the edges may remain available in the genomic data structure:

[0079] According to examples, the original graph-native coordinates are retained in newly introduced descriptors that are specific to graph-aligned data. In particular, the gr_path descriptor stores the sequence of edge identifiers that specifies the path in the graph reference genome to which a segment alignment or splice is mapped, while the gr_path_pos descriptor stores the corresponding position along that path. Together, these descriptors provide the native edge-based coordinate system of the graph. The existing pos descriptor, which normally specifies the mapping position of a segment, and the pair descriptor, which normally specifies the mate position of apaired-end read, may be repurposed to hold pseudo-linear coordinates. As a result, both the edgebased coordinates (gr path and gr_path_pos) and the pseudo-linear coordinates (pos and pair) can be present in parallel within the same dataset, thereby ensuring interoperability with graph-aware tools as well as tools relying on a conventional linear reference coordinate system.

[0080] This may enable interoperability with graph-aware analysis tools as well as tools that rely on a linear reference coordinate system. The mapping positions encoded in the existing “pos” and “pair” descriptors can be used instead for holding pseudo-linear coordinates if needed.

[0081] Hence, according to examples, the encoding comprises storing both edge-based coordinates (e.g., predefined linear positions of one or more edges of the reference graph genome) and pseudo-linear coordinates in the genomic data structure.

[0082] According to some examples, the generating of the extended splice information comprises: encoding at least some of the splice positions as absolute positions on the linear reference sequence or the path to which a splice was aligned; and optionally encoding at least some of the splice positions as relative delta values with respect to previously encoded positions.

[0083] According to some examples, splice positions are compressed using a combination of delta encoding and entropy coding: Splice positions are first represented either as absolute positions or as delta values relative to previously known positions. A flag associated with each splice position indicates whether the position is encoded in absolute form or in delta form. When delta encoding is used, the splice position is represented as the difference between the current splice position and the position of a preceding splice or segment, thereby reducing the magnitude of the values to be encoded. Both absolute and delta values are further compressed using context-adaptive binary arithmetic coding (CABAC), which exploits statistical redundancies in the distribution of splice positions, or other entropy encoding algorithms. This hybrid approach may achieve high compression efficiency while retaining flexibility for both linear and graph reference genomes. This may significantly reduce redundancy by referencing earlier absolute positions instead of repeating them.

[0084] According to examples, the generating of the extended splice information comprises: generating a graph path descriptor identifying paths of the graph reference genome traversed by the aligned two or more splices; and including the graph path descriptor in the extended splice information. According to examples, the graph path descriptor is used for indicating a path of thegraph reference genome traversed by any aligned read, including reads which do not comprise splices. Analogously, the graph path position descriptor can be used for storing and indicating the path-based positional information of each read alignment in graph-aligned data, including aligned reads which do not comprise splices.

[0085] For example, the graph path descriptor can encode a sequence of edge (aka. segment or branch) identifiers.

[0086] A graph path descriptor may, for example, comprise a compressed list of graph path identifiers, with delimiters marking transitions. It may be used to represent how reads and splice events traverse graph reference genomes. The graph path descriptor may be comprised in the extended splice information, e.g., the extended splice information of records, e.g., in type 4 datasets of the MPEG-G standard.

[0087] During encoding, an encoder may use the graph path descriptor for compact encoding of graph-based alignments. During decoding, a decoder may analyze the graph path descriptor for accurate reconstruction of read trajectories.

[0088] According to some examples, the method further comprises:generating a Reference Transform Target Descriptor - rftt descriptor - specifying the target nucleotides of a transformation, the transformation being a sequence edit operation (like substitution, insertion, deletion, inversion) applied to the linear reference sequence or to a graph edge of the graph reference genome to produce a new transformed reference sequence that supports more efficient alignment, storage, and decoding;generating a Reference Transform Position Descriptor - rftp descriptor - encoding positions of the transformation;generating a Reference Transform Edge Descriptor - rfte descriptor - associated with the reference genome, the rfte descriptor identifying edges (aka. segments or branches) of the graph reference genome to which the transformation applies; andincluding the rfte, rftp and rftt descriptors as read alignment information, in particular as the extended splice information or parts thereof, in the genomic data structure.

[0089] Creating and storing the rfte, rftp and rftt descriptors, also referred to as “reference descriptors”, may have the advantage of supporting reference-based compression of data, wherein reads or variants are described relative to a reference sequence. For example, the reference descriptors could comprise the following:rfte = edge ID, e.g., 123rftp = identify the position at an offset of, e.g. 10, from the beginning of the edge specified in rfte rftt = substitute the nucleotide (e.g. “A ”) at the identified position with the target, e.g. “T”

[0090] MPEG-G already defines reference transformation descriptors to support computed references and local assemblies. These descriptors operate in a linear reference genome model: They identify a sequence ID (chromosome, contig) and define a linear coordinate position on that sequence. However, in a graph reference genome, there may be multiple alternative edges / paths covering the same linearized coordinate. A pure linear coordinate is ambiguous — it cannot unambiguously identify which graph element (edge) should be edited. This makes the existing MPEG-G transformation system unsuitable for graph-based references.

[0091] The new rfte descriptor may have the advantage of extending MPEG-G’ s reference transformation model to graph references.

[0092] The rfte descriptor may support identifying substitutions in specific edges of the reference genome, e.g., to allow creating an edited version of the reference genome for improving the compression of aligned reads.

[0093] In a further beneficial aspect, instead of relying solely on sequence IDs and linear coordinates, rfte may directly identify a graph edge ID. Together with the Reference Transform Position Descriptor (rftp) and the Reference Transform Target Descriptor (rftt), it forms a triplet that describes which graph edges to transform (rfte), the nucleotide positions to appy the transform (rftp) and the target nucleotides (rftt). The rfte descriptor may remove ambiguity caused by multiple graph paths sharing the same linear coordinate. As each transformation applies to a unique edge ID, deterministic decoding may be ensured. Linear-only descriptors cannot distinguish between multiple paths / edges covering the same region.

[0094] A further advantage may be that the new rfte descriptor may allow applying transformations to specific edges rather than entire sequences or coordinate ranges (edge-levelgranularity). Thereby, fine-grained editing of complex graph regions with structural variants, repeats, or alternative loci may be enabled. In a further advantageous aspect, the rfte descriptor may allow the decoder to jump directly to the affected edge. This may allow avoiding scanning through large linear coordinate spaces or resolving ambiguous overlaps. Linear lookups are slower and less scalable when many alternative alleles exist. Graph reference genomes often represent thousands of samples with shared and unique edges. Hence, the rfte descriptor may enable transformations to be encoded once at the edge level, and reused across many paths. Linear transformations would require duplicating edits per sequence / coordinate, increasing storage and CPU costs.

[0095] According to one example, the method may in addition comprise the following method of processing an rfte, rftp, and rftt descriptor triplet, whereby the method is executed by a decoder, e.g., an MPEG-G decoder.

[0096] In a first step, the decoder parses control information. This step may comprise identifying that the genomic data structure comprises a dataset that is a graph reference dataset (dataset type = 5). Flags may indicate that reference transformation descriptors (rfte, rftp, rftt) are present.

[0097] The decoder reads the rfte descriptor first to identify the edge ID (or range of edge IDs) in the graph reference genome where the transformation applies. The decoder locates the edge sequence and topology of the identified edge(s) from the graph reference structure. Next in step, the decoder reads rftp descriptors to determine what transformation to apply to the identified edge(s). Examples for these transformations include: Substitution: replace bases at a given offset with another sequence; Insertion: insert a new sequence at a given anchor point; Deletion: remove bases between two anchor points; Inversion: reverse-complement a span. The rfte descriptors may include offsets, lengths, and payload sequences.

[0098] Then, the decoder processes the rftt descriptor to determine where to apply or store the results of applying the above-mentioned transformations on the above-mentioned edge(s). For example, the decoder may determine where to update a computed reference that is used for decoding alignment reads. In addition, or alternatively, the decoder may determine where in a local assembly reference (temporary reference for a region) edits should be applied, and / or if another graph-edge identified by an edge-ID should be modified.

[0099] After all the details concerning the one or more transformations have been determined, the decoder uses the information from the rfte and rftp descriptors to identify the edge(s) and the corresponding position(s) at which the nucleotides in the original reference genome are replaced by the target nucleotides specified by the rftt descriptor.

[0100] According to some examples, the decoder maintains coordinate mapping tables so that pseudo-linear coordinates and the splices descriptor remain valid even after transformations. This may ensure correct alignment of reads or variants referencing the modified graph.. This may also solve the problem of shifted positions due to the inclusion of indels (insertion deletion transformations).

[0101] The decoder may be configured to perform the decoding continuously by moving to the next rfte / rftp / rftt descriptor triplet to create triplets of decoded rfte / rftp / rftt descriptor values until all transformations (e.g., all transformations for the currently processed access unit or set of access units) are applied. Reads, variants, or splice points referencing the transformed edges can now be reconstructed accurately.

[0102] According to some examples, the reference genome is a graph reference genome and the method further comprises: identifying frequently occurring substitutions in the read alignment information to be incorporated into the reference genome through a reference transformation process; and representing the identified substitutions by their positions and nucleotide changes; in case the reference genome is a graph reference genome, representing the identified substitutions also by their edge IDs; and storing these representations in the rfte, rftp and rftt descriptors. For example, the read alignment information may be stored as read alignment dataset. The read alignment information may also comprise extended splice information being indicative of how the splices comprised in the reads are aligned.

[0103] This may have the advantage that common substitutions may be stored in storageefficient manner. By identifying frequently occurring substitutions in the alignment dataset and incorporating them into the references through a transformation process, the system may avoid having to signal the same differences repeatedly for each read. This may reduce redundancy in the compressed bitstream, improving storage efficiency and lowering transmission costs. The addressing of individual edges via the rfte descriptor may allow tying substitutions directly to graph edge IDs rather than ambiguous linear positions. Edits may be encoded in a very compactbut nonetheless complete manner as each substitution may be represented minimally by its edge ID (rfte), position (rftp), and target nucleotide (rftt). Thereby, a standardized, lightweight encoding format may be provided that may allow decoders to perform the parsing quickly and with low CPU overhead. Since the substitutions may be pre-integrated into the reference transformation process, a decoder may be enabled to reconstruct alignments against an already adapted reference. As a consequence, fewer per-read edits may need to be applied during decoding, reducing computational effort and accelerating reconstruction. Common variations incorporated once at the reference level can be reused by millions of reads. This may allow scaling the decoding process to large populations and deep sequencing datasets without linear growth in storage or processing cost.

[0104] According to some examples, the reference genome is a graph reference genome. The graph reference genome comprises one or more position-reference sequences, wherein the position-reference sequences are linear reference sequences with pre-defined linear coordinates. The graph reference genome comprises edges representing pangenomic variations connected to one another and / or to the one or more position-reference sequences. The method further comprises: computing pseudo-linear coordinates for the edges based on their distances from the upstream and downstream anchor points on the position-reference sequence; and / or computing pseudo-linear coordinates for the two or more aligned splices (and for other read alignments, if any) based on their mapping positions on the edges within the paths the splices (or reads comprising the same) are aligned to.

[0105] In some examples, the method may comprise encoding and storing the pseudo-linear coordinates in the genomic data structure and / or outputting the pseudo-linear coordinates to a user or to a software program for processing and / or visualizing the pseudo-linear coordinates.

[0106] Hence, a pseudo-linear coordinate according to some examples is a linearized position value assigned to nodes, edges, or alignments in a graph reference genome, computed relative to anchor points that connect the graph to predefined linear reference coordinates. For edges, pseudo-linear coordinates are derived from their distance to upstream and / or downstream anchors on a position-reference sequence. For read alignments, including the alignments of splices comprised therein, pseudo-linear coordinates are derived from the mapping positions of reads on graph edges along the paths they traverse.

[0107] The graph reference genome may be used for aligning reads, thereby creating a genomic data structure that comprises the graph reference genome and the aligned reads. A graph genome is a general data structure that represents genomic sequences and their variations in the form of a graph. In such a graph, nodes represent sequences (such as nucleotides, k-mers, or longer sequence segments), and edges represent possible connections or alternative paths.

[0108] Hence, computing pseudo-linear coordinates and using them, for example, to provide a searchable index, may facilitate processing and searching of a graph reference genome and of a graph genome that includes the graph reference genome alongside with aligned reads.

[0109] Computing pseudo-linear coordinates may be advantageous as they may provide a linear coordinate overlay for graph reference genomes and graph genomes, making graph-based data interoperable with linear tools and enabling efficient indexing, querying, and visualization.

[0110] By anchoring graph edges to position-reference sequences (linear sequences with predefined coordinates), the pseudo-linear coordinates may provide for compatibility with existing linear coordinate systems by creating a bridge between graph references and traditional genome browsers / analysis pipelines. They may enable interoperability with existing tools that expect linear coordinates. In addition, computing pseudo-linear coordinates for edges or read alignments may provide for a linearized coordinate system overlay on the graph which may allow fast random access queries (e.g., “fetch reads in chrl: 1-1,000,000”) even when the underlying data is graphbased. In a further advantageous aspect, pseudo-linear coordinates may make it easy to measure genomic distances and relationships in graph space using a linear proxy, simplifying downstream analyses and improving decoding performance. By storing reads in association with pseudo-linear coordinates, the decoder may be enabled to quickly place them in a linear coordinate framework without traversing the full graph structure. This may reduce CPU effort and accelerate reconstruction of alignments for applications like visualization, variant calling, and reporting.

[0111] Assigning pseudo-linear coordinates to edges representing pangenomic variation (SNPs, indels, SVs) may ensure that diverse haplotypes can still be referenced consistently and may allow for a scalable handling of population graphs without breaking linear-coordinate-based workflows.

[0112] According to some examples, one of the edges is represented in the graph reference genome as Edge A, wherein the pseudo-linear coordinates pos(Edge_A, xA) of a position XA onEdge_A connected to position-reference sequence through a path P consisting of a sequence of edges are computed according to the following formula:

[0113] where pl and p2 are the known linear positions of respectively the upstream and downstream anchor points of Edge A, dA is the distance in terms of number of nucleotides of position XA on Edge A leading to the upstream anchor point through path P, and |P| is the sequence length of path P.

[0114] According to some examples, in the special case that Edge A is directly connected to a position reference sequence, the pseudo-linear coordinates pos(Edge_A, xA) are computed according to the following formula:

[0115] where pl and p2 are the known linear positions of respectively the upstream and downstream anchor points of Edge A, and 1A is the sequence length of Edge A

[0116] According to some examples, only one anchor point exists for the edge Edge A. The pseudo-linear coordinates pos(Edge_A, xA) are computed according to either pos(Edge_A, xA) = Pi + xA, if only upstream anchor point at pi existsOrpos(Edge_A, xA) = p2— (lA— xA), if only downstream anchor point at p2 exists.

[0117] According to some examples, one of the edges is represented in the graph as edge Edge B. The pseudo-linear coordinates pos(Edge_B, xB) of a position XB on Edge B connected to a position XA on the Edge A are computed according to the following formula:Thereby, pl and p3 are the known linear positions of respectively the upstream and downstream anchor points of Edge B within the position reference sequence, and 1B is the sequence length of Edge B.

[0118] According to some examples, one of the edges for which the pseudo-linear coordinates are to be computed is represented in the graph as an edge that is connected to the position reference sequence via multiple different paths. The computation of the pseudo-linear coordinates for that edge comprises:selecting one of the multiple different paths based on a path selection strategy, the path selection strategy being selected from a group comprising:■ selecting the path containing the least number of edges;■ selecting the path containing the least number of nucleotide bases; and ■ excluding paths that involve edges incorporated into the graph reference in a version after the current edge was incorporated; andperforming at least one action selected from a group comprising:■ computing the pseudo-linear coordinates for the selected path;■ computing candidate pseudo-linear coordinates for the multiple paths, and selecting the one of the paths yielding the smallest, median, or largest value for the candidate pseudo-linear coordinates for computing the pseudo-linear coordinates; and■ computing candidate pseudo-linear coordinates for the multiple paths, and computing an average or a weighted average of the candidate pseudo linear positions computed from the multiple paths to provide the pseudo-linear coordinates.

[0119] The above features may provide the technical advantage that pseudo-linear coordinates may be computed in a consistent and unambiguous manner even in cases where an edge is connected to a position-reference sequence via multiple different paths. By applying a path selection strategy, ambiguities in path traversal are resolved, thereby improving the accuracy and reproducibility of coordinate computation. Furthermore, the ability to select paths based on criteria such as path length, base count, or version information may ensure that the computation is both efficient and robust against graph updates. The optional use of statistical measures such as minimum, median, maximum, or weighted averages across candidate paths may further improve the stability of the pseudo-linear coordinates and reduce bias introduced by any single graph path.Overall, these measures may enhance the reliability, computational efficiency, and scalability of pseudo-linear coordinate assignment in complex graph reference genomes.

[0120] According to some examples, the genomic data structure comprises a pseudo linear-position flag to indicate availability of the computed pseudo-linear coordinates. In addition, or alternatively, the pseudo-linear coordinates are included in annotation tables for graph-based genomic coordinates.

[0121] The provision of a pseudo-linear position flag may offer the technical advantage of enabling a decoder or downstream tool to immediately determine whether pseudo-linear coordinates are available without having to parse the entire data structure. This may reduce processing overhead and may accelerate selective access to data. Storing pseudo-linear coordinates in annotation tables may provide the advantage of making graph-based genomic coordinates interoperable with existing linear-coordinate-based tools and workflows. This may facilitate efficient indexing, random access queries, and integration with widely used bioinformatics pipelines, thereby improving usability and reducing computational cost when working with graph reference genomes.

[0122] In particular, according to some examples, the pseudo-linear coordinates are used to establish interoperability between graph-aligned and linear-aligned datasets.

[0123] According to some examples, the method comprises encoding and storing the pseudo-linear coordinates and optionally also the known linear positions of the edges of the graph reference genome into the genomic data structure.

[0124] For example, the pseudo-linear coordinates and optionally also the known linear positions of the edges of the graph reference genome may be encoded and stored in a dataset of type 5 (graph reference genome). In addition, or alternatively, the pseudo-linear coordinates and optionally also the known linear positions of the edges of the graph reference genome to which the reads (and their splices, if any) are aligned may be encoded and stored in a dataset of type 4 (graph-aligned read dataset).

[0125] In a further aspect, described herein is a computer-implemented method for representing and processing a read aligned to a reference genome in a memory of a computer system. The method comprises:receiving a genomic data structure, the genomic data structure comprising a compressed representation of a read, of a definition of a reference genome and of extended splice information comprising a parameter, the reference genome being one of: (i) a linear reference genome comprising multiple different linear reference sequences (e.g. chromosomes), and (ii) a graph reference genome comprising multiple paths associated with multiple different reference sequences (e.g. chromosomes),wherein the read comprises two or more splices aligned to the reference genome such that:■ in the case of (i) the linear reference genome, the two or more splices are aligned to different ones of the multiple different linear reference sequences, and■ in the case of (ii) the graph reference genome, the two or more splices are aligned to different ones of the paths of the graph reference genome,wherein the parameter indicates whether the splices are aligned to a graph reference genome or a linear reference genome;decoding the extended splice information with the parameter for determining if the reference genome is a graph reference genome or a linear reference genome; reconstructing a de-compressed representation of the two or more aligned splices such that the two or more aligned splices are mapped to different ones of the multiple different linear reference sequences or to different ones of the multiple different paths in the reference genome; andstoring the reconstructed, de-compressed representation of the two or more aligned splices in memory.

[0126] The described method may provide the technical advantage that read alignments spanning multiple reference sequences or multiple paths in a graph reference genome may be represented, compressed, and later reconstructed in a manner that is both accurate and resource efficient. By incorporating a parameter in the extended splice information that explicitly indicates whether the splices relate to a linear reference genome or to a graph reference genome, the decoding process may be simplified and unambiguous. This may reduce computational overhead, as the decoder may not need to infer the reference type from context, and may ensure faster andmore reliable reconstruction of the alignments. Moreover, because the alignments are stored in a compressed form and reconstructed only when needed, the method may achieve significant savings in storage space and transmission bandwidth. At the same time, it may reduce CPU and memory usage during decoding by enabling selective reconstruction of only those alignments required for a given task. Overall, the method may improve interoperability, storage efficiency, and decoding performance for both linear and graph-based genomic data.

[0127] According to some examples, the method further comprises outputting, via a user interface, the de-compressed representation of the two or more aligned reads.

[0128] For example, a sequencing analysis platform may be used to decode an MPEG-G file containing compressed representation of alignments of reads and of splices comprised therein to a graph reference genome. One read may have two splice events: The first splice maps to chromosome 1, path A, position 100,000. The second splice maps to chromosome 1, path B, position 150,000. The decoder reconstructs the de-compressed representation of this read alignment, including the read sequence, CIGAR string with splice operators, the splices descriptor indicating the respective path IDs and positions, and mapping quality values. Via the platform’s graphical user interface, the reconstructed alignment is output to the user in both text and visual form: In text form, displayed as a SAM / BAM-like line showing the read name, reference identifiers, positions, and alignment string. In visual form, the output is rendered as a track in a genome browser panel, where the user can see the read aligned across two distinct paths of the graph reference genome (inter-path alignment), with the splice junction highlighted. This may allow the user to directly inspect the reconstructed alignment, verify splice positions, and crosscheck variant evidence without needing to de-compress or parse the entire dataset.

[0129] According to some examples, the extended splice information comprises a splices descriptor. The reconstruction of the read alignment information, including information on the alignment of the two or more splices, comprises using information comprised in the extended splice information, in particular the splices descriptor, for determining properties of the splices and / or splice alignment positions.

[0130] The use of splices descriptor may provide the technical advantage that the reconstruction of read alignments may be carried out with high accuracy and efficiency. By relying on information contained in the splices descriptor, properties of splice events, such as orientation, length, andtarget path or sequence, as well as the precise splice alignment positions, may be directly determined without requiring complex recalculation or full re-alignment of reads. This may reduce computational overhead during decoding, improve reconstruction speed, and ensure that splice events are represented in a consistent and unambiguous manner, thereby enhancing both decoding performance and interoperability with downstream analysis tools.

[0131] According to some examples, the reconstructing of the information of the two or more aligned splices comprises: decoding the read alignment information (which may comprise the extended splice information and optionally further information related to the alignment of reads and splices); and creating extended CIGAR strings that represent the differences between each read alignment and the corresponding genomic regions in the reference genome. At least one of the created extended CIGAR strings is created for the read alignment comprising the two or more splices mapped to different sequences or paths in the reference genome.

[0132] The creation of extended CIGAR strings during reconstruction of the read alignments may provide the technical advantage that differences between read sequences and the corresponding genomic regions may be represented in a compact, standardized, and decoder-friendly form. By extending the CIGAR format to cover splices that span across different sequences or graph paths (“inter-sequence” / ”inter-path” alignments), even complex alignments can be captured without ambiguity. This may enable efficient decoding and reconstruction of spliced alignments, reduce the need for transmitting or storing full read sequences with explicit per-base differences, and may ensure compatibility with existing analysis pipelines that rely on CIGAR-like alignment notation. As a result, storage requirements may be reduced, decoding performance may be improved, and downstream interoperability with both linear and graph-based genome analysis tools may be facilitated

[0133] According to some examples, the method further comprises: determining if two consecutive splices in a read are aligned to different reference sequences or paths; if true, representing a concatenation of the two consecutive splices by an operator in an extended CIGAR string.

[0134] These features may allow capturing complex splice patterns in a compact and unambiguous form. This may avoid the need for verbose or redundant position encoding, thereby reducing the size of the compressed data. Furthermore, by introducing a specific operator forconcatenated splices, decoding may become simpler and more efficient, since the decoder can interpret the operator directly without additional logic to resolve multiple transitions. As a result, storage space may be conserved, decoding performance may be improved, and interoperability with downstream tools that parse CIGAR-like notation may be maintained while extending the expressive power of the format to graph-based and multi-path alignments

[0135] According to some examples, the operator in the extended CIGAR string representation is one of: undirected, forward, and / or reverse orientation of the downstream aligned splice.

[0136] The definition of an operator in the extended CIGAR string to indicate whether the downstream aligned splice has an undirected, forward, or reverse orientation may provide the technical advantage of unambiguously capturing the directionality of splice events in a compact symbolic form. This may reduce the need for additional descriptor fields to represent orientation, thereby saving storage space and simplifying the bitstream structure. At the same time, orientation-aware operators may improve decoding efficiency, as the decoder can immediately reconstruct the correct alignment direction without performing extra computations or lookups.

[0137] According to some examples, the extended CIGAR string representation for the two or more splices aligned to different sequences or paths comprises one or more splice operators to indicate transitions between different linear reference sequences or paths. Thereby, a splice operator referring to splices being inter-linear-sequence splices or inter-path splices is free of a base count value, while a splice operator referring to splices being intra-linear-sequence-splices or intra-path splices comprises a base count value.

[0138] The above-mentioned extended CIGAR string representation may have the technical advantage of encoding splice events with both accuracy and efficiency. By omitting a base count value for inter-linear-sequence or inter-path splices, the bitstream may avoid unnecessary data fields and may achieve more compact storage. Conversely, including a base count value for intrasequence or intra-path splices may ensure precise definition of the number of aligned bases within a single sequence or path. This differentiation may improve compression efficiency, reduces redundancy, and simplifies decoding, since the decoder can directly interpret the operator semantics without additional checks. As a result, storage space may be saved, computational resources required for decoding may be reduced, and alignment reconstruction may remain accurate and unambiguous for both linear and graph-based reference genomes.

[0139] According to some examples, the method further comprises: decoding the read alignments and retrieving nucleotide sequences from the reference genome using information comprised in the decoded read alignment information. In case one or more of the reads comprise splices, the read alignment information may comprise splice information, in particular the extended splice information described herein for several examples. In particular, the extended splice information may comprise a splices descriptor, and in the case of the reference genome being a graph reference genome, the extended splicing information may also comprise a graph path descriptor, and a graph path position descriptor.

[0140] The retrieval of nucleotide sequences from the reference genome based on decoded read alignment information, including data comprised in the extended splice information, may provide the technical advantage of enabling accurate reconstruction of read sequences and their alignments without requiring the entire reference to be redundantly stored or transmitted. By directly using alignment and splice data, the decoder may selectively access only those portions of the reference genome that are relevant for reconstruction, thereby reducing memory usage and computational overhead.

[0141] According to some examples, the reconstruction of the de-compressed representation of the two or more aligned splices comprises updating the two or more aligned splices with pseudo-linear coordinates.

[0142] Updating the aligned splices with pseudo-linear coordinates during reconstruction may provide the technical advantage of enabling graph-based alignments to be represented in a linearized coordinate system. This may improve interoperability with existing bioinformatics tools and workflows that rely on linear coordinates, while preserving the accuracy of graph-based alignments. By attaching pseudo-linear positions directly to splice information, selective queries and indexing based on linear ranges may become possible, reducing the need for complex graph traversals. This may enhance decoding efficiency and may support random access based on coordinates of interest.

[0143] According to some examples, the genomic data structure comprises read alignment information. The read alignment information comprises:a Reference Transform Target Descriptor - rftt descriptor - specifying the target nucleotides of a transformation, the transformation being a sequence edit operation (like substitution,insertion, deletion, inversion) applied to the linear reference sequence or to a graph edge of the graph reference genome to produce a new transformed reference sequence that supports more efficient alignment, storage, and decoding;a Reference Transform Position Descriptor - rftp descriptor - encoding positions of the transformation; anda Reference Transform Edge Descriptor - rfte descriptor- associated with the reference genome, the rfte descriptor identifying edges (aka. segments or branches) of the graph reference genome to which the transformation applies.

[0144] The method further comprises: decoding the rfte descriptor, the rftp descriptor and the rftt descriptor to obtain the edge IDs, positions and nucleotide changes of the frequently occurring substitutions in the read alignments; applying the decoded substitutions on the reference genome associated with the read alignments to provide a modified reference genome; and decoding the nucleotide sequences of the reads using the modified reference genome.

[0145] The inclusion of the rfte descriptor, the rftp descriptor, and the rftt descriptor as part of the read alignment information may provide the technical advantage of enabling reference transformations to be represented in a compact and structured manner within the genomic data structure. By identifying the target nucleotides of a transformation (rftt), specifying the transformation positions (rftp), and associating the transformation with particular edges of a graph reference genome (rfte), frequently occurring substitutions and other sequence edits may be applied directly to the reference genome instead of redundantly signaling them in each read. This may reduce storage requirements and improve compression efficiency. Furthermore, decoding these descriptors to obtain edge IDs, positions, and nucleotide changes may allow a decoder to apply the transformations and reconstruct a modified reference genome that better matches the aligned reads. This may improve decoding performance by reducing the number of per-read edits that need to be applied during alignment reconstruction. By supporting transformations on graph edges, the approach may ensure unambiguous handling of sequence edits in graph-based references, improving accuracy and scalability for population-level genomics.

[0146] The read alignment information may further comprise extended splice information described herein for various examples.

[0147] According to some examples, the method further comprises: outputting the reconstructed, de-compressed representation of the two or more aligned splices as an MPEG-G record in accordance with an extended MPEG-G standard, wherein in particular the MPEG-G record comprises an extended CIGAR string array and wherein the extended CIGAR strings are stored in the extended CIGAR string array.

[0148] Outputting the reconstructed, de-compressed representation of the two or more aligned splices and of any further read alignments, if any, as an MPEG-G record in accordance with an extended MPEG-G standard may provide the technical advantage of maintaining compatibility with the standardized MPEG-G framework while extending its expressive capacity to capture complex splice and graph-based alignment information. By organizing the extended CIGAR strings in an extended CIGAR string array within the MPEG-G record, alignment differences can be represented in a compact and structured manner, facilitating efficient storage and decoding. This arrangement may simplify access to extended alignment information, may support selective decoding of individual CIGAR strings, and may enable downstream tools to parse alignment data without additional conversion steps.

[0149] In a further aspect, described herein is a system comprising a processor and a memory. The processor is configured to execute instructions that cause the system to perform a method for representing a linear or graph-based genomic data structure in the memory, the method comprising:receiving a read and a definition of a reference genome, the reference genome being one of: (i) a linear reference genome comprising multiple different linear reference sequences (e.g. chromosomes), and (ii) a graph reference genome comprising multiple paths associated with multiple different reference sequences (e.g. chromosomes), wherein the read comprises two or more splices aligned to the reference genome such that:■ in the case of (i) the linear reference genome, the two or more splices are aligned to different ones of the multiple different linear reference sequences, and■ in the case of (ii) the graph reference genome, the two or more splices are aligned to different ones of the paths of the graph reference genome;generating extended splice information, the extended splice information comprising a parameter to indicate whether the splices are aligned to a graph reference genome or a linear reference genome;encoding the two or more aligned splices and the extended splice information in the genomic data structure to provide a compressed representation of the two or more aligned splices, the reference genome, and the extended splice information; andstoring the generated genomic data structure in the memory.

[0150] In a further aspect, a system comprising a processor and a memory is described herein, wherein the processor is configured to execute instructions that cause the system to perform a method for representing and processing a read aligned to a reference genome in the memory. The method comprises:receiving a linear or graph-based genomic data structure, the data structure comprising a compressed representation of a read, of a definition of a reference genome and of extended splice information comprising a parameter, the reference genome being one of: (i) a linear reference genome comprising multiple different linear reference sequences (e.g. chromosomes), and (ii) a graph reference genome comprising multiple paths associated with multiple different reference sequences (e.g. chromosomes), wherein the read comprises two or more splices aligned to the reference genome such that:■ in the case of (i) the linear reference genome, the two or more splices are aligned to different ones of the multiple different linear reference sequences, and■ in the case of (ii) the graph reference genome, the two or more splices are aligned to different ones of the paths of the graph reference genome,wherein the parameter indicates whether the splices are aligned to a graph reference genome or a linear reference genome;decoding the extended splice information with the parameter for determining if the reference genome is a graph reference genome or a linear reference genome; reconstructing a de-compressed representation of the two or more aligned splices suchthat the two or more splices are mapped to different ones of the multiple different linear reference sequences or to different ones of the multiple different paths in the reference genome; andstoring the reconstructed, de-compressed representation of the two or more aligned splices in memory.

[0151] The technical advantages of the systems described herein may be analogous to those of the respective methods.

[0152] In a further aspect, described herein is a computer-implemented method for representing a genomic data structure in a memory of a computer system. The method comprises.receiving a definition of a graph reference genome comprising edges (aka. segments or branches) and their connections, the graph reference genome comprising a linear reference sequence with pre-defined linear coordinates;identifying for each of at least some of the edges one or multiple paths that connect the edge to the linear reference sequence, the path comprising the at least one edge and optionally further ones of the edges;computing a pseudo linear position of a point (XA) on the at least one edge (edge A), the computing comprising:■ identifying an upstream and / or downstream anchor point in the path, an anchor point being a point on the path where an edge in the path is linked to one of the predefined linear coordinates of the linear reference sequence;■ identifying a predefined linear coordinate linked to the identified upstream and / or downstream anchor point;■ identifying the one of the predefined linear coordinates (px) that reflects the position of the point (xA) on the path relative to the upstream and / or downstream anchor point; and■ using the identified predefined linear coordinate (px) as the pseudo-linear coordinate of the point (xA) on the at least one aligned edge (edge A); assigning the pseudo linear position to the point (xA) in the graph reference genome;encoding the graph reference genome and the pseudo-linear coordinate in a compressed representation of the graph reference genome; andstoring the compressed representation of the graph reference genome in the genomic data structure in the memory.

[0153] This may have the advantage of enabling graph reference genomes to be efficiently indexed, queried, and integrated with existing linear-coordinate-based tools. By computing pseudo-linear coordinates for points on graph edges using upstream and / or downstream anchors linked to predefined linear coordinates, the method may allow establishing a consistent linearized coordinate system for graph reference genomes and graph genomes comprising the same. This may avoid the need for full graph traversal during decoding or querying and may allow direct mapping of graph-based alignments into a conventional coordinate framework. Assigning and storing pseudo-linear positions in a compressed representation of the graph reference genome may further reduce storage space and transmission costs, while maintaining unambiguous alignment information. Overall, the method may improve compression efficiency, may accelerate decoding and random access, and may reduce CPU and memory resources required for processing graph reference genomes. Furthermore, the pseudolinear coordinates may enhance interoperability between graph-based genomic references and linear-coordinate-based analysis workflows.

[0154] According to some examples, one or more pseudo-linear coordinates are computed and stored for each of the edges connected to the linear reference sequence. In particular, the pseudo-linear coordinates can be computed and stored for the beginning of each of these edges.

[0155] This may allow establishing clear and unambiguous anchor points between the graph reference genome and the linear reference. This may improve the accuracy and reproducibility of coordinate mapping and may facilitate efficient indexing of the graph structure. By storing these pseudo-linear positions, the decoder may rapidly resolve queries and reconstruct alignments without requiring full traversal of the graph, thereby reducing computational overhead. Moreover, the use of standardized anchor points at edge beginnings supports consistent integration with existing linear-coordinate-based analysis pipelines.

[0156] According to some examples, the pseudo-linear coordinate of the point (XA) on an edge of the graph reference genome is computed using both an upstream anchor point and a downstreamanchor point. The pseudo-linear coordinate is calculated by interpolation between the predefined linear coordinates of the upstream and the downstream anchor points.

[0157] By considering anchor points on both sides of the edge, local variations in graph topology may be smoothed out, and the resulting coordinate may better reflect the true relative position of the point within the graph. This interpolation approach may reduce bias that could arise from relying on a single anchor, enhance reproducibility across different graph versions, and may ensure consistent integration with linear-coordinate-based analysis tools.

[0158] According to some examples, the pseudo-linear coordinate of the point (XA) is computed using only the upstream anchor point or only the downstream anchor point and wherein the pseudo-linear coordinate of the point (XA) is computed as an offset from the single anchor point within the path.

[0159] Computing the pseudo-linear coordinate of a point using only an upstream or only a downstream anchor point, and determining the coordinate as an offset from that single anchor within the path, may provide the technical advantage of reducing computational complexity while still ensuring a consistent linearized coordinate framework. This approach may enable efficient coordinate calculation even in cases where only one anchor point is available, such as incomplete or evolving graph references.

[0160] According to some examples, the pseudo-linear coordinate is encoded as an integer offset relative to the predefined linear coordinate of the upstream anchor point.

[0161] These features may provide the technical advantage of enabling compact and efficient representation of graph-based positions. Offsets may be encoded with fewer bits than absolute coordinates, thereby improving compression efficiency and reducing storage space. At the same time, using an integer offset may ensure exact reconstruction of the coordinate while avoiding floating-point operations, which may simplify decoding and may reduce computational overhead. This offset-based scheme may also facilitate rapid random access by allowing direct calculation of pseudo-linear positions from a known anchor, enhancing both performance and interoperability with linear-coordinate-based analysis tools.

[0162] According to some examples, the pseudo-linear coordinate of the point is encoded as an absolute linear coordinate derived from the predefined linear coordinate of the downstream anchorpoint. For example, the pseudo-linear coordinate is computed from the predefined linear coordinate of the downstream anchor point and an offset value, the offset value indicating the distance of the point from the predefined linear coordinate of the downstream anchor point.

[0163] Encoding the pseudo-linear coordinate as an absolute linear coordinate derived from the predefined linear coordinate of the downstream anchor point may provide the technical advantage of ensuring unambiguous placement of graph positions in a linearized coordinate system. By anchoring the coordinate calculation to a downstream reference point, this approach may enable deterministic mapping that is reproducible across different graph traversals. The use of absolute coordinates may simplify random access queries and downstream data integration, since absolute positions may be directly compared to existing linear-coordinate-based references without additional offset calculations. This may enhance interoperability, facilitate efficient indexing, and reduce computational effort during decoding and analysis.

[0164] According to some examples, multiple pseudo-linear coordinates are computed for multiple points along the path and stored in the genomic data structure.

[0165] Computing multiple pseudo-linear coordinates for multiple points along a path and storing them in the genomic data structure may provide the technical advantage of enabling finer-grained mapping between graph-based and linear coordinate systems. This may increase accuracy in locating and reconstructing read alignments, especially in long or structurally complex graph regions. By storing multiple reference points along a path, random access queries may be answered more efficiently, since positions may be resolved locally without traversing the entire graph. This may improve decoding speed, reduce computational overhead, and may enhance the robustness of coordinate mapping for downstream analysis.

[0166] According to some examples, multiple pseudo-linear coordinates are computed and are stored in in graph-based alignment data, graph reference genome and / or annotation tables in association with nodes, edges or paths of the graph reference genome. An annotation table can be, for example, a type of dataset for storing downstream genomic data such as genomic variants.

[0167] Computing multiple pseudo-linear coordinates and storing them in annotation tables in association with nodes, edges, or paths of the graph reference genome may provide the technical advantage of creating a structured and accessible mapping between graph-based and linearized coordinates. By embedding pseudo-linear positions directly in annotation tables, the data structuremay allow fast lookup of graph elements based on linear coordinates, enabling efficient indexing and selective access. This may reduce the need for full graph traversal during decoding or analysis, thereby lowering computational overhead.

[0168] According to some examples, the pseudo-linear coordinate is computed to enable interoperability between graph-aligned data and linear-aligned data.

[0169] According to some examples, the pseudo-linear coordinates are used by a decoder to project read alignments on the graph reference genome into a linear coordinate system. For example, the decoder may provide the pseudo-linear coordinates to a legacy genomic data processing or visualization software that expects a linear reference genome.

[0170] In addition, or alternatively, the pseudo-linear coordinates are used by an encoder to project read alignments on the graph reference genome into a linear coordinate system. For example, the pseudo-linear coordinates may be stored in the genomic data structure, and thereby store an explicit projection of the read alignments to the linear coordinate system in the genomic data structure. In other examples, the pseudo-linear coordinates may not be stored in the genomic data structure, but may be processed and / or output separately, e.g. via a software for visualizing the aligned reads before or while they are encoded and stored in the data structure.

[0171] This may enable interoperability with existing linear-based formats and tools without losing the richer alignment information contained in the graph structure. This projection may simplify downstream processing by allowing alignments to be encoded in familiar linear coordinates, thereby reducing integration complexity.

[0172] According to some examples, the read is received as one out of a plurality of reads, which may or may not comprise multiple splices.

[0173] According to some examples, the method comprises receiving read alignments being indicative of how one or more reads are aligned to the graph reference genome, and computing pseudo-linear coordinates for the reads aligned to the graph reference genome.

[0174] According to some examples, at least one of the reads comprises two or more splices aligned across different edges or paths (“inter-path alignments”) in the graph reference genome. The method further comprising computing pseudo-linear coordinates for the aligned two or more splices.

[0175] Computing pseudo-linear coordinates for splices aligned across different edges or paths of the graph reference genome may provide the technical advantage of enabling discontinuous alignments to be consistently encoded in a unified linearized coordinate framework. This may ensure that even complex multi-splice alignments spanning different graph elements of a graph reference genome may be unambiguously located and compared using linear coordinates. By providing pseudo-linear positions for such splices, random access and selective decoding may be simplified, since queries can be resolved by coordinate ranges even if the two consecutive splices are mapped to different sequences or paths rather than requiring full graph traversal.

[0176] According to some examples, the method comprises: using the pseudo-linear coordinates to create a searchable index for the graph reference genome that supports searches for nodes, edges, paths or other graph-based components (e.g., also aligned reads) using a coordinate as search key; and storing the index in the genomic data structure to enable random access search queries in the genomic data structure, the random access search using search keys comprising linear genomic coordinates or linear genomic ranges.

[0177] This may provide the technical advantage of enabling graph-based genomic data to be accessed through conventional linear coordinate systems. By supporting searches for nodes, edges, paths, or other graph-based components using linear coordinates or linear coordinate ranges as keys, the index may ensure interoperability with existing bioinformatics tools and workflows that rely on linear references. Storing the index directly in / as part of the genomic data structure may allow efficient random access without full graph traversal, and may allow providing a genomic data structure that is fully self-contained. This may allow reducing computational overhead, memory usage, and query response times, and may improve scalability for large genomic datasets.

[0178] According to some examples, the pseudo-linear coordinates are stored in the genomic data structure to support selective decoding of graph-aligned reads identified using linear genomic coordinates as search keys.

[0179] This may provide the technical advantage of enabling efficient retrieval of only the relevant portions of compressed data. By allowing linear genomic coordinates to serve as search keys, the method may ensure compatibility with existing tools and workflows that operate in linear coordinate systems, while internally mapping those keys to graph-based alignments. It may reduce decoding overhead by avoiding the need to de-compress unrelated data. As a consequence, it mayalso lower memory and CPU usage during query processing, and accelerate access to targeted reads.

[0180] According to some examples, the pseudo-linear coordinates are transmitted together with extended splice information in a dataset encoded in accordance with the MPEG-G standard.

[0181] This may have the advantage that the graph-based alignment data may be self-contained and interoperable within a standardized framework. By evaluating both pseudo-linear coordinates and the splices descriptor, the decoder may immediately reconstruct both the alignment topology in the graph and its corresponding linearized representation without additional external data. This may reduce synchronization complexity between different data sources, may accelerate decoding, and may improve reliability of data exchange across systems. Furthermore, integrating pseudo-linear coordinates into MPEG-G datasets may enhance compression efficiency and enable seamless use of graph-based genomic data in existing MPEG-G-compliant analysis and storage pipelines.

[0182] According to some examples, the pseudo-linear coordinates pos(Edge_A, xA) of the position XA on Edge A connected to position-reference sequence through a path P consisting of a sequence of edges are computed according to the following formula:

[0183] where pl and p2 are the known linear positions of respectively the upstream and downstream anchor points of Edge A, dA is the distance in terms of number of nucleotides of position XA on Edge A leading to the upstream anchor point through path P, and |P| is the sequence length of path P.

[0184] According to some examples, in the special case that Edge A is directly connected to the position reference sequence, the pseudo-linear coordinates pos(Edge_A, xA) are computed according to the following formula:

[0185] where pl and p2 are the known linear positions of respectively the upstream and downstream anchor points of Edge A, and 1A is the sequence length of Edge A.

[0186] According to some examples, only one anchor point exists for the edge Edge A, and wherein the pseudo-linear coordinates pos(Edge_A, xA) are computed according to either pos(Edge_A, xA) = Pi + xA, if only upstream anchor point at pi existsOrpos(Edge_A, xA) = p2— (lA— xA), if only downstream anchor point at p2 exists

[0187] According to some examples, the graph reference genome comprises an edge Edge A as described above, and further comprises an edge Edge B, wherein the pseudo-linear coordinates pos(Edge_B,xB) of a position XB on Edge B connected to a position XA on the Edge A are computed according to the following formula:

[0188] where pl and p3 are the known linear positions of respectively the upstream and downstream anchor points of Edge B within the position reference sequence, and 1B is the sequence length of Edge B.

[0189] In a further aspect, described herein is a computer-implemented method for representing and processing a graph reference genome in a memory of a computer system. The method comprises:receiving a genomic data structure comprising a compressed representation of a graph reference genome and of pseudo-linear coordinates, the graph reference genome comprising edges and their connections, the graph reference genome comprising a linear reference sequence with pre-defined linear coordinates, wherein each of at least some of the edges is connected to the linear reference sequence via one or multiple paths; receiving at least one linear genomic coordinate defining a genomic region of interest; searching the pseudo-linear coordinates to identify the ones of the edges or other graphbased components associated with pseudo-linear coordinates within the region of interest; selectively decoding only the identified edges or graph-based components for reconstructing a de-compressed representation of only the part of the graph referencegenome associated with the genomic region of interest; andstoring the reconstructed, de-compressed representation part of the graph reference genome in the memory.

[0190] According to some examples, the further graph components comprise reads aligned to the paths. The method further comprises: using, by a decoder, the pseudo-linear coordinates to project one or more of the reads aligned to the graph reference genome into a linear coordinate system; and outputting, via a user interface, a representation of the projected reads.

[0191] This may provide the advantage of making graph-based alignments directly compatible with existing linear-coordinate-based tools and workflows. Users may view and analyze graph-aligned reads in the familiar context of a linear genome, thereby improving usability and interoperability. By performing the projection at the decoder, the method may reduce computational burden on downstream applications, since the projection is resolved once during decoding.

[0192] In a further aspect, described herein is a system comprising a processor and a memory. The processor is configured to execute instructions that cause the system to perform a method for representing a genomic data structure in the memory. The method comprises:receiving a definition of a graph reference genome comprising edges (aka. segments or branches) and their connections, the graph reference genome comprising a linear reference sequence with pre-defined linear coordinates;identifying for each of at least some of the edges one or multiple paths that connect the edge to the linear reference sequence, the path comprising the at least one edge and optionally further ones of the edges;computing a pseudo linear position of a point (XA) on the at least one edge (edge A), the computing comprising:■ identifying an upstream and / or downstream anchor point in the path, an anchor point being a point on the path where an edge in the path is linked to one of the predefined linear coordinates of the linear reference sequence;■ identifying a predefined linear coordinate linked to the identified upstream and / ordownstream anchor point;■ identifying the one of the predefined linear coordinates (px) that reflects the position of the point (XA) on the path relative to the upstream and / or downstream anchor point; and■ using the identified predefined linear coordinate (px) as the pseudo-linear coordinate of the point (XA) on the at least one aligned edge (edge A); assigning the pseudo linear position to the point (XA) in the graph reference genome; encoding the graph reference genome and the pseudo-linear coordinate in a compressed representation of the graph reference genome; andstoring the compressed representation of the graph reference genome in a genomic data structure in the memory.

[0193] In a further aspect, described herein is a system comprising a processor and a memory. The processor is configured to execute instructions that cause the system to perform a method for processing a graph reference genome in the memory. The method comprises:receiving a genomic data structure comprising a compressed representation of a graph reference genome and of pseudo-linear coordinates, the graph reference genome comprising edges and their connections, the graph reference genome comprising a linear reference sequence with pre-defined linear coordinates, wherein each of at least some of the edges is connected to the linear reference sequence via one or multiple paths; receiving at least one linear genomic coordinate defining a genomic region of interest; searching the pseudo-linear coordinates to identify the ones of the edges or other graphbased components associated with pseudo-linear coordinates within the region of interest; selectively decoding only the identified edges or graph-based components for reconstructing a de-compressed representation of only the part of the graph reference genome associated with the genomic region of interest; andstoring the reconstructed, de-compressed representation part of the graph reference genome in the memory.

[0194] For example, the genomic data structure may comprise a plurality of genomic sequences and can comprise at least a portion of a reference genome. A data processing system receives a definition of a graph reference genome, comprising a plurality of graph reference genome edges, each specifying a sequence of characters, and a plurality of links representing connections between the plurality of graph reference genome edges. The system then generates a genomic data structure for the received graph reference genome definition, comprising a reference sequence count specifying a number of a plurality of reference sequences (e.g., chromosomes). Additionally, each of the plurality of reference sequences comprises a unique reference sequence identifier and an edge count specifying a number of the plurality of graph reference genome edges corresponding to that reference sequence. Each of the plurality of graph reference genome edges comprises (i) a unique edge identifier; (ii) an edge group identifier, each edge group identifier identifying an edge group to which the edge belongs, wherein the plurality of graph reference genome edges may optionally belong to two or more different edge groups; (iii) an edge sequence comprising a sequence of characters, which may include an empty string, represented by the edge; and (iv) a number of connections associated with the edge. And each connection associated with a graph reference genome edge includes: (a) a connection edge identifier identifying a second edge to which the respective edge is connected; (b) a direction specifying whether the identified second edge is upstream or downstream of the respective edge; (c) a connection type specifying which of a plurality of different possible connection types the respective edge comprises; and (d) a position specifying a position on the identified second edge or on the respective edge at which the connection occurs. The system then stores the generated graph data structure in memory.

[0195] Generally, a method for representing a genomic data structure in a memory of a computer system is provided. The method includes: receiving a definition of a graph reference genome, comprising: (i) a plurality of edges, each specifying a sequence of characters, and (ii) a plurality of links representing connections between the plurality of graph reference genome edges; generating a genomic data structure for the received graph reference genome definition, comprising a reference sequence count specifying a number of a plurality of reference sequences (e.g. chromosomes); each of the plurality of reference sequences comprising: a unique reference sequence identifier and an edge count specifying a number of the plurality of edges corresponding to that reference sequence; each of the plurality of edges comprising: (i) a unique edge identifier; (ii) an edge sequence comprising a sequence of characters, which may include an empty string,represented by the edge; and (iii) a number of connections associated with the edge; each connection associated with an edge comprising: (a) a connection edge identifier identifying a second edge to which the respective edge is connected; (b) a direction specifying whether the identified second edge is upstream or downstream of the respective edge; (c) a connection type specifying which of a plurality of different possible connection types the respective edge comprises; and (d) a position specifying a position on the identified second edge or on the respective edge at which the connection occurs; and storing the generated graph data structure in memory.

[0196] According to an example, each link connection associated with an edge comprises: (a) a connection edge identifier identifying a second edge to which the respective edge is connected; (b) a direction specifying whether the identified second edge is upstream or downstream of the respective edge; (c) a connection type specifying which of a plurality of different possible connection types the respective edge comprises; and (d) a position specifying a position on the identified second edge or on the respective edge at which the connection occurs.

[0197] According to an example, the connection type identifying which of a plurality of different possible connections the respective edge comprises, comprises at least the following different types of connections: (1) a connection between end points of two edges; (2) a connection joining a middle of the respective edge to or from an end point of another edge sequence; (3) a connection joining an end point of the respective edge to or from a middle of another edge sequence.

[0198] According to an example, the graph data structure further comprises, for each of the plurality of edges: (iv) an edge group identifier, each edge group identifier identifying an edge group to which the edge belongs, wherein the plurality of edges may optionally belong to two or more different edge groups; (v) an edge rank specifying a rank of an edge among a group of overlapping edges in the reference genome, wherein a rank of 0 represents a foundational linear reference, with increments of 1 for each additional overlapping layer; and (vi) a number of characters in the sequence of characters represented by the edge.

[0199] According to an example, the graph data structure further comprises an edge group count specifying a number of edge groups in the graph reference genome, and wherein each identified edge group further comprises a unique edge group identifier.

[0200] According to an example, each identified edge group further comprises a version identifier identifying a major and / or minor version of the graph reference genome to which the edge group was first added.

[0201] According to an example, the method further includes: receiving, at a genomic data structure decoder, the genomic data structure from memory; decoding, by a genomic data structure decoder, the received graph data structure to build at least a portion of a graph reference genome; and providing the built graph reference genome.

[0202] According to an example, the method further includes: updating the stored genomic data structure, comprising: receiving a plurality of graph reference genome edges from one or more new edge groups; updating the genomic data structure, including: (i) updating the edge count, (ii) adding a new edge group identifier for each of the received plurality of graph reference genome edges, (iii) adding a unique edge sequence identifier for each of the received plurality of graph reference genome edges; (iv) adding a number of connections associated with each edge and for each connection adding an edge connection, a connection type, and a position, and (v) updating the edge group information to include the one or more new edge groups; and storing the updated generated graph data structure in memory.

[0203] According to an example, the splices descriptor comprises splicing information for each splice of each genomic read that can be aligned to all possible locations in the reference genome.

[0204] According to an example, the method further includes: inferring, while adding the received plurality of genomic reads to the genomic data structure, one or more new edges for the graph reference genome when a plurality of genomic reads cannot be mapped to the graph reference genome; adding the plurality of genomic reads that cannot be mapped to the graph reference genome to the genomic data structure using information from the one or more new edges; and storing the inferred one or more new edges as supplementary edges to the graph reference genome.

[0205] In a further aspect, described herein is a computer program enabling a processor to carry out one of the methods described herein.

[0206] In a further aspect, described herein is a computer program product enabling a processor to carry out one of the methods described herein.

[0207] In a further aspect, described herein is a data structure comprising extended splice information and / or other data described herein for various examples.

[0208] A “genomic data structure” as used herein is a data structure comprising genomic information. In particular, a genomic data structure can be a computer-readable container that stores compressed genomic information in fields arranged according to a defined syntax. In some examples, the structure conforms to the MPEG-G format and comprises datasets, access units, and records together with descriptors that encode reads, alignments, reference information, transformation data, and metadata.

[0209] A “dataset” as used herein is a set of data sharing one or more features. In particular, a “dataset” can be a top-level container grouping homogeneous genomic content (e.g., raw reads, aligned reads, variants, references, or graph references / read alignments).

[0210] A “dataset type” as used herein can be, for example, a value signaling the content class of the dataset (e.g., linear-aligned reads versus graph-aligned reads), enabling decoders to apply appropriate parsing, indexing, and decoding logic.

[0211] A “segment” as used herein, and as used in general in the context of genomic alignments, can be, for example, a continuous part of a read. A paired-end read comprises two segments. In case a read comprises multiple splices, it may align to multiple, non-continuous regions of the reference genome, thereby providing multiple aligned segments. For the sake of simplicity, the term “read” may also be used herein to refer to individual “segments”, because in respect to the alignment of segments to a reference genome, it does not matter if the segment represents a single-end read or one of the two components of a paired-end read. In the context of a graph reference genome, as for example in the sections “Proposed Changes to MPEG-G Part 1” and “Proposed Changes to MPEG-G Part 2” of this application text ranging from “Subclause 6.4.3.2 Dataset Header” to “Subclause 7.7 Graph Reference Parameter Set”, and as the case in various expressions referring to “edges (aka. segments or branches)”, the term “segment” is used to refer to a type of edges of a graph reference genome. According to examples, said type of edges - in contrast to the “standard” edges - are not self-contained with connection information with other edges, but rather need to be accompanied by the separate graph elements “links” that provide the connection information.

[0212] An “access unit (AU)” can be, for example, a container of the smallest independently decodable blocks, each of the access units comprising records of the same class or sharing common properties.

[0213] A “record” can be, for example, a piece of data that encapsulates one atomic item of information. For example, it can be the smallest addressable unit of compressed genomic data in an MPEG-Gfile. For example, it can be an atomic piece of genomic information. For example, for unaligned data, a record is an unaligned read or read pair; for aligned data, a record represents all the combinations of alignments of a read or read pair; for annotation data, a record refers to the information of a single genomic variant.

[0214] A “read” can be, for example, a nucleotide sequence output by a sequencing instrument together with optional quality scores. A read pair may denote two reads originating from opposite ends of a DNA fragment, which may be jointly represented in a single record. Hence, a “read” as used herein may refer to an individual segment, for single-end reads and for paired-end reads.

[0215] A “reference Genome (linear and graph)” as used herein is genomic sequence data that provides the sequence context for alignments. A linear reference genome comprises one or more distinct linear reference sequences (e.g., chromosomes).

[0216] A “position reference sequence” as used herein is a linear sequence in a graph reference genome annotated with positional information, in particular with one or more predefined linear coordinates.

[0217] A “graph reference genome” represents genomic sequence diversity as a graph of nodes and edges with multiple alternative paths. A “graph reference genome” can be a particular type of graph genome that is designated as a reference for alignment and downstream processing. Like a linear reference genome, it serves as the coordinate system against which sequencing reads are aligned, but instead of being strictly linear, it provides alternative paths and edges representing variation. A graph reference genome may embed to one or more linear reference sequences carrying predefined linear coordinates. These linear reference sequences carrying predefined linear coordinates are referred herein as “position-reference sequences”. Hence, a position-reference sequence can be described as a linear reference sequence endowed with predefined linear coordinates used to anchor a graph.

[0218] A “definition of a reference genome” may be the reference genome itself, i.e., all sequences which define the reference genome, or can be an identifier of a reference genome that may be downloaded from an accessible source, e.g., the internet.

[0219] A “graph genome” is a graph structure configured to encode genetic information in the form of a graph. For example, a graph genome may be used to store a wide spectrum of genetic diversity, including substitutions, insertions, deletions, structural variations, and alternative haplotypes across one or more genomes. It is thus a broad model of genomic variation without being tied to a specific baseline reference. In some examples, a graph genome may comprise a graph reference genome and a plurality of reads aligned to the graph reference genome.

[0220] A “graph element” can be, for example, an atomic component of a graph reference genome. A “node” may be a graph element that stores a DNA sequence fragment. An “edge” may be a graph element representing a directed sequence associated with a connection (also referred to as a segment or branch). In particular, an edge may be a graph element that is self-contained with connection information with other edges.

[0221] A “path” can be an ordered sequence of nodes and edges spelling, upon traversal, a genomic sequence or haplotype.

[0222] An “anchor point” is a location at which a graph element (node or edge) is linked to a specific predefined linear coordinate on the position-reference sequence (e.g., an upstream or downstream anchor for an edge) through a connected path.

[0223] A “read alignment” can be data specifying where and how a read maps to a reference genome. A read alignment may include information such as mapping position(s), orientation, and edit operations. Aligned segments are consecutively mapped portions of a read between discontinuities (e.g., between splice junctions), which may be encoded collectively in a segmentalignment descriptor. If a read comprises multiple splices, the read alignment may specify where an individual splice is aligned to the reference genome.

[0224] In general, a “descriptor” is a structured field within a data format that provides a specific piece of information about the data being represented. The descriptor may be, for example, an MPEG-G descriptor. Each descriptor has a defined syntax (how it is encoded in the bitstream) and semantics (what information it represents). A descriptor, according to some examples, is astructure that contains collectively encoded blocks of data of the same or similar nature (e.g. sequences, positions, alignments, splices, graph path, etc.) for improving compression power. For example, each data block in the “graph path position” descriptor can be an encoded concatenation of position values of all read alignments. In particular, a descriptor may carry information in a compressed, standardized way (e.g., encoding read positions as deltas rather than absolute values). Thereby, a descriptor may allow a decoder to interpret the descriptor to reconstruct meaningful genomic information such as a read’s alignment, a variant call, or a splice. Preferably, a descriptor is organized in the genomic data structure such that decoders can retrieve only the needed information (e.g., only alignment positions, or only splice data) without parsing the whole data content of the genomic data structure.

[0225] A descriptor can in particular be a structure that contains the compressed blocks of values of a specific type of information. For example, a position descriptor may contain the encoded positions of all read alignments. Sometimes, a descriptor can further comprise multiple subsequences (or sub-streams).

[0226] A “splice” can be data denoting a discontinuity in a read alignment where the mapping transitions between separated reference regions. In linear references, a splice may cross between different reference sequences; in graph references, a splice may transition between different graph paths or edges. Splices may be, for example, forward, reverse, or undirected.

[0227] The expression “extended splice information” can be, for example, data to indicate the presence and nature of splice information, in particular splice information related to the alignment to different linear reference sequences or to the alignment to different paths in a reference genome graph. Extended splice information can be stored in one or more fields that explicitly describe complex splice behavior beyond conventional linear intron gaps. Extended splice information may include, for example, cross-sequence and cross-path transitions. Presence of extended splice information may be indicated by a flag or by a parameter that identifies whether splice encoding pertains to a linear or a graph reference genome, enabling mode-aware decoding.

[0228] A “subsequence” within a descriptor, also referred to as “descriptor subsequence”, is an ordered collection of decoded symbols belonging to a descriptor. Each subsequence corresponds to a specific field of information inside a descriptor.

[0229] A “splices descriptor” can be, for example, a descriptor that encodes properties of a splice event. In particular, a splices descriptor may store information being indicative of how splice events in read alignments are represented.

[0230] For example, the structure of the splices descriptor may be as follows: a first flag (subsequence 0) may indicate whether a segment alignment (also referred to as “read alignment” or “aligned read”) contains splices. If splices are present, the splice length is encoded (subsequence 1). For positioning, a flag (subsequence 2) specifies whether a splice position is encoded relative to the previous splice (delta) or as an absolute coordinate. Depending on this flag, either a delta value (subsequence 3) or an absolute position (subsequence 4) is provided. Additional flags allow reuse of reference sequence or path information: subsequence 5 indicates whether the splice uses the same sequence ID as the preceding splice, otherwise a new sequence ID is given (subsequence 6). For graph-aligned data, a further flag (subsequence 7) indicates whether the splice remains on the same graph path as the previous splice.

[0231] This descriptor structure may allow compact and flexible encoding of splice events, supports both linear and graph reference genomes, and reduces redundancy by signaling when positions, sequence IDs, or paths remain unchanged between consecutive splices.

[0232] A “cross-sequence / path transition” can be, for example, a read alignment (e.g. the alignment of multiple splices in a read) spanning from one reference sequence or path to a different sequence or path. An intra-sequence / path transition is a read alignment, in particular an alignment of multiple splices in a read, that is discontinuously aligned to the same sequence or path. In e-CIGAR, cross-sequence / path operators may omit a base count and serve as compact transition markers, while intra-sequence / path operators may carry a base count to denote span length. Each alignment of a read or of a splice within a read may have assigned an orientation indicating the direction of alignment or a splice transition with respect to a path or reference sequence. Forward indicates traversal in the reference’s forward direction; reverse indicates traversal in the reversecomplement direction; undirected may indicate that directionality is unspecified or immaterial for the operation.

[0233] A “graph path descriptor (e.g., gr_path)” can be, for example, a descriptor that identifies the one or more graph paths traversed by each read or traversed by consecutive splices. It encodespath and / or edge identifiers and may employ delimiters to indicate endpoint transitions or midsequence transitions within a path.

[0234] A “graph path position descriptor (e.g., gr_path_pos)” can be, for example, a descriptor specifying the position of each alignment point within a referenced graph path or edge. Positions may be encoded as absolute values on the path or as delta values relative to previous anchors for improved compression.

[0235] A “reference transformation” can be, for example, a sequence edit operation (e.g., substitution, insertion, deletion, inversion) applied to a reference sequence to produce a computed or locally assembled reference better matching to a set of aligned reads. A “Reference Transform Target (rftt) Descriptor” can, for example, identify the target nucleotides of the transformation. A “Reference Transform Position (rftp) Descriptor” can, for example, encode transformation positions. A “Reference Transform Edge (rfte) Descriptor” can, for example, identify the graph edge(s) to which the transformation applies, enabling unambiguous edits in graph references.

[0236] The term “CIGAR” refers to a compact alignment notation expressing matches, mismatches, insertions, deletions, and clipping relative to a reference. An extended CIGAR (e-CIGAR) can, for example, comprise operators for splice transitions and graph-specific events, including operators that (i) carry a base count for intra-sequence / path transitions and (ii) omit a base count for cross-sequence / path transitions. Orientation information (undirected / forward / reverse) for the downstream splice may be encoded by operator choice.

[0237] A “computed reference” can be, for example, a transformed reference sequence derived from an existing reference by applying one or more reference transformations.

[0238] A “local assembly” can denote, for example, a locally reconstructed reference for a genomic region. Both a computed reference and a local assembly may be used to increase compression efficiency by aligning many reads to a closer matching reference.

[0239] The expression “pseudo-linear coordinates” may, for example, refer to linearized positions assigned to points on graph elements (e.g., edges, nodes, paths) to enable interoperability with linear coordinate systems. They may be computed using anchor points linked to predefined linear coordinates on a position-reference sequence. Depending on available anchors, the pseudo-linear coordinate may be calculated by interpolation between upstream and downstream anchors,or as an offset from a single anchor; values may be stored, for example, as integer offsets or absolute linear coordinates. The availability of pseudo-linear coordinates in the data structure may be indicated via, for example, a flag.

[0240] An “annotation table” can be, for example, a structured table associated with graphbased coordinates that stores pseudo-linear coordinates in association with additional information. In particular, an annotation table can be a type of dataset defined in the MPEG-G standard for the storage of downstream genomic data, such as genomic variants. Pseudo-linear coordinates can be stored in the annotation table alongside variants called with respect to a graph reference genome.

[0241] A “searchable index” can be, for example, data that maps query keys to byte offsets or identifiers enabling direct retrieval of relevant data. In some examples, the searchable index may enable random access to a bitstream representing the genomic data structure. Random access is the ability to jump to and selectively decode only the portions of the bitstream that satisfy a query (e.g., a linear genomic range). Selective decoding is the process of decoding only the identified access units, records, and / or descriptors required to answer a query or reconstruct specific results. In some examples, the searchable index of the genomic data structure may be the MPEG-G master index. In other examples, the searchable index is an additional annotation-table-based index or another indexing structure stored in the genomic data structure.

[0242] A “master index” can be, for example, a top-level index structure that enables random access to datasets in a genomic data structure by mapping query keys (e.g., coordinate ranges) to access units and access unit offsets.

[0243] The process of “encoding” can comprise, for example, transforming genomic inputs (reads, alignments, descriptors, reference and / or transformation data) into a compressed bitstream according to a predefined syntax that may depend on the nature of the data to be encoded. The process of “decoding” may refer to the inverse reconstruction process that restores the decompressed representation and, as needed, a transformed or computed reference for alignment interpretation. A compressed representation can be, for example, an entropy-coded, containerized form of the genomic data structure suitable for storage or transmission.

[0244] An extended MPEG-G record is a record that, in addition to standard fields, contains additional data to support additional functionalities. For example, an extended MPEG-G record may comprise one or more of the following: arrays for extended CIGAR strings, arrays forextended splice information, e.g., decoded from a splices descriptor, a graph path descriptor and / or a graph path position descriptor, and / or pseudo-linear coordinates or references thereto, enabling faithful reconstruction of multi-splice and / or graph-aligned reads.

[0245] A “mid-sequence transition” can be, for example, a transition within a path in a graph reference genome, wherein the mid-sequence transition denotes a path away from an internal position of a graph element rather than at its endpoint. An endpoint transition denotes a transition occurring at the boundary of a path or edge. In some examples, a graph path descriptor may encode delimiters to distinguish these cases for precise reconstruction.

[0246] Interoperability may denote the ability to project, compare, and jointly query graph-aligned and linear-aligned datasets using a common coordinate framework. Pseudo-linear coordinates and the associated flags / tables may enable projection of graph-aligned reads into linear coordinate space and support mixed queries by linear ranges.

[0247] User interface output may denote, for example, presentation of reconstructed, decompressed read alignments (including e-CIGAR representation, splice information, etc.) to a human or machine consumer, for example as a textual alignment line and / or a graphical track projected into linear coordinates.

[0248] FIG. 1 illustrates a schematic representation of a genomic data structure 100 according to one example. The genomic data structure may be a hierarchical arrangement of data structures that may contain logically organized blocks of sequencing and other data. The data structure may comprise a file header, at least one dataset group 102, and within each dataset group at least one dataset 104. Each dataset group contains a dataset group header and optional containers (for, e.g., metadata), and it may comprise one or more datasets. For example, each dataset group may selectively comprise sequencing data of a particular source, e.g., a particular individuum. Hence, the data structure 100 may comprise genomic information of one or more sources and hence, comprise one or more dataset groups. Each dataset is composed of a dataset header, a dataset parameter set, and optional containers (for metadata and protection information). It can also optionally contain a master index table - MIT, which facilitates random access inside each dataset. Each dataset may include a dataset header, a dataset parameter set, and one or more access units (AUs). The access unit is the actual data structure that contains the compressed sequencing data. It constitutes the smallest data structure that can be decoded by a decoder, as each access unitcomprises an AU header and one or more blocks containing descriptor streams. The descriptors 106.1-106.3 can include, for example, a splices descriptor 106.1, a graph path descriptor 106.2, a graph path position descriptor 106.3, and / or other types of descriptors. Each descriptor may correspond to a respective stream. A descriptor stream is the sequence of all encoded values of a particular descriptor across a group of genomic records. An access unit contains a collection of blocks. Each block is a portion of a descriptor stream, and it can be decoded independently using information from the dataset parameter set and from other access units, such as access units containing (fragments of) reference sequences. A block is a portion of the descriptor stream that belongs to the genomic records encoded in a particular AU. The data structure 100 may enable modular storage, efficient compression, and selective access of genomic data. In some examples, the genomic data structure is an MPEG-G file in accordance with the MPEG-G standard.

[0249] In accordance with the MPEG-G standard, different categories of genomic information are represented as dataset types. In particular, the standard specifies dataset types including: a dataset type “0” for raw genomic reads, wherein sequencing reads are stored prior to alignment; a dataset type “1” for aligned reads, wherein reads are stored together with alignment information relative to a linear reference genome; a dataset type “2” for a linear reference genome, wherein reference nucleotide sequences corresponding to, e.g. individual chromosomes, and their coordinates are encoded; a dataset type “3” for annotations, wherein variant, functional or other types of annotations with respect to a reference genome are represented; a dataset type “4” for graph-based read alignments, wherein reads are stored together with alignment information relative to a graph reference genome; and in some examples, a dataset type “5” for graph reference genomes, wherein graph-based structures including nodes, edges, and paths are stored to represent pangenomic variations. Each dataset 104 corresponds to one of the dataset types described above. This hierarchical arrangement may ensure that raw reads, aligned reads, linear reference sequences, graph reference genomes, variants, and annotations are each stored in a standardized manner as separate datasets within an MPEG-G file, and that such datasets can be selectively decoded through the use of access units and master index structures.

[0250] For example, the data structure may comprise a reference genome specified in the dataset for data type 5, wherein the graph reference genome comprises a plurality of graph reference genome edges, each specifying a sequence of characters. The plurality of graph reference genome edges may comprise 1000 or more edges, 10,000 or more edges, 100,000 or more edges,or 1,000,000 or more edges, among other options. Each of these edges may comprise a sequence of 10 or more characters, 100 or more characters, or 1,000 or more characters, among other options. Hence, the graph reference genome may be huge, and the methods described herein may significantly improve the speed and functionality of a data processing system configured for processing, encoding and / or decoding genomic data comprising a graph reference genome.

[0251] FIG. 2 shows a flow chart of an example method for representing genomic data in a data structure. The method may be executed by an encoder and may comprise receiving 202, by the encoder, a genomic read and a definition of a reference genome, which may be a linear reference genome comprising multiple sequences or a graph reference genome comprising multiple paths. The expression “receiving a definition” may denote the receiving of the respective genomic reference sequences, or may denote receiving a unique identifier for the reference sequence which may be stored, for example, in a publicly accessible database.

[0252] The read may contain one or more splices that are discontinuously aligned to the reference genome. For instance, a read originating from an RNA transcript may align partially to chromosome 1 and partially to chromosome 2 in the case of a linear reference, or across two alternative paths in a graph reference. The method further comprises generating 204 extended splice information that comprises at least a parameter indicating whether the reference genome is a linear or graph reference genome. The extended splice information may optionally also comprise, for example, splice alignment positions and orientations. Next in step 206, the encoder encodes the read and the extended splice information in a compressed form in a genomic data structure, e.g., in an MPEG-G compliant data structure, and storing 208 the data structure in a memory. This flow highlights how complex splicing events spanning multiple reference sequences or paths may be represented and stored efficiently.

[0253] FIG. 3 shows a flow chart of an example decoding method. The method may be executed by a decoder. In step 302, the decoder receives a genomic data structure comprising compressed genomic information. For example, the genomic data structure generated in the method of figure 2 or a bitstream version thereof may be received in step 302. The compressed genomic information contains extended splice information comprising at least a parameter indicating whether a reference genome referred to in the received genomic data structure is linear or graph-based. The genomic data structure also comprises a compressed representation of one ormore read alignments comprising a read with two or more splices discontinuously aligned to the reference genome. In step 304, the decoder decodes the extended splice information to determine, based on the parameter, whether the underlying reference is linear or graph-based. The decoder then in step 306 reconstructs the alignments of the one or more aligned reads, including the two or more aligned splices, thereby making use of the information whether the reference genome is linear or graph based, e.g., by searching for, de-compressing and applying descriptors which may be different for linear and graph-based reference genomes such as a splices descriptor, a graph path descriptor, and / or a graph path position descriptor. For example, if a read has two splices aligned to different paths of a graph reference genome, the decoder uses the descriptors to restore the precise positions and orientations of these splices. The reconstructed alignment is stored as a decompressed representation in memory in step 308, and is optionally output, e.g., displayed to a user via a graphical user interface or provided to downstream analysis pipelines. For example, the reconstructed alignment may be part of a reconstructed graph genome that can be provided to another memory, represented in a further genomic data structure, or provided via a user interface of the graph data structure system. The user interface may include a display, a mouse, and / or a keyboard for receiving user commands. The user interface may be located with one or more other components of the graph data structure system, or may be located remote from the graph data structure system and in communication via a wired and / or wireless communications network.

[0254] FIG. 4 illustrates a computer-implemented method for computing pseudo-linear coordinates in a graph reference genome. The method may be executed by an encoder and begins with receiving 402 a definition of a graph reference genome comprising edges and a linear reference sequence with predefined linear coordinates. For example, the graph may include multiple alternative edges representing different alleles, while the linear reference sequence corresponds to a canonical chromosome assembly. At step 404, the encoder identifies paths that connect graph edges to the linear reference sequence. In practice, this may involve identifying one or more traversals through the graph that link a variant edge back to a reference chromosome coordinate. Next in step 406, the encoder computes a pseudo-linear position of one or more points on one or more edges of the graph reference genome. This computation may be carried out using anchor points on the path that connect the edges to the linear reference sequence. For example, the pseudo-linear position of a base on an insertion edge may be computed as an offset relative to an upstream anchor located at chromosome 1: 1000. Next at step 408, the encoder assigned to the oneor more points its respectively computed pseudo-linear position. This may ensure that the graph element, although structurally non-linear, can be represented within a linearized coordinate system. Next in step 410, the encoder encodes the graph reference genome together with the pseudo-linear coordinates in a compressed representation. For example, the pseudo-linear coordinates may be delta-encoded relative to upstream anchors, thereby reducing storage space. Finally, at step 412, the encoder stores the genomic data structure comprising the compressed representation in memory. This may enable subsequent decoding, indexing, and random access operations. The process may allow complex graph structures to be mapped consistently into a linear coordinate framework, thereby ensuring compatibility with linear-based genomic tools.

[0255] FIG. 5 illustrates a computer-implemented method for selective decoding of graph reference genome components using pseudo-linear coordinates. The method may be executed, for example, by a decoder. At step 502, the decoder receives a genomic data structure comprising a compressed representation of read alignments, a definition of a graph reference genome, and pseudo-linear coordinates. In step 504, the decoder also receives one or more linear genomic coordinates defining a genomic region of interest. For example, a user may request all graph elements associated with the interval chromosome 1:950-1050. Step 504 and 502 may be performed at any order and also simultaneously. Next in step 506, the decoder uses the one or more linear genomic coordinates received in step 504 as key to search the pseudo-linear coordinates to identify graph components that fall within the specified region of interest. This may include nodes, edges, or paths whose assigned pseudo-linear positions overlap with the requested coordinate range. For instance, an alternative haplotype edge spanning pseudo-linear positions 980-1020 may be identified as relevant. Next in step 508, the decoder decodes only the identified graph components. This allows the decoder to reconstruct only the relevant part of the graph reference genome and any reads aligned to this part, rather than de-compressing the entire dataset. For example, only those edges overlapping the requested interval are de-compressed, thereby reducing CPU and memory usage. At step 510, the decoder storing the reconstructed part of the graph reference genome in memory, making it available for further analysis or visualization. This method may enable random access queries based on linear coordinates while operating on graph-based references, thereby combining the expressive power of graph reference genomes with the efficiency and compatibility of linear coordinate systems.

[0256] Referring to FIG. 6, a block diagram of an example data processing system for encoding, processing and / or decoding genomic information is shown. System 600 may be any of the systems described or otherwise envisioned herein, and may comprise any of the components described or otherwise envisioned herein. According to an example, system 600 comprises one or more of a processor 620, memory 630, user interface 640, communications interface 650, and storage 660, interconnected via one or more system buses 612. It will be understood that FIG. 6 constitutes, in some respects, an abstraction and that the actual organization of the components of the system 600 may be different and more complex than illustrated. According to an example, system 600 comprises a processor 620 capable of executing instructions stored in memory 630 or storage 660 or otherwise processing data to, for example, perform one or more steps of the method. Processor 620 may be formed of one or multiple modules. Processor 620 may take any suitable form, including but not limited to a microprocessor, microcontroller, multiple microcontrollers, circuitry, field programmable gate array (FPGA), application-specific integrated circuit (ASIC), a single processor, or plural processors.

[0257] Memory 630 can take any suitable form, including a non-volatile memory and / or RAM. The memory 630 may include various memories such as, for example LI, L2, or L3 cache or system memory. As such, the memory 630 may include static random access memory (SRAM), dynamic RAM (DRAM), flash memory, read only memory (ROM), or other similar memory devices. The memory can store, among other things, an operating system. The RAM is used by the processor for the temporary storage of data. According to an example, an operating system may contain code which, when executed by the processor, controls operation of one or more components of system 600. It will be apparent that, in examples where the processor implements one or more of the functions described herein in hardware, the software described as corresponding to such functionality in other examples may be omitted.

[0258] User interface 640 may include one or more devices for enabling communication with a user. The user interface can be any device or system that allows information to be conveyed and / or received, and may include a display, a mouse, and / or a keyboard for receiving user commands. In some examples, user interface 640 may include a command line interface or graphical user interface that may be presented to a remote terminal via communication interface 650. The user interface may be located with one or more other components of the system, or maylocated remote from the system and in communication via a wired and / or wireless communications network.

[0259] Communication interface 650 may include one or more devices for enabling communication with other hardware devices. For example, communication interface 650 may include a network interface card (NIC) configured to communicate according to the Ethernet protocol. Additionally, communication interface 650 may implement a TCP / IP stack for communication according to the TCP / IP protocols. Various alternative or additional hardware or configurations for communication interface 650 will be apparent.

[0260] Storage 660 may include one or more machine-readable storage media such as readonly memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, or similar storage media. In various examples, storage 660 may store instructions for execution by processor 620 or data upon which processor 620 may operate. For example, storage 660 may store an operating system 661 for controlling various operations of system 600.

[0261] It will be apparent that various information described as stored in storage 660 may be additionally or alternatively stored in memory 630. In this respect, memory 630 may also be considered to constitute a storage device and storage 660 may be considered a memory. Various other arrangements will be apparent. Further, memory 630 and storage 660 may both be considered to be non-transitory machine-readable media. As used herein, the term non-transitory will be understood to exclude transitory signals but to include all forms of storage, including both volatile and non-volatile memories.

[0262] While system 600 is shown as including one of each described component, the various components may be duplicated in various examples. For example, processor 620 may include multiple microprocessors that are configured to independently execute the methods described herein or are configured to perform steps or subroutines of the methods described herein such that the multiple processors cooperate to achieve the functionality described herein. Further, where one or more components of system 600 is implemented in a cloud computing system, the various hardware components may belong to separate physical systems. For example, processor 620 may include a first processor in a first server and a second processor in a second server. Many other variations and configurations are possible.

[0263] According to an example, storage 660 of system 600 may store one or more algorithms and / or instructions to carry out one or more functions or steps of the methods described or otherwise envisioned herein. For example, storage 660 and / or the memory 630 may comprise one or more of: an operating system 661, a genomic data structure 662, a decoder 663, an encoder 664, and a bioinformatics tool for pre-processing genomic data to be stored in the genomic data structure 662 via the encoder 664 and / or for post-processing genomic data obtained by the decoder 663 decoding the genomic data structure 662.

[0264] Referring to FIG. 7, in one example, is a graph-based reference genome 700 comprising a plurality of edges. In this example, the edges are patterned to represent a common source of edges. For example, edges 704 and 706 comprise the same pattern and thus were obtained from the same sample or source. Edges 714 and 716 similarly comprise a common pattern and were obtained from the same sample or source, but a different sample or source than edges 704 and 706. Edges 702 and 718 respectively were obtained from sources different from the previous samples or sources. Lastly, edges 708, 710 and 712 comprise a common pattern and were obtained from the same sample or source. In this example, edges 708, 710 and 712 correspond to a linear reference genome.

[0265] Although a display of the reference genome may comprise a visual indication of source such as the color or patterning as depicted in FIG. 7, or any other visual indicator, this is not a requirement. Further, when the reference genome is stored in memory, the indication of source may be a data point associated with the stored reference genome. In figures 7 to 13, endpoint edge transitions are indicated via circles at the ends of the edges, and mid-sequence edge transitions are indicated via diamond symbols.

[0266] According to an example, a graph-based reference genome can be stored in a memory of a computer system as a graph data structure, as described herein. The graph data structure represents a plurality of genomic sequences and can comprise at least a portion of a reference genome. The reference genome can be for anything that comprises a genome. The graph data structure thus comprises a graph reference genome, comprising a plurality of graph reference genome edges, each specifying a sequence of characters, and a plurality of links representing connections between the plurality of graph reference genome edges. Each of the plurality of graphreference genome edges represents a respective path through a portion of the graph reference genome.

[0267] FIG. 8 shows a copy 800 of the graph reference genome 700 in which a first path through the graph is highlighted in black.

[0268] FIG. 9 shows a copy 900 of the graph reference genome 700 in which a second path through the graph different from the first path is highlighted in black.

[0269] As can be seen from figures 7-9, a path through the graph reference genome may be specified by a list of edge-IDs and transitions from one edge to another and finally to the linear graph reference sequence(s).

[0270] FIG. 10 is a further example of a graph reference genome 902 that will be used in the following to illustrate different types of connections and how the connections can be characterized in a genomic data structure. The graph reference genome 902 comprises a plurality of edges A01, A02, B01, E01, B02 and a linear reference sequence C01. The edge E01 is connected to the reference sequence C01 at the anchor points p3, p4 via two endpoint edge transitions. The edge E01 is in addition connected to edges B01 and B02 via respective endpoint edge transitions, and is connected to the edges A01, A02 via mid-sequence edge transitions. Hence, the edge E01 may have six types of connection [1] to [6] to other edges and the reference sequence which may be characterized as follows:

[0271] For each connection associated with the edge indexed by i, the following fields may be specified in the genomic data structure: conn_edge_ID[i] is the ID of the edge to which the current edge is connected. conn_is_upstream[i] is a flag, if set to 1, indicates the connecting edge is on the upstream of the current edge, i.e. a path can only traverse from the connecting edge into the current edge but not vice versa. Otherwise, it is on the downstream. If the graph reference supports edges branching in or out from the middle of an edge sequence, the following additional fields are required: conn_type[i] is the type of the connection. Possible values include: 0 for a connection between the end points of two edges, 1 for branches in the middle of the current edge sequence, and 2 for a connection that joins an end point of the current edge to / from the middle of another edge sequence.

[0272] FIG. 11 is an illustration of a graph reference genome 904 comprising at least an edge EA aligned with and connected to a linear reference sequence R02, and how a pseudo-linear coordinate may be computed for a position PA on said edge edge EA.

[0273] The pseudo linear position for the position PA on edge EA in the graph reference 904 is computed with respect to a designated “linear sequence”, which is a collection of edges R02, R03 spanning across the graph with pre-defined linear coordinates. In addition to the linear reference sequence indicated by the connected edges R02, R03, the graph reference genome may comprise a further, disconnected linear reference sequence ROE The “linear sequence(s)” can be incorporated from an existing linear reference genome, e.g. Chromosome 1 of Human Genome Assembly GRCh38 (hg38). The linear reference sequence R01 and the further linear reference sequence {R02, R03} are represented as a thick solid line segments (or sequence thereof for R02 and R03) at the bottom of the figure and may be referred to as “linear reference sequence(s)” or “position reference sequence”.

[0274] The pseudo linear position of a point PA on edge EA connected to the linear reference sequence R02 through a path can be estimated by first identifying the upstream anchor point pl and the downstream anchor point p2 of the edge EA on the linear reference R02 and then computing a position between the known linear coordinates of the two anchor points pl, p2 that reflects the relative position of the point on the edge / path connecting the two anchor points. For example, withreference to the figure, the pseudo linear position of a point PA on edge EA at distance XA from the beginning of the edge EA can be estimated by the following formula:

[0275] where pi and p2 are the known linear positions of respectively the upstream and downstream anchor points of Edge A, and 1A is the sequence length (number of nucleotide bases) of Edge A.

[0276] In the case that only one anchor point exists for an edge, the pseudo linear position can be estimated by eitherpos(Edge_A, xA) = Pi + xA, if only upstream anchor point (at pi) existsOrpos(Edge_A, xA) = p2— (lA— xA), if only downstream anchor point (at p?) exists.

[0277] FIG. 12 is an illustration of a graph reference genome 906 comprising at least two edges EA and EB aligned with and connected to a linear reference sequence R02, and how a pseudo-linear coordinate may be computed for a point PB on said edge EB.

[0278] The pseudo linear position of a point PB on said edge EB at distance defined by position XB from the beginning of the edge can be estimated by the following formula:

[0279] where pi and ps are the known linear positions of respectively the upstream and downstream anchor points of edge EB (“Edge B”), XA is the local position on edge EA (“Edge A”) connected to Edge B, and 1B is the sequence length (number of nucleotide bases) of Edge B.

[0280] In the case where an edge is connected to the linear reference in a graph reference genome through multiple paths, one of the paths can be selected for computing the pseudo linear position. Different path selection strategies can be applied, e.g. selecting the path containing the least number of edges, selecting the path containing the least number of nucleotide bases, or further excluding paths that involve edges incorporated into the graph reference in a version after the current edge was incorporated. Other possible approaches include selecting thesmallest / median / largest value or computing a weighted average of the pseudo linear positions estimated from the multiple paths.

[0281] FIG. 13 is an illustration of a read 1202 comprising multiple splices SI, S2 and S3 922 which are aligned to linear reference sequences. The figure shows that the two splices SI and S2 are aligned across two different linear reference sequences R01 and R02, while the two splices S2 and S3 are aligned discontinuously to the same linear reference sequence R02.

[0282] A discontinuous mapping (or “alignment”) means that a single read does not align in one contiguous stretch, but instead aligns in pieces to different regions of the same sequence or even to different sequences. Such discontinuous mappings may occur, for example, in RNA sequencing, where reads may span exon-exon junctions, thereby aligning to multiple exons that are separated by intronic regions in the genomic reference. Discontinuous mappings may further arise in graph reference genomes, where a read traverses multiple alternative allelic paths, or in repetitive regions, where distinct parts of the read align to separate repeat units.

[0283] The representation of such discontinuous alignments is supported, according to some examples of the disclosed methods and systems, by means of extended alignment information, stored, for example, in a splices descriptor and other descriptors, which may allow a single read to be encoded together with information describing its alignment across multiple non-contiguous regions or across different reference sequences or paths. For example, the multiple linear reference sequences R01 and R02 may be different chromosomes. They may be comprised in a graph reference genome or they may be used as a linear reference genome comprising multiple different reference sequences.

[0284] FIG. 14 is an illustration of a graph reference genome 930 comprising multiple edges 752-768 to which splices 922 of a read 1202 are aligned. The read 1202 comprising multiple splices SI, S2 and S3 which are discontinuously aligned to different edges 754, 752, and hence, different paths, within the graph reference genome 930. The figure shows that the two splices SI and S2 of the read 1202 are aligned across two different reference edges 754, 752, and hence, different paths, while the two reads S2 and S3 are aligned discontinuously to the same edge 752, and hence, the same path, within the graph reference genome 930. The one or more linear reference sequences comprised in a graph reference genome is not shown in FIG. 14. Rather, the sequenceof edges 754, 760, 766 is highlighted in black color to illustrate that they together represent a path that is different from the path to which the splices S2 and S3 are aligned.EXAMPLES

[0285] Described below are examples of possible applications of the methods and systems described or otherwise envisioned herein. These examples are provided only as possible examples of the methods and systems described or otherwise envisioned herein, and therefore do not limit or prohibit other possible variations and examples. The data structure and format in which the genomic data is packaged and stored may take any of a wide variety of formats. Although a specific format of data storage and manipulation is described below with reference to various examples, it is understood that this is just one example of a data structure that may be utilized by the graph data structure system described or otherwise envisioned herein.

[0286] In some examples, support is provided for extended splice information for genomic reads aligned to both linear and graph reference genomes. The availability of such extended splice information may be indicated by means of a Boolean flag, for example a variable extended splice info flag set to “ 1”, or alternatively by means of a dataset type value, for example a variable dataset_type set to “4”, thereby signaling that the dataset comprises graph-aligned data.

[0287] According to examples, the dataset type may be used to indicate whether a dataset contains linear or graph-based alignment data. For linear alignment data, the splices descriptor is optional and its presence is indicated by setting the extended splice information flag to 1. The extended splice information is stored entirely in the splices descriptor. For graph-based alignment data, i.e., if the reference genome is a graph reference genome, the splices descriptor, the gr path descriptor and the gr_path_pos descriptor are always present. The splice information is contained across all these three descriptors.

[0288] In further examples, the syntax of a descriptor, e.g., of the splices descriptor, the graph path descriptor (gr path), and of the graph path position descriptor (gr_path_pos), as well as the data structure used for storing compressed bit streams of extended splice information and graph alignment data, together with the corresponding decoding processes, are described which represent an updated, extended version of the descriptors currently available in the MPEG-G standard. The updated syntax may have the advantage that each splice (i.e. split segment) of a read alignment, whether linear- or graph-based, can be mapped to different reference sequences (e.g.chromosomes) and, in the case of graph-aligned data, to different paths of a graph reference genome. This contrasts with the existing MPEG-G specification, in which all splices belonging to a single read alignment must be mapped to the same reference sequence.

[0289] The updated syntax of a genomic data structure stored as an MPEG-G file and the respective algorithms for encoding and decoding an MPEG-G file may have the advantage of being fully integratable and backward compatible, such that they function seamlessly with MPEG-G files encoded in accordance with earlier editions of the MPEG-G standard.

[0290] In the following, concrete examples will be provided for an updated and extended syntax and decoding process of CIGAR strings. In the extended CIGAR (e-CIGAR) syntax, CIGAR strings are updated such that splices mapped to different sequences or paths are supported. The e-CIGAR string thereby continues to compactly capture differences between read alignments and their corresponding references while being extended to handle cross-sequence and cross-path splicing events.

[0291] In additional concrete examples described below, support is provided for the use of pseudo-linear genomic coordinates for graph-aligned data, in addition to path-based positions that count the number of nucleotide bases from the beginning of a specific edge identified by an edge ID in the graph reference genome. Pseudo-linear coordinates allow cross-referencing of graph-aligned data with linear reference genomes, thereby improving interoperability between linear and graph-based genomic data and applications. The availability of pseudo-linear coordinates may be signaled by means of a Boolean flag, for example a variable pseudo linear pos flag set to “1” in graph-based datasets.

[0292] In addition, an example of a new descriptor, referred to as the Reference Transform Edge Descriptor (rfte), is described together with its decoding process. The rfte descriptor extends existing computed reference algorithms, such as “reference transformation” and “local assembly”, to enable editing of graph reference genomes in addition to linear reference genomes, with corresponding adaptations to the algorithms.

[0293] In the examples described herein, we refer to the MPEG-G specifications ISO / IEC 23092-1 “Transport and Storage of Genomic Information” (3rd Edition) simply as Part 1, ISO / IEC 23092-2 “Coding of Genomic Information” (3rd Edition) simply as Part 2, and ISO / IEC 23092-6 “Coding of Genomic Annotations” (1st Edition) simply as Part 6. For clarity, references in thedescription below to clauses, subclauses and table numbers correspond to the respective clauses, subclauses and table numbers in the MPEG-G standard, and modifications to existing text in the specifications are highlighted in bold. The MPEG-G standard is enclosed herewith in its entirety.

[0294] Proposed Changes to MPEG-G Part 1

[0295] Subclause 6.4.3.2 Dataset Header

[0296] In accordance with an example, with respect to the two dataset types 4 and 5, update the dataset header syntax: Include parameters specific to the following new dataset types: dataset type = 4 for graph-aligned content; and dataset type = 5 for graph reference as indicated in the table below:Updated Dataset Header Syntax

[0297] Subclause 6.4.3.7 Dataset Parameter Set

[0298] For dataset type = 4, include graph-related parameters in the encoding parametersQ data structure. For dataset type = 5, include a graph_ref_encoding_parameters() data structure.Updated Dataset Parameter Set Syntax

[0299] Subclause 6.4.6.1 Annotation Table Header

[0300] According to one example, parameters for graph-based genomic coordinates are included in the annotation table header as indicated in the table below:Updated Annotation Table Header Syntax

[0301] Subclause 6.4.1.3 Reference

[0302] According to one example, the following new reference types are included in Tables 15 and 16 of Part 1 of the MPEG-G standard:- reference type = MPEGG GRAPH REF for graph reference encoded as a dataset - reference type = RAW GRAPH REF for raw graph reference as specified in Table 2 - reference type = GFA REF for graph reference of type Graph Fragment Assembly (GF A) format

[0303] In addition, new subclauses “Supported GF A format” and “Conversion to raw graph reference” are added as indicated in the table below:Updated Reference Box SyntaxUpdated reference type Values

[0304] Subclause 6.3 Output Data Unit

[0305] According to some examples, the following new data unit types are added to the Data Unit Syntax of the MPEG-G standard as indicated below:■ data unit type = 5 for raw graph reference■ data unit type = 6 for graph-based parameter set■ data unit type = 7 for graph reference access unitsUpdated Data Unit Syntax

[0306] Proposed Changes to MPEG-G Part 2

[0307] According to some examples, the genomic data structure comprises data in accordance with a modified version of the syntax of MPEG-G Part 2 “Coding of Genomic Information”.

[0308] Subclause 7.2 Data Units

[0309] According to the modified syntax, the genomic data structure according to some examples includes new data unit types (similar to subclause 6.3 of Part 1), e.g., new data types 6 and 7, as specified in the table below.Updated Data Unit Syntax

[0310] Subclause 7.4.2 Encoding Parameters

[0311] According to some examples, the syntax of the encoding parameters of MPEG-G may be updated such that these parameters include a new parameter extended splice info flag, applicable to both linear and graph-aligned data. In addition, the encoding parameters may include new graph-related parameters specifically for graph-aligned data. Accordingly, in some examples, the semantics of NUM DESCRIPTORS is updated such that its value is set to 22.Updated Encoding Parameters Syntax

[0312] Subclause 7.6 Raw Graph Reference

[0313] According to some examples, a subclause for raw graph reference() and its associated data structures is added to the MPEG-G file syntax.Modified Raw Graph Reference SyntaxNew Group Syntax according to some examples

[0314] Thereby, the field “group ID” is the unique identifier of this group of edges, or segments and links. The field “group name” is the name of a group. The fields “group_maj_ver[i], group_min_ver[i]” are respectively the major and minor versions of the graph reference to which the group was first added. The use of version identifiers may enable traceability of when specific groups of edges or paths were added to the evolving graph reference genome, thereby supporting compatibility across different versions of the reference, facilitating updates, and ensuring reproducibility in downstream analyses. Hereby, a “field” can be the smallest, explicitly defined element of information in the bitstream syntax of an MPEG-G file. It corresponds to a specific data item inside a descriptor, header, or parameter set. Fields can be of fixed or variable length andare encoded using the bit-level coding rules specified in the standard (often with entropy coding such as CABAC). Together, fields form descriptors (e.g., a splices descriptor contains data that can be decoded into multiple fields like splice_len[j][i][k], splice_seq_ID[j][i][k], splice_pos[j][i][k]).New Edge Syntax according to some examples

[0315] Thereby, the field “edge lD” is the unique identifier of this edge in the graph. The field “edge group ID” is the identifier of the group to which the edge belongs. Edges in the same group are generally derived from the same source. The field “edge rank is the rank of the edge in the graph, 0 for edges on the linear reference, >0 otherwise. The field “edge len is the number of characters in the sequence represented by the edge. The field “edge seq is the sequence ofcharacters represented by the edge. The field “n conn” is the number of connections associated with the edge.

[0316] For each connection associated with the edge indexed by i, the following fields are specified: “conn_edge_ID[i]” is the ID of the edge to which the current edge is connected; “conn_is_upstream[i]” is a flag, if set to 1, indicates the connecting edge is on the upstream of the current edge, i.e. a path can only traverse from the connecting edge into the current edge but not vice versa. Otherwise, it is on the downstream.

[0317] If the graph reference supports edges branching in or out from the middle of an edge sequence, the following additional fields are required: The field “conn_type[i]” is the type of the connection. Possible values include: 0 for a connection between the end points of two edges, 1 for branches in the middle of the current edge sequence, and 2 for a connection that joins an end point of the current edge to / from the middle of another edge sequence. “conn_pos[i]” is the position on the current edge (when conn_type[i] == 1) or the connecting edge (when conn_type[i] == 2) at which the connection takes place. This value is omitted when the connection is at the end points of the two edges (when conn_type[i] == 1). A concrete example for the use of these fields for encoding the topology of the connected edges of a graph reference genome is illustrated in Figure 10.

[0318] Subclause 7.7 Graph Reference Parameter Set

[0319] According to some examples, a subclause for a graph_ref_parameter_set() data structure is added. The added subclause includes: Parameters for the coding of graph reference data (dataset type = 5), and attribute and compressor parameter sets for including user-defined data fields per graph element.New Graph Reference Parameter Set Syntax according to some examplesNew Graph Reference Encoding Parameters Syntax according to some examples

[0320] Subclause 7.8 Graph Reference Access Unit

[0321] According to some examples, a subclause for a graph_ref_access_unit() data structure that contains a header and the payload blocks of a graph reference is added to the subclause 7.8.

[0322] Clause 8 Descriptors

[0323] According to some examples, the descriptors mentioned in clause 8 in addition include genomic descriptors and the definitions of their subsequences for “aligned data” and for “graph reference data”.

[0324] The descriptors and definitions of the “aligned data” includes one or more of: gr_path for holding the path information for each read alignment; gr pos for holding the start position of each read alignment with respect to the beginning of the path to which it is aligned; splices for holding the splicing information for each read alignment, allowing splices of the same segment tobe mapped to different reference sequences and paths; and rfte for holding the edge IDs associated with each substitution in reference transformation specified by the rftp and rftt descriptors.

[0325] Preferably, graph reference data - descriptors and attributes are derived from the syntax of the raw_graph_reference() data structure.New Genomic Descriptors for Graph-Aligned DataNew Subsequences for descriptor_ID = 18 (Splices Descriptor)

[0326] The Splices Descriptor (descriptor lD = 18) defines how splice events in read alignments are represented. A first flag (subsequence 0) indicates whether a segment alignment contains splices. If splices are present, the splice length is encoded (subsequence 1). For positioning, a flag (subsequence 2) specifies whether a splice position is encoded relative to the previous splice (delta) or as an absolute coordinate. Depending on this flag, either a delta value (subsequence 3) or an absolute position (subsequence 4) is provided. Additional flags allow reuse of reference sequence or path information: subsequence 5 indicates whether the splice uses the same sequence ID as the preceding splice, otherwise a new sequence ID is given (subsequence 6). For graph-aligned data, a further flag (subsequence 7) indicates whether the splice remains on the same graph path as the previous splice.

[0327] This descriptor structure may allow compact and flexible encoding of splice events, supports both linear and graph reference genomes, and reduces redundancy by signaling when positions, sequence IDs, or paths remain unchanged between consecutive splices.New Subsequences for descriptor_ID = 11, 15 and 19 (msar, rname and gr path Descriptors)

[0328] According to examples, for the msar (descriptor_ID = 11), rname (descriptor_ID = 15), and gr path (descriptor lD = 19) descriptors, the syntax defines two subsequences. Subsequence 0 specifies the output of the decode descriptor subsequenceQ function when using CABAC METHOD O, and subsequence 1 specifies the output when using CABAC METHOD 1, as set out in subclauses 10.4.20.4.5 and 10.4.20.4.6 of the MPEG-G standard. Both subsequences are represented as unsigned integers. This construction may allow alternative entropy coding methods to be applied for efficient compression of descriptor values.New Subsequences for descriptor lD = 20 (gr path pos Descriptor)

[0329] The gr_path_pos descriptor (descriptor_ID = 20) may define how the position of a segment aligned to a graph path is encoded. A first flag (subsequence 0) indicates whether the segment aligns to the same path as the previous one. A second flag (subsequence 1) indicates whether the segment’s position is given as a relative delta to the previous alignment or as an absolute coordinate. Depending on this flag, either a delta value (subsequence 2) or an absolute position (subsequence 3) is provided. This structure may enable compact and flexible encoding of graph-based alignment positions.

[0330] The table specifies the internal structure of the rfte descriptor used in some examples of the disclosure. It defines a flag (subsequence 0) to indicate whether the substitution is on the same edge as the previous one, and, if not, provides the new edge ID (subsequence 1). This design improves compression by avoiding redundant transmission of edge IDs.New Subsequences for descriptor_ID = 21 (rfte Descriptor)

[0331] Subclause 9.6 Aligned Data

[0332] According to some examples, additional descriptors are defined for integration into the MPEG-G syntax. In particular, a splices descriptor, a graph path (gr path) descriptor, and a graph path position (gr_path_pos) descriptor are introduced and incorporated into Table 39 of the MPEG-G standard, which specifies the set of descriptor identifiers and their associated semantics. The inclusion of these descriptors extends the MPEG-G framework to natively support the representation of spliced alignments, graph path traversals, and path-based positional information, thereby enabling efficient encoding and decoding of read alignments to graph reference genomes..

[0333] Subclause 10.2.3 Type 1 AU (Class P)

[0334] Type 1 access units encode aligned sequencing reads which perfectly match the used reference sequence. At the beginning of the decoding process of each AU the variables msar_k and gr_path_k are initialized to 0.n) If dataset type == 4 (graph-aligned data), decode the gr path and gr path pos descriptors (proposed) as specified in subclauses 10.4.21 and 10.4.22.o) If dataset type == 4 (graph-aligned data) or extended splice info == 1, decode the splices descriptor as specified in subclause 10.4.20.p) If this process is being applied to access units of type 1 (Class P)

[0335] Hence, in some examples, the MPEG-G decoding process for type 1 access units (Class P), which encode aligned sequencing reads that perfectly match the reference sequence, is extended to support graph-aligned data and extended splice information. At the beginning of decoding each access unit, the variables msar k and gr_path_k are initialized to zero. In the case that the dataset type is equal to 4, corresponding to graph-aligned data, the decoder further decodes graph path (gr_path) and graph path position (gr_path_pos) descriptors in accordance with subclauses 10.4.21 and 10.4.22. In addition, if the dataset type is equal to 4 or if extended splice information is signaled as being present, the decoder also decodes the splices descriptor as specified in subclause 10.4.20. These measures extend the MPEG-G decoding process to enable the efficient reconstruction of read alignments aligned to graph reference genomes, as well as the handling of complex splice events.

[0336] Subclause 10.4.10 pair

[0337] In some examples, the MPEG-G syntax is modified in subclause 10.4.10 with respect to the field splicedSegMappingPos[i][j] in Table 63. The existing clause “on the same reference sequence as the previous splice” is deleted, since in the case that the variable extended splice info flag is set to 1, splice events are no longer restricted to occur on the same reference sequence. Instead, the splice can be mapped to a different reference sequence or, in the case of graph-aligned data, to a different path in the graph reference genome.

[0338] This modification may allow the MPEG-G standard to represent complex splice alignments across multiple reference sequences or paths, thereby extending the expressive capability of the syntax and enabling accurate reconstruction of discontinuous read alignments in both linear and graph-based reference contexts.

[0339] Add Subclause 10.4.20 splices (Decoding Process of Proposed Descriptor)

[0340] The splices descriptor holds additional splice information for each segment alignment. It supports the coding of splices that are mapped to different reference sequences and paths. This descriptor is only present if dataset type == 4 (graph-aligned data) or extended splice info flag == 1.The inputs to the decoding process are:- the variables dataset type, spliced reads flag and extended splice info flag (proposed) specified in subclause 7.4.2 of Part 2;- the variable classld specified in subclause 10.2.3 of Part 2;- the variable numberOfAlignedRecordSegments specified in subclause 10.4.10 of Part 2; - the array numberOfSegmentAlignments[] specified in subclause 10.4.12 of Part 2;- the arrays readLength[], numberOfSplicedSeg[] and splicedSegLength[][] specified in subclause 10.4.9 of Part 2;- the array gr_path_pos[][] specified in the decoding process of the gr_path_pos descriptor; - the array mappingPos[][] specified in subclause 10.4.2 of Part 2;- the arrays splicedSegMappingPos[][] and mateSeqId[][] specified in subclause 10.4.10 of Part 2;- the variable seqld set to sequence lD as specified in subclause 7.5.1.2 of Part 2.

[0341] The outputs of this process are the following arrays that provide splicing / splitting information for each read alignment:- n_splices[j][i], the number of splices in each segment alignment;- splice_len[j][i][k], the length of each splice;- splice_seq_ID[j][i][k], the ID of the reference sequence to which a splice is aligned; - splice_pos[j][i][k], the position of each splice. For linear reference, the position is with respect to the beginning of the reference sequence. For graph reference, the position is with respect to the beginning of the path to which the splice is aligned;- splice_same_path[j][i][k], a flag, if set to 1, indicates a splice is on the same path as the previous splice in the same segment alignment, not used for the first splice of each alignment (i.e. k == 0).

[0342] For all output arrays, i is the template index, j is the template-specific alignment index, and k is the splice index. In this description, subsequenceN is the subsequence identified by descriptor_subsequence_ID = N (i.e. subsequenceN = decoded_symbols

[0018] [N]).Decoding Process of the splices Descriptor

[0343] Hence, in some examples, a new subclause 10.4.20 is introduced to define the decoding process of a proposed splices descriptor. The splices descriptor holds additional splice information for each segment alignment and supports the encoding of splices that may be mapped to different reference sequences or to different graph paths. The descriptor is present when the variabledataset type is equal to 4 (graph-aligned data) or when the variable extended splice info flag is set to 1.

[0344] The inputs to the decoding process include variables and arrays defined in existing subclauses of Part 2 of the MPEG-G standard, such as dataset type, spliced reads flag, classld, numberOfAlignedRecordSegments, numberOfSegmentAlignments[], readLength[], numberOfSplicedSeg[], splicedSegLength[][], gr_path_pos[][], mappingPos[][], splicedSegMappingPos[][], and mateSeqId[][], as well as the variable seqld. The decoding process produces the above-mentioned arrays that describe the number and properties of splice events for each read alignment.

[0345] The step-by-step decoding process uses subsequences of descriptor!!) = 18 to determine whether segment-specific alignments have splices, to compute splice lengths, to determine splice positions either as relative deltas or as absolute coordinates, and to assign sequence identifiers either by reference to the same sequence as a prior splice or by decoding a new sequence identifier. For graph-aligned data, additional flags indicate whether consecutive splices are on the same graph path.

[0346] By introducing this decoding process, the MPEG-G framework may be extended to support spliced read alignments across different sequences or paths, thereby enabling efficient representation of discontinuous alignments in both linear and graph-based reference genomes. This may improve expressive capacity of the standard and may ensure accurate reconstruction of complex read alignments during decoding.

[0347] Add Subclause 10.4.21 gr path (Decoding Process of Proposed Descriptor)

[0348] In some examples, a new subclause 10.4.21 is introduced to define the decoding process of the proposed gr_path descriptor. The gr_path descriptor holds path information for each splice in each segment alignment and shall be present in a compliant bitstream when the variable dataset type is equal to 4, i.e. for graph-aligned data. Each gr path descriptor is encoded as a string of ASCII characters comprising a concatenated list of edge identifiers separated by delimiters. A primary delimiter, the symbol is used to indicate endpoint transitions between edges.

[0349] For graph references that support mid-sequence transitions (as indicated by the field mid seq transition flag as specified in raw_graph_reference() is set to 1), a secondary delimiter,the symbol is used to indicate mid-sequence transitions, when gr_second_path_delim as specified in Dataset Header is set to 1.

[0350] To make the representation of a path more compact, an edge ID Ei can be omitted in accordance with defined omission rules. Specifically, with respect to the previous edge Ei-i, it is the only possible edge or one of the highest preference in the graph. The edge omission rules are as follows:1. Determine the set of all possible edges connected to Ei-i on the downstream. If both mid_seq_transition_flag and gr second path delim are set to 1, extract only the edges branching out from the middle of Ei-i if the delimiter symbol is “>”, and extract only the edges connected to the end point of Ei-i on the downstream if the delimiter symbol is 2. If among all possible downstream edges there exist one or more edges belonging to the same edge group as Ei-i, then the one with the smallest edge index is selected as the preferred edge Epand go to Step 4.3. If among all possible downstream edges there exist one that belongs to the linear reference of rank 0, it is selected as the preferred edge Ep.4. If Ei == Ep, then the edge Ei can be omitted in the path.

[0351] The omission rules are repeatedly applied to all edges in the path except the first one. After path contraction, any consecutive sequence of at the end can be removed.

[0352] The syntax, semantics, and decoding process for the gr_path descriptor follow those of the tokentype descriptor as specified in subclause 10.4.20, when the variable encodingMode_ID is set to 0 in accordance with Table 8 of Part 2. The decoding produces the array decodedStrings[] as specified in subclause 10.4.20.5 of Part 2, for descriptor_ID equal to 19, with the variable gr_path_k defined in subclause 10.2.3 being used.

[0353] The output of the decoding process of the gr path descriptor is the array decodedStrings[] specified in subclause 10.4.20.5 of Part 2, when descriptor_ID is equal to 19.

[0354] The table below shows how the arrays of strings gr_path[][] and splice_path[][][] are computed using the following additional inputs:the variables dataset_type and spliced_reads_flag specified in subclause 7.4.2 of Part 2;- the variable classld specified in subclause 10.2.3 of Part 2;- the variable numberOfAlignedRecordSegments specified in subclause 10.4.10 of Part 2; - the variable numberOfAlignments, and the arrays numberOfSegmentAlignments[] and alignPtr[][] specified in subclause 10.4.12 of Part 2;- the array gr_path_same_as_prev[] [] specified in the decoding process of the gr path pos descriptor;- the arrays n_splices[][] and splice_same_path[][][] specified in the decoding process of the splices descriptor.

[0355] The output array gr_path[j][i] holds the path of each segment alignment or its first splice, and splice_path[j][i][k] holds the path of each splice in each segment alignment, where i is the template index, j is the template-specific alignment index, and k is the splice index.

[0356] Hence, by using the decoded strings, the arrays gr_path[j][i] and splice_path[j][i][k] can be computed. Here, gr_path[j][i] holds the path of each segment alignment or of its first splice, while splice_path[j][i][k] holds the path of each splice in a segment alignment, where i is the template index, j is the template-specific alignment index, and k is the splice index. Additional inputs for this process include the variables dataset type, spliced reads flag, and classld, as well as arrays such as numberOfSegmentAlignments[], alignPtr[][], gr_path_same_as_prev[][] from the decoding of the gr_path_pos descriptor, and splice-related arrays n_splices[][] and splice_same_path[][][] obtained from decoding of the splices descriptor.

[0357] By introducing the gr_path descriptor and its decoding process, the MPEG-G standard is extended to provide efficient and compact representation of graph path traversals in read alignments, thereby enabling accurate reconstruction of complex graph-based splicing events during decoding.Decoding Process of the gr path Descriptor

[0358] In some examples, the decoding of the gr_path descriptor is performed only when dataset type == 4 (graph-aligned data) and classld!= Class U. The process consumes path tokens from the array decodedStrings[] and reconstructs, for each segment-specific alignment and, where applicable, for each splice, the corresponding graph path strings.

[0359] Initialization and first segment (i = 0): For the leftmost record segment, the first template-specific alignment gr_path[0] [0] is set either (i) by copying the previously decoded path gr_path_prev when gr_path_k > 0 and gr_path_same_as_prev[0] [0] is true, or (ii) by consuming the next token decodedStrings[gr_path_k++] when a new path must be read. The resulting value is stored into gr_path_prev. For the remaining template-specific alignments of the first segment (j = 1... numberOfSegmentAlignments[0] - 1), the decoder reuses the immediately preceding path gr_path[j— 1 ] [0] when gr_path_same_as_prev[j][0] is true; otherwise it consumes the next token from decodedStrings[],

[0360] Subsequent segments (i > 1): For each additional record segment, alignments are visited in increasing order of the alignment indices alignIdx = alignPtr[j][i]. For each visited alignment, if gr_path_same_as_prev[alignIdx][i] is true, the decoder copies the path from the alignment in the previous segment (gr_path[alignPtr[j][i-1]][i-1]), thereby allowing inter-segment path reuse; otherwise, it consumes the next path token decodedStrings[gr_path_k++] and assigns it to gr_path[alignIdx] [i].

[0361] Per-splice paths: When spliced reads flag is set, the decoder also derives splice-level paths. For each segment i and each template-specific alignment j, the path of the first splice is initialized from the segment path: splice_path[j][i][0] = gr_path[j][i]. For subsequent splices k = 1... n_splices[j][i] - 1, if splice_same_path[j][i][k] is true, the path is copied from the previous splice splice_path[j][i][k— 1]; otherwise, a new token is consumed from decodedStrings[] and assigned to splice_path[j][i][k].

[0362] Outputs and indices: The process yields two arrays: (i) gr_path[j][i], the graph path string of each segment-specific alignment (first splice or segment path); and (ii) splice_path[j][i][k], the graph path string of each splice in each segment-specific alignment. Here, i denotes the record-segment (template) index, j denotes the template-specific alignment index, and k denotes the splice index. The variable gr_path_k is a running pointer into decodedStrings[],

[0363] The described reuse conditions (gr_path_same_as_prev, splice_same_path) and crosssegment copying via alignPtr may minimize the number of path tokens that must be explicitly transmitted and decoded. As a result, the bitstream may achieve higher compression efficiency while guaranteeing deterministic reconstruction of segment- and splice-level graph paths for graph-aligned datasets.

[0364] Add Subclause 10.4.22 gr path pos (Decoding Process of Proposed Descriptor)

[0365] The gr_path_pos descriptor holds the position on a path that marks the starting point of each segment alignment or its first splice. It shall be present in a compliant bitstream when dataset_type == 4 (graph-aligned data).

[0366] The inputs to the decoding process are:- the variable dataset_type specified in subclause 7.4.2 of Part 2;- the variable classld specified in subclause 10.2.3 of Part 2;- the variable numberOfAlignedRecordSegments specified in subclause 10.4.10 of Part 2; - the variable numberOfAlignments and the array alignPtr[][] specified in subclause 10.4.12 of Part 2.

[0367] The outputs of this process are:gr_path_same_as_prev[j][i], a flag, if set to 1, indicates the current segment alignment orits first splice is on the same path as the previous one;- gr_path_pos[j][i], the position on a path that marks the beginning of the current segment alignment or its first splice.

[0368] For both output arrays, i is the template index, and j is the template-specific alignment index. In this description, subsequenceN is the subsequence identified by descriptor_subsequence_ID = N (i.e. subsequenceN = decoded_symbols

[0020] [N]).

[0369] The gr_path_pos descriptor specifies the position on a graph path marking the start of each segment alignment or its first splice, and is present when dataset_type == 4 (graph-aligned data). Inputs include the variables dataset type, classld, numberOfAlignedRecordSegments, numberOfAlignments, and alignPtr[][] as defined in Part 2. Outputs comprise a flag gr_path_same_as_prev[j][i], indicating whether the current alignment or splice is on the same path as the previous one, and a position value gr_path_pos[j][i]. Subsequence 0 encodes the path continuity flag, subsequence 1 encodes whether the position is relative or absolute, and subsequences 2 or 3 provide the respective delta or absolute coordinate. This structure may enable compact yet unambiguous representation of graph path positions in segment alignments.Decoding Process of the gr path pos Descriptor

[0370] According to some examples, the decoder, when dataset type == 4 and classld! = Class U, processes each aligned record segment and its alignments to reconstruct graph path positions. For each segment, the variable gr_path_same_as_prev is obtained from subsequence 0 to indicate whether the segment is on the same path as the previous one. Subsequence 1 provides a flag pos is delta indicating whether the position is encoded as a relative delta or as an absolute coordinate. If the delta mode is active, the decoder determines the reference position from eitherthe corresponding alignment of the previous record (for the leftmost segment), the preceding alignment within the current record, or the previous segment of the current alignment, and then adds the delta value from subsequence 2. If the absolute mode is active, the position is read directly from subsequence 3. The reconstructed values are stored in gr_path_pos[alignIdx][i], while gr_path_pos_prev maintains continuity across records. This process may ensure compact encoding of graph path positions while enabling unambiguous reconstruction of segment alignments across successive records.

[0371] Add Subclause 10.4.20 rfte (Decoding Process of Proposed Descriptor)

[0372] According to one example, the MPEG-G standard is amended by introducing the rfte descriptor, which is present in access units of type 3 (Class M) when cr alg ID equals 1 and the dataset type indicates graph-aligned data, and optionally when cr alg ID equals 3. The rfte descriptor decodes into an array of edge identifiers (refTransfEdgeID[]) representing graph edges to which reference transformations apply. To improve compression efficiency, a first subsequence provides a flag indicating whether consecutive transformations apply to the same edge, while a second subsequence supplies a new edge identifier when required. This amendment may enable compact yet unambiguous signaling of transformations in graph reference genomes, thereby reducing redundancy and improving decoding performance compared to linear-only transformation models.

[0373] Hence, according to some examples, the rfte descriptor shall be present only in access units of type 3 (class M) when cr_alg_ID is set to 1 and dataset_type is set to 4 (graph-aligned data), as specified in subclause 7.4.2. In addition, the rfte descriptor may be present when cr alg ID is set to 3 and dataset type is set to 4 (graph-aligned data), as specified in subclause 7.4.2. It shall not be present in any other case.

[0374] The inputs to this process are, according to some examples:- the decoded_symbols[descriptor_ID] array specified in subclause 12.6.2.2 when descriptor_ID is equal to 21;- the current value of j21,0;

[0375] The output of this decoding process can be, for example, an array refTransfEdgeID[] containing the edge IDs of the transformations to be applied to a decoded raw reference as specified in subclause 11.3.3. The decoding process for rfte is specified for an entire access unit.

[0376] In this context, each subsequence is referenced by its descriptor subsequence lD = N, such that subsequenceN corresponds to the element decoded_symbols

[0021] [N],Decoding Process of the rfte Descriptor

[0377] According to one example, as indicated in the table above, the decoding process of the rfte descriptor iterates over the subsequences to reconstruct the identifiers of graph edges subject to reference transformations. For each index i, a first subsequence provides a flag (same_as_prev) indicating whether the current transformation applies to the same edge as the previous one. If the flag is set and i > 0, the current edge identifier is copied from the preceding entry in the array refTransfEdgeID[], Otherwise, a new edge identifier is obtained from a second subsequence. In this way, the rfte descriptor may allow multiple consecutive transformations on the same edge to be signaled compactly without retransmitting redundant edge identifiers, thereby improving compression efficiency and ensuring unambiguous decoding of reference transformations in graph genomes.

[0378] Subclause 10.5.2 Aligned Reads (Classes P, N, M, I, HM)

[0379] According to one example, Subclause 10.5.2 of the MPEG-G standard, relating to aligned reads of Classes P, N, M, I, and HM, is extended to update the decoding process for reads- Ill -that either contain extended splice information (extended splice info flag == 1) or are aligned to a graph reference genome (dataset_type == 4).Additional inputs to this process are:— the variables dataset type, crps flag, cr alg ID and extended splice info flag (proposed) as specified in subclause 7.4.2;— the variable rtype with value for the current record decoded as specified in subclause 10.4.14 if crps flag is equal to 1 and cr alg ID is equal to 2, 3 or 4;— the variable numberOfMappedRecordSegments calculated as specified in subclause 10.4.10;— the arrays numberOfSplicedSeg[] and splicedSegMappedLength[][] computed as specified in subclause 10.4.9;— the variable sequence lD as specified in subclause 7.5.1.2;— the arrays mateSeqId[][] and splicedSegMappingPos[][] computed as specified in subclause 10.4.10;— the arrays splice_seq_ID[0][][] and splice_pos[0][][] (as proposed and specified in the decoding process of the splices descriptor);— the array splice_path[0][][] (as proposed and specified in the decoding process of the gr path descriptor);— the arrays ref_sequence[][] and seq_start[] as specified in subclause 7.3;— the graph reference data structure, graph reference (as proposed);— the array refBuf[] as specified in subclauses 11.3.4, 11.3.5 and 11.3.6;— the computed graph reference data structure, grRefBuf (as proposed and to be specified in subclause 11.3.5);— the variable classld is computed as specified in subclause 10.2.3;

[0380] Hence, according to examples, additional inputs to this process include the variables dataset type, crps flag, cr alg ID, and extended splice info flag as defined in subclause 7.4.2, and the variable rtype decoded as specified in subclause 10.4.14 when crps flag equals 1 andcr alg ID equals 2, 3, or 4. Further inputs are the variable numberOfMappedRecordSegments computed in accordance with subclause 10.4.10, the arrays numberOfSplicedSeg[] and splicedSegMappedLength[][] from subclause 10.4.9, and the variable sequence lD defined in subclause 7.5.1.2. The decoding also uses the arrays mateSeqId[][] and splicedSegMappingPos[][] from subclause 10.4.10, the arrays splice_seq_ID[0][][] and splice_pos[0][][] generated by the decoding of the splices descriptor, and the array splice_path[O][][] obtained from the decoding of the gr path descriptor. In addition, the arrays ref_sequence[][] and seq_start[] from subclause 7.3 are used, together with the graph reference data structure graph reference and the computed graph reference buffer grRefBuf as proposed for subclause 11.3.5, and the array refBuf[] specified in subclauses 11.3.4-11.3.6. The variable classld is also included as computed under subclause 10.2.3.

[0381] These extensions may provide the technical advantage of enabling the decoding process to faithfully reconstruct alignments containing complex splice events or traversals of graph reference paths while maintaining compatibility with existing MPEG-G read classes.

[0382] According to one example, the decoding process is also applicable when the variable crps flag, as specified in Table 7, is equal to 1, provided that the rtype descriptor defined in subclause 10.4.14 is available and the decoded value for the current record is not equal to 5. Furthermore, if cr alg ID specified in Table 17 is equal to 2, 3 or 4 and the value of rtype is not equal to 0, the seqld is set to 0, refSeq is set to refBuf[] specified in subclauses 11.3.4, 11.3.5 and 11.3.6, and seqStart is set to 0.

[0383] Updated Decoding Process of sequence[] Array for Aligned Reads

[0384] According to one example, the decoding process of the sequence[] array for aligned reads is updated to handle both linear and graph-based references as well as extended splice information. For each mapped record segment i and each splice segment j, the variable mappedLength is set equal to splicedSegMappedLength[i][j]. If crps flag is equal to 1 and cr alg ID is equal to 2, 3, or 4, and the decoded value of rtype is not equal to 0, a reference-less computed reference is employed. In this case, seqld and seqStart are set to zero, and either the AU-specific computed linear reference sequence (refBuf) is selected when dataset type is less than 3, or the AU-specific computed graph reference structure (grRefBuf) is selected when dataset type is equal to 4.

[0385] In cases where dataset type is less than 3, i.e. for linear coordinate- based data, the decoding distinguishes whether extended splice information is present. If the extended splice info flag is set, the seqld is assigned from the splice-specific sequence identifier array (splice_seq_ID[O][i][j]). Otherwise, for the first segment i = 0, seqld is assigned from the sequence identifier of the access unit (sequence lD), while for subsequent segments seqld is taken from the mate sequence identifier (mateSeqId[0][i]). In both cases, seqStart is set to the corresponding start coordinate (seq_start[seqld]), and refSeq is set to the external or embedded linear reference sequence (ref_sequence[seqld]).

[0386] In cases where dataset type equals 4, corresponding to graph-aligned data, the seqld is obtained from the splice-specific sequence identifier array (splice_seq_ID[O][i][j]), and the graph reference data structure (graph reference) is selected as grRef.

[0387] According to some examples, for linear data, the pointer pRef is computed as the difference between the splice mapping position (splicedSegMappingPos[i][j]) and the sequence start position (seqStart), and the corresponding spliced sequence is extracted from the linear reference (refSeq). For graph-aligned data, the spliced sequence is obtained by invoking the function get_gr_sequence(), which returns the nucleotide sequence of length mappedLength from the specified path and position in the graph reference (splice_path[O][i][j], splice_pos[0][i][j]).

[0388] Finally, depending on the alignment class of the access unit, the decoded splice segment is processed by invoking the corresponding subclause-specific procedure: processSplSegN(ij) for Class N as defined in subclause 10.2.4, processSplSegM(ij) for Class M as defined in subclause 10.2.5, or processSplSegl(ij) for Class I and Class HM as defined in subclause 10.2.6.

[0389] For example, the decoding process can be implemented as indicated in the table below:

[0390] Decoding Process of Path Sequence in a Graph Reference

[0391] According to some examples, a decoding process, as specified in the table below, extracts a stretch of nucleotide sequence from a locus in a graph reference genome based on the following input arguments:— seqld, one of the sequence IDs specified in Raw Graph Reference— path, the IDs of a sequence of connected edges specified using the syntax of the gr_path descriptor— startPos, the 0-based start position of the target sequence with respect to the beginning of the path— segLen, the length of the target sequence to be extracted— grRef, the graph reference data structure from which the nucleotide sequence is extracted

[0392] The following are the major steps of the decoding process:1. Parse a path into a sequence of edge IDs and their associated transition types as indicated by their delimiter symbols2. Infer any omitted edges in the path3. Check if an edge-to-edge transition is valid in the graph reference4. Determine the properties and positions of the edge-to-edge connecting points5. Extract the nucleotide sequence between two connecting points on each edge6. Concatenate the extracted nucleotide sequences until reaching the full length of the target sequence.

[0393] Thereby the target nucleotide sequence for the specified locus of the graph reference genome may be produced.

[0394] Decoding Process of Path Sequence in a Graph Reference

[0395] According to one example, a function get_gr_sequence(seqld, path, startPos, segLen, grRef) is executed to extract a nucleotide sequence from a graph reference genome. The process receives as input a sequence identifier (seqld), a path string (path) encoded in accordance with the gr_path descriptor syntax, a start position (startPos), a segment length (segLen), and the graph reference data structure (grRef).

[0396] In a first step, the path string is parsed into a list of edge identifiers (p edge lD) together with corresponding delimiter types (p delim), where a delimiter denotes an end-point transitionand a delimiter “>” denotes a mid-sequence transition. If the path string is empty, the first edge is omitted, or the seqld is invalid, the process signals an error and terminates.

[0397] For each edge in the path, the algorithm validates whether the edge identifier is present in the graph reference. If an edge identifier has been omitted due to path contraction, the missing edge is re-inferred from the graph reference using the sequence identifier, the path context, and the delimiter type. For each valid edge, the edge length and the position of entry are determined. The entry position may be the specified start position for the first edge, or a connection point within the edge in the case of a mid-sequence transition.

[0398] The process then checks the validity of each edge-to-edge transition against the graph reference by means of connection indices and connection types. If a transition is invalid, an error is returned. Otherwise, the subsequence of the edge sequence defined by the start position and the connection position is extracted. The subsequences from successive edges are concatenated until the requested segment length (segLen) is reached, yielding the output sequence (out seq).

[0399] This process may ensure that contracted paths with omitted edges are correctly expanded, that invalid transitions are detected, and that nucleotide sequences spanning multiple connected edges can be reconstructed accurately and efficiently from a graph reference genome.

[0400] According to one example, the decoding process can comprise the steps indicated in the table below:

[0401] According to one example, a set of string operators and auxiliary functions are defined for use in the decoding processes described herein:strcat(sl,..., sN) returns the concatenation of the strings from si to sN. If any of the input strings si through sN is a single character, it is considered a string of length 1strlen(s) returns the length of string sstrtoc(s) returns all characters in string s in a sequence compliant with c(n) data type specified in subclause 6.3, where n corresponds to the length of string ssubstr(s, i, 1) returns a substring from s of length 1 starting from the (i + 1) th character. If (i + 1) > strlen(s), it will return a substring of length (strlen(s) - i) up to and including the last character in s.

[0402] The function find(keys, match value) returns an array of indices to the elements in the one dimensional array keys that contain match value, or returns a single index if the match value is unique.

[0403] The mathematical function Min(x, y) returns x if x <= y and returns y if x > y.

[0404] The notation return errorQ is used in this document to indicate that the decoding process has to stop due to a decoding error which cannot be handled.

[0405] The infer omitted edgeQ method (as specified in Table 14) infers and returns the ID of the edge right after pEdgeID[idx - 1] in the path based on its adjacent downstream edges in the graph reference, and, if available, the transition type specified by pDelim[idx - 1], Note that if idx >= sizeof(pEdgeID), a new element will be added to pEdgelD.

[0406] The dot notation is used for referencing a variable defined within a data structure. For example, grRef. sequence lD refers to the sequence lD array defined within the proposed raw graph reference structure grRef. For referencing a specific edge element in the graph reference structure, a simplified notation is used to denote the kthelement of the jthedge belonging to the ithsequence, such as grRef. edge_ID[i][j], grRef.edge_seq[i][j] and grRef. conn_pos[i][j][k].

[0407] Method for Inferring an Omitted Edge in a Path

[0408] According to one example, a method infer_omitted_edge(seqldx, pEdgelD, pDelim, idx) is defined to reconstruct omitted edges in a path representation of a graph reference genome during the decoding of a genomic data structure. The method first validates that the index idx is within the valid range, otherwise returning an error. The identifier of the previous edge is located using edge_ID[seq!dx], and all downstream connections are obtained from conn is upstream. A flag is ep is set to indicate whether the transition occurs at the endpoint of the previous edge. Where mid-sequence transition flags are active, downstream connections are filtered according to connection type.

[0409] If only one downstream connection is identified, its edge identifier is directly returned. If multiple candidate connections are present, inference rules are applied: preference is given first to edges belonging to the same group as the previous edge, and second to edges of rank 0 on the linear reference. If a unique candidate edge is determined under these rules, its identifier is returned as the omitted edge. This inference procedure enables compact path encoding by omitting explicit edge identifiers while still ensuring deterministic reconstruction of valid graph paths.

[0410] In addition, a validate transitionQ method is provided to verify edge connectivity, returning an error if the candidate edge is not a valid upstream or downstream connection relative to the current edge, and otherwise returning an index to the validated connection.

[0411] By enabling omitted edges to be deterministically reconstructed, the method may achieve higher compression efficiency in the bitstream, since redundant or predictable edge identifiers do not need to be explicitly transmitted. Second, the inference rules based on edge groups and ranks may ensure that path reconstruction remains unambiguous, even in complex graph topologies, thereby improving decoding accuracy and reproducibility. Third, the method may reduce storage and transmission overhead while maintaining full compatibility with graphreference genomes that include multiple paths, edges, and structural variants. Fourth, by incorporating the validate transitionQ check, invalid graph traversals are detected and eliminated during decoding. This may increase robustness and may prevent reconstruction errors.

[0412] For example, the method executed as part of the decoding may be described as indicated in the table below:

[0413] The validate transitionQ method (as specified in Table 15) returns -1 if the edge identified by connEdgelD is an invalid upstream (connlsUpStream == 1) or downstream (connlsUpStream == 0) edge connected to the edge indexed by currEdgeldx based on the graph reference. Otherwise, it returns an index to the connection being validated.

[0414] Method for Checking If an Edge Transition Is Valid in the Graph Reference

[0415] According to one example, a method is provided for validating whether a transition between two edges in a graph reference genome is permissible. The method receives as input a sequence index (seqldx), a current edge index (currEdgeldx), an identifier of a candidate connecting edge (connEdgelD), and a flag (connlsUpStream) indicating whether the transition is upstream or downstream. The method first determines candidate connection indices by applying a findQ operation to the array conn edge lD [seqldx] [currEdgeldx] as defined in the raw graph reference. For each candidate index, the method checks whether the upstream or downstream orientation stored in conn_is_upstream[seqldx] [currEdgeldx] [idx] matches the requested orientation. If a match is found, the corresponding index is returned as connldx; otherwise, a negative value is returned, indicating that the transition is invalid. The method may ensure that an edge can traverse into or out of another edge at at most one position, thereby providing deterministic validation of graph connections.

[0416] This method may ensure that reconstructed graph paths are valid with respect to the underlying graph reference genome. By explicitly checking orientation and edge connectivity, invalid transitions are detected early during decoding, thereby preventing the reconstruction of biologically implausible or topologically inconsistent paths. Moreover, by restricting validation toconnection indices stored in the raw graph reference, the method may minimize computational overhead while supporting efficient large-scale decoding of graph-aligned data.

[0417] According to some examples, the decoding process comprises a method as indicated in the table below:

[0418] Subclause 10.6 e-cigar

[0419] According to one example, the syntax of the ISO / IEC 23092 series E-CIGAR string is extended to provide explicit operators for representing splice events. In particular, the operator “n*” denotes an undirected splice of n bases, “n / ” denotes a forward splice of n bases, and “n%” denotes a reverse splice of n bases. While the undirected splice operator corresponds to the “nN” notation used in the SAM CIGAR representation, the forward and reverse splice operators are novel extensions without equivalents in the SAM CIGAR format. Furthermore, in cases where thevariable extended splice info flag equals 1 or where dataset type equals 4 (graph-aligned data), and the splice is aligned to a different reference sequence or path, the base count n is omitted from the operator.

[0420] This extension may enable splices to be represented not only in an undirected manner, as in existing standards, but also with explicit orientation information, thereby improving the accuracy of reconstructed alignments in both linear and graph reference genomes. The omission of the base count for cross-sequence or cross-path splices may reduce redundancy in the bitstream and improves compression efficiency, while retaining unambiguous reconstruction of splice transitions. Overall, these measures may extend the expressive power of the E-CIGAR notation while maintaining compactness and compatibility with both linear and graph-based genomic data representations.Syntax of the ISO / IEC 23092 series E-CIGAR string

[0421] Note that, according to examples, for the extended CIGAR representations “n*”, “n / ” and “n%”, if extended_splice_info_flag == 1 or dataset_type == 4, and the splice is aligned to a different reference sequence or path, the number n shall be omitted.

[0422] Subclause 11.3.3 Reference Transformation

[0423] According to one example, the reference transformation process of MPEG-G is updated to support graph references in addition to linear references.

[0424] The inputs to the process comprise the ref_sequence[seqld] array as defined in subclause 7.3.2, with seqld equal to the ref sequence lD as defined in subclause 7.5.2, together with the arrays refTransfPos[] and refTransfSubs[] as computed in subclauses 10.4.18 and 10.4.19. For graph-aligned data, where dataset type == 4, the inputs further comprise a raw graph reference data structure (grRef). In this structure, dot notation is used to reference variables, such as grRef. sequence lD, while edges within the graph are referenced by simplified notation, for example grRef. edge_ID[i] and grRef. edge_seq[i][j].

[0425] The output of the process is a modified ref_sequence[seqld] array in the case of linear data, or a modified grRef data structure in the case of graph-aligned data, together with an array refTransfOrigSymbols[] containing the original symbols at the transformation positions. For linear data, each substitution replaces the symbol at ref_sequence[seqId][refTransfPos[i]] with the corresponding substitution symbol, while saving the original symbol. For graph-aligned data, the process identifies the sequence index (s idx) and edge index (e idx) corresponding to the specified refTransfEdgeID[i], retrieves the original symbol at grRef.edge_seq[s_idx][e_idx][refTransfPos[i]], and replaces it with the substitution symbol.

[0426] This update of the reference transformation process may enable reference transformation to be applied not only to linear references but also to graph references, thereby extending MPEG-G to accommodate pangenomic data structures. By allowing transformations to target specific edges within a graph reference genome, the process may ensure that frequently observed substitutions or edits can be incorporated efficiently into the reference structure. This reduces redundancy, improves compression efficiency, and ensures accurate reconstruction of graph-based alignments during decoding. Furthermore, the preservation of original symbols inrefTransfOrigSymbols[] maintains traceability and enables reversibility of transformations, thereby enhancing robustness and reproducibility.

[0427] Hence, according to examples, the inputs to this process are the ref_sequence[seqld] array specified in subclause 7.3.2, with seqld equal to ref sequence lD as specified in subclause 7.5.2, and the arrays refTransfPos[],and refTransfSubs[] computed as specified in subclauses 10.4.18, 10.4.19 respectively.

[0428] In the case of graph-aligned data with dataset type == 4, the inputs should also include a raw graph reference data structure. The dot notation is used for referencing a variable defined within a data structure. For example, grRefsequence lD refers to the sequence lD array defined within the proposed raw graph reference structure grRef. For referencing a specific edge element in the graph reference structure, a simplified notation is used to denote the jth edge belonging to the ith sequence, such as grRef. edge_ID[i] and grRef. edge_seq[i][j]. The output of this process is the modified ref_sequence[seqld] array or gr ref data structure computed by applying the decoding process shown in the table below and a refTransfOrigSymbols[]array containing the substituted symbols in the original reference.

[0429] The updated reference transformation process according to some examples is specified in the table below, wherein bold words indicate changes relative to the existing reference transformation process in the MPEG-G standard.Updated Reference Transformation Process

[0430] Subclause 11.3.5 Local Assembly

[0431] According to one example, the process for constructing the reference is updated to support both linear and graph reference genomes.

[0432] Subclause 11.3.5.3 Process for the construction of the reference

[0433] The output of the local assembly process is an array refBuf[] (dataset type < 3) or refBuf[edge!dx][] (dataset type == 4) containing a sequence of consensus symbols, where edgeldx points to a particular edge in the graph reference.

[0434] The output of this process is an array refBuf[] in the case of linear data (dataset type < 3) or an array refBuf[edge!dx][] in the case of graph-aligned data (dataset type == 4), wherein edgeldx identifies a particular edge in the graph reference. For each position covered by aligned reads in the array crBuf[][], a consensus symbol is determined and appended to the corresponding refBuf[] or refBuf[edge!dx][].

[0435] For example, for each position covered by aligned reads in the array crBuf[][], the consensus symbol is derived as follows:e) Append the consensus symbol to the array refBuf[] or refBuf[edge!dx] [].f) If the optional rftp, rftt and rfte descriptors are present, copy (1) refBuf[] into ref_sequenceoutput[seqId][] in a raw_referenceoutputstructure (specified in subclause 7.3.2) if dataset type < 3, or (2) refBuf[edgeIdx] [] into edge_seqoutput[seqIdx][edgeIdx] [] in a raw graph referenceoutput structure (proposed) if dataset type == 4, where seqldx points to a particular sequence corresponding to seqld in the graph reference, according to the mapping position.

[0436] Hence, according to some examples, if the optional descriptors rftp, rftt, and rfte are present, the consensus reference is further copied as follows: (1) refBuf[] is copied into ref_sequence_output[seqld][] within a raw reference output structure, as defined in subclause 7.3.2, when dataset type < 3; or (2) refBuf[edgeIdx] [] is copied into edge_seq_output[seqldx] [edgeldx] [] within a raw graph reference output structure (proposed), when dataset type == 4, where seqldx identifies the sequence corresponding to seqld in the graph reference.

[0437] The result of the decoding process described above is a reference sequence contained in the array refBuf[] or refBuf[] [] which shall be used to decode the genomic records contained in the current AU for cases where the value of rtype is not equal to 0 or 5 as specified in subclause 10.4.14.

[0438] Subclause 11.3.5.4 Decoding Process for rftp and rftt

[0439] According to one example, when cr alg ID is equal to 3, and when the optional descriptors rftp, rftt and rfte are present in the bitstream, these descriptors are used to reconstruct the original reference sequence used for sequence alignment for the records in current Access Unit.

[0440] The decoder applies a transformation to the linear reference sequence ref_sequenceoutput[seqId][] or to the graph reference sequence edge seqoutput [seqldx] [edgeldx] [] constructed according to the process described in subclause 11.3.5.3 by replacing the symbols present in the reference sequence ref_sequenceoutput[seqId] [] or edge seqoutput [seqldx] [edgeldx] [] at the absolute position represented by each rftp; descriptor with the symbols conveyed by each corresponding rftti descriptor.

[0441] In the case of graph reference, seqldx is the index of the sequence corresponding seqld in the graph reference structure and edgeldx is the index of the edge corresponding to the edge ID indicated by each rftei descriptor.

[0442] This may enable accurate reconstruction of the reference used for alignment in both linear and graph contexts, while reducing storage and transmission overhead by avoiding retransmission of full reference sequences, ensuring decoding accuracy, and maintaining compatibility with existing linear and graph-based reference structures.

[0443] Subclause 13.2 MPEG-G Record

[0444] According to one example, the syntax and semantics of the MPEG-G Record are extended to convey splice and graph-alignment information in a backward-compatible manner.

[0445] Four one-bit indicators are added to the record header: extended alignment info signals the presence of per-alignment auxiliary flags; extended splice info signals the presence of the splices descriptor for linear datasets; graph aligned signals that the record contains graph-aligned data; and pseudo_linear_pos signals the availability of pseudo-linear coordinates.

[0446] For each alignment noa, if the record is linear (graph aligned == 0) or if pseudo-linear coordinates are present (pseudo linear pos == 1), a 40-bit mapping_pos is encoded. If the record is graph-aligned (graph aligned == 1), the path and starting position of the segment alignment are conveyed using a variable-length string splice_path[alignIdx][0] (encoding a contracted path as a delimiter- separated sequence of edge IDs) and a 24-bit splice_pos[alignIdx][0] (path-based start position).

[0447] When either extended splice info == 1 or graph aligned == 1, the record further carries splice payloads: an 8-bit n splices count per segment alignment, followed — if n splices > 0 — by one or more 24-bit splice len values, 16-bit splice_seq_ID values (linear sequence IDs or graph sequence IDs), optional path strings splice_path[alignIdx] [0] [i] for graph-aligned splices, and 24-bit splice_pos[alignIdx][0][i] entries that are absolute or delta positions as specified elsewhere.

[0448] For each template segment tSeg, the same conditional structure applies irrespective of pairing state: when the paired segment is in the same record (split alignment == 0), the field delta is present unless the data are purely graph-aligned without pseudo-linear positions; when the paired segment is mapped in another record (split alignment == 1), the pair location is conveyed bysplit_pos (unless purely graph-aligned without pseudo-linear positions) and split_seq_ID, with optional per-segment splice_path / splice_pos and splice payloads as above. Each alignment carries an ecigar len and the corresponding ecigar string, a reverse comp flag, optional flags when extended alignment info == 1, and one or more mapping score values according to the configured alignment-scoring depth.

[0449] When more alignments is set to 1, cross-record chaining uses next_pos and next seq ID to reference the next alignment location.

[0450] These additions may allow a decoder to reconstruct read alignments that span multiple linear sequences or graph paths, while preserving efficient random access (via mapping_pos when present), seamless interpretation of graph paths and positions (splice_path / splice_pos), and interoperability with existing MPEG-G decoders that ignore unknown flags and reserved fields.

[0451] For example, the updated MPEG-G record syntax may be specified as indicated in the table below:Updated MPEG-G Record Syntax

[0452] Subclause 13.3 Initialization Process

[0453] According to one example, the initialization process of MPEG-G Records is extended to support splice information and graph-based alignments.

[0454] The variable extended splice info is initialized from the extended splice info flag as defined in the proposed encoding parameters syntax. The variable graph aligned is set to 1 if dataset type == 4 and otherwise to 0, thereby indicating whether the record contains graph-aligned data. The variable pseudo_linear_pos is initialized from the gr_pseudo_linear_pos_flag as defined in the proposed encoding parameters syntax. The arrays n_splices[][], splice_len[][][], splice_seq_ID[][][], and splice_pos[][][] are initialized as the outputs of the decoding process of the splices descriptor, while the array splice_path[][][] is initialized as the output of the decoding process of the graph path descriptor.

[0455] Examples of how different variables are initialized are given below:— extended splice info = extended splice info flag (extended splice info flag as specified in the proposed encoding parameters syntax)— graph_aligned = (dataset_type == 4)? 1: 0 (dataset_type as specified in the encoding parameters syntax)— pseudo linear pos = gr_pseudo_linear_pos_flag (gr pseudo linear pos flag as specified in the proposed encoding parameters syntax)— n_splices[][], splice_len[][][], splice_seq_ID[][][] and splice_pos[][][] are outputs of the decoding process of the proposed splices descriptor— splice_path[][][] is the output of the decoding process of the proposed gr_path descriptor

[0456] These initializations may ensure that extended splice information and graph-specific alignment data are consistently available during the subsequent decoding of MPEG-G Records, enabling accurate reconstruction of alignments across multiple sequences or paths.

[0457] Proposed Changes to MPEG-G Part 6

[0458] Subclause 6.3 Annotation Parameter Set

[0459] According to one example, the annotation parameter set defined in MPEG-G Part 6 is extended to support the decoding of graph-aligned annotation data.

[0460] In particular, a new flag AT_gr_pos_flag is introduced to indicate whether graph-based genomic positions are used (AT_gr_pos_flag = 1) or whether linear-based positions are used (AT gr pos flag = 0). When graph-based positions are enabled, additional parameters are signaled, including a flag AT_gr_second_path_delim that indicates whether a second delimiter is available for specifying branch-out transitions in a graph path, a flag AT_gr_edge_pos_24_bits_flag that specifies whether edge positions are represented using 24 bits (or 16 bits if the flag is not set), and a flag AT pseudo linear pos flag that indicates whether pseudo-linear positions are available.

[0461] These extensions may provide explicit signaling for graph-based coordinates and enable compact yet unambiguous representation of annotations aligned to graph reference genomes, while maintaining compatibility with linear-based annotations through conditional activation of the graph-related fields.Updated Annotation Parameter Set Syntax

[0462] Subclause 7.2 Descriptors

[0463] According to one example, the descriptor set defined in Subclause 7.2 is extended to include additional descriptors for supporting graph-based genomic coordinates.

[0464] The additional descriptor ChrlD identifies the chromosome, while the descriptor ChrPos specifies the actual or estimated chromosome position on the base genome, wherein the base genome is represented as a linear reference composed of edges of rank 0. The additional descriptor ChrPosVar specifies the variance of the estimated chromosome position, wherein a value of zero indicates that the start position of the variant lies directly on the base genome. The additional descriptor EdgelD identifies the edge of the graph reference genome to which the beginning of the variant is mapped, and the descriptor EdgePos specifies the start position of the variant relative to the beginning of that edge. The additional descriptor Path represents an ordered list of edge identifiers corresponding to subsequent edges of the graph reference genome to which the variant is mapped.

[0465] Hence, the list of additional descriptors may comprise one or more of:■ ChrlD - chromosome ID■ ChrPos - actual or estimated chromosome position on the base genome (linear reference consisting of edges of rank 0)■ ChrPosVar - variance of the estimated chromosome position. A value of 0 indicates that the start position of the variant is directly on the base genome.■ EdgelD - the ID of the edge to which the beginning of the variant is mapped■ EdgePos - the start position of the variant from the beginning of the edge identified by EdgelD■ Path - an ordered list of edge IDs that identify any subsequent edges to which the variant is mapped

[0466] These descriptors may enable precise and unambiguous annotation of variants in both linear and graph-based genomic coordinate systems, thereby improving the accuracy and interoperability of variant representation across different reference structures.

[0467] Subclause 9.3 Descriptors Decoding Process

[0468] According to one example, the descriptor decoding process defined in Subclause 9.3 is extended to support graph-related descriptors.

[0469] In particular, decoding procedures are introduced for descriptors that convey graphbased genomic coordinates, including ChrlD, ChrPos, ChrPosVar, EdgelD, EdgePos, and Path. During decoding, the ChrlD and ChrPos descriptors are reconstructed to provide chromosomelevel localization of the variant, while ChrPosVar is decoded to indicate whether the reported position is exact or estimated. The EdgelD and EdgePos descriptors are decoded to determine the mapping of the variant to a specific edge of the graph reference genome and its position relative to the start of that edge. Finally, the Path descriptor is decoded to reconstruct the ordered list of edge identifiers that identify subsequent edges traversed by the variant.

[0470] This extension of the decoding process may ensure that graph-based coordinates are consistently interpreted, enabling unambiguous variant localization across both linear reference genomes and graph reference genomes, while maintaining compatibility with existing MPEG-G decoding workflows.

[0471] Clause 10 Output Format

[0472] According to one example, Clause 10 relating to the output format is extended to include graph-related fields in the syntax of records containing genomic coordinates.

[0473] For example, in addition to existing fields for linear coordinates, the extended syntax comprises fields for graph-based information such as EdgelD, EdgePos, and Path, as well as optional fields for pseudo-linear positions. The EdgelD and EdgePos fields identify the edge of the graph reference genome and the position on that edge to which a genomic feature is mapped, while the Path field provides an ordered list of edge identifiers corresponding to the subsequent edges traversed. These extensions allow records to represent both linear and graph-based genomic coordinates in a standardized manner, ensuring interoperability with linear reference-based toolswhile enabling precise representation of genomic features in graph reference genomes. This dual representation facilitates more accurate decoding, indexing, and analysis of genomic data across different reference structures.

[0474] All definitions, as defined and used herein, should be understood to control over dictionary definitions, definitions in documents incorporated by reference, and / or ordinary meanings of the defined terms.

[0475] Aspects of the present disclosure may be implemented as an apparatus, system, method, or computer program or computer program product, embodied in hardware, software (e.g., firmware, resident software, micro-code), or any combination thereof, generally referred to as a “circuit,” “module,” or “system.”

[0476] The disclosure may be embodied as a computer program product, in particular embodied in one or more computer-readable media. The computer program product is comprising program instructions, also referred to as computer executable code or computer program. A computer-readable storage medium as used herein encompasses any tangible storage medium which may store the program instructions. The computer-readable storage medium may be referred to as a computer-readable non-transitory storage medium.

[0477] Examples of computer-readable storage media include, but are not limited to: a computer memory like a magnetic hard disk drive, a solid state hard disk, flash memory, a USB thumb drive, like a Random Access Memory (RAM) or Read Only Memory (ROM), an optical disk (e.g. CD, DVD), a magneto-optical disk, and the register file of a processing unit.

[0478] A computer program product may include a computer-readable signal medium, which itself may embody the program instructions. The computer readable signal medium may include a propagated data signal with the program instructions embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that can communicate, propagate, or transport program instructions for use by or in connection with an instruction execution apparatus.

[0479] A processor or processing unit as used herein encompasses any electronic component which is able to execute the program instructions. This includes, for example, a CPU, GPU, microcontroller, or any processor core. It may comprise a single processor or multiple processors / cores, which can be located within the same computer component or distributed across multiple computer components in a networked system. Each computer component may comprise one or more of the electronic components.

[0480] The term apparatus should be interpreted to possibly refer to a single computer component or a collection or network of computer components.

[0481] Program instructions may comprise machine executable instructions or a computer program which when executed by a processing unit of the apparatus cause or enable the apparatus to perform an aspect of the present disclosure. Program instructions may be provided in any combination of one or more programming languages, including an object-oriented programming language and a conventional procedural programming language. Program instructions may be compiled into machine executable instructions or may be in a pre-compiled form and be used in conjunction with an interpreter which generates the machine executable instructions on the fly.

[0482] Aspects of the present disclosure are described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products according to the disclosure. It will be understood that each block or a portion of the blocks of the flowchart, illustrations, and / or block diagrams, can be implemented by computer program products when applicable. It is further understood that, when not mutually exclusive, combinations of blocks in different flowcharts, illustrations, and / or block diagrams may be combined.

[0483] The indefinite articles “a” and “an,” as used herein in the specification and in the claims, unless clearly indicated to the contrary, should be understood to mean “at least one.”

[0484] The phrase “and / or,” as used herein in the specification and in the claims, should be understood to mean “either or both” of the elements so conjoined, i.e., elements that are conjunctively present in some cases and disjunctively present in other cases. Multiple elements listed with “and / or” should be construed in the same fashion, i.e., “one or more” of the elements so conjoined. Other elements may optionally be present other than the elements specifically identified by the “and / or” clause, whether related or unrelated to those elements specifically identified.

[0485] As used herein in the specification and in the claims, “or” should be understood to have the same meaning as “and / or” as defined above. For example, when separating items in a list, “or” or “and / or” shall be interpreted as being inclusive, i.e., the inclusion of at least one, but also including more than one, of a number or list of elements, and, optionally, additional unlisted items. Only terms clearly indicated to the contrary, such as “only one of’ or “exactly one of,” or, when used in the claims, “consisting of,” will refer to the inclusion of exactly one element of a number or list of elements. In general, the term “or” as used herein shall only be interpreted as indicating exclusive alternatives (i.e. “one or the other but not both”) when preceded by terms of exclusivity, such as “either,” “one of,” “only one of,” or “exactly one of.”

[0486] As used herein in the specification and in the claims, the phrase “at least one,” in reference to a list of one or more elements, should be understood to mean at least one element selected from any one or more of the elements in the list of elements, but not necessarily including at least one of each and every element specifically listed within the list of elements and not excluding any combinations of elements in the list of elements. This definition also allows that elements may optionally be present other than the elements specifically identified within the list of elements to which the phrase “at least one” refers, whether related or unrelated to those elements specifically identified.

[0487] It should also be understood that, unless clearly indicated to the contrary, in any methods claimed herein that include more than one step or act, the order of the steps or acts of the method is not necessarily limited to the order in which the steps or acts of the method are recited.

[0488] In the claims, as well as in the specification above, all transitional phrases such as “comprising,” “including,” “carrying,” “having,” “containing,” “involving,” “holding,” “composed of,” and the like are to be understood to be open-ended, i.e., to mean including but not limited to. Only the transitional phrases “consisting of’ and “consisting essentially of’ shall be closed or semi-closed transitional phrases, respectively.

[0489] While several inventive examples have been described and illustrated herein, those of ordinary skill in the art will readily envision a variety of other means and / or structures for performing the function and / or obtaining the results and / or one or more of the advantages described herein, and each of such variations and / or modifications is deemed to be within the scope of the inventive examples described herein. More generally, those skilled in the art will readilyappreciate that all parameters, dimensions, materials, and configurations described herein are meant to be exemplary and that the actual parameters, dimensions, materials, and / or configurations will depend upon the specific application or applications for which the inventive teachings is / are used. Those skilled in the art will recognize, or be able to ascertain using no more than routine experimentation, many equivalents to the specific inventive examples described herein. It is, therefore, to be understood that the foregoing examples are presented by way of example only and that, within the scope of the appended claims and equivalents thereto, inventive examples may be practiced otherwise than as specifically described and claimed. Inventive examples of the present disclosure are directed to each individual feature, system, article, material, kit, and / or method described herein. In addition, any combination of two or more such features, systems, articles, materials, kits, and / or methods, if such features, systems, articles, materials, kits, and / or methods are not mutually inconsistent, is included within the inventive scope of the present disclosure. Features described in connection with a method or method step are, according to examples, implemented as features of a respective computer system and data structure and vice versa. The features of the method and computer system and computer program clauses described below can be combined with any example of the method, computer system, computer program and data structure described above.

[0490] In a further aspect, examples of methods and systems are described herein in accordance with the following clauses:1. A computer-implemented method for representing a genomic data structure (100) in a memory (630) of a computer system (600), the method comprising:receiving (402) a definition of a graph reference genome comprising edges (702-718) and their connections, the graph reference genome comprising a linear reference sequence with pre-defined linear coordinates;identifying (404) for each of at least some of the edges one or multiple paths that connect the edge to the linear reference sequence, the path comprising the at least one edge and optionally further ones of the edges;computing (406)a pseudo linear position of a point (XA) on the at least one edge (Edge A), the computing comprising:■ identifying an upstream and / or downstream anchor point in the path, an anchor point being a point on the path where an edge in the path is linked to one of the predefined linear coordinates of the linear reference sequence;■ identifying a predefined linear coordinate linked to the identified upstream and / or downstream anchor point;■ identifying the one of the predefined linear coordinates (px) that reflects the position of the point (XA) on the path relative to the upstream and / or downstream anchor point; and■ using the identified predefined linear coordinate (px) as the pseudo-linear coordinate of the point (XA) on the at least one aligned edge (Edge A); assigning (408) the pseudo linear position to the point (xA) in the graph reference genome;encoding (410) the graph reference genome and optionally also the pseudo-linear coordinate in a compressed representation of the graph reference genome; and storing (412) the compressed representation of the graph reference genome in the genomic data structure in the memory.

[0491] According to some first examples, the graph reference genome and also the pseudo-linear coordinate (or multiple coordinates) is encoded in the compressed representation of the graph reference genome. For example, the pseudo-linear coordinate(s) may be used for creating a searchable index that may be stored as part of the genomic data structure. This may have the advantage of providing a self-contained data structure that comprises ready-to use and optionally even searchable coordinates without requiring the decoder or any software downstream of the decoding process to compute the pseudo-linear coordinates.

[0492] According to some second examples, the pseudo-linear coordinates are not encoded and stored together with the reference genome or other genomic data in the genomic data structure. Rather, the pseudo-linear coordinates may be computed on-the-fly, e.g., by an encoder software or by any other software that may be used for processing the genomic data before it is encoded and stored. For example, this software could be a bioinformatics tool for pre-processing and / or visualizing genomic data. Computing and optionally displaying the pseudo-linear coordinates may assist a user or the software-tool to pre-process or select the genomic data to be encoded and stored in the genomic data structure.The method of clause 1, wherein one or more pseudo-linear coordinates are computed and stored for each of the edges connected to the linear reference sequence, in particular, for the beginning of each of these edges.The method of any one of the previous clauses, wherein the pseudo-linear coordinate of the point (XA) is computed using both an upstream anchor point and a downstream anchor point and wherein the pseudo-linear coordinate is calculated by interpolation between the predefined linear coordinates of the upstream and the downstream anchor points.The method of any one of the previous clauses, wherein the pseudo-linear coordinate of the point (XA) is computed using only the upstream anchor point or only the downstream anchor point and wherein the pseudo-linear coordinate of the point (XA) is computed as an offset from the single anchor point within the path.The method of any one of the previous clauses, wherein the pseudo-linear coordinate is encoded as an integer offset relative to the predefined linear coordinate of the upstream anchor point.The method of any one of the previous clauses, wherein the pseudo-linear coordinate is encoded as an absolute linear coordinate derived from the predefined linear coordinate of the downstream anchor point.The method of any one of the previous clauses, wherein multiple pseudo-linear coordinates are computed for multiple points along the path and stored in the genomic data structure. The method of any one of the previous clauses, wherein multiple pseudo-linear coordinates are computed and wherein the multiple pseudo-linear coordinates are stored in annotation tables in association with nodes, edges or paths of the graph reference genome.The method of any one of the previous clauses, wherein the pseudo-linear coordinate is computed to enable interoperability between graph-aligned data and linear-aligned data. The method of any one of the previous clauses, wherein pseudo-linear coordinates are used by an encoder and / or a decoder to project read alignments on the graph reference genome into a linear coordinate system.The method of any one of the previous clauses, further comprising receiving read alignments being indicative of how one or more reads are aligned to the graph reference genome, and computing pseudo-linear coordinates for the reads aligned to the graph reference genome. The method of clause 11, wherein at least one of the reads comprises two or more splices aligned across different edges or paths in the graph reference genome, the method further comprising computing pseudo-linear coordinates for the aligned two or more splices.The method of any one of the previous clauses, further comprising:using the pseudo-linear coordinates to create a searchable index for the graph reference genome that supports searches for nodes, edges, paths or other graph-based components using a coordinate as search key; andstoring the index in the genomic data structure to enable random access search queries in the genomic data structure, the random access search using search keys comprising linear genomic coordinates or linear genomic ranges.The method of any one of the previous clauses, wherein the pseudo-linear coordinates are stored in the genomic data structure to support selective decoding of graph-aligned reads identified using linear genomic coordinates as search keys.The method of any one of the previous clauses, wherein pseudo-linear coordinates are transmitted together with extended splice information in a dataset encoded in accordance with the MPEG-G standard.The method of any one of the previous clauses, wherein the pseudo-linear coordinate of the point (XA) on an edge of the graph reference genome is computed using both an upstream anchor point and a downstream anchor point, wherein one of the edges (702-718) of the graph reference genome is represented as Edge A, wherein the pseudo-linear coordinates pos(Edge_A, xA) of a position XA on Edge A connected to position-reference sequence through a path P consisting of a sequence of edges are computed according to the following formula:where pl and p2 are the known linear positions of respectively the upstream and downstream anchor points of Edge A, dA is the distance in terms of number of nucleotidesof position XA on Edge A leading to the upstream anchor point through path P, and |P| is the sequence length of path P,wherein in particular in the special case that Edge A is directly connected to the position reference sequence, the pseudo-linear coordinates pos(Edge_A, xA) are computed according to the following formula:where pl and p2 are the known linear positions of respectively the upstream and downstream anchor points of Edge A, and 1A is the sequence length of Edge A.The method of clause 16, wherein only one anchor point exists for the edge Edge A, and wherein the pseudo-linear coordinates pos(Edge_A, xA) are computed according to either pos(Edge_A, xA) = Pi + xA, if only upstream anchor point at pi existsOrpos(Edge_A, xA) = p2— (lA- xA), if only downstream anchor point at p2 exists The method of clause 16 or 17, wherein the graph reference genome further comprises an edge Edge B, wherein the pseudo-linear coordinates pos(Edge_B, xB) of a position XB on Edge B connected to a position XA on the Edge A are computed according to the following formula:where pl and p3 are the known linear positions of respectively the upstream and downstream anchor points of Edge B within the position reference sequence, and 1B is the sequence length of Edge B.A computer-implemented method for representing and processing a graph reference genome in a memory (630) of a computer system (600), the method comprising:receiving (502) a genomic data structure (100) comprising a compressed representation of a graph reference genome (700, 800, 900, 902, 904, 906, 930) and of pseudo-linear coordinates, the graph reference genome comprising edges (702-718) and their connections, the graph reference genome comprising a linear reference sequence (R01,R02) with pre-defined linear coordinates, wherein each of at least some of the edges is connected to the linear reference sequence via one or multiple paths;receiving (504) at least one linear genomic coordinate defining a genomic region of interest;searching (506) the pseudo-linear coordinates using the at least one linear genomic coordinate to identify the ones of the edges or other graph-based components associated with pseudo-linear coordinates within the region of interest;selectively (508) decoding only the identified edges or graph-based components for reconstructing a de-compressed representation of only the part of the graph reference genome associated with the genomic region of interest; andstoring (510) the reconstructed, de-compressed representation part of the graph reference genome in the memory.For example, the other graph- based components may be integral graph components or data values associated with the graph components. For example, the graph components can include graph components as defined in the existing MPEG-G standard, such as integral parts of a graph reference genome like edges, segments (type of edges in this context), links, chains, subgraphs, or clusters. In addition, or alternatively, the other graph components may comprise an extended concept of graph-based components that covers also graph-component-associated elements of an MPEG-G file, such as group (e.g., source of the genomic data), graph-based read alignments and genomic annotations (e.g. variants). The method of clause 19, wherein the further graph components comprise reads aligned to the paths, the method further comprising:using, by a decoder, the pseudo-linear coordinates to project one or more of the reads aligned to the graph reference genome into a linear coordinate system; and outputting, via a user interface, a representation of the projected reads.A system (600) comprising a processor (620) and a memory (630), the processor configured to execute instructions that cause the system to perform a method for representing a genomic data structure (100) in the memory, the method comprising:receiving (402) a definition of a graph reference genome (700, 800, 900, 902, 904, 906, 930) comprising edges (702-718) and their connections, the graph reference genome comprising a linear reference sequence (R01, R02) with pre-defined linear coordinates; identifying (404) for each of at least some of the edges one or multiple paths that connect the edge to the linear reference sequence, the path comprising the at least one edge and optionally further ones of the edges;computing (406)a pseudo linear position of a point (xA) on the at least one edge (Edge_A), the computing comprising:■ identifying an upstream and / or downstream anchor point in the path, an anchor point being a point on the path where an edge in the path is linked to one of the predefined linear coordinates of the linear reference sequence;■ identifying a predefined linear coordinate linked to the identified upstream and / or downstream anchor point;■ identifying the one of the predefined linear coordinates (px) that reflects the position of the point (XA) on the path relative to the upstream and / or downstream anchor point; and■ using the identified predefined linear coordinate (px) as the pseudo-linear coordinate of the point (XA) on the at least one aligned edge (Edge A); assigning (408) the pseudo linear position to the point (xA) in the graph reference genome;encoding (410) the graph reference genome and optionally also the pseudo-linear coordinate in a compressed representation of the graph reference genome; and storing (412) the compressed representation of the graph reference genome in a genomic data structure in the memory.A system (600) comprising a processor (620) and a memory (630), the processor configured to execute instructions that cause the system to perform a method for processing a graph reference genome in the memory, the method comprising:receiving (502) a genomic data structure (100) comprising a compressed representation of a graph reference genome (700, 800, 900, 902, 904, 906, 930) and of pseudo-linear coordinates, the graph reference genome comprising edges (702-718) and their connections, the graph reference genome comprising a linear reference sequence (R01,R02) with pre-defined linear coordinates, wherein each of at least some of the edges is connected to the linear reference sequence via one or multiple paths;receiving (504) at least one linear genomic coordinate defining a genomic region of interest;searching (506) the pseudo-linear coordinates to identify the ones of the edges or other graph components associated with pseudo-linear coordinates within the region of interest;selectively decoding (508) only the identified edges or graph components for reconstructing a de-compressed representation of only the part of the graph reference genome associated with the genomic region of interest; andstoring (510) the reconstructed, de-compressed representation part of the graph reference genome in the memory.23. A data structure (100), referred to as genomic data structure, comprising:a compressed representation of a graph reference genome (700, 800, 900, 902, 904, 906, 930) and of pseudo-linear coordinates, the graph reference genome comprising edges (702-718) and their connections, the graph reference genome comprising a linear reference sequence (R01, R02) with pre-defined linear coordinates, wherein each of at least some of the edges is connected to the linear reference sequence via one or multiple paths;and optionally also a searchable index, the index being configured for supporting searching (506) the pseudo-linear coordinates with a search key comprising at least one linear genomic coordinate to identify the ones of the edges or other graph components associated with pseudo-linear coordinates within a region of interest.

[0493] These examples may have the advantage of supporting the processing of genomic data associated with a graph reference genome using linear coordinates, thereby facilitating integration of graph-based genomic representations into current analysis pipelines without requiring extensive adaptation. The use of anchor points linked to predefined linear coordinates may preserve biological context and may ensure that genomic annotations remain interpretable in the familiar coordinate system. In addition, by encoding the graph reference genome together with pseudo-linear coordinates in a compressed representation, examples disclosed herein may achieve efficient storage and retrieval of large-scale genomic data structures, reducing computational and memory requirements. The pseudo-linear positions may enable rapid querying operations without the need to traverse the full graph structure for each operation, thereby improving computational performance. Accordingly, examples of computing or using pseudo-linear coordinates described herein may provide a genomic data structure and corresponding computer-system, computer program, and computer-implemented method that may allow graph reference genomes to be stored compactly, queried efficiently, and integrated seamlessly with established reference-based genomic resources.

[0494] Certain embodiments may be implemented in systems that are compliant with one or more compression standards, such as the MPEG-G family of standards. However, the disclosed embodiments are not limited to any particular standard and may also be applied to nonstandardized systems.List of Reference Numerals100 Genomic data structure102 Dataset group104 Dataset106.1-106.3 Descriptors202-510 steps600 Data processing system612 System bus620 Processor630 Memory640 User interface650 Communication interface660 Storage661 Operating system662 Genomic graph data structure663 Decoder664 Encoder700 Graph reference genome702- 718 Edges752-768 Edges800 Graph reference genome with first path highlighted 900 Graph reference genome with second path highlighted 902 Graph reference genome with edge connections 904 Graph reference genome with edge EA906 Graph reference genome with edges EA and EB 930 Graph reference genome (with read alignment) 1202 Read922 SplicesR01, R02 Linear reference sequences

Claims

ClaimsWhat is claimed is:

1. A computer-implemented method for representing a genomic data structure (100) in a memory (630) of a computer system (600), the method comprising:receiving (202) a read (1202) and a definition of a reference genome (700, 800, 900, 902, 904, 906, 920, 930), the reference genome being one of: (i) a linear reference genome (920) comprising multiple different linear reference sequences (R01, R02), and (ii) a graph reference genome (700, 800, 900, 902, 904, 906, 930) comprising multiple paths associated with multiple different reference sequences,wherein the read comprises two or more splices (922) aligned to the reference genome such that:■ in the case of (i) the linear reference genome, the two or more splices are aligned to different ones (R01, R02) of the multiple different linear reference sequences, and■ in the case of (ii) the graph reference genome, the two or more splices are aligned to different ones (752, 754) of the paths of the graph reference genome;generating (204) extended splice information (106), the extended splice information comprising a parameter to indicate whether the splices are aligned to a graph reference genome or a linear reference genome;encoding (206) the two or more aligned splices and the extended splice information in the genomic data structure to provide a compressed representation of the two or more splice alignments and the extended splice information; andstoring (208) the generated genomic data structure (100) in the memory.

2. The method of claim 1,wherein the genomic data structure is based on (i) the linear reference genome and wherein presence of the extended splice information in the genomic data structure is indicated by an extended splice information flag;and wherein in particular the extended splice information flag is or comprises a Boolean flag, in particular a variable extended splice info flag set to a first value if extended splice information is available or set to another value otherwise.

3. The method of any one of the previous claims, wherein the extended splice information comprises at least one of: a splices descriptor, a graph path descriptor, and a graph path position descriptor, wherein continuously aligned parts of the splices form aligned segments, and wherein the genomic data structure comprises the at least one descriptor to store encoded segment alignment information of the aligned segments such that data values stored in each of the at least one descriptors are of the same or of a similar nature.

4. The method of any one of the previous claims,wherein the extended splice information is stored in one or more of the following descriptors: a splices descriptor, a graph path descriptor, and a graph path position descriptor; and / orwherein the extended splice information comprises one or more of:■ a splice length indicating the length of the spliced region;■ a splice sequence ID being indicative of the reference sequence to which the splice is aligned;■ a splice path being indicative of the path to which the splice was aligned; ■ a splice position being indicative of an absolute or relative position indicating where within the path or linear reference sequence a splice is aligned;■ a splice orientation such as forward, reverse, or undirected; and ■ an indication if a splice transits to another one of the splices via crosssequence / cross-path transition or via an intra-sequence / intra-path transition.

5. The method of any one of the previous claims, wherein the generating of the extended splice information comprises:encoding at least some of the splice positions as absolute positions on the linear reference sequence or the path to which a splice was aligned;and optionally encoding at least some of the splice positions as relative delta values with respect to previously encoded positions.

6. The method of any one of the previous claims, further comprising:generating a Reference Transform Target Descriptor - rftt descriptor - specifying the target nucleotides of a transformation, the transformation being a sequence edit operation applied to the linear reference sequence or to a graph edge of the graph reference genome to produce a new transformed reference sequence that supports more efficient alignment, storage, and decoding;generating a Reference Transform Position Descriptor - rftp descriptor - encoding positions of the transformation;generating a Reference Transform Edge Descriptor - rfte descriptor - associated with the reference genome, the rfte descriptor identifying edges of the graph reference genome to which the transformation applies;wherein the method comprises including the rfte, rftp and rftt descriptors as read alignment information in the genomic data structure;wherein the method in particular further comprises:identifying frequently occurring substitutions in the read alignment information to be incorporated into the reference genome through a reference transformation process; representing the identified substitutions by their positions and nucleotide changes; in case the reference genome is a graph reference genome, representing the identified substitutions also by their edge IDs; andstoring these representations in the rfte, rftp and rftt descriptors.

7. The method of any one of the previous claims,wherein the reference genome is a graph reference genome,wherein the graph reference genome comprises one or more position-reference sequences, the position-reference sequences being linear reference sequences with pre-defined linear coordinates;wherein the graph reference genome comprises edges representing pangenomic variations connected to one another and / or to the one or more position-reference sequences;wherein the method further comprises:■ computing pseudo-linear coordinates for the edges based on their distances from the upstream and downstream anchor points on the position-reference sequence; and / or■ computing pseudo-linear coordinates for the aligned splices based on their mapping positions on the edges within the paths the reads are aligned to.

8. The method of claim 7,wherein the pseudo-linear coordinate of the point (XA) on an edge of the graph reference genome is computed using both an upstream anchor point and a downstream anchor point by interpolation between the predefined linear coordinates of the upstream and the downstream anchor points; orwherein the pseudo-linear coordinate of the point (XA) on an edge of the graph reference genome is computed using only the upstream anchor point or only the downstream anchor point, and wherein the pseudo-linear coordinate of the point (xA) is computed as an offset from the single anchor point within the path.

9. The method of claim 8, wherein the pseudo-linear coordinate of the point (XA) on an edge of the graph reference genome is computed using both an upstream anchor point and a downstream anchor point, wherein one of the edges (702-718) of the graph reference genome is represented as Edge A, wherein the pseudo-linear coordinates pos(Edge_A, xA) of a position XA on Edge A are connected to a position-reference sequence through a path P consisting of a sequence of edges are computed according to the following formula:where pl and p2 are the known linear positions of respectively the upstream and downstream anchor points of Edge A, dA is the distance in terms of number of nucleotidesof position XA on Edge A leading to the upstream anchor point through path P, and |P| is the sequence length of path P,wherein in particular in the special case that Edge A is directly connected to the position reference sequence, the pseudo-linear coordinates pos(Edge_A, xA) are computed according to the following formula:where pl and p2 are the known linear positions of respectively the upstream and downstream anchor points of Edge A, and 1A is the sequence length of Edge A.

10. The method of any one of claims 7-9, further comprising:encoding and storing the pseudo-linear coordinates and optionally also the known linear positions of the edges of the graph reference genome into the genomic data structure.

11. A computer-implemented method for representing and processing a read (1202) aligned to a reference genome in a memory (630) of a computer system (600), the method comprising:receiving (302) a genomic data structure (100), the genomic data structure comprising a compressed representation of a read (1202), of a definition of a reference genome (700, 800, 900, 902, 904, 906, 920, 930) and of extended splice information (106) comprising a parameter, the read comprising two or more splices (922), the reference genome being one of: (i) a linear reference genome (920) comprising multiple different linear reference sequences (R01, R02), and (ii) a graph reference genome (700, 800, 900, 902, 904, 906, 930) comprising multiple paths associated with multiple different reference sequences,wherein the two or more splices (922) are aligned to the reference genome such that:■ in the case of (i) the linear reference genome, the two or more splices are aligned to different ones of the multiple different linear reference sequences, and■ in the case of (ii) the graph reference genome, the two or more splices are aligned to different ones (752, 754) of the paths of the graph referencegenome,wherein the parameter indicates whether the splices are aligned to a graph reference genome or a linear reference genome;decoding (304) the extended splice information with the parameter for determining if the reference genome is a graph reference genome or a linear reference genome; reconstructing (306) a de-compressed representation of the aligned splices such that the two or more splices are mapped to different ones of the multiple different linear reference sequences or to different ones of the multiple different paths in the reference genome; andstoring (308) the reconstructed, de-compressed representation of the two or more aligned splices in memory.

12. The method of claim 10, wherein the reconstructing of the information of the two or more aligned splices comprises:decoding read alignment information comprised in the genomic data structure; and creating extended CIGAR strings that represent the differences between each read alignment and the corresponding genomic regions in the reference genome, wherein at least one of the created extended CIGAR strings is created for the read alignment comprising the two or more splices mapped to different sequences or paths in the reference genome.

13. The method of any one of the claims 10-11,wherein the extended CIGAR string representation for the two or more splices aligned to different sequences or paths comprises one or more splice operators to indicate transitions between different linear reference sequences or paths; wherein in the splice operator referring to splices being cross-linear-sequence splices or cross-path splices is free of a base count value; andwherein the splice operator referring to splices being intra-linear-sequence-splices or intra-path splices comprising a base count value.

14. The method of any one of the previous claims 10-12,wherein the reconstruction of the de-compressed representation of the two or more aligned splices comprises updating the two or more aligned splices with pseudo-linear coordinates; and / orwherein the genomic data structure comprises a searchable index of pseudo-linear coordinates and the method comprises:receiving (504) at least one linear genomic coordinate defining a genomic region of interest;searching (506) the pseudo-linear coordinates using the at least one linear genomic coordinate to identify the ones of the edges or other graph-based components associated with pseudo-linear coordinates within the region of interest;selectively (508) decoding only the identified edges or graph-based components for reconstructing a de-compressed representation of only the part of the graph reference genome associated with the genomic region of interest; andstoring (510) the reconstructed, de-compressed representation part of the graph reference genome in the memory.

15. A computer program comprising instructions which enable a processor to carry out the method of any one of the previous claims 1-14.

Images