What needs to be finished first
An iterative Competency Question backlog with prioritization exists and can be used to accept iteration outcomes.
Domain experts and later consumers of the linked-data resource are named and available for end-of-iteration reviews.
What needs to be ready before start
Ontology-structured Git repo (vocab/, examples/, docs/, tests/); backlog tool (Linear, Jira, GitHub Issues); CI with RDF validation and documentation generation (WIDOCO, pyLODE); publication toolchain (W3ID, GitHub Pages, persistent IRI).
Ontology engineer (Product Owner for the ontology), one to three modelers, one reviewer per iteration from consumer side, one maintenance owner for maintenance phase.
CQ backlog; use cases with priorities; reuse research results; licensing and governance decision; selected toolchain; iteration cadence (typically 2 weeks).
Weeks to months in 2-week iterations
Initialize repo from template. Configure iteration columns in GitHub project (Requirements, Implementation, Publication, Maintenance). First iteration with 3-5 CQs as sprint backlog. Schedule review at the end of the iteration.
The one question this method answers
How does the team deliver the ontology in iterative, releasable increments that cover Competency Questions and are usable by consumers?
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Ontological Requirements Specification | 3-5 days initially, then ongoing | Collect use cases, CQs, non-functional requirements, and pre-glossary. Identify reuse candidates (LOV, Schema.org, domain ontologies). Publish initial ORSD. | In Linked Open Terms, ORSD is maintained as a living document, not frozen. Changes come in as issues and are prioritized in backlog. |
2Phase 2: Implementation in iterations | Iterations of 1-2 weeks | Per iteration, pull CQs from backlog, model classes and properties, write examples, keep CI green, open pull request with review. Explicitly reference reuse patterns and sources. | Any PR without tests will be blocked in review. CI should run at least RDF syntax checks, consistency (for example via HermiT/ELK), and CQ test queries. |
3Phase 3: Evaluation and stakeholder review | 1-2 h per iteration end | Reviewer checks iteration result against completed CQs. Consumers test examples and documentation. Findings become new issues in backlog. Mark iteration as done or rework. | Reviews without consumers are token reviews. At least one reviewer from consumer side per iteration, otherwise iteration is not done. |
4Phase 4: Publication | 1-2 days per release | Set release version (SemVer). Generate documentation via WIDOCO/pyLODE. Configure persistent IRI (w3id.org or own domain). Publish license, changelog, examples. Check content negotiation. | Persistent IRI is mandatory. Linking to raw GitHub URLs will break consumers on the next repo move. |
5Phase 5: Maintenance | Ongoing, monthly rhythm | Handle change requests through issues. Quarterly or monthly releases. Mark deprecated classes with owl:deprecated and include migration guide in changelog. Actively gather consumer feedback. | Maintenance is the most difficult and most often forgotten phase. Without dedicated owner time (minimum 4 h/week) the ontology dies within 6 months. |
What comes out at the end
Git repository with ORSD, modular ontology files, sample data, CQ test suite, CI config, generated HTML documentation, releases with SemVer, changelog, and maintenance plan, published via persistent IRI.
SemVer (MAJOR for breaking changes, MINOR for additive changes, PATCH for documentation fixes). Changelog per release. Pre-releases with -alpha, -beta. Persistent IRI with version path (for example /v1.2.0/) plus latest alias.
Compact working template for Linked Open Terms with context, input, output artifacts, and next step.
Agile, lightweight methodology for developing ontologies and linked-data vocabularies.
When and for what do we use this method?
Which data, observations, decisions, or materials are available?
Short notes along the runsheet.
Owner, date, and success signal.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
Iteration 5 (12.05.-23.05.2026, reviewer @sabine, civil engineer).
Sprint backlog:
Implementation:
MaintenanceCycle with property cycleLengthYears.schema:Action for MaintenanceEvent (mapping in mapping.ttl).CI: all 38 CQ test queries green except CQ 16 (expected).
Review (@sabine): 2 findings. (1) Missing maintenance-cycle example for facade. (2) Documentation language inconsistent. Both added as issues for Sprint 6.
Release v0.5.0: Persistent IRI w3id.org/building-lifecycle/v0.5.0/. Docs at buildinglifecycle.org/v0.5.0/. Changelog updated.
Maintenance: Owner @marcus, monthly release. CR issue template activated.
Recognize symptoms and steer against them
ORSD is written once and then not touched, drifting away from reality.
Keep ORSD in repository and all changes as PRs. At each sprint review, verify ORSD is current. Actively update outdated sections or mark them deprecated.
Modeling PRs are merged without validation, broken RDF enters main, docs build fails.
Make CI mandatory: RDF syntax check, reasoner run, CQ test queries, and documentation generation. PRs without green CI should not be merged.
Ontology links to raw.githubusercontent.com URLs; every repo restructure breaks consumers.
Set up W3ID or own domain with content negotiation before first release. Better delay release than publish without persistent IRI.
Sprint reviews with other modelers but never with consumers or domain experts.
At least every second iteration include an external reviewer from consumer side. If not available, recruit participants as for usability testing.
After launch ontology is no longer maintained; issues remain open and new versions do not ship.
Document maintenance plan and owner before launch. Calendar monthly releases. If owner leaves, hand over ownership or announce deprecation.
In Iteration 4 it is discovered that Schema.org already covers the same concept, so classes must be mapped.
Plan reuse research as initial activity in phase 1 with minimum scope (for example 1 day). Search LOV systematically. Before introducing every new concept, check reuse first.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.