Read a candidate and compare a change
Start directly with a real Property Pack resource page. Then use a separate fictional revision to see how a change affects several views of one agreement.
Start with the page you have been asked to review
You do not need to finish the introductory chapters first. Keep the candidate's identity and version, read its definition, then choose one claim to examine. A good review can begin with one familiar subject and a well-explained counterexample.
The Property resource page is a real candidate definition. The identity card below reads the same maintained candidate data as that page; it is not a separately maintained model. Everything in the later change comparison is an invented teaching package, not actual candidate history.
- Candidate
property-pack-0.1- Version
0.1.0-draft- Candidate status
- machine proposed
- Publication standing
- public review only
- Resource
common:Property- Kind shown on the page
- Class
- Definition
- An identifiable unit of land, buildings or both that persists independently of any particular address, transaction or domain view.
- Identity criterion
- Candidate identity is continuity of the unit associated with the same assigned UPRN; lifecycle rules remain for working-group review.
“Class” describes the kind of model construct on this page. It is not the foundational judgement called an OntoUML Kind. Nor is this a record of Flat 1, an individual building or a live transaction. The definition proposes what a category includes; the Harbour Court story supplies fictional examples with which to practise reasoning.
Read four parts of the page together
- Identity: read the definition and unresolved identity questions, not just the resource label.
- Structure: inspect attributes, relationships and targets; a linked term is not automatically an accepted mapping.
- Constraints: distinguish what is currently expressed from what reviewers think should be required.
- Evidence: inspect source identity, version and trace kind. Separately inspect candidate status, technical determination, domain review, release and external recognition.
Identity and meaning: what would continue?
The reviewed candidate associates continuity with the same assigned UPRN and explicitly leaves lifecycle rules for working-group review. That is a proposed criterion to examine, not a settled answer to subdivision or merger. Ask what counts as the unit before and after the change, and what evidence would justify treating it as continuing or newly identified.
A changed postal description does not by itself prove a new property; an unchanged identifier does not by itself explain every physical or legal change. The useful challenge is the relationship between the identification practice and the domain identity criterion. We are not asserting a rule for how a real authority allocates UPRNs.
Model structure: what does one connection claim?
Follow a property listed under “Properties with this domain”, such as the candidate's “has address”. Read it as a connection between a property and an address description. Do not rewrite it in your mind as “the property is the address”. If the page does not name a broader model class, do not invent one. A diagram's layout also does not establish that two subjects are identical.
Constraints and shapes: what is being checked?
The resource page links declared requirements in related shapes. In the reviewed candidate, the Common Property shape requires one UPRN value represented as a digit-only string. That is a bounded requirement on a description. It does not establish that the reference was correctly assigned to the described subject or that the proposed continuity criterion is appropriate.
Follow the relevant linked shape rather than assuming the resource summary contains every rule. A missing constraint is not proof that anything is permitted; passing an encoded constraint is not semantic approval. If the rule excludes an ordinary case, bring the case and explain the mismatch.
Source evidence: what supports the proposal?
Direct source traces identify source items directly linked to the construct; structural traces carry evidence from more specific descendants to an organising model class. This is inherited evidence, not a direct source statement about that class. They are not interchangeable evidence that a source used the exact candidate wording. Neither kind of trace proves semantic truth or domain endorsement. Follow one source item and ask which part of the definition it actually supports.
The proposed home common is also a review question: sharing an identifier is not enough to establish a shared identity criterion and exchange meaning. The context register keeps the Common boundary, the property contexts and the machine-proposed DBT Smart Data scheme context distinct. Common supply arrows are not cross-context mappings; they do not establish adopted correspondences.
A version-linked challenge you could make
For
property-pack-0.1, version0.1.0-draft, I am reviewing common:Property: Identity and meaning. How would this criterion treat subdivision into two dwellings? The text leaves lifecycle rules open. Without a stated treatment, a recipient might carry evidence about the former unit onto a different resulting unit. What permitted source or domain review supports continuity in that case, and what remains explicitly unresolved?
This note gives a reference, consequence and question. It does not claim that subdivision already exists in the candidate's examples, prove that the criterion is wrong or supply an invented official identifier-allocation policy. “Please change Property” would leave all of that unstated.
Do not combine different kinds of standing
The source scope, candidate version, Technical Working Group determination, later domain review, release and external recognition are separate. A technical validation result is not itself the Technical Working Group's determination; that determination does not imply that every domain group has reviewed the meaning. A published review page is not adoption, and government use is not proof of formally delegated authority.
The Property Pack follows its separately recorded accelerated determination and later-review arrangement. Check the maintained determination page and review and release record for standing. A polished teaching diagram cannot change it.
Now compare a fictional change across the agreement
Leave the real candidate here. The following teaching draft A and teaching draft B are invented model versions. They are not Property Pack releases, report versions or a live website comparison feature. The change addresses the ambiguous access choices discussed in reviewing vocabularies.
Teaching draft A
Access outcome: “Whether the inspection was completed.”
Choices: Completed; Limited access; Not inspected.
Relationship: “Report has access outcome”, without identifying the visit or agreed areas.
Teaching draft B
Physical-access outcome: “How much of the identified nonempty set of agreed areas was physically accessed during this visit.”
Choices: All; Some but not all; None — with the full definitions established in the vocabulary.
Relationship: A report version records an access-outcome statement about an identified inspection and its agreed areas.
| View of the agreement | Effect of this fictional revision |
|---|---|
| Glossary | Separate physical access from completion of inspection work. Add the scope and exclusions to the meaning, not just a new preferred label. |
| Dictionary | Explain which visit and agreed set the outcome describes. Keep report issue date unchanged: it still describes issue of a report version. |
| Controlled vocabulary | Replace overlapping work/access choices with defined all/some/none physical-access outcomes. Missing evidence is not silently recoded as none. |
| Resource definitions | Describe the proposed access-outcome statement and its subject. The definition of a report version need not change merely because it can record this better-qualified statement. |
| Relationships | Make the report-version → statement → identified inspection and scope connection explicit. Preserve which report version made the statement. |
| Topic taxonomy | Leave “Roof condition” beneath “Building fabric” unchanged. This topic relationship says nothing about physical access. |
The access rule and examples also need review against the new scope. Generated delivery artefacts, including JSON-LD, would need to preserve any agreed change; they do not decide its meaning. A revision need not alter every view, but every affected view must tell a compatible story.
Comments
Loading comments…
Sign in to post a comment