Content from Introduction to Salmon Knowledge Modelling

Last updated on 2025-11-11 | Edit this page

Estimated time: 12 minutes

Overview

Questions

  • What are controlled vocabularies and why are they important for data interoperability?

Objectives

This is a Carpentry-style, hands-on workshop. Each module builds on your own data and progresses from discovering terms you already use → documenting them clearly → aligning them with others.

Introduction

This workshop helps participants collaboratively develop, document, and align controlled vocabularies to improve data interoperability in salmon research and management. It emphasizes practical, community-centered steps that support long-term reusability and transparency, while remaining adaptable to other organizations or domains.

Why Controlled Vocabularies Matter

Inconsistent terminology prevents data integration and makes shared understanding difficult across agencies, researchers, and Indigenous knowledge systems. Controlled vocabularies address this by:

  • Capturing and standardizing the meaning of key terms

  • Enabling clear documentation and communication

  • Forming the foundation for ontologies and semantic integration

Key Points

By the end of the first three modules, participants will have:

  • Discovered and reused existing terms and URIs.
  • Created clear definitions and documentation for local data.
  • Built a mapping table connecting their terms to others’.

Content from Reusing Terms — Search and Integrate Existing Vocabularies

Last updated on 2025-11-11 | Edit this page

Estimated time: 95 minutes

Overview

Questions

  • Are the terms I need already defined somewhere else?
  • How can I responsibly reuse existing terms and URIs?
  • What are the benefits of aligning early rather than reinventing?

Objectives

  • Learn how to discover and evaluate existing vocabularies relevant to your domain (e.g., Darwin Core, WoRMS, OBO ontologies).
  • Understand how to reuse URIs and integrate external definitions into your own data dictionary.
  • Practice linking your data elements to authoritative terms where appropriate.

Introduction

Every dataset — whether from your lab, your agency, or another research group — uses terms to describe its contents. Column headers, variable names, and codes all hold meaning, but often those meanings are assumed rather than shared.

When everyone invents their own terms for the same concept (e.g., SmoltCond, ConditionFactor, CF), it becomes difficult to integrate or compare data across projects.

Reusing existing terms — with clear definitions and persistent identifiers (URIs) — makes your data:

  • Easier to share and integrate

  • More interoperable and transparent

  • Aligned with others in your community

  • Future-proof for modeling and ontology building

This session helps you learn where to find existing vocabularies, how to decide what to reuse, and how to incorporate those terms into your own data dictionary.

Callout

🧩 Core Ideas

Term reuse means adopting existing, well-defined concepts instead of inventing new ones.

Each reused term has a URI (Uniform Resource Identifier) that makes it globally recognizable.

Reusing does not mean losing your local context — you can still describe how your project uses a term, while referencing a shared definition.

This is a key first step in making your data “semantic” — meaning it can be understood by both humans and machines.

  1. Warm-up Discussion (10 min) Ask:

“What challenges do you face when merging data from other sources?”

“Has anyone tried to interpret someone else’s dataset and gotten confused by a term?” → Summarize: inconsistent naming blocks reuse and synthesis.

  1. Concept: Why Reuse? (10 min) Explain that reusing existing terms ensures that data “speak the same language.” Example:
  1. Demonstration: Searching Existing Vocabularies (15 min) Instructor shares screen:
  • Search for “salmon” or “brood year” on BioPortal.bioontology.org or NVS.
  • Show how to view term metadata (label, definition, URI, license).
  • Demonstrate copying the URI into the Data Dictionary Template.
  1. 🧠 Challenge / Activity 1: Find and Reuse (30 min)
Discussion

Challenge 1: Find and reuse (30 min)

Goal: Identify existing vocabulary terms that match your own dataset.

Steps:

  1. Select 3–5 column names from your dataset.

  2. Search for equivalent terms in one or more repositories.

  3. Record matches in the Data Dictionary Template:

  • Your local term
  • External URI
  • Source vocabulary name
  • Notes on whether it’s an exact or close match

Group Debrief (10 min) Ask:

  • Which terms were easy to find?
  • Which were hard or missing?
  • When would you decide to reuse vs. define your own?
  1. Reflection (10 min) Discuss the downstream benefits:
  • Reusing terms enables automatic linking and machine-readability.
  • Fewer mapping issues later when integrating salmon datasets.

Updated data dictionary with at least three reused terms and their URIs.

Learners understand how to find, evaluate, and record external vocabularies.

Key Points
  • Controlled vocabularies capture shared meaning of terms.
  • Reusing existing URIs improves interoperability and credibility.
  • Reuse saves time, avoids duplication, and makes future integration easier.

Content from Documenting Terms — Write Clear, Useful Definitions

Last updated on 2025-11-11 | Edit this page

Estimated time: 95 minutes

Overview

Questions

  • How can I make sure others understand and correctly use my terms?
  • What makes a good definition or label?
  • How should I record units, examples, and relationships between terms?

Objectives

  • Extract and describe terms from their dataset.
  • Write unambiguous, well-structured definitions.
  • Record associated metadata (units, codes, examples).

Introduction

You’ve identified the key terms used in your datasets — and maybe even found some existing ones to reuse. Now comes the part that makes your work understandable, trustworthy, and reusable: clear documentation.

Inconsistent or missing definitions are one of the biggest barriers to data reuse. For example:

What does “sample date” really mean — collection date, processing date, or submission date?

Does “juvenile” refer to an age class, a length range, or a life stage?

What are the units? Are they consistent across datasets?

This session will help you document your terms precisely, so anyone — whether a collaborator, data manager, or future researcher — can understand exactly what you meant.

Callout

🧩 Core Ideas

Documentation is data. It’s the layer that makes data understandable and reusable.

A well-documented term includes:

  • Preferred label: the human-readable name.
  • Definition: what the term means and how it’s used.
  • Units or scale: how it’s measured.
  • Example values: what typical data look like.

Notes: clarifications, special cases, or links to other terms.

Think of your data dictionary as a user manual for your dataset.

Example

Term Definition Units Example Notes
Condition factor A measure of fish body condition, typically calculated as weight/length³. dimensionless 1.05 Used as an indicator of energy reserves at smolt stage.
Smolt age The age (in years) of a salmon when it migrates from freshwater to the ocean. years 2 Derived from scale analysis.
Capture date The date when a specimen was physically collected in the field. ISO 8601 (YYYY-MM-DD) 2023-05-14 Not to be confused with processing or tagging date.

The more clearly you describe your terms now, the easier it becomes to share, integrate, and align your data later — especially when mapping to vocabularies or building ontologies.

  1. Concept: What Makes a Good Definition? (15 min) Show two examples: ❌ “Run timing: when fish come back.” ✅ “Run timing: The seasonal period during which adult salmon return from the ocean to their natal freshwater spawning areas.” Discuss why clarity, precision, and context matter.

  2. Demonstration: Documenting a Term (10 min) Instructor walks through one dataset column, filling in the template:

Label: brood_year

Definition: “The calendar year when the majority of parental salmon spawned.”

Unit: “Year (YYYY)”

Example: “2017”

Notes: “Equivalent to term in DFO Salmon Concept Scheme.”

  1. Activity: Extract and define (40 min)
Discussion

Challenge 1: Extract and define (40 min)

Goal: Create clear, consistent documentation for your own dataset terms.

Review your dataset and list 10–15 column names. Record in a shared data dictionary template (CSV):

  • Label (term name)

  • Definition (clear, context-rich description)

  • Units or codes used

  • Example value(s)

  • Notes on ambiguity or uncertainty

  1. Discussion: Patterns and Pitfalls (15 min)

Which terms were hardest to define?

Were there local abbreviations or codes that need clarification?

How can we document uncertainty? (e.g., “derived from visual estimate”).

  1. Reflection (10 min) Connect to next steps:

A well-documented data dictionary is the foundation for term alignment.

Later modules will link these definitions to others via mappings.

  • A draft data dictionary covering at least 10 key terms.

  • Peer-reviewed feedback on definition clarity.

  • Improved awareness of semantic gaps in existing data.

Key Points
  • A data dictionary is the bridge between raw data and understanding.
  • Good definitions reduce misinterpretation and support machine processing.
  • Documentation is both a social and technical task.

Content from Concept Decomposition

Last updated on 2025-11-11 | Edit this page

Estimated time: 92 minutes

Overview

Questions

  • What are the components that make up a concept?
  • How do I tell when two terms are the same, related, or overlapping?
  • What patterns or relationships exist among my documented terms?
  • How can I show these relationships clearly?

Objectives

  • Decompose complex concepts into simpler, more explicit parts.
  • Identify relationships (e.g., broader, narrower, related) among terms.
  • Use visual mapping to show how concepts connect.
  • Prepare a set of refined concepts that can be formalized in a schema.

Introduction

Now that your terms are well-defined and documented, the next step is to look beneath the surface — to unpack how those terms relate to one another.

This process, called concept decomposition, helps you:

  • See what each concept really means.
  • Identify overlaps or hidden distinctions between terms.
  • Prepare for formal modeling (where meaning becomes machine-readable).

For example:
The term “juvenile salmon” might seem simple — until you realize it includes age, size, and life stage. By decomposing it into parts (“life stage: juvenile”, “species: salmon”, “habitat: freshwater”), you make the meaning explicit and ready for alignment with other datasets or vocabularies.

Callout

🧩 Core Ideas

  • Concept decomposition means breaking a term down into its essential pieces of meaning.

  • It helps you move from words → structure.

  • Relationships matter: knowing how one term connects to another is as important as defining it.

  • Visualizing your terms helps spot patterns and inconsistencies.

Example

Term Broader Concept Narrower Concept Related Concept
Juvenile salmon Salmon Parr Smolt
Smolt Juvenile salmon — Ocean migrant
Spawning habitat Habitat Redd site —

From this, we can see that Smolt is a narrower stage within Juvenile salmon, and that Spawning habitat relates to but is distinct from Redd site — these are building blocks for the next module, where we’ll start expressing these ideas formally.

  1. Welcome & Overview (10 min) Instructor Talking Points

“We’ve documented and clarified what our terms mean — now we’ll start exploring how they relate to each other.”

“This process helps identify overlaps, redundancies, and relationships that will make your vocabulary more consistent and integrable.”

“You’ll learn to see terms not just as words, but as concepts in a network of meaning.”

Key Framing Questions

  • What happens when two teams use different terms for the same thing?
  • How can we make these relationships visible and agreed upon?
  • How might this help us integrate data across programs or agencies?
  • Encourage learners to see this as a detective exercise: uncovering the hidden structure of their vocabulary.
  1. Guided Example: Breaking Down a Concept (10 min) Instructor Demo

Use a familiar term, e.g., “juvenile salmon”, and walk through decomposing it into component ideas.

Ask aloud:

  • What is the core idea here?
  • What attributes or qualifiers are implied (e.g., life stage, species, habitat)?
  • Is this term broader or narrower than another concept we’ve seen?

Discussion Prompt

Ask participants:

“Can you think of a term in your data that’s used differently by different teams or datasets?” Use these examples to highlight why decomposition and mapping relationships improves clarity.

  1. Activity: Decompose and Map Your Own Terms (30 min)

Instructor Tips

Encourage them not to overthink — this is exploratory, not final.

If they get stuck, prompt with:

“What is this a type of?”

“What does this include?”

“What is this related to but not the same as?”

Walk around (or circulate in breakout rooms) and listen for examples that highlight ambiguity or hierarchy.

Discussion

Challenge 1: Build a Mapping Table (40 min)

  1. Pick 3–5 documented terms from their Module 2 work.

  2. Break each term down into its essential pieces of meaning.

  3. Identify any broader/narrower/related concepts.

  4. Sketch a mini concept map (e.g., on whiteboard, MS Paint, or sticky notes).

  1. Discussion & Wrap-Up (10 min) Group Discussion

Invite volunteers to share their concept maps or a tricky example they encountered.

Ask:

“Where did you find terms that overlap or conflict?”

“How might this process help clarify things for your collaborators?”

“What relationships were hardest to define?”

Encourage connections to real-world integration challenges — e.g., two agencies using different terms for similar stages or metrics.

💡 Instructor Notes & Tips Common Challenges

Learners get bogged down in wordsmithing — remind them that this stage is about structure, not final phrasing.

Difficulty identifying relationships — use analogies (e.g., “species is to genus as narrower is to broader”).

Too narrow a focus — encourage learners to zoom out to see relationships across datasets, not just within one.

Optional Extension

If time allows, show a quick example of a simple schema diagram (e.g., a few boxes and arrows). Explain that this is where they’re heading: transforming their decomposed concepts into a formal structure that can support data interoperability.

Key Points
  • Relationships reveal meaning.
  • Decomposing terms uncovers hidden assumptions.
  • Mapping across datasets helps identify where vocabularies can be aligned.
  • Concept decomposition prepares you for formalization in SKOS and ontology modeling (coming next!).

Content from From Concepts to Semantics — Introducing SKOS

Last updated on 2025-11-11 | Edit this page

Estimated time: 80 minutes

Overview

Questions

  • How do we move from lists of terms and definitions to formal, machine-readable vocabularies?
  • What does it mean to give a term a URI and define its relationships to others?
  • How can SKOS help represent our concepts and mappings in a structured, shareable way?
  • How do hierarchical relationships (“broader”, “narrower”, “related”) clarify meaning and enable interoperability?

Objectives

  • Explain the purpose of SKOS in representing controlled vocabularies.
  • Map existing terms and definitions from a data dictionary into basic SKOS structure (Concept, prefLabel, definition, broader, narrower, related).
  • Understand how SKOS differs from an ontology but connects to it (conceptual bridge).
  • Create a simple schema diagram showing relationships among terms, using SKOS-like semantics.

Key Takeaways for the Instructor to Reinforce

SKOS is about organizing concepts, not building full ontologies yet.

It’s okay if learners don’t fully “get” RDF — focus on relationships and hierarchy.

Encourage conversation about meaning, consistency, and relationships between concepts.

Diagrams help demystify formal semantics — it’s okay to stay visual!

Facilitator Prompt:

“You’ve all worked on documenting your data terms and even aligning them across datasets. But how do we represent those relationships formally, so others can understand or reuse them — including computers? That’s where SKOS comes in.”

Questions to ask the room:

“What happens if two groups both define ‘condition factor’ slightly differently?”

“How do you think we could show that one term is broader or narrower than another?”

“Why might this matter when sharing data or integrating across studies?”

Instructor Tip:

Keep it conversational — the goal is to surface the problem space that SKOS solves. Don’t introduce jargon yet.

Teaching Flow

  1. Define SKOS in plain language:

“SKOS stands for Simple Knowledge Organization System. It’s a way to represent vocabularies — lists of terms and their relationships — in a structured way computers and humans can understand.”

  1. Relate it to what they already know:

“You already have terms, definitions, and mappings. SKOS gives those structure — think of it as putting your dictionary into a well-organized tree.”

  1. Show an example.

  2. Make the bridge to ontology:

“SKOS is not an ontology — it doesn’t describe processes or logic. But it helps us get there by establishing consistent language.”

Instructor Notes:

If learners seem intimidated, reassure them: “You don’t need to write code today — we’re just organizing concepts visually.”

Have a slide or printed SKOS term table for reference: Concept, prefLabel, definition, broader, narrower, related, exactMatch, closeMatch.

Introduction

Learners have already identified and documented terms (Modules 1–3), and developed competency questions (Module 4). This module introduces semantic structure: how to move from “terms and mappings” to “concepts and relationships” that can be shared, reused, and machine-readable.

This is the first dip into ontology thinking, using SKOS because it’s lightweight, visual, and flexible.

SKOS (Simple Knowledge Organization System) provides a lightweight, flexible way to express controlled vocabularies and their relationships using the Semantic Web.

SKOS Term Meaning Example (Salmon Context)
skos:Concept A unique concept or term “Smolt condition factor”
skos:prefLabel The preferred human-readable label “Condition factor”
skos:definition Text definition of the concept “A measure of body condition calculated as weight/length³”
skos:broader More general concept “Smolt condition factor” broader: “Condition metric”
skos:narrower More specific concept “Smolt condition factor” narrower: “Fork length condition factor”
skos:related Related but not hierarchical concept “Condition factor” related to: “Smolt age”
skos:exactMatch, skos:closeMatch Crosswalk to another vocabulary “Condition factor” exactMatch: https://vocab.nerc.ac.uk/condition_factor/

SKOS helps structure your data terms before you build an ontology — it’s a bridge between documentation and formal reasoning.

Discussion

Challenge 1: From Data Dictionary to SKOS (25 min)

Purpose: Practice turning natural-language data terms into formal SKOS concepts.

Instructions:

  1. Take 3–5 terms from your data dictionary (Modules 1–3).
  2. For each term, fill in:
  • Preferred label
  • Definition (or short description)
  • Broader / narrower / related concepts (if applicable)
  • Equivalent or similar terms in another dataset or vocabulary

  1. Assign a temporary URI (e.g., https://example.org/salmon/condition_factor).

  2. Note which relationships are uncertain or need discussion.

🧠 Tip: You don’t need RDF syntax yet — the goal is concept structure, not code.

Concept PrefLabel Definition Broader Related URI
Smolt condition factor Condition factor Weight/length³, used as an indicator of fish health Condition metric Smolt length https://vocab.salmon.org/SmoltConditionFactor
Discussion

Challenge 2: Build a Simple Schema Diagram (20 min)

Purpose: Visualize how your SKOS concepts relate to one another.

Instructions:

  1. On a whiteboard or digital diagram tool (e.g., MS PowerPoint, Google Slides, MS Paint, paper):
  • Draw boxes for each concept.
  • Connect them with arrows labeled broader, narrower, or related.
  1. Check:
  • Is the hierarchy logical (no circular relationships)?
  • Are broader/narrower concepts consistent in scope?
  • Where could you reuse existing concepts from other vocabularies?
  1. Optional: Add color or icons to distinguish reused vs. new concepts.

💬 Reflection (10 min)

Discuss as a group:

  • What patterns or redundancies did you notice in your terms?
  • Which concepts could be reused from an existing vocabulary?
  • How does formalizing these relationships help you answer your Competency Questions from Module 4?

End by connecting this back to Competency Questions (Module 4):

“Your CQs ask big research questions. The SKOS structure helps ensure your vocabulary supports answering those questions consistently.”

Key Points
  • SKOS helps bridge informal definitions and formal semantics.
  • It supports controlled vocabularies that can later evolve into ontologies.
  • Creating a schema diagram helps visualize and communicate conceptual structure.
  • Reusing terms and clearly defining relationships builds semantic interoperability.

Content from From Terms to Meaning - Framing Knowledge with Competency Questions

Last updated on 2025-11-11 | Edit this page

Estimated time: 92 minutes

Overview

Questions

  • What is a Competency Question (CQ) and how does it help in ontology development?

Objectives

  • Explain what a Competency Question (CQ) is and why it’s useful in ontology development.
  • Formulate domain-relevant CQs that reveal how concepts connect and what data relationships matter.
  • Use CQs to guide vocabulary refinement and early ontology design.
  • Understand how CQs validate whether a knowledge model meets its intended purpose.

Introduction

Why Competency Questions?

Think of CQs as the “user stories” of ontology design — they describe what users (researchers, managers, etc.) need to know or compare, and ensure your data terms and structures can support those needs.

They help you: - Focus on purpose-driven vocabulary development - Identify data gaps early - Build alignment between scientists, data managers, and modelers

Example: Salmon Data Integration Context

Imagine you have multiple datasets on sockeye salmon:

  • Fraser River dataset: smolt length, weight, and ocean entry date
  • Bristol Bay dataset: similar metrics, but uses different column names and sampling protocols

Possible Competency Questions might be:

  • “Is the average smolt condition at ocean entry higher in one population than another?”
  • “Do differences in smolt condition explain variation in adult return rates?”

From these questions, you can see what concepts need alignment: condition factor, smolt stage, population, region, and return abundance.

  1. Concept Introduction (15 min)

Prompt discussion:

“If your vocabulary or ontology were a smart assistant, what questions would you want it to answer?”

Use this to introduce Competency Questions as a design tool.

Explain: Competency Questions (CQs) help define:

What knowledge must be represented.

How concepts are related.

Which data connections are needed to answer real-world questions.

Example:

“Are differences in sockeye smolt condition at ocean entry contributing to differences in adult return abundances between Fraser River and Bristol Bay populations?” → This implies relationships between smolt condition, population, location, ocean entry timing, and adult return abundance.

Show how each CQ points toward relationships that need to exist in the ontology (e.g., “hasCondition,” “occursAt,” “belongsToPopulation”).

  1. Demonstration: Deriving CQs from Data (10 min)

Instructor uses one term from the data dictionary (e.g., brood_year) and models a possible CQ:

“How does brood year relate to adult return abundance?”

“Which brood years correspond to years of low marine survival?”

Show how these questions hint at:

Entities: brood year, adult return, marine survival rate

Relationships: occurs_in_year, affects, has_rate

Explain that this is the first step in translating vocabulary terms into knowledge relationships.

  1. 🧠 Challenge / Activity 1: Writing Competency Questions (35 min)
Discussion

Challenge 1: Identify decision points

Goal: Draft and refine CQs that reflect the research or management needs represented by your data.

Steps:

  1. Review your vocabulary terms or data dictionary from earlier modules.

  2. In small groups, brainstorm 3–5 natural-language questions that:

  • Are answerable using your data (or could be if integrated).
  • Require multiple terms or relationships to answer.
  • Reflect real research or management scenarios.

  1. Write each question on a sticky note or digital card.

  2. Group similar questions and discuss:

  • Which terms appear most often?
  • What relationships are implied?

Facilitator Notes:

Encourage specificity. Instead of “What affects salmon survival?”, refine to “Does earlier ocean entry date affect survival of Fraser River Chinook smolts?”

Keep language natural — these aren’t queries yet, just conceptual targets.

  1. 🧩 Challenge / Activity 2: Extracting Relationships (20 min)
Discussion

Challenge 2: Write your own competency questions

Goal: Identify which terms and relationships are needed to answer each CQ.

Instructions:

In small groups or pairs, write 2–3 CQs that your data integration or modeling efforts should be able to answer.

Focus on specific, realistic, and answerable questions — avoid vague ones like “What is salmon health?”

Check your questions:

  • Are key concepts clearly defined?
  • Do you know what data source could answer it?
  • What relationships would your ontology need to represent?

🧩 Example Revision:

Too broad: “What affects salmon survival?”

Better: “Does smolt condition at ocean entry affect adult return rates by region?”

Discussion

Challenge 3: Connect CQs to terms

Using your data dictionary from Modules 1–3:

  • Highlight which terms appear in your CQs.
  • Identify any missing terms or unclear definitions.
  • Note which terms might need alignment across datasets (e.g., “region,” “population,” “condition”).
Key Points
  • Competency Questions express the intended use of an ontology in natural language.
  • They help translate real-world research and management questions into conceptual structures.
  • CQs are iterative, evolving as you refine your vocabulary and build your ontology.
  • Good CQs are specific, testable, and connected to real data needs.

Content from Bonus Session

Last updated on 2025-11-14 | Edit this page

Estimated time: 93 minutes

Ontology Game Workshop

Making Sense of Salmon Research Data

Overview

Questions

  • What is an ontology, and how does it differ from a data dictionary?
  • Why does salmon research data need clearer semantics?
  • What challenges arise when different people organize the same vocabulary?

Objectives

  • Define “ontology” in the context of data integration.
  • Recognize data ambiguity problems common in salmon science.
  • Connect these problems to ontology-based solutions.
  • Recognize why implicit structures must become explicit in an ontology.
  • Reflect on the need for controlled vocabularies.

Facilitator Tips

  • Keep the tone light and curious — emphasize exploration, not correctness.
  • Encourage laughter when groups disagree — it mirrors real data harmonization.
  • Use salmon-specific examples participants recognize to ground abstraction.
  • End with a call to action: share a link or example ontology relevant to their domain (e.g., EnvO, Darwin Core, OBO Foundry).

Introduction

  • Welcome participants and outline the workshop structure.
  • Introduce the idea that ontologies = shared meaning frameworks — not just fancy dictionaries.
  • Use a relatable example: “If one project measures ‘juvenile abundance’ and another measures ‘smolt density’, do we know if those data can be compared?”

Slide or flipchart talking points:

  • Data integration challenges in salmon research:
    • Different terms for similar things.
    • Ambiguous definitions.
    • Data collected at different scales or life stages.
  • How ontologies help:
    • Clarify relationships between terms.
    • Enable machine-readable data structures.
    • Support data discovery and reuse.

Transition:

“Let’s explore how our own thinking about salmon data reflects some of these challenges.”

Introduction

An ontology acts as the database schema or rule book for your knowledge model. It defines:

Types of entities (nodes): “Person,” “Film,” “Genre.”

Types of relationships (edges): A “Person” can “direct” or “star in” a “Film.”

Properties for entities and relationships: A “Person” has a “name” and “birth year.”

Ontologies provide foundational rules and structure, ensuring consistent interpretation by both humans and machines.

Understanding transitive properties

A transitive property is a relationship where if A relates to B, and B relates to C, then A relates to C.

Here is an example of how different life stages of salmon relate to spawning events, using a few clear classes and one transitive property.

We often record salmon data at different points in their life cycle — for example, a smolt Migration Event one year and a Spawning Event several years later.

By using a transitive property like hasLifeStageEvent, we can reason that the same Stock is connected across all those events.

Transitive properties help us:

  • Represent hierarchies (e.g., Species → Population → Individual).

  • Capture temporal or process chains (e.g., Smolt → Adult → Spawner).

  • Enable reasoning that connects related concepts without manually writing every link.

Callout 
Stock_A hasLifeStageEvent SmoltMigration_2022 .

SmoltMigration_2022 hasLifeStageEvent Spawning_2025 .

thus

Stock_A hasLifeStageEvent Spawning_2025 .
Discussion

Sorting the Vocabulary Soup (20 min)

Goal: Experience how people intuitively categorize domain concepts — and how different those categories can be.

Materials

  • Card sets with one term per card (20–30 total per table)
  • Example terms:
    water temperature, age, length, weight, life stage, spawn date, smolt, tag ID, river reach, capture event, habitat type, species, sex, growth rate, migration timing
  • Timer (10–15 minutes)
  • Table space or wall for grouping

Instructions

  1. Each group gets a shuffled deck of term cards.
  2. Ask them to organize terms into groups that make sense to them.
    No rules — they can group by theme, data type, biological scale, etc.
  3. Once grouped, have each group name their categories.
  4. Optional: groups walk around and view each others’ arrangements.

Implicit meanings of compound terms

We often see compound terms within dataset columns, yet compound terms often embed multiple concepts. For example, “Mark-recapture escapement estimate” includes:

  • Entity: population
  • characteristic: escapement
  • Measurement Method: mark-recapture

We cannot express these implicit meanings inside the table without first decomposing the term. Understanding these components helps clarify meaning and supports data integration.

Debrief Discussion (10 min)

Prompt questions:

  • What patterns did you notice?
  • Did your groups agree easily? Where did disagreements arise?
  • Were any terms hard to place?
  • What kinds of groupings emerged — by measurement type, by organism, by process?

Facilitator takeaway:

“This shows how even shared vocabulary can have different implicit structures — an ontology helps make those structures explicit.”

Discussion

Dissecting Salmon Terms (20 min)

Goal: Reveal the hidden components and embedded meanings in compound terms.

Materials

  • Each group receives 4–6 “compound” term cards.
    Examples:
    • Life stage
    • Spawner abundance
    • Tag detection event
    • Smolt-to-adult return rate (SAR)
    • Migration success
    • Egg-to-fry survival
  • Blank mini-cards or sticky notes
  • Pens or markers
  • Labels for concepts: Entity, Property, Process, Event, Assertion, etc.

Instructions

  1. Each group breaks down each compound term into its atomic concepts.
    • Example:
      Life stage → organism + developmental phase + (implied) habitat + age range
      Tag detection event → tagged individual + receiver + location + time
  2. Write each sub-concept on separate sticky notes.
  3. Label the type of each component (e.g. property, process).
  4. Optional challenge: Which team can identify the most distinct sub-concepts in 5 minutes?

Miro key:

Spawner abundance | adult salmon population | abundance | census count at weir Capture efficiency | Sampling method event | error | statistical model, such as mark-recapture Ocean-age 3 | population demographic | count | age classification, but how??

Discussion (10 min)

  • Which terms were most complex or ambiguous?
  • How could decomposition help when mapping data between projects?
  • Do you see examples where datasets might use the same word but mean different things?

Facilitator takeaway:

“Ontologies make these hidden structures explicit. When we define relationships clearly, our data become easier to integrate and reason over.”

Discussion

Build a Mini-Ontology (20 min)

Goal: Experience how explicit relationships can organize knowledge.

Materials

  • Blank cards or sticky notes (reuse from previous task)
  • Printed relationship arrows or connectors labeled:
    • is a
    • has property
    • occurs at
    • involves
    • measured in
    • related to
  • Optional: string or tape to connect items on a wall or table

Instructions

  1. Using the decomposed concepts from Task 2, groups now connect them into a network using relationship arrows.
    • Example:
      Tag detection event involves tagged individual
      Tag detection event occurs at location
      location has property river reach
  2. Encouraged to build small hierarchies (e.g., smolt is a juvenile is a life stage).
  3. Optional: introduce a “data integration twist” — merge two groups’ mini-ontologies and reconcile overlapping terms.

Discussion

  • How did your structure clarify meaning?
  • What relationships felt intuitive vs forced?
  • Where did alignment challenges appear when merging?

Facilitator takeaway:

“Ontologies don’t just name concepts — they define how those concepts relate. This structure is what lets systems automatically align datasets.”

Wrap-Up and Reflection (10 min)

Group discussion prompts:

  • Where in your research workflows do you see ambiguity in data terms?
  • Which tasks today reflected real challenges in your projects?
  • What would be the first step towards adopting an ontology in your work?

Facilitator closing:

“By making meaning explicit, ontologies turn local data into shared, interoperable knowledge. Even small steps — like decomposing terms or defining relationships — move us toward more integrated salmon science.”

Optional Gamification Ideas

  • Ontology Bingo: Each participant gets a bingo sheet with boxes like “Found a synonym”, “Identified hidden concept”, “Merged two groups”, “Defined an ‘is-a’ relationship”.
    Mark off during tasks; first to shout “Semantic alignment!” wins a small prize.

  • Ontology Auction: Each group receives a “dataset” card (e.g., spawn timing dataset, tag detections, habitat surveys).
    They can “bid” for ontology terms (like event, location, organism, measurement) to integrate their data — illustrating the value of reusability.

Key Points

  • Ontologies go beyond vocabulary—they structure meaning.

  • Shared semantics make integration and reuse possible.

  • Even small conceptual differences can block interoperability.