Make meaning a shared resource
Understand the model, use your professional judgement to improve it, or study the ontology-modelling discipline behind it. Two audiences, one connected agreement.
A date can be correctly formatted and still describe the wrong event. A floor area can have the right unit and still include a different part of the dwelling. Two records can carry the same address without describing the same thing. Useful property information needs the distinctions people rely on in their work.
Semantic modelling makes those distinctions explicit and reviewable. An ontology describes the things, meanings and relationships involved. You do not have to write ontology code to explain why a definition misses a normal case, why two choices overlap or which evidence a statement needs.
Choose the work you want to do
Understand and work with the model
For property practitioners, data stewards, analysts, developers and other participants who are not ontology modellers.
Start with familiar situations. Inspect definitions, choices, relationships and rules; compare evidence; turn a difficult case into an actionable review question. No formal syntax is required.
Start with shared meaning, or go straight to a candidate you can inspect.
Design the ontology
For ontology modellers, semantic architects and people making formal representation decisions.
Apply identity analysis, roles and phases, contextual boundaries, qualified mappings, evidence and time. Work with the selected RDF, OWL, SKOS and SHACL profiles and the governing decisions.
A field guide with three useful starting points
-
Understand shared meaning
Five chapters explain what we are building, its benefits and limits, the six views of an agreement, a connected property story and how the modelling work is done.
-
Explore the model
Nine chapters examine identities, roles, measurements, time, evidence, vocabulary, connections, rules and permission descriptions. Each develops the distinction through concrete cases.
-
Review and contribute
Eight working references help you frame a question, review a definition or diagram, test choices and rules, bring evidence, inspect a candidate and follow a reasoned revision.
This is a reference to use, not a course you must finish before taking part. The examples show their premises and worked responses. Changed-premise cases show when the answer changes—and when the evidence no longer permits an answer. Definitions of technical terms link to the site's one glossary.
Follow the question, not just the vocabulary
In the fictional Harbour Court case, an inspection of Flat 1 takes place on 12 August. A report is issued on 14 August and corrected on 20 August. There is no second visit. What would a recipient wrongly conclude if “inspection date” were filled with the latest report issue date?
- Report v1 was issued on 14 August 2026 and describes the inspection of Flat 1 on 12 August.
- Report v2 was issued on 20 August 2026 and revises v1. It describes the same inspection, not a second visit.
- The issue date belongs to each report version. The inspection date belongs to the inspection. A form, tree or graph can preserve these same distinctions.
Follow the complete story through the building, its dwellings, the access account and a conditional requirement. Then compare other situations: borrowing and guaranteeing in different arrangements, measurement boundaries, a valuation opinion, document preparation and a permission description.
Local meaning, explicit connections, shared discipline
Our approach begins with a bounded question and the evidence and professional distinctions needed to answer it. The contextual boundaries for this phase are already documented. Within them, definitions need accountable ownership and coherent meaning; between them, connections must say what they preserve.
This is not a rejection of formal analysis or useful shared standards, and it is not a claim that all other ontology work starts with a universal hierarchy. Suitable existing meaning should be reused. Where meanings differ, a mapping must explain the correspondence instead of erasing the difference because two labels look alike. See how the method works.
Your knowledge changes what can be specified
Before a draft exists
“Our two floor-area accounts include different spaces. A recipient sees only two numbers and assumes they disagree.”
This identifies a question and consequence. Turn it into a modelling question with an ordinary case and a difficult variation.
When you have a candidate page
“This definition joins the report and its inspection. What happens when a report is corrected without another visit?”
This tests a proposed distinction. Review the definition and show what a recipient could misunderstand.
Use the member guide for current participation arrangements, or express interest in a working group. Reading an exercise submits nothing. Technical validation, professional review and authority to release a specification are different things.
Separate the method, the draft and the illustration
The selected decisions describe the modelling discipline within OPDA's stated scope. The Property Pack is an actual machine-proposed candidate component with its own determination and review record. The fictional cases in this field guide are teaching material, not candidate implementation or adopted industry rules.
We are developing a specification. Generated delivery artefacts follow from the ontology; this guide does not teach payload formats or require participants to operate a linked-data application. Its subject is the meaning we need to agree, the evidence behind it and the judgement that improves it.
Comments
Loading comments…
Sign in to post a comment