Working group kick-off
A shared language for property information
You bring the domain knowledge. OPDA turns it into a model the group can understand, challenge and improve.
Questions are welcome throughout
Ontology strategist · Agentic engineer
Hello, I’m
Henrik Pettersen
I turn specialist knowledge into shared models, international standards and working systems. Today, agentic engineering helps me do that faster—without outsourcing judgement.
You bring knowledge of your field. I lead the modelling process that turns the group’s resources, discussions and feedback into reviewable candidates and familiar outputs.
25 years working with ontologies. Connecting specialist knowledge, international standards and production systems.
One continuous practiceFrom expert knowledge to working standards.
Working-group orientation
What this first meeting is for
Set the context
Why this working group exists, the problem it addresses and how it fits the wider programme.
Present the approach
How existing work informs domain-led modelling, with distinct contexts and explicit cross-context mappings.
Make the model accessible
A plain-language introduction to data models and ontologies—and how familiar schemas and forms can be generated from them.
Show the path ahead
How shared resources become published model candidates, and how the group will review and improve them.
This is an orientation and presentation, with questions welcome throughout—not a live modelling workshop.
Illustrative context lenses
Meaning changes across bounded contexts
A property does not need one universal definition. Each domain can describe what matters locally without flattening those meanings into one model.
These examples explain the approach; each group reviews and determines its own meaning. Formal cross-context mappings are reviewed separately.
Continuity with a better source of meaning
Evolution, not replacement
What carries forward
- Schemas, forms and worked examples
- Existing standards and vocabularies
- Glossaries, dictionaries and validation
- Website and implementation experience
Evidence, traceability, tests and compatibility inputs.
What changes
- Domain groups review and agree local meaning
- Each bounded context receives equal focus
- Differences are mapped rather than flattened
- Review happens through readable website candidates
A recorded OPDA decision controls whether a candidate moves forward; interoperability aligns the boundaries.
Start with the basics
What is a data model?
An agreed map of the important business things, what they mean, how they fit together and the rules that apply.
Before choosing a file format, agree what the information means.
A familiar view
Forms and schemas organise data as a tree
A tree is excellent for one workflow, form or exchange contract: every item has a chosen place and path.
Property information submission
{
"organisation": { … },
"submission": {
"submitted": "2026-08-31",
"property": {
"address": "14 Oak Road",
"floorArea": 92
}
},
"evidence": [ … ]
} The tree answers: “Where does this value go in this particular message or form?”
The connected view
An ontology connects knowledge as a graph
The same concepts can participate in several relationships without being trapped inside one document path.
The graph answers: “What does this mean, and how can it connect safely to other information?”
Complementary, not competing
Same knowledge, different views
Electronic form
Organisation details
Submission details
Property details
Supporting evidence
JSON tree
$.organisation$.submission$.submission.property$.evidence[]Ontology graph
A governed source, familiar views
You do not need to understand ontologies
A candidate ontology makes proposed meaning explicit. Reviewed transformations produce familiar outputs.
Precision without fragmentation
Why separate domain models?
“Property” can legitimately mean something different in each context. Where a relationship is needed, a reviewed mapping can make that difference explicit.
The common boundary supplies a small set of shared elements. It is not a route through which every context must pass.
Programme structure
A governed family of working groups
Six domain groups own their local meaning. A cross-cutting interoperability group aligns what must work across their boundaries.
Cross-group alignment
Its remit is boundary agreements
When constituted, representatives align only what must work across contexts. Questions about local meaning return to the group that owns them.
Small common boundary ontology
Only concepts and relationships genuinely shared across contexts. It is not a universal model or a transit route.
Context map
Where meaning originates, where information crosses a boundary and which group owns each decision.
Reviewed mappings
Reviewed relationships connect context-owned concepts where information crosses a boundary. The mapping method is governed separately.
Shared conventions
Identifiers, provenance, versioning and change conventions where cross-context consistency is required.
The semantic content
What each working group develops
Each group uses six connected kinds of content to make its own business meaning explicit and reviewable.
Business glossary
What do practitioners mean by each term?
Data dictionary
Which data elements are recorded, in what form and with what expectations?
Taxonomies
How are concepts organised into broader and narrower meanings?
Controlled vocabularies
Which governed terms, codes and values may be used?
Resources
Which important things and concepts need stable identity and description?
Relationships
How do those resources connect, participate and constrain one another?
Representations for different consumers
What OPDA publishes and generates
A reviewed semantic package can be represented through formats that people and systems already use.
Ontology in RDF
The machine-readable graph of resources, relationships and constraints.
JSON Schemas
Generated exchange contracts for existing schema and form tooling.
Website · PDF · Markdown
Readable, versioned documentation for review and reuse.
Mapping runtime
A potential runtime for ontology/schema mapping and validation where a deployment needs it.
Questions that expose gaps
One completeness lens, eleven themes
A participant-facing checklist, not eleven models. Select a theme to reveal the practical question it asks.
Meaning 4 themes
Trust 3 themes
Correctness 2 themes
Exchange 2 themes
Readable, reviewable candidates
The website becomes the working surface
Members review diagrams, terms, definitions, examples and changes—not source code.
See the model in contextThe site presents the developing property-pack model through contextual boundaries, diagrams, definitions and source-linked detail.
Challenge a specific pointWorking-group pages will connect open questions and discussion to the exact term, relationship or decision under review.
Follow each revisionVersioned working-group candidates will show what changed, why it changed and what still needs agreement.
This Conveyancing page demonstrates the review surface. It is not this working group’s candidate model.
Open current demonstration ↗
Resource-first modelling
First: share what already exists
Your working group’s first candidate will be grounded in the materials, language and edge cases its members already use.
The modelling loop
Start with evidence. Review a candidate. Repeat.
Authorised source material starts the work once. Modelling, publication and human review then repeat as the candidate improves.
Human review directs the next modelling pass. AI accelerates the work; it does not supply the decision.
AI is the drafting accelerator
What AI helps with — and what it cannot decide
The modelling lead directs the work. AI accelerates analysis and drafting; domain experts decide meaning, and only a recorded human governance decision can move a candidate to a later stage.
- Extract terms, rules and examples
- Compare sources and expose differences
- Propose relationships and candidate definitions
- Find gaps, contradictions and missing evidence
- Incorporate reviewed feedback rapidly
- What is true in any domain
- Which stakeholder judgement should prevail
- Whether restricted material may be published
- How feedback is disposed or a dispute resolved
- Whether a candidate moves to a later stage or is approved
Participants do not need to run or adopt AI. Review centres on the meaning, evidence, assumptions and recorded decisions.
A visible candidate cycle
Publish, review, revise, repeat
Each version remains a model candidate until the working group records consensus. Consensus may produce a stable working-group draft; it does not ratify or adopt a standard.
Clear channel roles
Where each conversation belongs
Use the route announced for your group. Exact tools, access details and handling arrangements are supplied with the invitation.
Share only material your organisation is authorised to provide. Describe sensitive or restricted sources first so OPDA can agree an appropriate review route with you.
The immediate sequence
What happens after this session
The coordinator confirms the route
Members receive the discussion, source-intake and review details for their group.
Members share resources
Authorised materials arrive with source, permission and sensitivity information.
The modelling team prepares candidate 0.1
AI-assisted modelling produces definitions, relationships, documentation and open questions.
The group reviews
The candidate is published through the working-group review surface and improved through recorded feedback.
The first ask is simple: when the route arrives, share the resources that best explain how your part of the domain works.
The working-group promise
You bring the knowledge.
OPDA makes it reviewable.
and domain judgement+02The modelling team
prepares candidates+03The group challenges
and improves the meaning
No ontology expertise and no AI adoption are required. Your working knowledge is the contribution.
Questions and next steps.
opda.org.uk · Open Property Data Association