<?xml version="1.0" encoding="UTF-8"?>
<rss  xmlns:atom="http://www.w3.org/2005/Atom" 
      xmlns:media="http://search.yahoo.com/mrss/" 
      xmlns:content="http://purl.org/rss/1.0/modules/content/" 
      xmlns:dc="http://purl.org/dc/elements/1.1/" 
      version="2.0">
<channel>
<title>Soomro Lab</title>
<link>https://soomrolab.com/blog/</link>
<atom:link href="https://soomrolab.com/blog/index.xml" rel="self" type="application/rss+xml"/>
<description>Bioinformatics for plant breeding at Agriculture and Agri-Food Canada&#39;s Brandon Research and Development Centre.</description>
<generator>quarto-1.9.38</generator>
<lastBuildDate>Wed, 05 Aug 2026 05:00:00 GMT</lastBuildDate>
<item>
  <title>Breeding data is a graph. We should probably store it that way.</title>
  <dc:creator>Tayab Soomro</dc:creator>
  <link>https://soomrolab.com/blog/posts/2026-08-05-knowledge-graphs-for-breeding.html</link>
  <description><![CDATA[ 




<div class="panel">
<p><strong>Draft.</strong> This post was assembled from an internal memo and has not been reviewed for public release. Edit or delete it before publishing the site.</p>
</div>
<p>In most breeding programs, information lives in disconnected systems. Pedigrees sit in one database, genotypes in another, field notes in spreadsheets, environmental data somewhere else again. Each system is fine on its own terms. The problem shows up the moment a question spans two of them.</p>
<p>Ask something like <em>which high-yielding lines carry a particular haplotype while still keeping enough genetic diversity from the rest of the program?</em> and you are looking at a manual joining exercise — export, match on line IDs that were entered slightly differently in each system, reconcile, repeat. It is doable. It is also expensive enough that most questions of that shape simply never get asked, which is the real cost.</p>
<section id="modelling-the-relationships-instead-of-the-tables" class="level2">
<h2 data-anchor-id="modelling-the-relationships-instead-of-the-tables">Modelling the relationships instead of the tables</h2>
<p>A knowledge graph takes a different starting point. Rather than storing tables and joining them later, you model the entities that actually exist in a breeding program — lines, parents, markers, haplotypes, environments, traits — and store the relationships between them directly. <em>This line has this parent. This parent carries this marker. This marker sits in this haplotype. This haplotype was scored in this environment.</em></p>
<p>Once the relationships are the primary object, traversing them is a query rather than a project. The question above becomes something you type.</p>
</section>
<section id="what-it-looks-like-in-practice" class="level2">
<h2 data-anchor-id="what-it-looks-like-in-practice">What it looks like in practice</h2>
<p>A few groups have already built interfaces worth clicking through:</p>
<ul>
<li><a href="https://helium.hutton.ac.uk/#/">Helium</a>, James Hutton Institute</li>
<li><a href="https://bioinformatics.cragenomica.es/perseus/home">PERSEUS</a>, CRAG</li>
<li><a href="https://tgil.donga.ac.kr/SoyPedi/index.html">SoyPedi</a>, a digitised soybean pedigree interface</li>
</ul>
<p>Helium and PERSEUS both let you pan around a crop pedigree and colour it by trait, so you can watch a trait move through the crosses. For wheat that is a useful visual validation: we select parents for particular traits, and this lets us confirm the traits actually carried through. KASP marker calls can be colour-coded onto the same pedigree and overlaid with the phenotype data, which is a quick way to check whether a marker is genuinely driving a trait or just travelling near it.</p>
<p>That is a back-of-the-napkin example, but it is the kind of thing that comes up weekly.</p>
</section>
<section id="the-longer-arc" class="level2">
<h2 data-anchor-id="the-longer-arc">The longer arc</h2>
<p>The payoff grows as phenotyping gets cheaper. Automated, high-throughput phenotyping in the trial plots captures trait data at much finer granularity with less manual labour, which means more statistical power to detect genomic associations. That data has to land somewhere that can hold it alongside everything else.</p>
<p>Further out, the same integrated structure is the groundwork for a digital twin of a breeding program: a computational model connecting genomics, pedigree, environment and field performance closely enough to evaluate candidate crosses before growing them all out. That is a long horizon. The graph is the first step, and it is useful well before you get there.</p>
</section>
<section id="where-we-are" class="level2">
<h2 data-anchor-id="where-we-are">Where we are</h2>
<p>We are building a pedigree tool for wheat along these lines, and running a QTL analysis on a bi-parental wheat population as a near-term application — tracing which markers were passed down to the two parents, then asking which progeny carry both the markers and the associated traits.</p>
<p>More when there is something to show.</p>


</section>

 ]]></description>
  <category>breeding informatics</category>
  <category>knowledge graphs</category>
  <guid>https://soomrolab.com/blog/posts/2026-08-05-knowledge-graphs-for-breeding.html</guid>
  <pubDate>Wed, 05 Aug 2026 05:00:00 GMT</pubDate>
</item>
</channel>
</rss>
