Define the domain
Name the purpose, audience, scope, source language, and questions the model must answer.
Meaning has a boundaryLearning path · 02
Make shared meaning explicit.
When people and software use the same words differently, systems drift. Define concepts, relationships, states, and rules so a shared model can be interpreted, tested, and revised.
Outcome
Build models that reveal assumptions.
By the end of the path, a learner should be able to define a bounded domain, distinguish classes from instances, create controlled vocabulary, model relationships and states, test competency questions, and publish the model with its limits.
Structure the model
Represent concepts, identifiers, relationships, constraints, lifecycle states, and provenance.
Make assumptions visibleTest interpretation
Use examples, counterexamples, queries, and stakeholder review to find ambiguity and omission.
Models require challengeSequence
From language to a testable knowledge model.
Vocabulary
Collect terms, definitions, synonyms, exclusions, and source contexts.
Entities and relations
Model what exists in the domain and how the parts connect.
States and provenance
Represent change, confidence, authorship, evidence, and version history.
Queries and review
Test whether the model answers real questions without inventing certainty.
Practice artifact
Produce a small, documented domain model.
The guided module moves from competency questions and source vocabulary to relationships, sample records, provenance, and known gaps.
Source shelf and correction
Learn from open semantic-web standards.
Begin with the W3C specifications for RDF 1.1 Concepts, OWL 2 Overview, and the SKOS Primer. They address different modeling needs; none is a universal answer for every domain.
Find an ambiguous definition or broken example? Open a specific correction issue.