Introduction

The scimantic schema is a LinkML schema for representing the scientific method as provenance chains — questions, hypotheses, evidence, conclusions, and the acts that connect them.

This book is the public log of rebuilding that schema from scratch in its third release (v0.3.0), guided by the methodology in Ontology Development 101 (Noy & McGuinness, 2001 – or N&M) adapted to LinkML Schema terminology and the panschema toolchain.

Schema versions

v0.2.0 was an attempt to retrofit BFO/CCO grounding onto v0.1.0’s PROV-O-derived structure. The exercise was somewhat successful, but the path to get there was indirect and imperfect. We translated PROV relations to CCO process-participant relations after the fact rather than starting from BFO categories. That experience motivated this rebuild using N&M as a guide.

What this book does

It rebuilds the scimantic schema from scratch as v0.3.0, using the seven steps of N&M as scaffolding:

1. Determine the domain and scope
2. Consider reusing existing ontologies
3. Enumerate important terms
4. Define classes and the class hierarchy
5. Define properties (slots)
6. Define facets (slot_usage)
7. Create instances and validate

Each step gets a chapter. The schema is built incrementally, with frozen snapshots of schema/scimantic.yaml embedded at each stage so the reader sees exactly where the schema was when that chapter was written. Later chapters can call back to specific tagged listings without ambiguity.

How to read this book

• Frozen listings are exact snapshots of the schema at a moment in time, embedded inline via mdbook-listings. The tag (e.g., scimantic-yaml-v1) is the identity; the SHA-256 in book/listings.toml is the integrity check.
• Inline callouts annotate specific lines or regions of a listing, explaining design choices in the schema itself or in generated artifacts (e.g., .ttl, .json).
• Schema documentation (rendered HTML class cards, graph viz, navigation) lives at the URLs above. The book describes the journey; the schema docs describe the destination.

What this book doesn’t do

It doesn’t teach LinkML or BFO/CCO from scratch. There are better resources for that. It references them as needed and links out for depth. The audience is someone comfortable enough with LinkML and ontology basics to follow design discussion at the level of “should Question subclass cco:DirectiveInformationContentEntity or cco:DescriptiveInformationContentEntity?” not someone learning what slots: means.“

Domain and Scope

This chapter applies Step 1 of Ontology Development 101 (Noy & McGuinness, 2001) to scimantic.

The next four sections address each question in turn. A fifth section covers what scimantic deliberately does not model, and a closing note on iteration.

What domain does scimantic cover?

Scimantic models the scientific method as a process — the sequence of acts and artifacts by which researchers turn questions into published, evidence-supported analyses and conclusions.

Three categories of concepts:

• Process artifacts — Question, Hypothesis, Evidence, Result, Conclusion, Premise, ExperimentalMethod, Dataset, Annotation, …
• Acts that produce or transform them — QuestionFormation, LiteratureSearch, EvidenceExtraction, EvidenceAssessment, HypothesisFormation, DesignOfExperiment, Experimentation, Analysis, ResultAssessment
• Relations between them — hasInput, hasOutput, precededBy, hasAgent, supports, contradicts, derivedFrom, …

scimantic is domain-neutral. It is equally applicable to a physics simulation, a biology experiment, a literature-only meta-analysis, or a software-measurement (e.g., metrology) study. Whatever discipline you bring, the same process structure applies. Questions get formed, evidence gets gathered, hypotheses get tested, conclusions get drawn.

Domain-specific vocabulary and processes live in lower-level ontologies (e.g., a physics ontology, a biology ontology, etc.) and attach via class-and-slot URIs when consumers need it. This will enable fine-grained knowledge base development within a particular domain as well as effective cross-domain research and discovery.

What are we going to use the ontology for?

Two consumers drive the design:

• A structured-provenance authoring tool — for authoring research notes as provenance graphs. Needs Question / Hypothesis / Evidence / Premise / Conclusion as first-class authoring concepts.
• t2t — book-and-app project building a “trunk-to-theory” knowledge system. Uses the full graph as the backing data model.

These are the live consumers. The schema’s class and slot choices must support them. Other potential consumers (literature managers, notebook tools, lab-notebook systems) are welcome but don’t drive design at this stage.

What questions should the ontology answer?

Sketch list — questions an instance graph built on scimantic should answer:

1. What questions did a given literature search address?
2. What new questions did a given literature search surface?
3. What annotations on source documents grounded a given piece of Evidence?
4. What evidence has been assessed for credibility and accepted as Premise?
5. From which premises was a given hypothesis synthesized?
6. Which evidence supports or contradicts a given hypothesis?
7. For two competing hypotheses, what evidence has been gathered on each side?
8. What experimental methods were designed to test a given hypothesis, and what evidence informed the design?
9. What experiments executed a given experimental method?
10. What act produced a given dataset, and what method did it apply?
11. What dataset(s) did a given analysis consume to produce a result?
12. What is the uncertainty model for a given Result, and how was it derived?
13. What conclusions derive from a given experimental result?
14. Who (which Agent) performed a given act, and when?
15. What are the acts in the lineage of a given conclusion, traced back to the originating question?

Judging from this list (mirroring N&M’s analytical pattern from their wine example), the ontology will include: process artifacts (Question, Hypothesis, Evidence, Premise, Result, Conclusion, ExperimentalMethod, Dataset, Annotation); acts (QuestionFormation, LiteratureSearch, EvidenceExtraction, EvidenceAssessment, HypothesisFormation, DesignOfExperiment, Experimentation, Analysis, ResultAssessment); provenance relations (hasInput, hasOutput, derivedFrom, precededBy, hasAgent); and uncertainty representation (URREF-derived qualities on relevant artifacts). Provenance — tracing each artifact back to the act that produced it and the agent who performed that act — is core to the scope; the specific implementation mechanics (which relations carry explicit inverse slots vs. derive from upper-ontology declarations, cardinalities, slot_usage refinements) are deferred to Chapters 6 and 7.

This list is a sketch, not a contract. It informs design; Chapter 8 will revisit each question and verify the ontology can actually answer it.

Who will use and maintain the ontology?

• Authors: contributors welcome once the rebuild stabilizes; the book is meant to make the design rationale legible enough that newcomers can extend the schema without archeology.
• Methodology stewardship: mappings to upper- and mid-level ontologies (BFO 2020, Common Core Ontologies) require ontology expertise; Chapter 3 starts that work and consults external references for each major term decision.
• Downstream maintainers: consumers such as t2t re-validate against their build pipelines on each scimantic-schema release tag.

What scimantic does not model

The schema deliberately leaves several adjacent concerns to other vocabularies:

• Domain-specific terms. No built-in physics / biology / chemistry / etc. concepts. The schema is domain-neutral; consumers bring their own domain ontologies or skip them entirely.
• Truth-value or evidence-strength reasoning. Evidence has supports / contradicts slots that record claimed relationships between artifacts; the schema doesn’t adjudicate them. Reasoning layers (downstream SPARQL, LLM reasoners) do that work.
• Full bibliographic structure. citation is a free-form reference slot. DC, CSL, BibTeX, Wikidata, etc. cover typed bibliographic records better.
• Institutional / funding context. Orthogonal to the process. PROV-O Agent (transitively, via CCO/BFO mappings in Ch 3) and dcterms cover what’s needed; the schema doesn’t model institutions or grants directly.
• Time-series / measurement data internals. Dataset is a process-artifact handle. DCAT or discipline-specific data schemas cover the internal structure of the data itself.

The pattern is consistent: scimantic models the process around research, not the contents of the research domain. Consumers compose scimantic with whatever domain vocabularies and reasoning layers their use case requires.

On iteration

N&M-101 §3 opens with three fundamental rules:

The answers above will evolve. Today’s competency questions reflect what v0.1.0 and v0.2.0 surfaced as useful; Chapters 3 onward will likely surface gaps that motivate new questions, and that’s not failure — it’s Rule 2 made operational.

The schema as it stands at the end of Chapter 2 is the minimal stub committed alongside this chapter: just metadata, no classes yet. Chapter 3 takes the first concrete step of populating it — reviewing existing ontologies to decide what to import vs. invent.

Reusing Existing Ontologies

This chapter applies Step 2 of Ontology Development 101 (Noy & McGuinness, 2001) to scimantic.

That last sentence is where scimantic parts ways with the guide. N&M set reuse aside for pedagogy. They build their wine ontology from scratch because it is easier to teach that way. scimantic makes the opposite choice on purpose: the entire motivation for the v0.3.0 rebuild (Chapter 1) was that v0.2.0 retrofitted an upper-ontology grounding after the fact, and the fix is to start from reused foundations rather than bolt them on later. So this chapter is load-bearing in a way N&M’s Step 2 is not. It decides, term-source by term-source, what scimantic imports versus invents, and the decisions here constrain every chapter that follows.

The output of this chapter is deliberately small: a prefix block and an unchanged imports: list in schema/scimantic.yaml. Classes themselves come later (Steps 3–6). The prefix block is the machine-readable record of the decisions below. Throughout, reuse means naming scimantic’s classes against foreign IRIs rather than copying those ontologies. The LinkML mechanics of how that naming works are described below, after the reuse decisions, just before the listing.

The foundation: BFO 2020 and CCO

Two ontologies are not just reused but foundational. Every scimantic class will ultimately subclass something in them.

Basic Formal Ontology (BFO) 2020 is a top-level ontology standardized as ISO/IEC 21838-2:2020 and the shared upper layer of the OBO Foundry. Its job is to fix a small set of rigorous categories for what exists. Of those, the one scimantic leans on hardest is the continuant / occurrent split.

scimantic’s domain is a process: questions get formed, evidence gets gathered, conclusions get drawn. So the continuant/occurrent distinction is the backbone the schema needs. We reuse BFO via the obo: prefix; BFO terms are opaque IRIs of the form obo:BFO_0000015 (process). See Arp, Smith & Spear, Building Ontologies with Basic Formal Ontology (MIT Press, 2015) for the rationale behind those categories.

Common Core Ontologies (CCO) is a suite of mid-level ontologies that extend BFO, bridging the gap between BFO’s abstractions and domain-specific vocabularies. CCO is where scimantic gets most of the general categories it would otherwise have to reinvent. Between them, BFO and CCO supply the handful of kinds the whole schema is built from, each one a category scimantic commits to reuse:

• Artifacts — the information itself: Question, Hypothesis, Evidence, Premise, Result, Conclusion. Grounded in CCO Information Content Entity (ICE, cco:ont00000958) and its descriptive / designative / directive subdivisions.
• Acts — the agentive processes that produce and transform artifacts: QuestionFormation, LiteratureSearch, Experimentation, Analysis. Grounded in CCO Planned Act (cco:ont00000228). They count as planned acts because each carries out a method or protocol (itself a directive ICE) that prescribes it.
• States — conditions that hold steady over an interval: a conclusion standing unrefuted, a measured value holding constant, a question left open. Grounded in CCO Stasis (cco:ont00000819).
• Qualities — the properties an artifact carries, chiefly its uncertainty and credibility. Grounded in BFO Quality (obo:BFO_0000019). CCO ships no uncertainty quality of its own, so defining one under BFO Quality is a candidate for a later chapter to weigh, with URREF (below) the likely vocabulary.
• Agents — who performs the acts: researchers, groups, organizations. Grounded in CCO Agent (cco:ont00001017).

All of it unfolds over time, BFO temporal region (obo:BFO_0000008), which timestamps each act and bounds the interval a state occupies.

These already exist as standardized, BFO-grounded categories; rolling scimantic’s own versions would duplicate that work and give up the main thing grounding buys: interoperability. One caveat the survey turned up: CCO’s Stasis is under active revision upstream, so a later chapter may want to insulate scimantic against the churn. One candidate is to pin a thin local class over Stasis rather than subclass it directly, the same defensive move URREF’s unstable namespace invites.

CCO’s v2.0 (2024) terms are the opaque IRIs above (cco:ont00000958 is Information Content Entity); see Jensen et al., The Common Core Ontologies (FOIS 2024) and the CUBRC Overview of the Common Core Ontologies (Rudnicki, 2019).

This is the grounding ch01 promised and the decision ch02 deferred here: “should Question subclass cco:DirectiveInformationContentEntity or cco:DescriptiveInformationContentEntity?” is now a well-posed question, because both candidate parents exist in a vocabulary we’ve committed to reuse. Answering it is Chapter 5’s job; making it answerable is this chapter’s.

Provenance without PROV-O

One reuse decision runs the other way: not reusing PROV-O at all. It needs justifying, because on the surface it looks counterintuitive.

scimantic’s domain is provenance. The competency questions in Chapter 2 (“what act produced this dataset?”, “who performed it, and when?”, “trace this conclusion back to its originating question”) are textbook provenance queries. The W3C PROV-O Recommendation is the lingua franca for exactly these: prov:Entity, prov:Activity, prov:Agent, prov:wasGeneratedBy, prov:used. scimantic v0.1.0 was grounded in PROV-O for this reason. So why does v0.3.0 not declare a prov: prefix at all?

Because grounding in PROV-O is what v0.2.0 spent its effort trying to walk back. PROV-O is loose by design: prov:Entity spans both continuants and occurrents, which helps interchange but breaks down under a rigorous upper ontology. Going from v0.1.0 to v0.2.0 meant translating PROV relations into BFO/CCO process-participant relations after the fact, the indirect path ch01 calls out; re-importing PROV-O as a grounding now would repeat it.

The bridge scimantic needs already exists as an external, maintained, peer-reviewed artifact. Beverley et al., A semantic approach to mapping the Provenance Ontology to Basic Formal Ontology (Nature Scientific Data, 2025; arXiv:2408.03866) align every class and object property of PROV-O and its W3C extensions to BFO, CCO, and RO (the OBO Relations Ontology, the BFO-aligned standard for relations like part of and participates in, where much of PROV’s relational vocabulary lands). The mappings ship as three standalone files: PROV-BFO, PROV-CCO, and PROV-RO. Because scimantic grounds in CCO, it inherits that bridge transitively. This is what ch02 meant by “PROV-O Agent (transitively, via CCO/BFO mappings).”

With that alignment in hand, declaring PROV mappings in scimantic would be redundant, not helpful. A consumer who needs PROV interoperability applies PROV-CCO against a scimantic graph and gets canonical PROV typing, more complete than the handful of close_mappings scimantic could hand-author, and without the risk of an over-tight exactMatch where the real relationship is approximate. The alignment lives upstream, not in scimantic. The specific correspondences (cco:Agent to prov:Agent, the act hierarchy to prov:Activity, and so on) live in the PROV-CCO file; spelling them out belongs with the chapters where scimantic defines its own classes and relations. scimantic grounds in BFO/CCO and cites the alignment for anyone who needs PROV, meeting the interoperability need by reuse rather than by importing PROV-O itself.

Specialized vocabularies

Beyond the foundation, scimantic reuses five narrower vocabularies, each covering a concern ch02 explicitly declined to model itself. None are foundational (they attach to specific classes that arrive in later chapters), but committing to them now keeps the prefix block an honest manifest.

• dcterms (Dublin Core Terms) — general metadata (titles, dates, creators, free-form citation). ch02 sends typed bibliographic structure downstream to DC/CSL/BibTeX and institutional/funding context to dcterms; this is that landing pad, and an uncontroversial one to reuse.
• oa (W3C Web Annotation Data Model) — annotations and text selectors. scimantic’s Annotation (a highlight over a span of a source document, produced by a LiteratureSearch) is a W3C annotation; reusing oa:Annotation and its selector machinery means scimantic doesn’t reinvent text-anchoring. A W3C Recommendation with real tool support.
• dcat (Data Catalog Vocabulary) — dataset description. ch02 draws a firm line: Dataset is a process-artifact handle, and the internal structure of the data is DCAT’s job (or a discipline-specific schema’s), not scimantic’s. The dcat: prefix is how that handle connects to the catalog layer.
• np (Nanopublication schema) — small, attributed, independently-citable assertions. scimantic’s claim-bearing artifacts (Hypothesis, Evidence, Result, Conclusion) are natural nanopublications; np: lets a consumer mint them as such for citation and attribution without scimantic prescribing the packaging.
• urref (Uncertainty Representation and Reasoning Evaluation Framework) — the uncertainty layer (Costa et al., Towards unbiased evaluation of uncertainty reasoning: the URREF ontology, Fusion 2012). ch02 lists “URREF-derived qualities on relevant artifacts” as in-scope, so the uncertainty model of an Evidence or Result has a vocabulary to attach to. It is also the one reuse target without a stable, canonical IRI 3.1.4, a Step-2 finding in its own right, since reuse decisions include judging a source’s long-term addressability, not just its concepts.

What scimantic invents

Reuse is not the whole story. Everything characteristic of scimantic, the discipline-neutral vocabulary of the scientific method, is original: Question, Hypothesis, Evidence, Premise, Result, Conclusion and the acts QuestionFormation, LiteratureSearch, EvidenceExtraction, HypothesisFormation, Experimentation, Analysis, and so on. None of these exist in BFO, CCO, or any vocabulary above; supplying them is why scimantic exists.

The division of labor is the consistent pattern from ch02: reuse the scaffolding, invent the discipline. BFO supplies the categories of being; CCO supplies the generic shapes of information and action; the specialized vocabularies cover annotation, datasets, citation, nanopublication, and uncertainty. What scimantic adds is the process structure of research itself, built by subclassing the reused categories under original names. Those classes live under the scimantic: prefix. The one place CCO leaves a gap is an uncertainty quality; whether scimantic fills it under BFO Quality is a candidate for Chapter 6 to take up, with URREF’s guidance.

The reuse decision, at a glance

How reuse works in LinkML

With the decisions made, here is one mechanical point before the listing, because LinkML’s reuse model may trip up people who arrive from OWL.

In OWL you reuse an ontology by owl:imports-ing it. The imported axioms become part of the ontology’s logical closure. LinkML’s imports: keyword looks like that but is not that. LinkML imports: pulls in other LinkML schemas (most commonly linkml:types, the built-in type library). It does not ingest external OWL ontologies like BFO or CCO.

Instead, scimantic reuses external ontologies the way LinkML intends:

• class_uri / slot_uri bind a scimantic class or slot to a canonical IRI in another vocabulary. For example, a class Agent with class_uri: cco:Agent is the CCO agent class as far as the generated RDF/OWL is concerned. scimantic just gives it a readable local name and LinkML-shaped slots.
• Mapping slots (exact_mappings, close_mappings, related_mappings, broad_mappings, narrow_mappings) record looser cross-vocabulary correspondences as SKOS-style annotations, without claiming identity.
• prefixes declare the namespaces those IRIs live in. This is the only piece that lands in this chapter; the class_uris that consume the prefixes arrive in Chapter 5.

The upshot: reusing BFO and CCO costs scimantic nothing at the imports: level. imports: stays at just linkml:types. Reuse is expressed by naming (i.e., pointing local classes at foreign IRIs) rather than by ingestion. This keeps scimantic.yaml human-readable while the generated OWL still carries correct upstream ancestry.

The schema so far

The decisions above land as changes to the prefixes: and imports: blocks in schema/scimantic.yaml:

id: https://w3id.org/scimantic
name: scimantic
description: |-
  A LinkML schema for representing the scientific method as provenance
  chains, grounded in BFO 2020 (ISO/IEC 21838-2:2020) and the Common
  Core Ontologies (CCO). v0.3.0 is a ground-up rebuild — see the
  [book](https://padamson.github.io/scimantic-schema/) for the
  chapter-by-chapter journey, following Ontology Development 101
  (Noy & McGuinness, 2001) adapted to LinkML.
license: https://creativecommons.org/licenses/by/4.0/
version: 0.3.0-dev

prefixes:
  # The LinkML metamodel and scimantic's own namespace
  linkml: https://w3id.org/linkml/
  scimantic: https://w3id.org/scimantic/

  # Foundational grounding: BFO and CCO
  obo: http://purl.obolibrary.org/obo/
  cco: https://www.commoncoreontologies.org/

  # Reused domain vocabularies: metadata, annotation, datasets,
  # nanopublication, uncertainty
  dcterms: http://purl.org/dc/terms/
  oa: http://www.w3.org/ns/oa#
  dcat: http://www.w3.org/ns/dcat#
  np: http://www.nanopub.org/nschema#
  urref: http://eturwg.c4i.gmu.edu/files/ontologies/URREF.owl#

default_prefix: scimantic
default_range: string

imports:
  - linkml:types

The prefix block is a reuse manifest 3.1.1; BFO and CCO are the foundation every later class hangs from 3.1.2; the absent prov: prefix is a decision, not an oversight 3.1.3; URREF is committed but its namespace is provisional 3.1.4; and imports: stays minimal because external ontologies are reused by naming, not ingestion 3.1.5.

Next

The foundations are chosen and named; nothing is yet classified against them. Chapter 4 takes N&M Step 3, enumerating the important terms of the domain to produce the candidate vocabulary that Chapter 5 will then arrange into a class hierarchy beneath the BFO and CCO categories committed here.

Important Terms

This chapter applies Step 3 of Ontology Development 101 (Noy & McGuinness, 2001) to scimantic.

The temptation in this step is to start organizing. N&M say not to: the goal is a comprehensive list, not a sorted one. Overlap is fine; whether a term becomes a class or a slot, and where it sits in a hierarchy, is later work (Chapters 5 and 6). This chapter only gathers the vocabulary.

That also means it is nearly free of code. Harvesting terms changes nothing on its own, and the schema is almost as Chapter 3 left it; the one exception is the second pass’s reuse step, which commits a single new prefix, cito: (its diff appears below). Otherwise the output of this step is the list itself, plus what ch02 anticipated: harvesting terms surfaces new competency questions, which we let happen and record.

How the competency questions drive the vocabulary

N&M’s method is that the competency questions from Chapter 2 — the sketch of questions a scimantic knowledge base should be able to answer — tell you which terms you need: a knowledge base can answer a question only if its vocabulary names the things the question asks about. So we read each question the way someone writing the query against the finished graph would: the question fixes a node to start from, a thing to return, and a path of edges between them. The terms the question demands are the node-types and edge-types on that path, plus the ones it quietly presupposes.

What follows walks all fifteen questions in clusters, harvesting terms as it goes. The harvest has three moves: it carries the terms ch02/ch03 and v0.1/v0.2 already settled, it adds the ones a question surfaces (marked (new)), and it reconsiders the v0.2 terms no question demands. A ground-up rebuild should prune as well as accrete, so the terms the questions retire are collected at the end, once every question, original and surfaced, has been asked.

Walking the questions

The search–question loop (CQ 1–2)

“What questions did a given literature search address?” (CQ 1) and “What new questions did a given literature search surface?” (CQ 2) are mirror images. CQ 1 reads a search’s input questions (the ones motivating it); CQ 2 reads its output questions (the ones it raised). Together they demand that a single Question node be able to play both roles — output of one act, input to a later one — which is the shape of the whole method: a search raises questions that drive the next search.

A literature search also ranges over something. The question says “literature search,” which presupposes the literature: the documents searched. That forces a new artifact, SourceDocument, that the search ranges over and that annotations later point at. v0.1 and v0.2 only had a free-form source string; CQ 3 will make the node unavoidable.

New terms this pair forces: SourceDocument (artifact); the relations addresses (search → its motivating question) and surfaces (search → a question it raised), both specializations of the generic hasInput/hasOutput that let a query tell a search’s motivating question apart from its document inputs and its raised outputs; and a latent open state on a question (a search addresses and raises open questions).

The evidence-to-hypothesis spine (CQ 3–5)

These three chain into the core of the method. “What annotations on source documents grounded a given piece of Evidence?” (CQ 3) runs Evidence → Annotation → SourceDocument, with the annotation pinned to a span by its TextSelector and offsets. “What evidence has been assessed for credibility and accepted as Premise?” (CQ 4) filters evidence by an assessment and its outcome. “From which premises was a given hypothesis synthesized?” (CQ 5) returns the premises that a HypothesisFormation act combined into the hypothesis.

CQ 4 is the sharp one. It needs the outcome of an EvidenceAssessment — accepted, rejected, or deferred — as something queryable, so it can return only the accepted evidence; and it needs the link from accepted evidence to the Premise it became. That link is not generic derivedFrom: Evidence and Premise are the same claim at two epistemic stages, not one claim derived from another. This is the Evidence/Premise overlap ch04 flagged earlier made concrete: CQ 4 is the query the eventual modeling choice (two classes, or one class with a status) has to serve, and CQ 5 then requires that a premise be a node you can traverse from.

New terms: AssessmentOutcome (accepted / rejected / deferred); the relations groundedIn (evidence → annotation), promotedFrom (premise → the evidence it was accepted as), and synthesizedFrom (hypothesis → its premises); a graded credibility value rather than a bare flag (assessing for credibility implies a measured value); and an accepted / premise-standing state — the previously thin States kind gains its first well-motivated members here, since “being a premise” is a condition that holds over an interval until retracted.

Support and contrast (CQ 6–7)

“Which evidence supports or contradicts a given hypothesis?” (CQ 6) is the question the starting vocabulary was seeded from; everything it names is already present (Evidence, Hypothesis, supports, contradicts). Its only new pressure is latent: if scimantic ever wants to say who asserted that support, when, or how strongly, the support edge has to become a node of its own (a reified evidential relation), not a bare property.

“For two competing hypotheses, what evidence has been gathered on each side?” (CQ 7) adds the first genuinely new idea to the vocabulary: contrast. Up to here every relation has been lineage (this came from that). CQ 7 needs two hypotheses to stand as rivals, which nothing in the vocabulary expresses. It forces competesWith (a symmetric hypothesis–hypothesis relation). And it exposes a missing edge underneath it: two hypotheses compete because they answer the same question, so there is a presupposed addresses relation from a Hypothesis back to the Question it answers — currently unstated. Whether competition is asserted directly or derived from a shared question is a later decision; the terms go on the list now.

Method, experiment, dataset (CQ 8–11)

This cluster pivots on acts and methods, and the four questions cannot be answered independently. “What experimental methods were designed to test a given hypothesis, and what evidence informed the design?” (CQ 8) needs a tests relation — and tests is a different verb from supports/contradicts: it is prospective intent (we built this to probe the hypothesis), where support is retrospective verdict (the evidence came back and bears on it). The vocabulary must keep the two apart.

“What experiments executed a given experimental method?” (CQ 9) needs an executes relation tying an Experimentation to the ExperimentalMethod it ran — an edge the vocabulary lacks. (In BFO/CCO terms a method is a plan specification that an act realizes, so this may reuse an upstream relation rather than mint a fresh one.)

“What act produced a given dataset, and what method did it apply?” (CQ 10) widens both: it says “what act,” not “what Experimentation,” so it quantifies over acts generically and needs Act to be a real superclass, not just a reading-group label; and an Analysis that produced a dataset also “applied a method,” which pushes ExperimentalMethod toward a more general Method. “What dataset(s) did a given analysis consume to produce a result?” (CQ 11) reads inputs and outputs through one act node, and the idiomatic verbs consumes / produces show up as candidate typed readings of hasInput/hasOutput.

The four together force the chapter’s biggest single tension: is an ExperimentalMethod a reusable template or a per-study instance? CQ 9’s many-to-many “executed by” and CQ 10’s “any act applies a method” both argue for a reusable template plus a general Method, which in turn argues that CQ 8’s tests belongs on the design act, not the method. Three questions, one decision — deferred to Chapter 5.

New terms: tests (design/method → hypothesis, prospective); executes (act → method); Act (generic superclass); Method (generalization of ExperimentalMethod, with experimental and analytical sub-kinds); the typed readings consumes / produces; and a cluster of optional descriptors the questions gesture at — a design rationale, an execution fidelity/deviation, and per-execution parameter bindings distinct from a method’s default Parameters.

Uncertainty and conclusions (CQ 12–13)

“What is the uncertainty model for a given Result, and how was it derived?” (CQ 12) is the strongest pull toward promoting uncertainty from a slot to a structured class. The word “model” means uncertainty is not a scalar: it carries a model family (Gaussian, bootstrap, posterior), its parameters and confidence level, and a nature (aleatory or epistemic, the URREF distinction ch03 committed to). And “how was it derived” straddles two readings — derivation as a descriptive attribute (URREF-style metadata) or as a deriving act (an error-propagation or calibration step with its own inputs and agent). The question gives different answers depending on which the schema picks.

“What conclusions derive from a given experimental result?” (CQ 13) forces almost no new noun but presses a relation: derivedFrom (conclusion → result) must stay consistent with the act path behind it (a ResultAssessment that took the result in and put the conclusion out), so that CQ 13’s answers compose into CQ 15’s lineage. The adjective “experimental” also presupposes a way to tell a result’s origin — recoverable by tracing back to an Experimentation act rather than by a new attribute.

Terms, new and reconsidered: a structured uncertainty (model, nature, derivation, parameters, confidence level), of which model, parameters, and confidence level are new. UncertaintyDerivation is not new but a v0.2 class CQ 12 re-surfaces. And v0.2’s four fine-grained natures (Ambiguity, Vagueness, Incompleteness, Aleatory) fold into the coarse aleatory/epistemic nature the question actually asks for. Plus the relations hasModel / hasNature linking an uncertainty to its facets, and a candidate statistical / inference method as the thing that produces uncertainty and credibility values (see the comparative findings below).

Agency, time, and lineage (CQ 14–15)

“Who (which Agent) performed a given act, and when?” (CQ 14) is the question that promotes time from background grounding to a named term. The “who” half reuses hasAgent. The “when” half is where the precision lives: acts are occurrents that unfold in time (ch03’s continuant/occurrent backbone), so an act’s “when” is a temporal region — an interval — not merely a creation instant. The starting vocabulary only had createdAt, which silently asserts every act is instantaneous; that is false for an Experimentation running for days. CQ 14 forces a real, interval-capable temporal term and the relation that attaches it.

“What are the acts in the lineage of a given conclusion, traced back to the originating question?” (CQ 15) is the capstone: a recursive provenance query that exercises the whole graph. To enter the chain from a conclusion you traverse backward from artifact to act, so it forces producedBy — the named inverse of hasOutput — as a first-class, traversable relation. It needs precededBy and derivedFrom to be transitive (the recursion is a property path). And it surfaces that lineage is encoded three ways at once — act-to- act precededBy, artifact-to-artifact derivedFrom, and the act↔artifact threading of hasInput/hasOutput — which must be kept mutually consistent. CQ 15 also quietly assumes the provenance graph is a DAG: lineage is generally a converging tree, “the originating question” may be plural, and an act can never precede one that occurred later.

New terms: TemporalRegion (with the instant vs interval distinction, and startTime / endTime / duration); the relation occursAt / hasTemporalRegion (act → time); producedBy (artifact → its producing act — v0.2’s isOutputOf, renamed to read as a relation); an optional materialized hasOriginatingQuestion shortcut; and the recorded characteristics that lineage demands — transitivity on precededBy/derivedFrom and an acyclicity assumption on the whole graph.

The vocabulary, enlarged

Collecting the harvest. Terms carried from ch02/ch03 are plain; terms surfaced by reading the questions closely are marked (new). The grouping is for reading only — it is not the class hierarchy, and a term’s group does not decide class-versus-slot.

Artifacts

• Question, Hypothesis, Evidence, Premise, Result, Conclusion
• ExperimentalMethod (with Parameters); Method (new — generalizes ExperimentalMethod to cover analytical methods)
• Dataset
• Annotation (with TextSelector)
• SourceDocument (new — the document a search ranges over and an annotation targets)
• AssessmentOutcome (new — accepted / rejected / deferred verdict of an assessment)

Acts

• QuestionFormation, LiteratureSearch, EvidenceExtraction, EvidenceAssessment, HypothesisFormation, DesignOfExperiment, Experimentation, Analysis, ResultAssessment
• Act (new — the generic superclass CQ 10/14/15 quantify over)
• UncertaintyDerivation (from v0.2; conditional — only if uncertainty derivation is modeled as an act)

Agents

• Agent, with Person, Group (of researchers), Organization

Qualities and other attributes

• uncertainty (carried, but CQ 12 pushes it toward a structured term) with model, nature (aleatory/epistemic), derivation, parameters, confidence level (the last two new)
• credibility, and a graded credibility value (new)
• value, unit
• the selector offsets: exact, prefix, suffix, startOffset, endOffset, pageNumber
• label, citation, source, content, accessLevel, publishable
• startTime, endTime, duration (new — interval “when”)
• candidate descriptors (new, optional): design rationale, execution fidelity/deviation, per-execution parameter bindings, result origin/kind, lineage step order

States (the thin kind of ch04, now populated)

• a question open (new)
• a claim accepted / standing as a premise (new)
• a conclusion standing unrefuted (carried)
• candidate: a hypothesis favored over a competitor, under test; a method validated by ≥1 execution (new, latent)

Relations

• carried: hasInput, hasOutput, precededBy, hasAgent, derivedFrom, supports, contradicts, refines, prescribes, hasUncertainty, hasBody, hasTarget, hasSelector
• addresses (search → motivating question; hypothesis → its question), surfaces (search → raised question)
• groundedIn (evidence → annotation), promotedFrom (premise → evidence), synthesizedFrom (hypothesis → premises)
• competesWith (hypothesis ↔ hypothesis, symmetric)
• tests (design/method → hypothesis, prospective intent)
• executes (act → method), consumes / produces (typed readings of input/output)
• hasModel, hasNature (uncertainty → its facets)
• occursAt / hasTemporalRegion (act → time)
• producedBy (artifact → its producing act; the named inverse of hasOutput — v0.2’s isOutputOf, renamed), optional hasOriginatingQuestion
• recorded characteristics: precededBy and derivedFrom are transitive; the provenance graph is assumed acyclic (a DAG)

Temporal (promoted from background grounding to named terms)

• TemporalRegion, with TemporalInstant and TemporalInterval

A second pass: the new questions loop back through Steps 2 and 3

ch02 said the competency-question list was “a sketch, not a contract” and predicted that later chapters “will likely surface gaps that motivate new questions, and that’s not failure — it’s Rule 2 made operational.” Reading the original fifteen closely did exactly that: it raised about forty more. Rather than list them and defer, we do what Rule 2 asks and loop back, running this new batch through the steps already taken — reuse (Step 2) and term-harvesting (Step 3), the same passes the originals went through. The hierarchy (Step 4) is still Chapter 5; these questions feed it.

The ones that earn a place are the inverses, the gaps, the provenance-of-the-link, the contrast, and the integrity questions the original fifteen imply but never state:

• Inverses (provenance runs both ways). Which literature searches addressed a given question? What evidence was extracted from a given annotation or source document? What hypotheses were synthesized from a given premise? Which analyses consumed a given dataset? Which acts did a given agent perform, and over what period? What conclusions trace back, transitively, to a given originating question?
• Gaps in the chain. What evidence was assessed but rejected? What evidence remains unassessed? Is a given premise still accepted, or has its acceptance been retracted?
• Provenance of the link. For a given support or contradiction, which act and agent established it, when, and with what strength?
• Contrast. What question do two competing hypotheses jointly address? Across all the evidence, which of them carries the greater weight? Is one piece of evidence shared between them, supporting one while contradicting the other?
• Method and uncertainty. What hypotheses is a method capable of testing, versus the one it was designed to test? By what statistical method were a result’s uncertainty and credibility derived? Is that uncertainty aleatory or epistemic?
• Integrity and impact. Is a given conclusion’s lineage complete and acyclic — every artifact tracing to a producing act, back to a question? Do two conclusions share a common ancestor? If an upstream premise or result were retracted, which downstream conclusions are affected?
• From the neighbors. Given any claim — hypothesis, premise, or conclusion — what supports and what challenges it? How many independent lines of evidence back a conclusion, and how strong is each? Which acts and artifacts belong to the same study?

Step 2 again — what to reuse for them

scimantic is not the first schema to model scientific claims, evidence, and provenance, and several of the new questions ask for things the neighbors already have. Running Chapter 3’s “consider reuse” pass again, now aimed at the new questions’ terms, both validates the existing vocabulary and turns up candidate sources — to adopt now, or defer the way Chapter 3 deferred URREF. A research pass over the neighbors sorted them into four buckets.

Where scimantic aligns. Its provenance relations map cleanly onto PROV-O: hasInput/hasOutput/ derivedFrom/hasAgent/precededBy are PROV’s used/wasGeneratedBy/ wasDerivedFrom/wasAttributedTo/wasInformedBy. Its Annotation + TextSelector are the W3C Web Annotation model it already reuses via oa:, and the Micropublications model pairs claims with exactly that anchoring. supports is the universal positive term across the literature.

The same reconsidering retired v0.2’s reuse mixins (Nanopublication, DCATDataset, UncertaintySubject) in favor of the by-URI prefix manifest, as recorded in Reconsidered from v0.2; the second pass adds no mixins, only the reuse below.

Adopt: CiTO, for the claim relations (a new prefix). No established model pairs supports with contradicts. The well-trodden vocabulary is CiTO, the SPAR Citation Typing Ontology, whose object properties carry no domain or range and so apply claim-to-claim as readily as document-to-document. scimantic adopts it: supports maps to cito:supports, contradicts to cito:disputes (or the stronger cito:refutes), and refines to cito:extends/updates. CiTO is the second pass’s one manifest change — a cito: prefix, the only candidate here that needs one, since the rest live under the obo: prefix Chapter 3 already declared. The manifest grows by one entry:

--- scimantic-yaml-v1
+++ scimantic-yaml-v2
@@ -23,13 +23,15 @@
   cco: https://www.commoncoreontologies.org/
 
   # Reused domain vocabularies: metadata, annotation, datasets,
-  # nanopublication, uncertainty
+  # nanopublication, uncertainty, claim relations
   dcterms: http://purl.org/dc/terms/
   oa: http://www.w3.org/ns/oa#
   dcat: http://www.w3.org/ns/dcat#
   np: http://www.nanopub.org/nschema#
   urref: http://eturwg.c4i.gmu.edu/files/ontologies/URREF.owl#
+  cito: http://purl.org/spar/cito/
 
 default_prefix: scimantic
 default_range: string

The one caveat, recorded in the cito callout: CiTO’s own narrative is about citations between documents, not claims, though its authors’ examples are claim-level and its axioms impose no such limit.

Adopt as mapping targets (no new prefix). Two OBO-Foundry ontologies are reachable through the existing obo: prefix and worth binding to when the classes and slots land:

• IAO, the Information Artifact Ontology, has neutral hypothesis and conclusion textual-entity terms. They become exact_mappings on scimantic’s Hypothesis and Conclusion, with CCO’s Information Content Entity staying the primary grounding: interoperability without a second ancestry claim.
• RO, the OBO Relations Ontology already named in Chapter 3’s PROV alignment, supplies has input / has output; scimantic’s input and output slots map to it for OBO-wide interoperability, with CCO and BFO relations primary.

Defer, the URREF way. The two closest conceptual fits are also the least stable:

• SEPIO, the Scientific Evidence and Provenance Information Ontology, is built for exactly this domain — assertion, evidence line, evidence item — but its OWL is mid-migration to a LinkML model, its last release is years old, and its term IRIs are not currently stable. It is the intended source for a Claim superclass and evidence lines, and like URREF it is committed in principle and pinned behind a thin local class until those IRIs settle.
• The Micropublications model (Claim, Evidence, Argument, with reified support) maps just as closely, but its IRI dead-ends in a personal repository last touched in 2016. Same posture: cite the pattern, defer the binding.

The Study container and a statistical-derivation method have candidate homes in OBI and OBCS (also under obo:), but both are biomedical in scope, and their genuinely neutral content — an investigation as a planned process, a statistical analysis — is largely already reachable through BFO, CCO Planned Act, and IAO. They stay candidate mappings to revisit if scimantic mints those classes, with STATO weighed against OBCS for the statistics.

Decline. The SPAR document-discourse ontologies (DoCO/DEO) model a paper’s sections, not its claims, and define no Hypothesis, Evidence, or Premise. SWAN’s IRIs are dead, its Google Code home gone, and its ideas survive in Micropublications. EXPO is grounded in SUMO, a rival upper ontology that would clash with the BFO/CCO base; its one portable lesson — that some inquiry is exploratory, with no prior hypothesis — is a question for Chapter 5 (is Hypothesis mandatory in the chain?). All three are prior art, nothing to import.

Step 3 again — the terms they add

Run the new questions through the same lens as the first pass: each cluster is a fresh demand for terms. The yield is smaller, because most of these questions reuse the existing vocabulary in new directions rather than name new things. Two clusters are the exception.

Inverses force no new nouns. “Which searches addressed a question,” “what evidence came from an annotation,” “which analyses consumed a dataset” each read an existing edge backward. What they force is a Chapter 6 decision, not a Step 3 term: whether each inverse (addressedBy, extractedInto, consumedBy, and the rest) is a stored slot or derived from its forward relation by the reasoner. The first pass already named one such inverse, producedBy, for the same reason.

Gaps in the chain add an outcome value and a state. “What evidence was assessed but rejected” needs the rejected value of the AssessmentOutcome the first pass derived from CQ 4; “is a premise still accepted, or retracted” needs a retracted state on a premise or conclusion. “What remains unassessed” needs no new term, only the absence of an assessment act. Together these thicken the States kind the first pass left thin.

Provenance of the link forces a relation to become a node. “Who asserted that this evidence supports that hypothesis, when, and how strongly” cannot be answered by a bare supports edge, which has nowhere to hang an asserter or a strength. The answer is a reified EvidentialRelation carrying polarity, strength, an asserting act, and an agent. This is the one place the second pass restructures a relation the first pass treated as a plain edge.

Contrast mostly reuses. The competing-hypotheses questions lean on competesWith and addresses, both derived in the first pass. The only addition is a weight of evidence per hypothesis, computed from the support and contradict edges rather than stored.

Method and uncertainty adds one term and sharpens one. “By what statistical method were a result’s uncertainty and credibility derived” forces a StatisticalMethod, the act-or-method that produces the uncertainty quality the first pass named but left unsourced. “What a method is capable of testing versus what it was designed to test” sharpens tests into a capability-versus-intent distinction, a Chapter 5 refinement rather than a new term.

Integrity and impact name nothing. “Is a conclusion’s lineage complete and acyclic,” “do two conclusions share an ancestor,” “if a premise is retracted, which conclusions break” ask the graph to be well-formed and to support impact analysis. They are the first questions that test the vocabulary’s shape rather than its contents, which makes them Step 7 (validation, Chapter 8) work more than Step 3. The one finding to record is that the provenance graph must be a DAG, which the first pass already surfaced from CQ 15.

From the neighbors force the genuinely new, higher-level terms. With Step 2’s reuse pass behind them, the “any claim,” “lines of evidence,” and “same study” questions add a layer above the individual artifacts: a Claim / Assertion superclass over Hypothesis, Premise, and Conclusion (the thing supports, contradicts, and refines all range over); an EvidenceLine grouping several pieces of evidence with a strength; and a Study / Investigation container over one question-to-conclusion cycle. Each also reconsiders v0.2’s flatter shape: v0.2 had Hypothesis, Premise, and Conclusion as unrelated siblings under no Claim parent, and Evidence wired straight to a claim with no line between.

In order of how much they reshape the model, the second pass’s additions are:

• Claim / Assertion — candidate superclass over Hypothesis, Premise, Conclusion
• EvidentialRelation — the reified support/contradict edge, with polarity, strength, asserter, and agent
• EvidenceLine — a grouping of evidence carrying a strength
• Study / Investigation — a container over one inquiry cycle
• StatisticalMethod — the deriver of uncertainty and credibility
• new states and outcomes: an assessment rejected, a claim retracted
• the inverse relations, read backward from existing ones

As with the first pass, this stops at naming. Whether a Claim superclass, an evidence line, or a study earns a place in the hierarchy, and whether the inverses are stored slots or derived, is Step 4 and Step 5 work, for Chapters 5 and 6. Chapter 8 will revisit the whole question set, original and surfaced, as the validation litmus test.

Reconsidered from v0.2

The harvest’s third move, and the reason it comes last: a term is only safely retired once every question is on the table, original and surfaced. With both passes run, v0.2 still has terms that no question asks for. A rebuild from the questions should reconsider these rather than carry them by habit. None is settled-as-dropped here — Step 3 only flags — but naming them keeps the rebuild honest: it prunes as well as accretes, which is the point of starting from the questions instead of from v0.2.

• status / ActStatus. v0.2’s enum for an act’s lifecycle phase. No question asks for it. The second pass’s gaps questions (“is a premise still accepted, or retracted?”) come closest, but they ask for a claim’s standing, which the States kind (grounded in CCO Stasis) answers, not an act’s lifecycle enum. A status enum and a Stasis state compete; choosing between them is a Chapter 5 decision, but the question set does not require the v0.2 enum.
• Ambiguity, Vagueness, Incompleteness, Aleatory. v0.2’s four fine-grained uncertainty natures. Both CQ 12 and the second pass’s “aleatory or epistemic?” ask only for the coarse split, so these fold into a single nature facet until a question needs the finer grain.
• The reuse mixins Nanopublication, DCATDataset, UncertaintySubject, URREFEvidence. v0.2 reused nanopublication, DCAT, and URREF by mixing in wrapper classes. Chapter 3 reuses them by URI through the prefix manifest instead, so the mixin classes are superseded rather than dropped for cause.
• The BFO/CCO wrapper classes (BFOEntity, InformationContentEntity, Act, and the rest). v0.2’s thin classes carried upper-ontology IRIs; Chapter 3’s grounding by class_uri makes them unnecessary. A mechanism change, recorded here for completeness.

Two more are not dropped but renamed or relabeled, and are corrected in the lists above: isOutputOf is carried as producedBy, and UncertaintyDerivation is a v0.2 class, not a new one.

What the list leaves unsettled

The point of the list is to be comprehensive, not resolved. Most of what two passes of close reading sharpened are genuine open choices, left open on purpose for Chapters 5 and 6. Two are not choices at all: the questions force them, and Chapter 5 only has to place them, so they are set apart at the end. And the reuse bind-later calls from the Step 2 passes belong on the same ledger.

• Evidence versus Premise. Two classes, one class with a status, or a subclass relation. CQ 4 (an acceptance outcome and a promotion link) and CQ 5 (a premise that must be a traversable node) jointly constrain the choice without settling it.
• Method: template or instance. The single decision behind CQ 8, 9, and 10; resolve it once and the three fall into place. It also fixes where tests lives (on the design act or the method) and whether tests splits into capability (can test) versus intent (designed to test).
• Uncertainty: slot or class. CQ 12’s “model, nature, parameters, derivation” is a structured bundle that strains a scalar slot.
• Specialized versus generic relations. Nearly every question wanted a named, typed edge (addresses, surfaces, groundedIn, promotedFrom, synthesizedFrom, executes, consumes, producedBy) that is semantically a specialization of the generic hasInput/hasOutput/derivedFrom. Which become real slots and which are generic-relation-plus-typed-range is a Chapter 6 question.
• Stored versus derived relations. A separate axis from the typing above: some edges may be computed rather than stored. competesWith can be asserted or derived from two hypotheses sharing an addresses question; the inverses (addressedBy, consumedBy, extractedInto, …) can be stored slots or reasoner-derived from their forward relation; and a hypothesis’s weight of evidence is computed from its support and contradict edges. Which are materialized is a Chapter 6 call.
• To reify or not. Support, derivation, and evidence-lines can stay as plain edges or become nodes that carry their own provenance. The questions that ask who said so, when, and how strongly push toward reification.
• The higher-level layer. Whether to add the candidates the second pass surfaced — a Claim superclass, evidence lines, a Study container, an explicit statistical-derivation method — or keep the flatter, artifact-by-artifact vocabulary. Each is a Chapter 5 call.
• Is Hypothesis mandatory in the chain? EXPO’s portable lesson (Step 2’s decline) was that some inquiry is exploratory, with no prior hypothesis. Whether the question-to-conclusion spine requires a Hypothesis node or lets evidence reach a conclusion without one is a Chapter 5 question about the core shape.
• Naming alignment. With CiTO adopted, supports/contradicts/ refines have reuse targets (cito:supports / cito:disputes or cito:refutes / cito:extends). Whether scimantic renames its relations to CiTO’s or keeps its own names and maps them with skos:closeMatch is a Chapter 5/6 call.
• Status enum versus Stasis state. v0.2 modeled an act’s standing as a status enum value; the rebuild’s States kind grounds the same idea in CCO Stasis. A slot-valued status or a reified state: the reconsidering surfaced the choice, and Chapter 5 makes it.
• Reuse bindings still deferred. Beyond the term and hierarchy choices above, the Step 2 passes left several bind-later calls open: SEPIO and Micropublications (cited as the closest models, not bound), OBI/OBCS with STATO weighed for the statistics, and URREF carried from Chapter 3. Each is revisited when the class or slot it would attach to actually lands.

The last two are not open questions: the competency questions force them, and Chapter 5 only has to place them in the hierarchy.

• Act as a real superclass. CQ 10, 14, and 15 quantify over acts generically, so Act has to be a shared supertype, not a reading-group label.
• Time as an interval. Acts are occurrents that unfold over time, so CQ 14’s “when” is a temporal region, not the instant createdAt silently assumed, which is simply false for an Experimentation that runs for days.

Next

The vocabulary is on the table, enlarged over two passes and trailing the new questions and the higher-level candidates the second pass surfaced. Chapter 5 takes N&M Step 4, sorting these terms into classes and arranging them into a hierarchy beneath the BFO and CCO categories Chapter 3 committed to — resolving the overlaps, the template-versus-instance and slot-versus-class choices, and the naming alignments this chapter was free to leave open.

Classes and Hierarchy

This chapter applies Step 4 of Ontology Development 101 (Noy & McGuinness, 2001) to scimantic.

ch04 produced the salient concepts bottom-up, by reading the competency questions. This chapter places them top-down, under the BFO and CCO categories Chapter 3 committed to. That is N&M’s combination approach, and it is where the schema starts to grow: ch04 was nearly free of code, but Step 4 turns the vocabulary into classes.

The work of the chapter is the ledger ch04 left unsettled. Those decisions are not independent, so the chapter takes them in dependency order: first the scaffold under BFO/CCO, then the claim spine (the core of the method), then method and act, then the reification questions, and last the higher-level layer that depends on all of them. Two decisions are slot-shaped rather than hierarchy-shaped (which named relations become real slots, and which are stored versus derived); those belong to Step 5 and wait for Chapter 6.

Anchoring to BFO and CCO

Every scimantic class ultimately subclasses one of the foundational kinds Chapter 3 committed to. Placing the harvest under them is mostly mechanical:

• Artifacts are information content entities (CCO Information Content Entity, under BFO continuant), falling into a few of CCO’s ICE kinds. The claims — hypotheses, evidence, results, conclusions — are Descriptive ICEs: content asserting what is or might be the case. A question is an ICE too, but interrogative rather than descriptive (it asks, it does not assert), so it grounds in the general ICE. The methods are Prescriptive ICEs (CCO’s directive branch): content prescribing what to do. Datasets and annotations are ICEs alongside them.
• Acts — the formations, searches, assessments, experiments, analyses — are planned acts (CCO Planned Act, under BFO occurrent).
• States are conditions grounded in CCO Stasis (the subject of the next section).
• Qualities (credibility, the uncertainty facets) are BFO qualities.
• Agents are CCO Agents.
• Temporal regions locate the occurrents in time (BFO temporal region).

Two placements here are forced by the questions, not chosen, and the chapter records them rather than deliberating them. CQ 10, 14, and 15 quantify over acts generically — what act produced this dataset, the acts in the lineage — so Act has to be a real shared supertype over the nine act classes, not a reading-group label. And CQ 14’s “when” is an interval: acts are occurrents that unfold over time, so an act is located at a TemporalInterval, not stamped with a single createdAt instant, which would be false for an experiment that runs for days. These are the scaffold the contested decisions hang on.

Dataset and Annotation make the class_uri side of that distinction concrete 5.1.1:

# scimantic-yaml-v3.yaml
# @@ 274,286 @@
  Dataset:
    class_uri: dcat:Dataset
    description: >-
      A dataset reused from W3C DCAT: the input to an analysis or
      experiment, or the output a result is drawn from.

  Annotation:
    class_uri: oa:Annotation
    description: >-
      An annotation on a source document, reused from the W3C Web
      Annotation model; an EvidenceExtraction draws a piece of
      Evidence from one.

The remaining foundational kinds and artifacts take their places — Agent grounded in CCO Agent 5.2.1 and an act’s TemporalInterval in BFO’s one-dimensional temporal region 5.2.2, Question under the general ICE 5.2.3, Result a Descriptive ICE 5.2.4, and SourceDocument a CCO Document 5.2.5 — the bearer evidence is drawn from, not the content — leaving the contested decisions the rest of the chapter settles:

# scimantic-yaml-v3.yaml
# @@ 189,223 @@
  Agent:
    subclass_of: cco:ont00001017
    description: >-
      A material entity that performs acts and bears responsibility
      for them — a researcher, group, or institution.

  TemporalInterval:
    subclass_of: obo:BFO_0000038
    description: >-
      The stretch of time an act occupies, with a beginning and an
      end rather than a single instant.

  Question:
    subclass_of: cco:ont00000958
    description: >-
      An information content entity expressing what an inquiry seeks
      to answer; the output of a QuestionFormation and the start of
      a provenance chain.

  Result:
    subclass_of: cco:ont00000853
    description: >-
      A finding produced by an Analysis; the input a ResultAssessment
      weighs in drawing a conclusion.

  SourceDocument:
    subclass_of: cco:ont00001298
    description: >-
      A document a LiteratureSearch surfaces and an Annotation marks
      up; the bearer a piece of Evidence is extracted from.

The claim spine

The core of the method is the chain from a question, through evidence and premises, to a hypothesis and a conclusion. Three of ch04’s open decisions shape it, and they lock together: how standing is modeled, what distinguishes evidence from a premise, and whether a hypothesis is mandatory. They are taken in that order because each constrains the next.

Standing as state, not status

v0.2 recorded an act’s lifecycle phase as an enum value on a status slot. The rebuild does not. An enum value is a scalar: it can say a premise is accepted, but it carries no interval over which the acceptance holds and no trace of the act that conferred it. Every standing the competency questions ask about is temporal and provenanced. CQ 4 returns evidence an assessment accepted; the second pass’s gaps questions ask whether a premise is still accepted or has been retracted, a question about an interval closed by a later act.

So scimantic models standing as a reified State, grounded in CCO’s Stasis: a condition that obtains over a TemporalInterval and points back to the act that established it and the agent who performed it. OpenState, AcceptedState, and RetractedState are subtypes of State, each attached to the entity it qualifies. They are kind-agnostic: the standing lives in the act that confers it and the interval it holds over, not in a class per claim type, so three adjudication standings cover every entity rather than one state each. This is the cross-cutting decision of the cluster: once standing is a state, the same three carry an open question, an accepted or retracted premise, a conclusion accepted in review and standing until refuted, and a method validated by execution. The next two decisions spend it.

In the schema, that is State and its three standings, each grounded in CCO Stasis 5.3.1:

# scimantic-yaml-v3.yaml
# @@ 160,187 @@
  State:
    abstract: true
    subclass_of: cco:ont00000819
    description: >-
      A condition that obtains over a temporal interval,
      established by an act. scimantic models standing as state
      rather than as an enum value.

  OpenState:
    is_a: State
    description: >-
      The standing of a claim awaiting adjudication: a question not
      yet answered, or a conclusion submitted but not yet accepted.

  AcceptedState:
    is_a: State
    description: >-
      The standing of a claim or method endorsed by an establishing
      act — evidence accepted as a premise, a conclusion accepted in
      review, or a method validated by a successful execution —
      holding until any retraction.

  RetractedState:
    is_a: State
    description: >-
      The standing of a claim or method whose acceptance has been
      withdrawn.

Evidence and Premise: one claim, two standings

When assessed evidence becomes a premise, is that a new class, a status on the old one, or a derivation? ch04 settled the framing: evidence and premise are the same claim at two epistemic stages, not one claim derived from another. With standing now modeled as state, the resolution is direct.

A piece of evidence is an information content entity: a claim about the world, under CCO’s Descriptive Information Content Entity. An EvidenceAssessment weighs it for credibility and, if it passes, confers an AcceptedState. The premise is that same claim, now bearing the accepted state. There is no second class and no derivedFrom edge 5.4.3; promotedFrom is identity-preserving, a transition in standing rather than the creation of a new node. CQ 4 then filters evidence by a queryable state, and CQ 5 — which needs a premise to be a node you can traverse from into HypothesisFormation — is satisfied because the premise is the evidence node itself, reached with no indirection.

Step 4 places the pieces — the Evidence claim, the AcceptedState it comes to bear, and the EvidenceAssessment that confers it — but the promotion between them is relational: a claim bearing a state, an act conferring it. Those are slots, so the wiring that makes the promotion queryable, and promotedFrom a transition rather than a phrase, is Step 5 work that lands in Chapter 6. The listings here show the participating classes; the slots that carry a promotion come with the rest of the slot work. This is also why the three pieces sit in three different listings below — the claim layer, the states, and the acts — rather than in one place: nothing yet binds them into a single view.

One distinction still earns a name. Accepted is a state, the outcome of assessment. Premise is better read as a role, in BFO’s sense of a realizable entity: a claim plays the premise role when it serves as an input to a particular hypothesis formation, and the same claim can be a premise in one argument and not in another. scimantic models acceptance as the Stasis state and premise-hood as the role an accepted claim realizes when a HypothesisFormation takes it as input. The claim is one node; its acceptance and its use are recorded without cloning it.

Hypothesis is optional

Does the chain require a hypothesis? The seeded vocabulary runs Question → Hypothesis → Evidence → Conclusion, which reads as though every conclusion descends from a hypothesis. Chapter 2’s scope says otherwise: it admits a literature-only meta-analysis, and the lesson scimantic took from EXPO — the experiment ontology Chapter 4 declined to reuse, because it builds on SUMO rather than the BFO/CCO base — is that some inquiry is exploratory, with no prior hypothesis to test. Forcing a Hypothesis node into every lineage would mismodel exactly the inquiry the domain claims to cover.

So a Conclusion may trace to its premises and evidence with or without an intervening Hypothesis. The hypothesis is a node that can sit in a lineage, not a required link in it.

This leaves a consequence for the higher-level layer to collect. If the spine must carry supports, contradicts, and refines whether or not a hypothesis is present, those relations cannot range on Hypothesis alone; they need a shared parent over everything a claim relation can touch — hypothesis, premise, conclusion alike. The pressure for a Claim superclass starts here, and the chapter settles it when it reaches that layer.

The claim layer is a single abstract Claim, grounded in CCO’s Descriptive Information Content Entity 5.4.2 by subclass_of 5.4.1, over Hypothesis, Evidence, and Conclusion:

# scimantic-yaml-v3.yaml
# @@ 45,78 @@
  Claim:
    abstract: true
    subclass_of: cco:ont00000853
    slots:
      - supports
      - contradicts
      - refines
    description: >-
      An information content entity that asserts something about the
      world. The shared parent of the claim relations, so supports,
      contradicts, and refines apply whether or not a hypothesis is
      present.

  Hypothesis:
    is_a: Claim
    description: >-
      A conjectured claim a study may be designed to test. Optional
      in the chain, since exploratory inquiry has none.

  Evidence:
    is_a: Claim
    description: >-
      A claim offered as bearing on another. It becomes a Premise
      once an EvidenceAssessment accepts it, the same node now
      carrying an AcceptedState.

  Conclusion:
    is_a: Claim
    description: >-
      A claim drawn from premises and evidence, with or without an
      intervening hypothesis.

It carries the three claim relations, mapped to CiTO and bound for reification into an EvidentialRelation when this chapter reaches it 5.5.1:

# scimantic-yaml-v3.yaml
# @@ 288,307 @@
slots:

  supports:
    range: Claim
    exact_mappings:
      - cito:supports
    description: Asserts that one claim bears positively on another.

  contradicts:
    range: Claim
    exact_mappings:
      - cito:disputes
    description: Asserts that one claim bears negatively on another.

  refines:
    range: Claim
    exact_mappings:
      - cito:extends
    description: Asserts that one claim refines or extends another.

With the spine fixed, the next cluster turns to method and act.

Method and act

Three questions (CQ 8, 9, and 10) turn on a single decision: is an experimental method a reusable template, or a thing made fresh for each study? ch04 named this the chapter’s biggest single tension. It resolves the way Evidence and Premise did, by dissolving the dichotomy.

A method is a plan specification: a Prescriptive information content entity (CCO’s directive branch) that prescribes how to carry out an act. As an ICE it is a continuant, existing independently of any particular run, and an act realizes it. Experimentation realizes an ExperimentalMethod; Analysis realizes an AnalyticalMethod. That is the reusable, one-to-many shape CQ 9 (“what experiments executed a given method”) and CQ 10 (“what act applied a method”) require: a method is executed by many acts, and “act” generalizes across experimentation and analysis, which pushes ExperimentalMethod up under a general Method. A generic template and a study-specific protocol are then both plan specifications at different grain, not two classes, and the template-versus-instance framing falls away.

What does not live on the method is intent. A reusable method cannot itself be “designed to test hypothesis H,” because the same method serves different hypotheses in different studies. The thing designed to test H is the act that designed it. So tests, the prospective intent CQ 8 asks for, attaches to DesignOfExperiment, not to Method. CQ 8’s “methods designed to test H” becomes a traversal: from the hypothesis, back along tests to the design act, forward to the method it produced. The method’s type-level capability (the kind of hypothesis it can test) is a separate affordance no question demands, so it waits.

Placing tests on the design act keeps it the distinct verb ch04 insisted on. tests is prospective intent, carried by a design act before the evidence is in; supports and contradicts are retrospective verdicts, carried by the evidence after. They never collapse, because they sit on different nodes: an act and a claim.

Two threads from the spine run through here. A method is realized by an act exactly as a premise’s role is realized by a hypothesis formation: the schema leans on BFO’s one machinery for realizable entities in both places. And the State pattern reaches methods too, a method gaining an AcceptedState when a successful execution validates it, as a premise gains one when an assessment accepts it.

Which CCO relation executes should map to, rather than a freshly minted slot, is a Step 5 question that waits with the other slot decisions for Chapter 6.

Both halves are in the schema now. The Method plan specifications, grounded in CCO’s Prescriptive ICE 5.6.1, with ExperimentalMethod and AnalyticalMethod under the general Method:

# scimantic-yaml-v3.yaml
# @@ 139,158 @@
  Method:
    abstract: true
    subclass_of: cco:ont00000965
    description: >-
      A prescriptive information content entity that prescribes how
      to carry out an act, realized by the acts that execute it.
      Exists independently of any single run.

  ExperimentalMethod:
    is_a: Method
    description: >-
      A method prescribing how to carry out an experiment; realized
      by an Experimentation act and designed by a DesignOfExperiment.

  AnalyticalMethod:
    is_a: Method
    description: >-
      A method prescribing how to analyze data to produce a result;
      realized by an Analysis act.

And the nine acts that realize them, under the Act supertype 5.7.1:

# scimantic-yaml-v3.yaml
# @@ 80,137 @@
  Act:
    abstract: true
    subclass_of: cco:ont00000228
    description: >-
      An agentive planned process that produces or transforms
      artifacts. The shared supertype CQ 10, 14, and 15 quantify
      over.

  EvidenceAssessment:
    is_a: Act
    description: >-
      Weighs a piece of evidence for credibility and, on
      acceptance, confers an AcceptedState on it.

  QuestionFormation:
    is_a: Act
    description: >-
      The act of forming a question; its output an open Question.

  LiteratureSearch:
    is_a: Act
    description: >-
      A search over source documents that addresses motivating
      questions and may surface new ones.

  EvidenceExtraction:
    is_a: Act
    description: >-
      The act of extracting a piece of Evidence from an annotation
      on a source document.

  HypothesisFormation:
    is_a: Act
    description: The act of synthesizing a Hypothesis from its premises.

  DesignOfExperiment:
    is_a: Act
    description: >-
      The act of designing an experimental method to test a
      hypothesis; the bearer of the prospective tests intent.

  Experimentation:
    is_a: Act
    description: >-
      The act that executes an experimental method, realizing its
      plan.

  Analysis:
    is_a: Act
    description: >-
      The act that applies a method to data to produce a result.

  ResultAssessment:
    is_a: Act
    description: >-
      The act of assessing a result and drawing a conclusion from
      it.

With method and act placed, the next cluster asks when a value or an edge should become a node of its own: the reification questions behind uncertainty and the evidential relation.

Reification: when an edge becomes a node

Some of what the questions ask for is not a thing but a relationship, and a relationship can be modeled two ways: as a bare edge between two nodes, or as a node of its own that both endpoints point to. Promoting an edge to a node is reification, and it has a cost, an extra node on every instance of the relationship. So the rule is not to reify everything, nor nothing, but to reify on demand: a relationship becomes a node exactly when a question asks for a property of the relationship itself, not just of its endpoints.

scimantic has already reified its core relationships without naming it. Every transformation in the method is an act, and an act is a node that carries its own agent, time, inputs, and outputs, so the deriving of a result, the forming of a hypothesis, and the assessing of evidence are nodes already. The reification question is only about the relationships the act model leaves as edges.

One of them earns a node. supports, contradicts, and refines are edges from a claim to the claim it bears on, and for most purposes that is enough. But the second pass asks more: for a given support, which act and agent established it, when, and with what strength. Those are properties of the support itself, which a bare edge has nowhere to hold. So the support becomes an EvidentialRelation, a node reifying a cito-typed link between two claims and carrying its polarity (the cito mapping), a strength, the asserting act, and the agent. It is a Descriptive ICE in its own right: a recorded claim that one claim bears a given relation to another.

The other relationships stay edges. derivedFrom runs between artifacts, but every derivation already has an act behind it that holds the agent and the inputs, and reifying the edge as well would record the same provenance twice. The evidence line, which groups several pieces of evidence under one strength, is a reification too, but it belongs to the higher-level layer — the chapter’s capstone — so it is introduced there, not here.

In the schema, that reified node is the EvidentialRelation 5.8.1:

# scimantic-yaml-v3.yaml
# @@ 225,231 @@
  EvidentialRelation:
    subclass_of: cco:ont00000853
    description: >-
      A reified claim-to-claim relation: a Descriptive ICE carrying a
      cito-typed polarity, a strength, the asserting act, and the
      agent.

Uncertainty as a model, not a number

The starting vocabulary carried uncertainty as a number on a result. CQ 12 asks for more than a number: what is the uncertainty model for a given result, and how was it derived? A model is a family (Gaussian, bootstrap, posterior), its parameters, a confidence level, and a nature (aleatory or epistemic). A scalar slot cannot hold that bundle. So uncertainty is a class, the same reification move the last section made: a value the questions interrogate becomes a node.

Two things hide in that class, and keeping them apart is the decision. The uncertainty is a quality of the result: the result is uncertain, and that quality inheres in it.

The model is information that quantifies the quality: the choice of family and the fitted parameters are content about the uncertainty, not the uncertainty itself. So scimantic models an UncertaintyModel, a Descriptive ICE that quantifies the result’s uncertainty quality, rather than loading structure onto a bare quality. The quality stays a BFO Quality, as Chapter 3 grounded it; the model is the ICE that describes it.

Chapter 3 committed to URREF in principle for exactly this: the model’s nature facet, aleatory versus epistemic, is URREF’s distinction. But nothing binds in this chapter. nature is itself a Step-5 slot (Chapter 6), and URREF’s namespace is still the provisional placeholder Chapter 3 flagged — so the UncertaintyModel carries no urref: mapping here. scimantic adopts the distinction now and defers its encoding — a urref: mapping, or a plain enum if URREF’s IRIs never settle — to Chapter 6. And it would be a mapping target, not a grounding: scimantic stays grounded in BFO/CCO and points out to URREF the way the claim relations point to CiTO, on the deferred footing Chapter 3 set.

CQ 12’s second half, how was it derived, is a relationship the reification policy sends to an act. By what statistical method were the result’s uncertainty and credibility computed, from what inputs, by which agent? Those are properties of a derivation, so the derivation is an act: a deriving act applying a StatisticalMethod, which is a Method in the sense the last cluster fixed, a Prescriptive ICE realized by the act that carries it out. Credibility is the simpler sibling of uncertainty, a graded quality whose provenance is the EvidenceAssessment that produced it, with no structured model of its own.

In the schema, the uncertainty cluster is two BFO qualities 5.9.1 — Uncertainty and Credibility — the UncertaintyModel 5.9.2 that quantifies the first, and the StatisticalMethod that derives them:

# scimantic-yaml-v3.yaml
# @@ 233,258 @@
  Uncertainty:
    subclass_of: obo:BFO_0000019
    description: >-
      A quality of a result quantifying how much it could vary;
      borne by the result, quantified by an UncertaintyModel.

  Credibility:
    subclass_of: obo:BFO_0000019
    description: >-
      A graded quality of a piece of evidence expressing how far it
      can be relied on; conferred by an EvidenceAssessment.

  UncertaintyModel:
    subclass_of: cco:ont00000853
    description: >-
      A Descriptive ICE that quantifies a result's uncertainty
      quality: a family, its parameters, a confidence level, and a
      nature (aleatory or epistemic).

  StatisticalMethod:
    is_a: AnalyticalMethod
    description: >-
      An analytical method prescribing how to derive a result's
      uncertainty and credibility from data.

With reification settled, what remains is the layer above the individual artifacts: whether the evidence line, the Claim superclass the spine pressed for, and a Study container earn a place. That is the higher-level layer, and it is the last cluster.

The higher-level layer

The last cluster asks whether anything sits above the individual artifacts, or whether the flatter, artifact-by-artifact vocabulary is enough. ch04 surfaced three candidates from the neighbors questions. One — the Claim superclass — the spine already settled and the schema already has: the neighbors question (given any claim, hypothesis, premise, or conclusion, what supports and what challenges it?) only confirms why a queryable parent had to exist, and Claim is the parent an EvidentialRelation links. The other two are new, and each is demanded.

An EvidenceLine. The reification section deferred this grouping to here. The neighbors ask how many independent lines of evidence back a conclusion, and how strong is each? A query cannot count lines or weigh them unless a line is a thing. So an EvidenceLine is the reified grouping the policy pointed to: a Descriptive ICE collecting several pieces of evidence under one strength, asserting their joint bearing on a claim. This is the closest scimantic comes to an off-the-shelf model. SEPIO names an evidence line for exactly this, and Micropublications reifies evidence the same way; both become mapping targets on the deferred footing Chapter 3 set for SEPIO, citing the pattern and binding the IRIs once they settle.

A Study. The neighbors ask which acts and artifacts belong to the same study? That needs a study to be a node the rest belong to. So a Study, or Investigation, is a container over one question-to-conclusion cycle. Unlike the other two it sits on the act side, not the artifact side: a planned process whose parts are the formations, searches, experiments, and analyses of one inquiry, grounded in CCO’s planned-process layer. OBI offers an investigation class for the same idea, and OBCS or STATO a home for the StatisticalMethod the reification section named; both stay candidate mappings, deferred until scimantic mints the classes, as the second pass left them.

Each was forced by a neighbors question rather than chosen for elegance: EvidenceLine discharges the reification the earlier section deferred, and Study gives the acts and artifacts of one inquiry a container to belong to. With them placed — and Claim already settled — the structural work of Step 4 is done.

In the schema, the higher-level layer adds EvidenceLine 5.10.1 and the Study container 5.10.2 (the Claim superclass the spine pressed for is already in place):

# scimantic-yaml-v3.yaml
# @@ 260,272 @@
  EvidenceLine:
    subclass_of: cco:ont00000853
    description: >-
      A Descriptive ICE grouping several pieces of evidence under
      one strength and asserting their joint bearing on a claim.

  Study:
    subclass_of: cco:ont00000228
    description: >-
      A planned process whose parts are the formations, searches,
      experiments, and analyses of one question-to-conclusion cycle.

Next

Step 4 is settled. Every term has a class, and every class a place under BFO and CCO. The decisions ch04 left open have answers, the forced placements are made, and the higher-level layer is in.

What remains is slot work, and it is Step 5. Chapter 6 settles three questions this chapter left to it:

• which of the named relations become real slots, and which are a generic relation with a typed range;
• whether each inverse is stored or derived by the reasoner;
• whether scimantic renames its claim relations to CiTO’s, or keeps its own and maps them with skos:closeMatch.

That is where the classes this chapter shaped get their properties.

Slots

This chapter applies Step 5 of Ontology Development 101 (Noy & McGuinness, 2001) to scimantic.

ch05 placed the classes; this chapter gives them properties. For scimantic that means, overwhelmingly, N&M’s fourth kind — relationships to other individuals. The schema models the scientific method as provenance, and provenance is relational: which act produced a result, which agent performed it, what evidence supports a conclusion, which method an experiment executed. A few slots are intrinsic (a relation’s strength, an uncertainty’s confidence level), but the spine of Step 5 is wiring the classes together.

That wiring is where ch04’s deferred implementation questions and ch05’s slot-shaped promises come due. They are not independent — every relation faces the same handful of questions: how to type it, whether to give it an inverse, whether to store or derive it, how many values it takes, and what to call it. So the chapter settles those as policies first, then walks the relations cluster by cluster and applies them.

The policies

scimantic’s relations are many, but they divide along a few axes that recur for every one of them. Settling the axes once, up front, keeps the per-relation walk that follows mechanical.

Name the relation; don’t genericize it

LinkML lets a relation be either a named slot with its own domain, range, and mappings, or a single generic relation whose meaning rides on a typed range. scimantic names them. hasInput, supports, tests, and performedAt each become their own slot, not facets of one relatedTo. A named slot is self-documenting, carries its own CiTO/CCO mapping, and is directly queryable — what supports this claim is a slot traversal, not a filtered scan of a polymorphic edge. The generic option is held in reserve for a genuinely polymorphic relation, of which scimantic has none. This is N&M’s own counsel on domain and range — name the property and pin it to the most general class that can bear it:

Inverses come from upstream, not from new slots

Every relation has a reverse reading — what produced this result is the inverse of what this act produced. scimantic declares the forward direction only, and leaves the reverse to the upstream owl:inverseOf declarations its grounding inherits (mostly CCO’s) plus SPARQL’s ^prop path. It mints a second, explicit inverse slot only where a consumer must traverse the reverse direction without a reasoner — for instance, where a downstream consumer is built around it. The default halves the slot count and avoids the drift v0.2 carried, where isOutputOf was an explicit slot but isInputOf was derived, and the two could disagree.

Store the edge; derive the aggregate

A provenance edge and the act, agent, and interval behind it are primary facts — scimantic stores them. A roll-up computed from those facts is not: a hypothesis’s weight of evidence is a function of its supports/contradicts edges, and whether a premise is still accepted is a function of its state intervals and any later retraction. Materializing those as stored slots would let them drift from the edges they summarize, so scimantic derives them — by rule or SPARQL — rather than storing them. The line is: store what an act asserts; derive what a query computes.

Cardinality from the competency questions

How many values a slot takes is read off the questions, not guessed. A Conclusion draws on one or more premises, so the relation into it is multivalued; an Act occupies exactly one TemporalInterval, so its time slot is single and required; a Hypothesis is optional in a lineage (ch05), so the relation that would reach it cannot be required. The default is single-valued and optional, tightened to multivalued or required only where a competency question demands a collection or a mandatory filler. (N&M file cardinality under Step 6; scimantic decides it alongside the slot, since the question that motivates a slot usually fixes its multiplicity too.)

Name for scimantic; map to the standard

Several relations have an upstream analogue: the claim relations align with CiTO, act participation with CCO’s process roles. scimantic keeps its own names — supports, not cito:supports — and carries the upstream term as an exact_mappings (the CiTO mappings are already on supports/contradicts/refines from ch05). A domain-fit name reads better in the schema and in instance data, and the mapping preserves the interoperability a rename would buy, without adopting another vocabulary’s labels wholesale. The rule generalizes: name the relation for scimantic, map it out.

With the policies set, the rest of the chapter is application. It takes the relations in the order the classes came: the claim relations first (the spine), then act participation, then the state attachments, and last the fields the reified classes carry.

The claim relations

The spine’s three relations — supports, contradicts, and refines — were minted in ch05 as a tracer, carrying only a range and their CiTO mappings. Step 5 gives them the rest of their facets, and they are the clearest place to watch the policies bite.

Range is Claim, not its subtypes. A claim relation runs claim to claim, and any kind can sit at either end: evidence supports a conclusion, a conclusion refines a hypothesis, one premise contradicts another. The range is therefore the shared parent Claim — the superclass the spine pressed ch05 into minting — not an enumeration of Hypothesis, Evidence, and Conclusion. That is N&M’s range rule:

Multivalued, optional. One claim can bear on many: a single piece of evidence supports several conclusions; a conclusion refines a string of hypotheses. So each relation is multivalued. None is required — a claim need not support, contradict, or refine anything.

No inverse slot. What contradicts this claim is the reverse of contradicts, and the policy leaves it to a query — SPARQL ^contradicts, not a stored isContradictedBy. The reverse is derivable, so scimantic does not double the slot.

Stored edges, derived aggregate. The edges are stored facts. The roll-up they feed is not: a hypothesis’s weight of evidence — how its supporting evidence nets against its contradicting evidence — is computed from these edges on demand, never materialized, so it cannot drift from them.

Step 5 adds exactly one facet to each — the cardinality — over the bare slots ch05 minted:

--- scimantic-yaml-v3
+++ scimantic-yaml-v4
@@ -288,20 +288,23 @@
 slots:
 
   supports:
     range: Claim
+    multivalued: true
     exact_mappings:
       - cito:supports
     description: Asserts that one claim bears positively on another.
 
   contradicts:
     range: Claim
+    multivalued: true
     exact_mappings:
       - cito:disputes
     description: Asserts that one claim bears negatively on another.
 
   refines:
     range: Claim
+    multivalued: true
     exact_mappings:
       - cito:extends
     description: Asserts that one claim refines or extends another.

When the edge needs provenance, it reifies. A bare supports edge records that one claim bears on another; it has nowhere to hold who asserted the support, when, or with what strength. When a question asks for those — and the second pass does — the edge becomes an EvidentialRelation, the node ch05 placed for exactly this. The bare slot and the reified node are two readings of one link: the slot for the common case, the node when the relation itself carries facts. EvidentialRelation’s own fields wait for the chapter’s last cluster.

Act participation

The acts are where most of the provenance lives, so they carry most of the relations. Four attach in this cluster; the two busiest — the input and output edges — wait on a range question the section after settles.

agent and performedAt attach at Act. Every act has an agent who performed it and an interval it ran over, so both sit at the shared Act supertype and all nine acts inherit them — N&M’s rule:

agent ranges on Agent, multivalued (collaborative science gives an act more than one), mapped to CCO’s has agent (cco:ont00001833). performedAt ranges on TemporalInterval — ch05’s “when is an interval, not an instant” — mapped to BFO’s occupies temporal region (obo:BFO_0000199).

tests attaches at DesignOfExperiment. ch05 settled that the prospective intent to test a hypothesis rides on the design act, not the method it produces, so tests (range Hypothesis) attaches there alone — no other act bears it. It is scimantic’s own: the upstream vocabularies have no clean term for prospective experimental intent, so it carries no mapping.

executes attaches at Experimentation and Analysis. An act that runs a method executes it (range Method); only the two method-running acts bear it, and they share no parent below Act, so it attaches at each. Its mapping is the chapter’s neatest catch: the intuitive name is “realizes”, but BFO realizes is reserved for realizable entities — roles and dispositions — while a Method is content (a Prescriptive ICE). The right relation is CCO’s prescribed by (cco:ont00001920), whose range is exactly Prescriptive ICE: the act is prescribed by the method’s plan specification.

The input and output edges remain. They are the acts’ busiest relations — the lineage questions (CQ 14, 15) walk them — but their fillers are diverse (a Dataset, a Result, an Annotation, a Method), with no tight common class to range over. How to range a relation whose fillers span the schema is the open question, taken up next.

Ranging the input and output edges

hasInput and hasOutput are the relations the lineage questions walk — what act produced this dataset, the acts feeding a conclusion — so they must be single generic relations on Act, not a thicket of per-act slots a lineage query would have to union. That is the reasoning that made Act a generic supertype, and it maps straight onto CCO’s own generic has input (cco:ont00001921) and has output (cco:ont00001986).

The catch is the range. An act’s inputs and outputs span the schema — a Dataset, a Result, an Annotation, a Method, a Claim — with no single parent below “entity” to range over. N&M warns against both horns:

scimantic threads it with an any_of union: the base range enumerates the artifact classes an act can touch, covering every filler without inventing a near-THING superclass to retrofit onto ch05’s hierarchy. The precise per-act range — Analysis.hasInput is a Dataset, EvidenceExtraction.hasInput an Annotation — is a slot_usage refinement, and Chapter 7’s central worked example.

The cluster’s six slots, with their CCO/BFO mappings glossed:

--- scimantic-yaml-v4
+++ scimantic-yaml-v5
@@ -79,10 +79,15 @@
 
   Act:
     abstract: true
     subclass_of: cco:ont00000228
+    slots:
+      - agent
+      - performedAt
+      - hasInput
+      - hasOutput
     description: >-
       An agentive planned process that produces or transforms
       artifacts. The shared supertype CQ 10, 14, and 15 quantify
       over.
 
@@ -113,22 +118,28 @@
     is_a: Act
     description: The act of synthesizing a Hypothesis from its premises.
 
   DesignOfExperiment:
     is_a: Act
+    slots:
+      - tests
     description: >-
       The act of designing an experimental method to test a
       hypothesis; the bearer of the prospective tests intent.
 
   Experimentation:
     is_a: Act
+    slots:
+      - executes
     description: >-
       The act that executes an experimental method, realizing its
       plan.
 
   Analysis:
     is_a: Act
+    slots:
+      - executes
     description: >-
       The act that applies a method to data to produce a result.
 
   ResultAssessment:
     is_a: Act
@@ -306,5 +317,70 @@
     range: Claim
     multivalued: true
     exact_mappings:
       - cito:extends
     description: Asserts that one claim refines or extends another.
+
+  agent:
+    range: Agent
+    multivalued: true
+    exact_mappings:
+      - cco:ont00001833
+    description: The agent or agents who performed an act.
+
+  performedAt:
+    range: TemporalInterval
+    exact_mappings:
+      - obo:BFO_0000199
+    description: The temporal interval an act occupies.
+
+  tests:
+    range: Hypothesis
+    description: >-
+      The hypothesis a DesignOfExperiment is designed to test:
+      prospective intent, carried by the design act rather than the
+      method it produces.
+
+  executes:
+    range: Method
+    exact_mappings:
+      - cco:ont00001920
+    description: >-
+      The method an act carries out; the act is prescribed by the
+      method's plan specification.
+
+  hasInput:
+    multivalued: true
+    any_of:
+      - range: Claim
+      - range: Question
+      - range: Result
+      - range: Method
+      - range: Dataset
+      - range: Annotation
+      - range: SourceDocument
+    exact_mappings:
+      - cco:ont00001921
+    description: >-
+      An artifact an act consumes; ranged broadly over the schema's
+      artifacts here, narrowed per-act in Chapter 7.
+
+  hasOutput:
+    multivalued: true
+    any_of:
+      - range: Claim
+      - range: Question
+      - range: Result
+      - range: Method
+      - range: Dataset
+      - range: Annotation
+      - range: SourceDocument
+    exact_mappings:
+      - cco:ont00001986
+    description: >-
+      An artifact an act produces; ranged broadly here, narrowed
+      per-act in Chapter 7's facets.

With act participation wired, the next cluster turns to the state attachments.

State attachment

ch05 reified standing as a State, grounded in CCO’s Stasis — a process over which a claim holds an unchanging condition. Step 5 wires the three relations that make a state a queryable node.

A state records whose standing it is, which act set it, and over what interval it holds, so all three slots attach at the shared State supertype and the standings inherit them:

• qualifies ranges on Claim or Method — the two things that bear a standing (a claim accepted or open, a method validated). It is scimantic’s own: a Stasis presumes independent continuants endure, but scimantic’s bearers are information content entities, so no upstream relation fits cleanly — the nearest, BFO has participant, is too generic to claim.
• establishedBy ranges on Act, mapped to CCO’s caused by (cco:ont00001819): a state, itself a process, is caused by the act that conferred it.
• occursOver ranges on TemporalInterval, mapped to BFO’s occupies temporal region (obo:BFO_0000199) — the same relation performedAt uses, because a State is a Stasis process and occupies its interval exactly as an act does.

The agent is not a fourth slot. The act that established a state already carries its agent, so who set this standing is derived — establishedBy, then the act’s agent — not stored twice.

promotedFrom is derived, not a slot. ch05’s evidence-to-premise promotion is identity-preserving: the same claim acquires an AcceptedState, no new node, no edge — so there is nothing to store. What was this premise promoted from is answered by reading the claim’s states (it gained an AcceptedState, conferred by an EvidenceAssessment), a query over qualifies and establishedBy — exactly the stored-versus-derived line the policies drew.

--- scimantic-yaml-v5
+++ scimantic-yaml-v6
@@ -170,10 +170,14 @@
 
   State:
     abstract: true
     subclass_of: cco:ont00000819
+    slots:
+      - qualifies
+      - establishedBy
+      - occursOver
     description: >-
       A condition that obtains over a temporal interval,
       established by an act. scimantic models standing as state
       rather than as an enum value.
 
@@ -382,5 +386,27 @@
     exact_mappings:
       - cco:ont00001986
     description: >-
       An artifact an act produces; ranged broadly here, narrowed
       per-act in Chapter 7's facets.
+
+  qualifies:
+    any_of:
+      - range: Claim
+      - range: Method
+    description: >-
+      The claim or method whose standing this state records — the
+      entity it qualifies.
+
+  establishedBy:
+    range: Act
+    exact_mappings:
+      - cco:ont00001819
+    description: The act that established this state.
+
+  occursOver:
+    range: TemporalInterval
+    exact_mappings:
+      - obo:BFO_0000199
+    description: The interval over which this state holds.

With standing wired, the last cluster turns to the fields the reified classes carry — the evidential relation, the uncertainty model, the evidence line, and the study.

The reified fields

Four of the classes ch05 placed are reifications: each turns a relationship or a description into a node so it can carry its own provenance. Where supports is a bare claim-to-claim edge, an EvidentialRelation is that edge promoted to a node — and a node has to name its own endpoints. So it carries a subject and an object (the two claims), a polarity for which way it bears, a strength, and an assertedBy pointing at the act that made the assertion. Agent and time aren’t repeated on the relation: they hang on that act, reached through assertedBy. As the claim-relations cluster noted, the bare slot and the reified node are two readings of one fact — the lightweight edge for the common case, the node when the assertion’s own provenance is what you need to record.

Both the bare slot and the reified node relate a claim to a claim — domain and range alike are Claim. That raises a question neither domain/range nor a facet can answer: may a claim bear on itself, and does the bearing run both ways? Whether refines is irreflexive and asymmetric, contradicts symmetric, supports neither — that is a per-relation choice, deferred to Chapter 7, where LinkML’s relational slot characteristics can state it.

Enumerate what’s closed; leave open what isn’t

polarity and nature get LinkML enums; family stays a string. The test is whether the value space is closed. Polarity has exactly three members, and they are the claim relations — so EvidentialPolarity’s permissible values are supports / contradicts / refines, each carrying the same CiTO meaning as the bare slot it mirrors. The reified polarity and the lightweight edge then agree by construction, not by a parallel kept up by hand. nature is the aleatory-versus-epistemic split — irreducible randomness versus reducible ignorance — closed, but with no settled IRI: it’s a plain enum, and the URREF grounding flagged in Chapter 3 stays deferred. family — Gaussian, bootstrap, a posterior draw — is open-ended; enumerating it would be false precision, so it remains an open string.

One strength, shared and still unbounded

strength is defined once and referenced by both EvidentialRelation and EvidenceLine: the strength of a bearing reads the same whether the bearing is a single relation or a line pooling several pieces of evidence under one weight. It is a plain float here, as is UncertaintyModel’s confidenceLevel. Their scales and bounds — strength on what interval, confidence in [0, 1] — are facets, which N&M make Step 6 work; Chapter 7 sets them. UncertaintyModel also carries a quantifies edge to the Uncertainty quality it models, so the descriptive node and the BFO quality it describes are linked, not merely co-present.

A study has occurrent parts

Study stands for a whole question-to-conclusion cycle, so its one slot is hasPart, ranging over Act. The slot maps to BFO’s has occurrent part (6.4.1), not the general has part (BFO_0000051): a study is a process and its parts are processes, so the occurrent-specific, transitive relation is the exact one — generic parthood would drop the commitment that these parts are themselves unfoldings in time.

--- scimantic-yaml-v6
+++ scimantic-yaml-v7
@@ -238,14 +238,21 @@
       up; the bearer a piece of Evidence is extracted from.
 
   EvidentialRelation:
     subclass_of: cco:ont00000853
+    slots:
+      - subject
+      - object
+      - polarity
+      - strength
+      - assertedBy
     description: >-
-      A reified claim-to-claim relation: a Descriptive ICE carrying a
-      cito-typed polarity, a strength, the asserting act, and the
-      agent.
+      A reified claim-to-claim relation between a subject and an
+      object claim: a Descriptive ICE carrying a cito-typed
+      polarity, a strength, and the asserting act, through which
+      the agent and time are reached.
 
   Uncertainty:
     subclass_of: obo:BFO_0000019
     description: >-
@@ -259,10 +266,16 @@
       can be relied on; conferred by an EvidenceAssessment.
 
   UncertaintyModel:
     subclass_of: cco:ont00000853
+    slots:
+      - quantifies
+      - family
+      - parameters
+      - confidenceLevel
+      - nature
     description: >-
       A Descriptive ICE that quantifies a result's uncertainty
       quality: a family, its parameters, a confidence level, and a
       nature (aleatory or epistemic).
 
@@ -273,17 +286,23 @@
       uncertainty and credibility from data.
 
   EvidenceLine:
     subclass_of: cco:ont00000853
+    slots:
+      - members
+      - strength
+      - bearsOn
     description: >-
       A Descriptive ICE grouping several pieces of evidence under
       one strength and asserting their joint bearing on a claim.
 
   Study:
     subclass_of: cco:ont00000228
+    slots:
+      - hasPart
     description: >-
       A planned process whose parts are the formations, searches,
       experiments, and analyses of one question-to-conclusion cycle.
 
@@ -408,5 +427,109 @@
   occursOver:
     range: TemporalInterval
     exact_mappings:
       - obo:BFO_0000199
     description: The interval over which this state holds.
+
+  subject:
+    range: Claim
+    description: >-
+      The claim that bears on another in an evidential relation.
+
+  object:
+    range: Claim
+    description: >-
+      The claim borne upon in an evidential relation.
+
+  polarity:
+    range: EvidentialPolarity
+    description: >-
+      Which cito-typed direction the relation takes — supports,
+      contradicts, or refines.
+
+  strength:
+    range: float
+    description: >-
+      How strongly the bearing holds; an unbounded float here, with
+      scale and bounds set in Chapter 7's facets. Shared by
+      EvidentialRelation and EvidenceLine.
+
+  assertedBy:
+    range: Act
+    description: >-
+      The act that asserted this relation; its agent and time are
+      reached through the act.
+
+  quantifies:
+    range: Uncertainty
+    description: The uncertainty quality this model quantifies.
+
+  family:
+    range: string
+    description: >-
+      The distribution or method family — Gaussian, bootstrap, and
+      so on. An open string, not enumerated.
+
+  parameters:
+    range: string
+    multivalued: true
+    description: >-
+      The model's parameters; free strings here, with structured
+      typing left to a later increment.
+
+  confidenceLevel:
+    range: float
+    description: >-
+      The confidence level the model reports, e.g. 0.95; its bounds
+      set in Chapter 7's facets.
+
+  nature:
+    range: UncertaintyNature
+    description: Whether the uncertainty is aleatory or epistemic.
+
+  members:
+    range: Evidence
+    multivalued: true
+    description: >-
+      The pieces of evidence this line groups under one strength.
+
+  bearsOn:
+    range: Claim
+    description: The claim the evidence line jointly bears on.
+
+  hasPart:
+    range: Act
+    multivalued: true
+    exact_mappings:
+      - obo:BFO_0000117
+    description: >-
+      The acts that compose this study — the formations, searches,
+      experiments, and analyses of one question-to-conclusion cycle.
+
+enums:
+
+  EvidentialPolarity:
+    description: >-
+      The direction of an evidential relation, mirroring the bare
+      claim-relation slots and carrying the same CiTO typing.
+    permissible_values:
+      supports:
+        meaning: cito:supports
+        description: One claim bears positively on another.
+      contradicts:
+        meaning: cito:disputes
+        description: One claim bears negatively on another.
+      refines:
+        meaning: cito:extends
+        description: One claim refines or extends another.
+
+  UncertaintyNature:
+    description: >-
+      Whether a result's uncertainty is aleatory (irreducible
+      randomness) or epistemic (reducible lack of knowledge). A
+      plain enum for now; a URREF grounding is deferred.
+    permissible_values:
+      aleatory:
+        description: Irreducible variability in the phenomenon.
+      epistemic:
+        description: Reducible uncertainty from limited knowledge.

That closes Step 5: every class that needs slots now has them. What is left is tightening, not adding — per-act narrowing of hasInput / hasOutput, numeric bounds on strength and confidenceLevel, requiredness and defaults — the facet work N&M reserve for Step 6, and the subject of Chapter 7.

Slot Usage and Facets

This chapter applies Step 6 of Ontology Development 101 (Noy & McGuinness, 2001) to scimantic.

Step 5 gave every class its slots, each defined once at the most general class that bears it. Step 6 tightens them at the point of use. A facet says what a slot’s values may be, and how many; LinkML’s slot_usage adds the per-class dimension: how one subclass narrows a slot it inherited without touching the slot’s global definition. The Step-5 definitions were deliberately wide: the abstract Act carries hasInput over every artifact, strength is an unbounded float. Step 6 narrows that breadth class by class, tightening each slot to what its bearer actually uses.

One rule governs all of it: a facet may only restrict, never widen. slot_usage on a subclass can shrink an inherited range, raise a minimum cardinality, or pin a value, but it can never re-admit what the parent left out. So each Step-5 envelope is also the outer bound on every Step-6 refinement that narrows it.

Per-act inputs and outputs

ch06 gave every act the same hasInput and hasOutput: the abstract Act carries both, ranged over the whole artifact union: Claim, Question, Result, Method, Dataset, Annotation, SourceDocument. That was the envelope. This cluster spends it. Each concrete act narrows those two slots, in slot_usage, to the artifacts it actually consumes and produces.

The narrowing takes three shapes. Most acts restrict a slot to a single range: Analysis consumes a Dataset and produces a Result, ResultAssessment consumes a Result and produces a Conclusion. A few keep a smaller union: EvidenceExtraction draws on either an Annotation or the SourceDocument it sits on; QuestionFormation may be prompted by a prior Question or Result, or by nothing at all. And two acts narrow a slot to nothing:

EvidenceAssessment weighs a piece of evidence and, on acceptance, confers an AcceptedState on it. Its effect is a standing, carried by State.establishedBy, not a new artifact. So its hasOutput is maximum_cardinality: 0 (7.1.1): the act yields no artifact at all. DesignOfExperiment’s hasInput is zero for the mirror reason (7.1.2). The hypothesis it works from arrives through tests, so nothing flows in through hasInput.

This table is also the method’s sequencing. scimantic has no precedes slot and no fixed pipeline; the order of acts is emergent, and this is where it emerges. An act that consumes an artifact can only run after the act that produced it. ResultAssessment hasInput→Result and Analysis hasOutput→Result together say, without ever stating an order, that assessment follows analysis. The nine narrowings induce a partial order on the acts: a happens-before read straight off the input and output types.

We don’t hard-wire the textbook question→…→conclusion sequence, because real inquiry doesn’t obey it. Exploratory work has no hypothesis, a LiteratureSearch can surface fresh questions, studies iterate and skip steps. scimantic records what happened as a DAG and lets the familiar order fall out of the types. (BFO offers precedes / preceded by for occurrents if an explicit order were ever wanted; here the I/O chain plus each act’s performedAt interval already fix it, so scimantic doesn’t reach for it.)

Every narrowing only restricts: each act’s inputs and outputs stay a subset of the Step-5 envelope, never more. That is the chapter-opening rule, applied nine times.

--- scimantic-yaml-v7
+++ scimantic-yaml-v8
@@ -91,60 +91,113 @@
       artifacts. The shared supertype CQ 10, 14, and 15 quantify
       over.
 
   EvidenceAssessment:
     is_a: Act
+    slot_usage:
+      hasInput:
+        range: Evidence
+      hasOutput:
+        maximum_cardinality: 0
     description: >-
       Weighs a piece of evidence for credibility and, on
       acceptance, confers an AcceptedState on it.
 
   QuestionFormation:
     is_a: Act
+    slot_usage:
+      hasInput:
+        any_of:
+          - range: Question
+          - range: Result
+      hasOutput:
+        range: Question
     description: >-
       The act of forming a question; its output an open Question.
 
   LiteratureSearch:
     is_a: Act
+    slot_usage:
+      hasInput:
+        range: Question
+      hasOutput:
+        any_of:
+          - range: SourceDocument
+          - range: Question
     description: >-
       A search over source documents that addresses motivating
       questions and may surface new ones.
 
   EvidenceExtraction:
     is_a: Act
+    slot_usage:
+      hasInput:
+        any_of:
+          - range: Annotation
+          - range: SourceDocument
+      hasOutput:
+        range: Evidence
     description: >-
       The act of extracting a piece of Evidence from an annotation
       on a source document.
 
   HypothesisFormation:
     is_a: Act
+    slot_usage:
+      hasInput:
+        range: Evidence
+      hasOutput:
+        range: Hypothesis
     description: The act of synthesizing a Hypothesis from its premises.
 
   DesignOfExperiment:
     is_a: Act
     slots:
       - tests
+    slot_usage:
+      hasInput:
+        maximum_cardinality: 0
+      hasOutput:
+        range: ExperimentalMethod
     description: >-
       The act of designing an experimental method to test a
       hypothesis; the bearer of the prospective tests intent.
 
   Experimentation:
     is_a: Act
     slots:
       - executes
+    slot_usage:
+      hasInput:
+        range: Dataset
+      hasOutput:
+        range: Dataset
     description: >-
       The act that executes an experimental method, realizing its
       plan.
 
   Analysis:
     is_a: Act
     slots:
       - executes
+    slot_usage:
+      hasInput:
+        range: Dataset
+      hasOutput:
+        range: Result
     description: >-
       The act that applies a method to data to produce a result.
 
   ResultAssessment:
     is_a: Act
+    slot_usage:
+      hasInput:
+        range: Result
+      hasOutput:
+        range: Conclusion
     description: >-
       The act of assessing a result and drawing a conclusion from
       it.
 

Numeric bounds

Two slots carry numbers rather than references: strength (on EvidentialRelation and EvidenceLine) and confidenceLevel (on UncertaintyModel). Step 5 left both as unbounded floats, with the interval deferred to here. A float admits any real value, which is wrong for both: a strength of 4.2 or a confidence of -0.3 is meaningless. The minimum_value and maximum_value facets close that, pinning each to [0, 1].

strength is a magnitude, not a signed quantity. Direction already lives in polarity (supports, contradicts, refines), so a bearing that weakly contradicts is polarity: contradicts with a low strength, never a negative one. Weakness, then, needs no slot of its own: it is the low end of [0, 1]. The schema keeps the three senses of “weak” apart, each on its own slot. A weak bearing is low strength, weak evidence is low Credibility, and a shaky result is high Uncertainty.

confidenceLevel is a reported confidence, so [0, 1] is the probability interval it lives on.

These are value bounds, a different facet from cluster 1’s range narrowing. There we restricted which classes a slot points at; here we restrict which numbers a value may take. The instinct is the same: say no more than the domain allows, applied now to the two kinds of value a slot can hold.

--- scimantic-yaml-v8
+++ scimantic-yaml-v9
@@ -499,14 +499,16 @@
       Which cito-typed direction the relation takes — supports,
       contradicts, or refines.
 
   strength:
     range: float
+    minimum_value: 0
+    maximum_value: 1
     description: >-
-      How strongly the bearing holds; an unbounded float here, with
-      scale and bounds set in Chapter 7's facets. Shared by
-      EvidentialRelation and EvidenceLine.
+      How strongly the bearing holds, as a magnitude in [0, 1];
+      direction is carried by polarity. Shared by EvidentialRelation
+      and EvidenceLine.
 
   assertedBy:
     range: Act
     description: >-
       The act that asserted this relation; its agent and time are
@@ -529,13 +531,14 @@
       The model's parameters; free strings here, with structured
       typing left to a later increment.
 
   confidenceLevel:
     range: float
+    minimum_value: 0
+    maximum_value: 1
     description: >-
-      The confidence level the model reports, e.g. 0.95; its bounds
-      set in Chapter 7's facets.
+      The confidence level the model reports, in [0, 1] (e.g. 0.95).
 
   nature:
     range: UncertaintyNature
     description: Whether the uncertainty is aleatory or epistemic.
 

Required and optional

The last facet axis is cardinality: how many values a slot must have. Most of the schema’s slots are optional by default, so the sweep here is deciding which ones a record cannot do without.

scimantic takes the lenient stance its PROV-O lineage suggests: an activity asserts what is known, so provenance metadata stays optional. agent, performedAt, and an act’s inputs are left unconstrained, because real records often lack a known performer, time, or explicit input. The schema should capture a partial record, not reject it.

What it does require is structural integrity: the fields without which an entity is not coherent. A reified relation needs its endpoints and direction, so EvidentialRelation requires subject, object, and polarity. An evidence line needs what it groups and what it bears on, so EvidenceLine requires members and bearsOn. A state needs the thing it qualifies, a study needs its parts, and an uncertainty model needs the quality it quantifies.

The acts add one required slot apiece, on the output side. An act defined by what it produces must produce it: a QuestionFormation without a Question, or an Analysis without a Result, is incomplete in a way an act missing its agent is not. So each act whose identity is its product requires that output, narrowed in cluster 1 and now floored at one. Inputs stay optional, since an act can usually be reconstructed from its output alone.

--- scimantic-yaml-v9
+++ scimantic-yaml-v10
@@ -106,18 +106,19 @@
   QuestionFormation:
     is_a: Act
     slot_usage:
       hasInput:
         any_of:
           - range: Question
           - range: Result
       hasOutput:
         range: Question
+        required: true
     description: >-
       The act of forming a question; its output an open Question.
 
   LiteratureSearch:
     is_a: Act
     slot_usage:
       hasInput:
         range: Question
       hasOutput:
@@ -131,41 +132,44 @@
   EvidenceExtraction:
     is_a: Act
     slot_usage:
       hasInput:
         any_of:
           - range: Annotation
           - range: SourceDocument
       hasOutput:
         range: Evidence
+        required: true
     description: >-
       The act of extracting a piece of Evidence from an annotation
       on a source document.
 
   HypothesisFormation:
     is_a: Act
     slot_usage:
       hasInput:
         range: Evidence
       hasOutput:
         range: Hypothesis
+        required: true
     description: The act of synthesizing a Hypothesis from its premises.
 
   DesignOfExperiment:
     is_a: Act
     slots:
       - tests
     slot_usage:
       hasInput:
         maximum_cardinality: 0
       hasOutput:
         range: ExperimentalMethod
+        required: true
     description: >-
       The act of designing an experimental method to test a
       hypothesis; the bearer of the prospective tests intent.
 
   Experimentation:
     is_a: Act
     slots:
       - executes
     slot_usage:
@@ -180,28 +184,30 @@
   Analysis:
     is_a: Act
     slots:
       - executes
     slot_usage:
       hasInput:
         range: Dataset
       hasOutput:
         range: Result
+        required: true
     description: >-
       The act that applies a method to data to produce a result.
 
   ResultAssessment:
     is_a: Act
     slot_usage:
       hasInput:
         range: Result
       hasOutput:
         range: Conclusion
+        required: true
     description: >-
       The act of assessing a result and drawing a conclusion from
       it.
 
   Method:
     abstract: true
     subclass_of: cco:ont00000965
     description: >-
@@ -459,18 +465,19 @@
       - cco:ont00001986
     description: >-
       An artifact an act produces; ranged broadly here, narrowed
       per-act in Chapter 7's facets.
 
   qualifies:
     any_of:
       - range: Claim
       - range: Method
+    required: true
     description: >-
       The claim or method whose standing this state records — the
       entity it qualifies.
 
   establishedBy:
     range: Act
     exact_mappings:
       - cco:ont00001819
@@ -479,28 +486,31 @@
   occursOver:
     range: TemporalInterval
     exact_mappings:
       - obo:BFO_0000199
     description: The interval over which this state holds.
 
   subject:
     range: Claim
+    required: true
     description: >-
       The claim that bears on another in an evidential relation.
 
   object:
     range: Claim
+    required: true
     description: >-
       The claim borne upon in an evidential relation.
 
   polarity:
     range: EvidentialPolarity
+    required: true
     description: >-
       Which cito-typed direction the relation takes — supports,
       contradicts, or refines.
 
   strength:
     range: float
     minimum_value: 0
     maximum_value: 1
     description: >-
@@ -510,18 +520,19 @@
 
   assertedBy:
     range: Act
     description: >-
       The act that asserted this relation; its agent and time are
       reached through the act.
 
   quantifies:
     range: Uncertainty
+    required: true
     description: The uncertainty quality this model quantifies.
 
   family:
     range: string
     description: >-
       The distribution or method family — Gaussian, bootstrap, and
       so on. An open string, not enumerated.
 
   parameters:
@@ -539,29 +550,32 @@
       The confidence level the model reports, in [0, 1] (e.g. 0.95).
 
   nature:
     range: UncertaintyNature
     description: Whether the uncertainty is aleatory or epistemic.
 
   members:
     range: Evidence
     multivalued: true
+    required: true
     description: >-
       The pieces of evidence this line groups under one strength.
 
   bearsOn:
     range: Claim
+    required: true
     description: The claim the evidence line jointly bears on.
 
   hasPart:
     range: Act
     multivalued: true
+    required: true
     exact_mappings:
       - obo:BFO_0000117
     description: >-
       The acts that compose this study — the formations, searches,
       experiments, and analyses of one question-to-conclusion cycle.
 
 enums:
 
   EvidentialPolarity:

Relational characteristics

ch06 left a question open. The claim relations are Claim-to-Claim: supports, contradicts, and refines take Claim as both domain and range. That shape raised a question domain and range alone cannot answer: may a claim bear on itself, and does a bearing run both ways? The answers are not facets of a value or a count. They are characteristics of the relation, which LinkML carries as boolean slot metaslots and lowers to OWL property axioms a reasoner can enforce.

All three claim relations are irreflexive: no claim bears on itself. A claim that supports, contradicts, or refines itself is a small circularity the reasoner can now reject, and it is the direct answer to ch06’s domain-equals-range question. The relation runs among claims, never from a claim back to itself.

The three then part on direction. refines is asymmetric: if one claim refines another, the second does not refine the first, since refinement sharpens or extends what came before and the reverse cannot also hold. (Asymmetry already implies irreflexivity, so the two travel together.)

supports and contradicts are directional but not one-way, so neither symmetric nor asymmetric fits. Evidence supporting a hypothesis is not the hypothesis supporting the evidence, yet two claims can support each other in a coherent pair. Contradiction is subtler: logical incompatibility is symmetric, but scimantic’s contradicts is the evidential cito:disputes, and disputation flows from the disputing claim to the disputed one. A null result contradicts the hypothesis it tested; the hypothesis does not dispute the result. Two studies with opposite findings, though, contradict each other. So both relations stay where they began, irreflexive and nothing more.

The empty symmetric and transitive columns are deliberate, not an oversight. The transitive relations in provenance are real, but they are lineage and order, and a slot for each is the wrong place to keep them. scimantic stores the atomic edges, hasInput and hasOutput and the act chain, and lets the transitive closures fall out of SPARQL property paths, the same store-the-edge-derive-the-aggregate call ch06 made. A symmetric corroborates would be derivable too, from two claims supporting a common target. Transitivity and symmetry are present in the graph; they are queried, not declared.

One slot is the exception, and it earns the axiom. Study.hasPart maps to BFO’s has occurrent part, which BFO defines as transitive, so a study’s parts’ parts are its parts. Because scimantic grounds in BFO by URI rather than importing it, that transitivity is not inherited, so the schema declares transitive: true to make BFO’s own semantics explicit and to be ready for composite acts with sub-acts.

That leaves refines and a tempting fourth characteristic. Refinement reads transitively, a refinement of a refinement being a refinement, and declaring it would let a reasoner hand back the whole ancestry. But OWL 2 DL forbids a property from being both transitive and asymmetric or irreflexive, the restriction that keeps reasoning decidable. Transitivity would cost the one-way and no-self guarantees, and the ancestry it would infer is already a refines+ path away. Asymmetry wins; transitivity stays off.

--- scimantic-yaml-v10
+++ scimantic-yaml-v11
@@ -383,22 +383,26 @@
   supports:
     range: Claim
     multivalued: true
+    irreflexive: true
     exact_mappings:
       - cito:supports
     description: Asserts that one claim bears positively on another.
 
   contradicts:
     range: Claim
     multivalued: true
+    irreflexive: true
     exact_mappings:
       - cito:disputes
     description: Asserts that one claim bears negatively on another.
 
   refines:
     range: Claim
     multivalued: true
+    irreflexive: true
+    asymmetric: true
     exact_mappings:
       - cito:extends
     description: Asserts that one claim refines or extends another.
 
@@ -569,8 +573,9 @@
   hasPart:
     range: Act
     multivalued: true
     required: true
+    transitive: true
     exact_mappings:
       - obo:BFO_0000117
     description: >-
       The acts that compose this study — the formations, searches,

Refinement and Validation

This chapter applies Step 7 of Ontology Development 101 (Noy & McGuinness, 2001) to scimantic, and with it closes the rebuild.

Step 7 is instances, but here instances are a means rather than the end. Building them out against a real study is how the schema gets validated, and refined in the same motion: each filled-in slot value tests whether the ontology can carry the study, and the gaps that surface are the refinements to make. Validation and refinement are not two phases here. They are one interleaved activity.

That refinement comes from two directions. One is dogfooding: validating the schema against Appendix A’s worked study, instance by instance, surfaces what it still lacks. The other is reflection, stepping back from the finished hierarchy to ask whether every class it accumulated still earns its place. This is the one kind of refinement that needs no instances to motivate it. N&M’s second rule, that ontology development is necessarily iterative (Chapter 2), makes both expected. The chapter opens with the reflection, because the graph alone made it plain.

Culling the uncertainty cluster

At the end of Chapter 7 the schema was complete enough to review as a whole. Its provenance classes form a single connected component in the graph: claims, acts, and artifacts linked by hasInput, hasOutput, and the act chain. Four classes stand outside it. Uncertainty, Credibility, and UncertaintyModel form a fragment the provenance chain never reaches, and StatisticalMethod, though placed under AnalyticalMethod, is used by no act. All four were added in Step 4 and have gone unused since. The question is whether they belong in scimantic at all.

Two reasons say they do not.

The first is a category error. Uncertainty and Credibility were grounded as BFO qualities (obo:BFO_0000019), and Chapter 5 reasoned that a result’s uncertainty “inheres in the result.” But a quality inheres only in an independent continuant, and the thing it was meant to qualify, a Result, is not one. A result is an information content entity, a generically dependent continuant, and a quality cannot inhere in it.

The grounding was incorrect from the start, independent of the graph; the disconnected component only made it easy to notice.

The second is a layering error. Uncertainty is a property of the data, not of the provenance chain. A distribution over a data point or a confidence interval on a result belongs with the data itself, a layer below the one scimantic models. That layer already has a vocabulary for it: scimantic’s Dataset is a dcat:Dataset, and DCAT’s quality companion, the W3C Data Quality Vocabulary (DQV), attaches quality measurements and annotations to a dataset. A consumer records a result’s uncertainty as one such measurement, against the data rather than the provenance graph. scimantic records that a result was produced, by which act and from which dataset; how far it could vary is the data layer’s to express.

So all four classes are removed, along with the slots only they bore (quantifies, family, parameters, confidenceLevel, and nature), the UncertaintyNature enum, and the now-unused urref: prefix.

Removing a class is not the same as denying what it named, and two of the four need a note on where their content goes. Credibility is not lost, only relocated. An EvidenceAssessment already weighs a piece of evidence and, on acceptance, confers an AcceptedState on it; credibility is the judgment that assessment makes, read from the conferred state, not a separate quality that needs its own class. (If a graded score is wanted over the plain accept-or-reject verdict, it is a slot on EvidenceAssessment, where the judgment is made.) StatisticalMethod was is_a AnalyticalMethod, but statistics is orthogonal to the analytical/experimental split rather than a subtype of one side. If a concrete statistical method type is needed later, it returns as a mixin composed onto the relevant method, added on demand rather than now.

The removal also settles two threads earlier chapters left open. Chapter 2’s twelfth competency question, what is the uncertainty model for a given result, and how was it derived?, falls to the data layer rather than scimantic, and the validation pass will mark it out of scope. The [0, 1] bound Chapter 7 placed on confidenceLevel is removed with the class that carried it; the matching bound on strength is unaffected.

--- scimantic-yaml-v11
+++ scimantic-yaml-v12
@@ -23,13 +23,11 @@
   cco: https://www.commoncoreontologies.org/
 
   # Reused domain vocabularies: metadata, annotation, datasets,
-  # nanopublication, uncertainty, claim relations
+  # nanopublication, claim relations
   dcterms: http://purl.org/dc/terms/
   oa: http://www.w3.org/ns/oa#
   dcat: http://www.w3.org/ns/dcat#
   np: http://www.nanopub.org/nschema#
-  urref: http://eturwg.c4i.gmu.edu/files/ontologies/URREF.owl#
   cito: http://purl.org/spar/cito/
 
@@ -311,39 +309,6 @@
       polarity, a strength, and the asserting act, through which
       the agent and time are reached.
 
-  Uncertainty:
-    subclass_of: obo:BFO_0000019
-    description: >-
-      A quality of a result quantifying how much it could vary;
-      borne by the result, quantified by an UncertaintyModel.
-
-  Credibility:
-    subclass_of: obo:BFO_0000019
-    description: >-
-      A graded quality of a piece of evidence expressing how far it
-      can be relied on; conferred by an EvidenceAssessment.
-
-  UncertaintyModel:
-    subclass_of: cco:ont00000853
-    slots:
-      - quantifies
-      - family
-      - parameters
-      - confidenceLevel
-      - nature
-    description: >-
-      A Descriptive ICE that quantifies a result's uncertainty
-      quality: a family, its parameters, a confidence level, and a
-      nature (aleatory or epistemic).
-
-  StatisticalMethod:
-    is_a: AnalyticalMethod
-    description: >-
-      An analytical method prescribing how to derive a result's
-      uncertainty and credibility from data.
-
   EvidenceLine:
     subclass_of: cco:ont00000853
@@ -528,35 +493,6 @@
       The act that asserted this relation; its agent and time are
       reached through the act.
 
-  quantifies:
-    range: Uncertainty
-    required: true
-    description: The uncertainty quality this model quantifies.
-
-  family:
-    range: string
-    description: >-
-      The distribution or method family — Gaussian, bootstrap, and
-      so on. An open string, not enumerated.
-
-  parameters:
-    range: string
-    multivalued: true
-    description: >-
-      The model's parameters; free strings here, with structured
-      typing left to a later increment.
-
-  confidenceLevel:
-    range: float
-    minimum_value: 0
-    maximum_value: 1
-    description: >-
-      The confidence level the model reports, in [0, 1] (e.g. 0.95).
-
-  nature:
-    range: UncertaintyNature
-    description: Whether the uncertainty is aleatory or epistemic.
-
   members:
     range: Evidence
     multivalued: true
@@ -597,14 +533,3 @@
       refines:
         meaning: cito:extends
         description: One claim refines or extends another.
-
-  UncertaintyNature:
-    description: >-
-      Whether a result's uncertainty is aleatory (irreducible
-      randomness) or epistemic (reducible lack of knowledge). A
-      plain enum for now; a URREF grounding is deferred.
-    permissible_values:
-      aleatory:
-        description: Irreducible variability in the phenomenon.
-      epistemic:
-        description: Reducible uncertainty from limited knowledge.