3DOnt

3DOnt · 3DGraph · 3DGraphExplorer

Point clouds that
know what they are.

A laser scan gives millions of coordinates. 3DOnt turns them into a knowledge graph: every point linked to the objects it constitutes, every object to its parts, its classes and the expert knowledge of its domain — so that a conservator, an urban planner or a forester can ask the cloud what they actually want to know.

No installation. The graphs, the queries and the segmentations run on your machine; only natural-language questions go to a translation service.

The problem

Rich data, poor use.

Point clouds are cheap, dense and everywhere — heritage documentation, smart cities, forestry. Yet outside of technical disciplines they are mostly looked at, not used. Four gaps keep them there.

01

Heterogeneity

Thermal and multispectral rasters, sensors, archival documents, expert knowledge: all relevant, none tied to the geometry in a common structure.

02

Semantic poverty

At best, a label per point. No objects, no parts and wholes, no taxonomy — none of the structure through which experts reason.

03

Inspectability

Viewers colour a scalar field and threshold it. Domain questions (“which capitals are lower than…”, “which roofs are made of…”) are out of reach.

04

Technical barrier

The people who need the answers — conservators, architects, planners — should not have to write code or query languages.

The representation

The 3DGraph: one graph, two levels.

The 3DGraph re-expresses a point cloud in RDF/OWL against 3DOntCore, a domain-agnostic backbone ontology that domain extensions (urban, heritage, forestry, Pompeii …) specialise.

  • Dual level. Points and objects are both individuals. A point Constitutes every object it belongs to — the window, the facade, the building — so the multi-label nature of reality is kept, not flattened.
  • Mereology. Objects are linked by Is_part_of / Has_as_part, derived from how their points overlap.
  • Taxonomy. Every object is an instance of its class and of all its ancestors: a Car is a Four-Wheeled Vehicle, a Vehicle, a Movable Object.
  • Emergent properties. Bounding boxes, dimensions, surfaces are computed per object and stored as data properties: geometry becomes queryable.
  • Integration. Rasters, scalar fields, sensor streams and manual annotations attach to points and objects as acquisitions — one homogeneous framework.
T-BOX · classes OBJECTS · macro-entities POINTS Immovable_Object Building Structural_Element Functional_Element Building #3 Facade #13 Window #7 Is_part_ofIs_part_of rdf:type Constitutes: one point → several objects
A point of a window constitutes the window, its facade and its building; objects are linked by mereology and typed by the taxonomy. Both axes are explicit, so they can be travelled.
Try it: the same temple front, re-segmented by the two resolutions. The Explorer does the same on millions of real points.

Inspection

Dynamic Semantic Segmentation S(Mr, Tr)

A classified cloud usually commits to one segmentation. A 3DGraph holds all of them at once: since every point knows every object it constitutes and every object knows all its classes, a segmentation is just a choice of two resolutions.

  • Mr, mereological resolution — from the finest parts (abacus, echinus) to the wholes (column, temple).
  • Tr, taxonomical resolution — from the most specific class (Echinus) to the most general (Building_Part, Object).
  • Targeted segmentation — keep only the lineages you care about.

Nothing is recomputed and no network is re-run: changing the segmentation is moving along structure already in the graph.

Try it on YTU3D →

Integration and reasoning

Expert knowledge lives in the graph.

Domain knowledge is not a separate spreadsheet: it is part of the ontology, and reaches the geometry through the same links as everything else.

acquisition

What a point is made of

Material maps, thermal day / night rasters, scalar fields, sensors — attached to points and objects.

→
T-box

What experts know about it

Materials are individuals with physical properties: specific heat capacity, permeability to water …

→
rules

Explainable inference

Rules combine the two into new properties — heating propension, flooding risk, dew-formation risk — with every step traceable.

→
query

Actionable answers

“Building points hotter than 40 °C by day”, “ground made of impermeable materials”.

Ferrara

Points carry their material and two thermal acquisitions; rules derive a heating-propension and a flooding-risk index. Open →

Semantic digital twins

Sensor streams as individuals of the graph, linked to the objects they monitor; time-aware rules predict dew formation in a heritage building (Santa Chiara, Trento). Open →

What-if

Hypothesised conditions (temperature, humidity, presence of a pathogen) run through the same rules on a temporary copy of the graph — the forestry extension uses it for susceptibility indices.

Accessibility

Ask in plain language: NL-2-SPARQL.

SPARQL can express any question about a 3DGraph — but few experts write SPARQL. NL-2-SPARQL is a neuro-symbolic translator: the language model does only what it is good at, the graph does the rest.

  1. Parse. A fine-tuned LLM turns the question into a structured parse: the words, how they relate, the logical operators, the filters, what to return. It never sees the graph and never writes SPARQL.
  2. Map. Each word is mapped on the ontology vocabulary (lexical, WordNet and embedding similarity), with the user confirming ambiguous cases.
  3. Explore and build. The Graph Exploration and Query Building step finds the paths between the mapped terms in the ontology graph and writes the query.
  4. Answer. The query runs on the 3DGraph and the answer lights up in 3D.

Because the LLM does not memorise the schema, the same translator works on any domain extension. Online, the parser runs in your browser (WebGPU) and a small free service maps its output on the ontology; the generated SPARQL runs in your browser. No API key is involved.

“windows of the buildingswith a height greater than 20” LLM parserstructure only, no schema 3DOntCore + extensionthe vocabulary Graph exploration & query building window → Window · building → Building · height → Z_Length > 20 SELECT ?p WHERE { ?p base:Constitutes ?w . ?w a base:Window ; base:Is_part_of ?b . ?b a base:Building ; base:Z_Length ?h . FILTER(?h > 20) }
The division of labour of NL-2-SPARQL (Codiglione & Remondino, Digital Heritage 2025).

Online demo

Four 3DGraphs, four things to see.

Each project is chosen for what it shows best. Open one, read its card, click “what this project can show”.

Under the hood

A desktop explorer, ported to the browser.

The 3DGraphExplorer is a Qt/C++ desktop application on top of a QLever triple store. The online demo keeps the same semantics with no server to pay for:

  • Points as arrays, objects as RDF. Each 3DGraph is split into compact typed arrays for the points and an RDF graph of the objects and the ontology, loaded into Oxigraph (WebAssembly) in your browser.
  • Point-aware SPARQL. Queries that talk about points are rewritten on the fly: the object part runs on the graph, the point part on the arrays.
  • Free hosting. Pages, data and parser models on Hugging Face, computation on your machine, including the NL-2-SPARQL parser (WebGPU); only the mapping of the parse on the ontology runs on a small free service.
Your browser three.js viewerOxigraph (WASM) · SPARQLsegmentations · plotsNL parser (WebGPU) HF static Spacethis site + the app Hugging Face3DGraphs · parser models NL-2-SPARQL serviceHF Space · no key parse → SPARQL
Static hosting, client-side computation.

Publications

Read more

Project page: 3dom.fbk.eu/projects/3DOnt · 3D Optical Metrology unit, Fondazione Bruno Kessler · University of Trento.