Why Matrix Structure Matters
An omics table is more than a grid of numbers. Each measurement belongs to both a sample and a feature. If the table’s orientation is misunderstood, or an identifier is confused with a measurement, values can be assigned to the wrong biological entity. A reliable reading therefore starts by locating the sample axis, the feature axis, and the identifiers that name them.
The earlier material on measurement targets and feature granularity distinguishes what an assay measures from the level at which its features are defined. Here the focus is the data structure: how those measurements are arranged, and how separate metadata tables connect to them. The same basic principles apply whether a matrix records RNA features, methylation features, proteins, metabolites, or another kind of assay feature.
Read the Axes Before Reading the Values
The phrase “sample-by-feature matrix” describes the two kinds of entities represented, but it does not guarantee that samples are displayed in rows. In one common orientation, rows are samples and columns are features. In another, rows are features and columns are samples. The header labels and documentation determine which orientation is being used.
If there are \(n\) samples and \(p\) features, a samples-in-rows matrix has \(n\) rows and \(p\) measurement columns, while a features-in-rows matrix has \(p\) rows and \(n\) measurement columns. For clarity, write \(M_{ij}\) for the measurement associated with sample \(i\) and feature \(j\), regardless of display orientation. In a samples-in-rows table, \(M_{ij}\) is at row \(i\), column \(j\); in a features-in-rows table it is at row \(j\), column \(i\).
An identifier is not itself a measurement merely because it occupies a cell in a table. For example, a column called “sample_id” names rows; it is not a measured feature. Similarly, feature names or codes label columns or rows. Descriptive fields such as tissue label or feature description are metadata, not entries in the measurement matrix.
Worked Example: Interpreting a Features-in-Rows Matrix
Suppose a hypothetical assay table is documented as having features in rows and samples in columns:
| feature_id | S-A | S-B | S-C |
|---|---|---|---|
| F-101 | 12 | 18 | 15 |
| F-205 | 4 | 7 | 6 |
There are \(n=3\) samples and \(p=2\) features. The displayed measurement array has 2 rows and 3 sample columns, but its conceptual sample-by-feature version has dimensions \(3\times2\). The value 7 is associated with sample S-B and feature F-205. In the notation above, it is \(M_{2,2}=7\), taking S-B as sample 2 and F-205 as feature 2 in the stated ordering.
If the table is transposed to put samples in rows, the measurements become:
| sample_id | F-101 | F-205 |
|---|---|---|
| S-A | 12 | 4 |
| S-B | 18 | 7 |
| S-C | 15 | 6 |
The location changed, but the association did not: S-B and F-205 still identify the measurement 7. Transposition changes layout, not what the values mean.
Identifiers and Metadata Tables
A sample metadata table typically has one row per sample and a sample identifier column. Other columns may describe properties such as collection label, tissue category, or processing batch. A feature metadata table typically has one row per feature and a feature identifier column, alongside descriptive fields. These tables serve different purposes: sample metadata describe samples, while feature metadata describe features.
To connect sample metadata to a measurement matrix, the identifier used as the key must be present in both representations. When samples occupy matrix rows, that key may be an explicit column or the row names. When samples occupy matrix columns, the key may be the column names. The same principle applies to feature metadata and feature identifiers.
The join should be made by identifier values, not by position. Two tables can contain exactly the same samples in different orders. Pairing their first rows, second rows, and so on would then attach metadata incorrectly. A valid one-to-one link requires identifiers that are unique in each table and matching identifiers for the entities being linked. If IDs are duplicated, absent, or inconsistent, the join cannot be assumed to have the intended meaning.
Worked Example: Joining Sample Metadata by Identifier
Consider a hypothetical samples-in-rows matrix with two features:
| sample_id | F-1 | F-2 |
|---|---|---|
| S-01 | 10 | 2 |
| S-02 | 14 | 5 |
| S-03 | 11 | 3 |
The separate, hypothetical sample metadata table is in a different order:
| sample_id | tissue |
|---|---|
| S-03 | liver |
| S-01 | blood |
| S-02 | liver |
First check the key: the matrix has the three distinct identifiers S-01, S-02, and S-03, and the metadata table has each of those identifiers exactly once. The identifier sets match, so each measurement row has one corresponding metadata row. Joining on sample_id produces:
| sample_id | F-1 | F-2 | tissue |
|---|---|---|---|
| S-01 | 10 | 2 | blood |
| S-02 | 14 | 5 | liver |
| S-03 | 11 | 3 | liver |
For example, S-01 receives the metadata value “blood,” even though S-01 was the second row in the metadata table. Matching the first rows by position would instead assign “liver” to S-01, which would be an error.
Why Key-Based Joining Preserves the Measurement Meaning
The logic of a safe join can be stated precisely. Let the matrix have sample identifiers \(s_1,\ldots,s_n\), with each row containing measurements for one sample. Let the metadata table assign a descriptive record \(A(s)\) to each sample identifier \(s\). If every matrix identifier occurs exactly once in the metadata table, then each matrix row has exactly one metadata record to attach. The values in the measurement row remain unchanged; only the corresponding descriptive fields are added.
This follows directly from the key condition. For each \(i\), uniqueness and presence give one and only one metadata record \(A(s_i)\). Thus the joined row is the original measurement row for \(s_i\), paired with \(A(s_i)\). If a key is missing, there is no record to attach; if it is duplicated, there is more than one candidate record. In either case, the intended one-to-one correspondence is not established.
This is a structural justification, not a claim that the metadata are scientifically accurate. A technically successful join can still attach a wrongly recorded tissue label or use an identifier that was assigned inconsistently. Key checks protect correspondence; they do not validate the truth of every field.
Worked Example: Diagnosing an Invalid Metadata Key
Suppose a hypothetical matrix has sample identifiers S-1, S-2, and S-3. A metadata table contains:
| sample_id | collection_site |
|---|---|
| S-1 | site A |
| S-2 | site B |
| S-2 | site C |
The matrix key set is \(\{\text{S-1},\text{S-2},\text{S-3}\}\). The metadata key values include S-1 and S-2, but S-2 appears twice and S-3 is absent. Therefore, the metadata do not provide exactly one record for every matrix sample: S-2 has two candidate records, and S-3 has none.
A one-to-one join is not justified. It might create multiple rows for S-2 or leave S-3 without a site label, depending on the software and join settings. The correct next step is to investigate the source records and determine whether S-2 is a duplicated entry, whether the two records refer to different entities, and whether S-3 has a missing metadata record. One should not arbitrarily keep the first S-2 row or infer S-3’s site from neighboring rows.
Wide Matrices, Long Tables, and Practical Checks
A wide matrix places many feature measurements in separate columns (or many sample measurements in separate rows). It is compact and makes the sample and feature axes easy to inspect when the table is rectangular. A long table instead has columns such as sample_id, feature_id, and measurement, with one row per sample-feature pair. Long form makes the identifiers explicit on every record and can be convenient for grouping or combining records. Neither layout removes the need to verify what each identifier names and how metadata keys correspond.
Before analysis or transfer between software systems, check the structure rather than relying on appearance. A useful audit is:
Use headers and documentation to determine whether rows are samples or features and whether columns are features or samples.
Identify the sample and feature identifiers, and distinguish them from measurements and descriptive fields.
Confirm that identifiers are present and unique where one record per entity is expected. Compare the identifiers that should match across tables.
After joining or transposing, check the dimensions and inspect a few known sample-feature pairs to confirm that their values and metadata remain associated correctly.
Common warning signs include an unexpected number of rows after a join, a missing identifier column, repeated keys, or measurements that shift to different sample or feature labels after reshaping. A changed row order by itself is not evidence of an error; changed associations are. When the orientation or key meanings cannot be established from the data and documentation, the structure is unresolved and should not be guessed.
Common Mistakes and Limits
- Assuming samples are always rows. Matrices may be stored in either orientation. Read the labels and confirm the convention before interpreting a cell.
- Joining by row number. Different ordering makes positional matching unsafe. Join by an identifier whose meaning is established.
- Treating labels as measurements. A sample ID or feature ID identifies an entity; it is not another measured feature.
- Ignoring duplicate keys. A duplicated key can produce ambiguous or repeated matches, even if the joined table looks plausible.
- Assuming a successful join proves correct metadata. The join establishes a match according to the supplied keys. It cannot confirm that the keys or descriptive values were recorded correctly.
These checks establish the basic correspondence among samples, features, measurements, and metadata. They do not determine how different measurement scales should be interpreted, whether missing values have a particular cause, or how samples from different assays should be matched. Those questions require additional information beyond matrix orientation and key structure.
Check Your Understanding
Answer each question, then compare your reasoning with the solutions.
- A table has 8 feature rows and 12 columns named with sample IDs. How many samples and features does it contain, and which axis represents samples?
- In a samples-in-rows matrix, what does the entry at row S-4 and column F-9 represent?
- A sample metadata table contains the same IDs as the matrix but in a different order. Should the tables be matched by row position or by sample ID? Explain.
- A matrix contains S-1 and S-2, while a metadata table contains S-1, S-2, and S-3 once each. Is the metadata key unique, and do the identifier sets match?
- After a metadata join, the number of matrix rows doubles. Give one structural problem that could explain this and a suitable check.
Solutions. 1. It contains 12 samples and 8 features; samples are columns. 2. It is the measurement for sample S-4 and feature F-9. 3. Match by sample ID, because row order can differ and is not a reliable link. 4. The metadata IDs are unique, but the sets do not match because S-3 has no corresponding matrix sample. 5. A metadata key may be duplicated, causing multiple matches for a matrix sample; check whether each sample ID occurs exactly once in the metadata table and inspect duplicated IDs.