From Data to Meaning: Why We Need Ontologies Before AI
I’ve finally discovered the name for how property/asset ‘data’ joins up across teams and stakeholders, throughout the asset life cycle.
In my mind’s eye, there are thousands of data points. Each one with a specific relationship to a physical location, a component, a person, a process, and an outcome. If I could draw it (and I have tried) it would be a series of dots, representing the data, and connecting lines, colour coded, depicting the relationships. A bit like a neural network.
Having considered this more, I don’t think there are enough colours to show all these relationships and what they mean. It would need a proper legend which would probably look quite chaotic! Thankfully, someone has already devised a way of conveying this. Not so much for humans to understand but, importantly, for machines to read. It’s called a semantic ontology.
Why is this important?
Property professionals instinctively understand how buildings work. Our systems don’t.
If we are to deploy symbolic AI (AI that follows a logic), then we need to be able to convey our logic in a manner that the machines can read and then, reason with. Chris Lees makes a compelling argument why we need to ‘get-the-human-out-of-the-loop’, but I want to explore how this concept is relevant to property data. Something I come into contact with every day, as a surveyor.
Structure isn’t the same as meaning
Let’s start with the property hierarchy; a concept all Block and Estate Managers will be familiar with, given it underpins how a property management systems work.
Many of the proprietary systems use Estate > Block > Unit and the Building Safety Act now necessitates the need for ‘Level’ to be inserted to support the Golden Thread.
So now we have Estate > Block > Level > Unit or, to accommodate for non-residential properties:
Site > Structure > Level > Space
Whilst these systems provide structure, have capabilities to design workflows, and provide dashboard views, seldom are they fully utilised.
When looking at the raw data held in some of these systems, it is muddled, confused and fields aren’t used as intended. I can hazard a guess at what the person curating the data meant but without a clear definition, I can’t be sure. As a result, the information presented and the inferences made in arriving at conclusions are diluted, lack integrity and distort what may be actually happening on the ground.
Dashboard reporting happens outside the system, in Excel and Power BI. But that’s so 2011 which isn’t quite deemed fashionable enough to be deemed ‘old skool’… yet!
This happens for a number of reasons.
During the implementation phase, the system is configured to the organisation’s preferences; normally to ensure continuity of operation and reporting. Systems are implemented in silos without considering all stakeholders. Customisation, whilst not an issue per se, results in inconsistencies particularly around the categorisation of the fields and menu choices, which makes analysis nigh on impossible without a clear rationale.
For instance, a field called ‘Property Type’ should have choices such as ‘House, Terraced house, End of terrace house, Detached house, Bungalow, Block of flats, Purpose built block of flats, Converted block of flats etc’. It shouldn’t include customer types or tenure types; two entirely separate fields.
Thankfully, HACT have created the UK Housing Data Standards powered by OSCRE which support this objective and is a starting point for any organisation managing property to help apply the data in a meaningful way.
Personally, I find these systems useful as a way of storing data and extracting it in a structured way. But until we explain the meaning of the data (in a machine-readable way), very few live systems are currently capable of being ‘AI ready’ or providing the assurance that Boards, Investors and Customers demand.
The questions we are asked (and always will be)
At each layer of the hierarchy there will be entities or things which have attributes and properties. These are the things that join up / interact in certain and explicit ways, as well as the details (properties) we need to know about those things (entities), to help us make decisions, plan, manage property and keep people safe.
A common question asked by a leaseholder in a block of flats is ‘why am I paying for the lift’? The answer lies in the lease, the service charge matrix and apportionment schedule. But until all of those documents are reviewed, an answer cannot be given. In reality, leaseholders are often told that, because they are a leaseholder, they contribute to the services through the service charge, as dictated by their lease.
That answer is fine, but what if the leaseholder in question lives on the ground floor, has their own entrance directly from the outside and doesn’t benefit from the lift? That answer then doesn’t feel right and leads inevitably to complaints.
As a starting point, the data needs to be structured in a data model which can then be populated and used to build monthly reports / Management Information.
For example, a Component:
- Has attributes
- expected life
- replacement cost
- inspection regime;
- Is located in [a Space];
- Serves [Dwellings];
- Is part of [Estate].
Just those data points alone would highlight that the lift doesn’t serve the flat in question. But without intrinsic knowledge of the building or the ability to interpret a drawing or lease, the meaning is lost, and answers can’t be given with certainty.
Data model to semantic ontology (Meaning)
Whilst a property asset manager will be able to infer the meaning of the data based on their knowledge and experience, this inference can vary, is subjective, and might not accord with the organisation’s policies or their client’s specific requirements. Furthermore, it will be based on what they know and have had to assume. In larger organisations, such as Housing Associations, a property management model is less common, and specific functions perform tasks (often in silos).
Coupling the data model with a semantic ontology, injects meaning to the data and paves the way for AI being deployed to answer questions in nuanced and varied ways. Crucially, the ability for machines to interact with the structured data and apply logic also provides certainty and assurance, as the outputs can be tested and audited against a clear rationale, and balanced in terms of risk (provided that it is written by people with knowledge of how things should work).
- A component should be replaced at the end of its expected life
- Expected life indicates how long from now a thing is likely to last before it needs replacement
- Estimated replacement cost is the total cost of replacing a thing, including the removal and disposal of the existing thing and installation and commissioning of a new thing.
Dashboards then start talking:
Worked example:
Cold-water tank
Take a cold-water tank for instance. The property manager receives a report from the building manager that they have observed some corrosion following their monthly visual inspection of the tank. The last quarterly sampling tests came back fine but they are now due again, so the property manager asks the maintenance contractor to inspect and advise. The maintenance contractor finds that there is some sediment in the water and recommends that the sampling should be increased to monthly, to monitor the situation. Alternatively, the tank could be replaced.
The property manager reviews the cost of the enhanced sampling frequency versus the cost of the replacement tank. They also look at the performance of associated components such as the pumps, maintained by a different contractor, and note enhanced repairs due to their age. The property manager knows that the pumps are due for replacement and had been monitoring but with the risk of more down time, causing disruption for residents and potentially leading to complaints, they recommend to their client that the tank and pumps should be renewed.
The client accepts the recommendation but because there are insufficient reserve funds, due to arrears, they will need to cash flow the installation. They ask the property manager to provide a schedule of rents so they can assess the impact of the disruption and loss of rent arising from compensation payments, against the cost of capital. Despite interest rates being high, the client decides, being a good landlord, to replace the system as it is the right thing to do given the impact the failing system is having on its customers. It will also serve as a defence against breach of lease for failing to maintain the pumps or claims of historic neglect.
Reality
This is a common occurrence and illustrates the day-to-day decision-making across property management. Having worn both hats in this scenario, I can say with certainty that those types of decisions are currently made with much less information due to time pressures and inaccessibility of data/information. As a result, the outcome will almost always vary based on the data available, who is reviewing, their experience, values and biases.
The exciting bit
The scenario above is possible today where you have a single property manager, with years of experience, intrinsic knowledge, working in unison with their client; the reality is there are few property managers afforded the time, given the remit, or with the right skills to manage what can be extremely challenging issues which stem from poor quality data.
Add to this an operating model that works in theory but relies on strong data foundations. Silos emerge, teams are inhibited and knowledge is rootbound resulting in unhappy customers, compromised safety and general friction all round. Boards lose confidence, regulators are delving deeper and residents are uniting to demand better.
I genuinely believe there is a practical way forward, that doesn’t require a property/ asset/ housing manager to be wedded to their portfolio. But it will require organisations to change their approach to data fundamentally. Park the systems, they will come and start to embrace the meaning. That will not only create data of value, but translate into asset value, happy clients and delighted customers.
