Geometry vs Knowledge

Reading a cad dwg is one of the most basic and earliest skills an engineer develops. You'd have read and authored thousands, maybe hundreds of thousands of cad file across your career. You immediately can identify what different lines, circles, hatches mean. You might not even need to know the layer names or block names to exactly identify the meaning of 1 line from another. A pdf or a jpg of the plan gives you the same inference a cad dwg gives. It's so very easy for us to understand the semantics.

For a machine, what gives semantics to these random geometric entities? Layers and blocks are the primary handles. There are of course other ways including attributes and Xdata, but I'll stick to layers and blocks for now.

The problem is these conventions aren't uniform. though there are ISO standards, different organizations, disciplines, and engineers follow their own. So how do we translate this geometry and the semantics that the humans can infer into something that machines can understand?

Mapping layer naming conventions and block references to formal classes is a start. A simple mapping is all that is required for this classification within an organization. I'm exploring ontology for this.

Is this sufficient? Even with everthing correctly classified, the machine still doesn't know how things relate. And on top of that, a real cad file is messy: wrong layers, non-standard names, bad drafting.

This is where topology becomes important. Topology processes the geometry to find structure that classification alone cannot. It helps in making a group of primitive geometry into a model that is more meaningful, and also helps in cleaning up the file. Once you have that structure, the ontology becomes much more meaningful, and gives the machine something to reason over.

I've been working on CAD, BIM, IFC, topology and ontology, and realise this gap between geometry and knowledge is clearly closing.