A detailed model can show where a crack was photographed. To support a conservation decision, we also need to know when the image was taken, what else was measured, which interpretation was proposed, and who reviewed it. Those relationships do not emerge automatically from a mesh or a textured surface.
A useful first step is to make one small chain of evidence queryable, before attempting a comprehensive “intelligent” platform.
Research context
Our paper PANOPTES: A Digital Twin Ontology for Cultural Asset Management, by George Pavlidis, Vasileios Sevetlidis and Vasileios Arampatzakis, was presented at IEEE-CH in Florence, 8–10 September 2025. The repository gives 8 September 2025 as its publication date. Developed in the ARGUS context, PANOPTES connects cultural assets with observations, diagnoses, predictions, threats and decisions. It builds on CIDOC CRM, SOSA/SSN, PROV-O, GeoSPARQL and OWL-Time, and describes a mapping to a relational backend.
The example here is an independently constructed, minimal teaching graph. Its assets, timestamps and readings are fictional. The example.org/heritage-demo/ terms are local teaching terms, not an official PANOPTES vocabulary or an ARGUS deployment export.
Start with a question
Consider this request: “Show the relative-humidity observations associated with wall 1, including their time and unit.”
This forces us to identify the wall, the observed property, the observation event and its result. A bare database value such as 74 answers none of those questions by itself. Even attaching a timestamp leaves the unit and the object unresolved.
SOSA/SSN provides terms for observations, sensors, features of interest and observed properties. PROV-O supplies a separate vocabulary for provenance. They address complementary questions: what was observed, and how did a subsequent information product come about?
A small graph with explicit meaning
@prefix ex: <https://example.org/heritage-demo/> .
@prefix sosa: <http://www.w3.org/ns/sosa/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
ex:observation-1 a sosa:Observation ;
sosa:hasFeatureOfInterest ex:wall-1 ;
sosa:madeBySensor ex:rh-sensor-1 ;
sosa:observedProperty ex:relative-humidity ;
sosa:hasSimpleResult "74.0"^^xsd:decimal ;
ex:unit "percent relative humidity" ;
sosa:resultTime "2025-09-11T09:00:00+03:00"^^xsd:dateTime .
The custom ex:unit string makes the example readable. A shared production dataset should use an agreed unit vocabulary and document conversions. We would also distinguish a sensor’s physical location from the heritage feature it is intended to monitor: a nearby environmental reading is not necessarily a direct measurement of the wall’s moisture content.
Ask the graph
SPARQL lets us select observations matching those relationships:
PREFIX ex: <https://example.org/heritage-demo/>
PREFIX sosa: <http://www.w3.org/ns/sosa/>
SELECT ?observation ?value ?unit ?time WHERE {
?observation a sosa:Observation ;
sosa:hasFeatureOfInterest ex:wall-1 ;
sosa:observedProperty ex:relative-humidity ;
sosa:hasSimpleResult ?value ;
ex:unit ?unit ;
sosa:resultTime ?time .
}
ORDER BY ?time
The companion dataset returns one fictional row: observation 1, value 74.0, percent relative humidity, at the stated time. The query retrieves the evidence. It does not diagnose damage.
Keep an observation separate from a decision
The fuller example adds a review activity that uses the observation, and an inspection request derived from that activity. Its status explicitly says that damage has not been established. A high reading alone cannot determine the material response, the duration of exposure, the sensor’s reliability, or the appropriate intervention.
This distinction becomes especially useful when an interpretation changes. We can preserve the original observation and record a later review rather than overwriting the evidence with the latest conclusion. A predictive model should similarly carry its version, inputs and uncertainty alongside its output.
What to build before adding automation
I would begin by choosing stable asset identifiers, retaining raw measurements, documenting units and time conventions, and making one conservation question reproducibly answerable. I would then test whether a second person can follow the evidence from the query result to its source.
An ontology cannot repair a miscalibrated sensor or an ambiguous asset identifier. Its practical value is that those assumptions and relationships can be represented explicitly, inspected, and challenged. That makes it a useful foundation for decision support without confusing a machine-readable assertion with a confirmed physical fact.
Complete reproducible example
These files contain synthetic teaching data and calculations. They do not reproduce a trained model or a field deployment.
heritage.ttl
@prefix ex: <https://example.org/heritage-demo/> .
@prefix sosa: <http://www.w3.org/ns/sosa/> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
# Entirely fictional teaching data, not an ARGUS measurement or PANOPTES schema.
ex:wall-1 a sosa:FeatureOfInterest .
ex:rh-sensor-1 a sosa:Sensor .
ex:relative-humidity a sosa:ObservableProperty .
ex:observation-1 a sosa:Observation, prov:Entity ;
sosa:hasFeatureOfInterest ex:wall-1 ;
sosa:madeBySensor ex:rh-sensor-1 ;
sosa:observedProperty ex:relative-humidity ;
sosa:hasSimpleResult "74.0"^^xsd:decimal ;
ex:unit "percent relative humidity" ;
sosa:resultTime "2025-09-11T09:00:00+03:00"^^xsd:dateTime .
ex:review-1 a prov:Activity ;
prov:used ex:observation-1 .
ex:inspection-request-1 a prov:Entity ;
prov:wasGeneratedBy ex:review-1 ;
prov:wasDerivedFrom ex:observation-1 ;
ex:status "inspection requested; damage not established" .
observations.rq
PREFIX ex: <https://example.org/heritage-demo/>
PREFIX sosa: <http://www.w3.org/ns/sosa/>
SELECT ?observation ?value ?unit ?time WHERE {
?observation a sosa:Observation ;
sosa:hasFeatureOfInterest ex:wall-1 ;
sosa:observedProperty ex:relative-humidity ;
sosa:hasSimpleResult ?value ;
ex:unit ?unit ;
sosa:resultTime ?time .
}
ORDER BY ?time