Open Property Data Association
Smart Property Data Trust Framework
Become a member Join a working group

    Ontology modelling

    A practical guide to deciding what a model means, testing its commitments and making those decisions reviewable.

    Technical modelling guide Method atlas

    Method basisUpdated

    Three property practitioners compare one terraced house with an unlettered floor plan and a separate report folio in a bold risograph scene.

    Start with a distinction that matters in the work. Give it a clear definition and an accountable home. Then ask difficult questions of it. This guide teaches the judgement between a source phrase and an ontology statement—the part that a diagramming tool, a schema generator or a language model cannot settle for you.

    For ontology modellers and facilitators, the six chapters form a connected argument. For a particular authoring task, the references below provide the selected profiles. Readers who want the idea before the method can begin with understanding shared meaning.

    Six chapters in modelling judgement

    The running case is fictional Harbour Court: one building, two dwellings, concurrent buyer and seller roles, an inspection and revised reports. The facts are deliberately small; the questions are not. Follow them from foundational analysis to a candidate that a domain expert can challenge.

    1. Foundations and modelling judgement

      What makes this the same thing, an essential type, a dependent entity or a whole? Work through the four axes and the limits of mechanical checks.

    2. Choose the right representation

      Should this be a class, a controlled value, a literal or a qualified relationship? Make each node and arrow earn its place.

    3. Identity through roles and change

      What persists when a person changes roles, a record is corrected or a dwelling is subdivided? Separate participation from identity.

    4. Connect meanings across contexts

      What agreement connects these contexts, and which exact term correspondences apply? Preserve both scales without inventing equivalence.

    5. Evidence, claims and time

      Which assertion has this source, and which event does this date concern? Follow one visit through two reports and a correction.

    6. From source evidence to model decisions

      How does an ambiguous source requirement become a defensible candidate? Assemble evidence, alternatives, examples and a decision for review.

    One innocent field can hide several decisions

    “Latest survey date” sounds ready to model. But is a survey a visit, an assessment or a document? Is its subject the building or a dwelling? Does the date describe the visit, the report’s creation or its receipt? Does “latest” select the most recent event or the newest account of an earlier event?

    A source field gives us evidence that somebody needs an answer. It does not decide those meanings. A defensible model makes the interpretations visible, tests them against examples and records who can resolve the difference. More structure is justified when it preserves a needed distinction; less structure is justified when the distinction has no consumer.

    One agreement, several independent concerns

    The method is domain-led within six established property bounded contexts. Practitioners judge meaning; formal analysis exposes commitments; external standards provide reusable vocabulary; validation checks the agreed constraints. The Interoperability Working Group governs boundary agreements without turning those contexts into one universal property model.

    Eight retained concerns keep the work complete: domain structure, vocabulary and taxonomy, classification metadata, validation and constraints, cross-domain mappings, provenance and quality, temporal state and history, and sensitivity and access semantics. Each needs a disposition, not a separate ontology. Concerns organise the work; foundational discipline applies across them; facets and semantic homes answer different questions.

    RDF/RDFS/OWL meaning, applicability hints, SHACL constraints and selected derivations remain distinct. JSON-LD artefacts are generated from the model, not designed here as another authority. Model-review governance is also separate from the wider SPDTF Trust Framework: these chapters explain domain semantics, not scheme operation or application deployment.

    Keep the authoring references close

    The chapters explain why a decision matters. These references specify how the selected method expresses, checks and records it. Use the relevant profile alongside the example rather than replacing reasoning with a checklist.

    The result to aim for

    A useful candidate lets a reviewer find the definition, see the ordinary case, challenge the hard case and inspect the evidence behind the choice. It explains the rejected alternative and its consequences. Where an identity criterion, mapping or rule remains unresolved, that question is visible rather than concealed by a convenient encoding.

    Technical evidence has equally precise limits. A parsed graph, a successful shape run, a populated four-axis check and a correct competency-query answer establish different things. An accepted method does not prove an implementation exists. A validated candidate does not become an adopted domain model through a green badge.

    Where this guide gets its authority

    ADR-0063 establishes the domain-led approach and scope. ADR-0067 establishes first-principles Property Pack modelling and resource homes. ODR-0062 organises the method; ODR-0061 and ODR-0063 require foundational analysis without external upper-ontology subsumption.

    The decision register records applicable scope, amendments and source-method provenance. Older accepted decisions retain their recorded scope. The schema-derived ontology remains a separately identified evidence corpus; the teaching here re-authors useful questions under the current method, not its historical conclusions.

    Comments

    Loading comments…