Recognize the MS-DIAL 5 suggested-annotation name prefixes

[htsugawa]

Problem

MS-DIAL 4 marked its precursor-only suggestions with a single "w/o MS2:" prefix. MS-DIAL 5 splits that bucket in two, in DataAccess.SetMoleculeMsPropertyAsSuggested:

shape	meaning
no MS2: X	MS2RawSpectrumID < 0 — no product-ion spectrum at all
low score: X	a product-ion spectrum exists but the reference search did not meet the acceptance criteria

The "w/o MS2: " line in SetMoleculeMsProperty is commented out. Two readers still tested only the MS-DIAL 4 spelling, which never matches MS-DIAL 5 output:

1. MoleculerNetworking.GetOntologyColor gave precursor-only and low-score suggestions an ontology colour on the molecular network, identical to a confident annotation — on a graph whose edges are built from MS/MS similarity, so a miscoloured node seeds false annotation propagation by eye. Reachable from MsdialGuiApp only; the Console msn command uses the edge-only statics and does not build nodes.
2. DataAccess.IsReferenceMatchedName (added in Feature/console retention time correction #766) reported them as Reference matched in the Console quality-assurance matrix. This is the Console path MS-DIAL Interactive drives.

Measured on the checked-out console_fastlc_demo output: the .mdalign holds 1021 rows starting no MS2: , 230 starting low score: , and zero starting w/o MS2.

Decision

Both shapes are excluded. They are produced only on the branches where MsScanMatchResult.IsReferenceMatched is false (MsScanMatching sets it as IsSpectrumMatch && TotalScore > cutoff && RT/RI match), so neither is an accepted reference match. A low-score row does have product-ion evidence and ranks above a precursor-only one, but the ontology colour and the Reference matched flag are both binary claims about an accepted annotation, and neither shape qualifies. Preserving the low-score/precursor-only distinction visually would be a third state — separate work, not this predicate.

"w/o MS2: " is kept: SetPeptideMsPropertyAsSuggested still writes it, and MS-DIAL 4 wrote it everywhere. The MS-DIAL 4 sources under src/MSDIAL4/ are correct as they stand and are untouched.

Change

The prefix vocabulary and the predicate now live together in CompMs.Common.Utility.AnnotationName, and the writers build their names from it, so a renamed prefix cannot leave a reader stale. The helper is in CommonStandard because the vocabulary is shared by CommonStandard (networking) and MsdialCore (export) and the project dependency runs MsdialCore → CommonStandard only. DataAccess.IsReferenceMatchedName is kept as a delegating overload.

One behavioural refinement beyond the added prefixes: GetOntologyColor moves from Contains to the helper's StartsWith-after-TrimStart matching, so a legitimate compound name that merely contains Unknown or RIKEN mid-string is no longer misread. All MS-DIAL 5 shapes are prefixes. IsReferenceMatchedName already used StartsWith, so for the Console path the change is purely additive.

Verification

• CommonStandardTests 844/844 pass; MsdialCoreTests 295/295; MsdialLcMsApiTests 66 pass / 2 skipped.
• New tests cover all four MS-DIAL 5 name shapes plus the peptide shape and the placeholders, and assert the writer/reader invariant. With the two prefixes removed from the predicate they fail as Expected:<rgb(0,0,0)>. Actual:<rgb(255, 165, 0)>, reproducing the reported symptom.
• MSDIALCUI built Release/net48 (5.5.241113) and the console_fastlc_demo LC-MS run re-executed over its 7 SCIEX WIFF files, exit 0.
• .mdalign byte-identical to the pre-fix run. .mzTab identical once the job id is normalized. In .qa.tsv, columns 1–11 are byte-identical and column 12 changes in one direction only: 3919 rows TRUE → FALSE, 0 FALSE → TRUE, with the 1196 genuine TRUE rows preserved.

Follow-up, deliberately not in this PR

MztabFormatExport.cs (lines 172, 309, 495) tests Contains("no MS2") and so already excludes precursor-only suggestions, but not low score. Whether low-score rows belong in mzTab-M is a separate scientific question about that export, so the exporter is untouched here — including its string literals.

MoleculerSpectrumNetworkingTest.MergeNodeFiles in the Console test app carries the same stale literal, but its only caller is commented out, so it has no behavioural effect.

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

Newly added test files are missing required using directives, which will prevent the test projects from compiling.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR centralizes MS-DIAL “suggested annotation” name prefixes and the “is this an accepted reference match?” predicate so that both MS-DIAL 5 suggestion shapes (no MS2: / low score:) are consistently excluded by downstream readers (molecular networking node coloring and Console QA export).

Changes:

• Added CompMs.Common.Utility.AnnotationName to own suggestion-prefix vocabulary and the IsReferenceMatched() predicate.
• Updated MS-DIAL 5 name writers (DataAccess.Set*M*AsSuggested) and readers (DataAccess.IsReferenceMatchedName, MoleculerNetworking.GetOntologyColor) to use AnnotationName.
• Added regression tests to cover MS-DIAL 5 suggestion prefixes and the writer/reader invariant.

File summaries

File	Description
tests/MSDIAL5/MsdialCoreTests/Utility/DataAccessTests.cs	Extends QA/export test cases to include MS-DIAL 5 suggestion prefixes.
tests/Common/CommonStandardTests/Utility/AnnotationNameTests.cs	New unit tests for the centralized suggestion-prefix predicate and writers.
tests/Common/CommonStandardTests/Algorithm/Function/MoleculerNetworkingTests.cs	New regression tests ensuring suggestion-shaped names do not receive ontology coloring.
src/MSDIAL5/MsdialCore/Utility/DataAccess.cs	Uses AnnotationName for suggestion naming and delegates IsReferenceMatchedName() to it.
src/Common/CommonStandard/Utility/AnnotationName.cs	New shared helper defining prefixes and the IsReferenceMatched() predicate.
src/Common/CommonStandard/Algorithm/Function/MoleculerNetworking.cs	Replaces ad-hoc Contains(...) checks with AnnotationName.IsReferenceMatched(...).

Review details

• Files reviewed: 6/6 changed files
• Comments generated: 2
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.