KMAP: A BIM Knowledge Map in Two Languages, and Why Position Had to Mean Something
Every BIM class I teach runs into the same wall. The vocabulary is not the difficult part, because IFC, ISO 19650, level of development, the common data environment, clash detection and digital twins are all terms that people can define on request. The difficulty is that almost nobody can show how those terms connect to each other on a single page, so each one arrives as an isolated fact and the shape of the field never appears.
So I built the page. It is one map of BIM containing 73 terms, 92 relations and 8 clusters, and it exists in Korean and in English with the same structure on both sides. This post shows the map, explains why the clusters are cut the way they are, and then covers the two rounds of tool updates that building the map forced me to make.
One page of BIM
Solid outline means a person confirmed the term. Dashed outline means the term is still an unreviewed AI draft. At the moment exactly one term out of 73 is confirmed, and the legend prints that accounting inside the image rather than hiding it in a caption. The legend text itself is Korean, because the tool interface has never been localized and only the map content exists in both languages.
Eight clusters, cut by layer of work rather than by software
People who learn BIM as a list of product names have to learn it again every time the product changes, so I cut the map by the layer of work that each term belongs to instead of by the vendor that sells it.
- Standards and openness: IFC, IDS, BCF, bSDD, MVD, COBie, ISO 19650, openBIM
- Information management: common data environment, owner requirements, BIM execution plan, level of development, information need, naming conventions, version control, review and approval
- Authoring and platforms: Revit, ArchiCAD, Rhino Grasshopper, Civil 3D, Tekla, Navisworks, Solibri, IFC viewers
- Automation and development: Dynamo, the Revit API, Python, parametric modeling, generative design, add-in development, data schemas, batch automation
- Analysis and simulation: clash detection, quantity takeoff, 4D scheduling, 5D cost, energy analysis, structural analysis, visibility analysis, layout optimization
- Construction and site: shop drawings, site scheduling, site scanning, point clouds, prefabrication, safety review, field verification, as-built models
- Operations and assets: digital twins, asset management, maintenance history, IoT sensors, energy monitoring, space management, data handover, lifecycle cost
- AI and data: machine learning, computer vision, synthetic data, knowledge graphs, LLM assistance, predictive models, data quality, rule-based checking
The lines that cross clusters carry the actual content
The interesting part of the map is not what sits inside a cluster, because any textbook can give you that list. The interesting part is the set of lines that run between clusters, and five of them explain most of what goes wrong on real projects.
- ISO 19650 to common data environment to owner requirements to BIM execution plan, which traces how a standard stops being a document and turns into a procedure that somebody has to run every week.
- IFC to COBie to data handover, the path along which design information is supposed to become an operational asset, and the path where most of it quietly evaporates.
- Dynamo to the Revit API to generative design to layout optimization, the route by which automation grows into analysis instead of staying a set of convenience scripts.
- Point cloud to as-built model to digital twin to IoT sensors, where the site feeds operations, assuming anyone bothered to keep the survey.
- IDS to rule-based checking, and knowledge graph to bSDD, the two newest lines, along which standards become automated verification.
Adoption almost never stalls inside a cluster. It stalls on these lines: the model exists but the handover does not, or the standard has been purchased but no checking rules were ever written against it. A map that shows only clusters hides exactly the failures worth talking about.
The Korean and English pair, and what did not survive the crossing
The two versions carry identical structure, 73 terms and 92 relations each, so a term sits in the same position in both files and you can hold one next to the other while reconciling Korean project vocabulary against an international specification. Three measured limits came out of the exercise, and I would rather write them down than let a reader discover them alone.
The Korean version renders every label, 73 out of 73, at both 1280 and 1024 pixels wide. The English version renders 69 out of 73 at the same two widths, and the four missing labels are not missing nodes, because the nodes remain present, clickable and listed in the side panel while only their text fails to place. I varied spacing and depth across several combinations and the count stayed at four every time, so the cause sits inside the label placement routine and remains unresolved. Longer English words needing more room is the obvious suspicion, and a suspicion is not a diagnosis.
On a phone at 390 pixels the map shows 37 of 73 labels in Korean and 36 in English. That is an area limit rather than a defect, since 73 terms will not fit legibly on a phone screen at any typography that a room full of people could read, and the remaining terms are reachable by dragging the map or by opening the list. For presenting to an audience I would use a tablet or a laptop.
The last limit is the honest one: only the graph content is bilingual. The tool interface around it, including the menus and the band captions visible in the next two figures, is still Korean, because localizing the product itself was never part of this exercise.
Update one: the three things the tool needed before anyone could use it
Making a real map exposed gaps that a demonstration never would, and all three of them had the same shape: the product could show a result beautifully and then fail at the moment somebody wanted to do something with it.
The first gap was the exit. Every output the tool produced was aimed at a human being, meaning a picture, a link or a block of text, and there was no contract that another program could consume. So the copy menu now writes a JSON file in a declared format that carries the terms, the relations, the confirmation state and the provenance stamp.
The second gap was review. The rule of the tool has always been that AI produces a draft and a person confirms it, but confirming meant clicking 73 terms one at a time, an operation nobody can perform in front of a class. The list header now carries a progress bar, a single control that confirms everything, and an undo that reverts precisely the terms which were unconfirmed immediately beforehand.
The third gap was provenance. A saved graph used to be a picture whose origin nobody could establish, so every export now carries a stamp naming the model, the source and the time, and that stamp travels through the saved file, the shared link and the JSON alike.
One rule inside that work is worth stating plainly, because it cost me an argument with myself. The JSON reports whether a term is confirmed, and it deliberately does not carry a field claiming who authored the term. Once a person has confirmed an AI draft, a word typed by a human and a word generated by the model and then approved are no longer distinguishable, and inventing a field that pretends otherwise would put a false provenance claim into a file that other software will trust.
I also shipped a defect and then found it, and this is the part of the section I would prefer to leave out. When the side panel header wrapped onto two lines, a fixed minimum height of 46 pixels pushed the second line underneath the list body, producing a control that was fully visible and completely unclickable. Comparing the element actually receiving the click at those coordinates against the element drawn there is what exposed it, and the fix was a single flex property.
Update two: position had to mean something
The blunt finding came from a review round in which eighteen reviewers all reached the map and none of them got value from it. My first instinct was that the graphics looked dated, and that instinct was wrong. The real problem was that position encoded nothing whatsoever, so a reader could move nodes around, produce a different picture, and learn exactly the same amount as before, which is nothing.
The answer was not a visual restyling but an axis, and the map now offers views in which the coordinates themselves make a claim.
Hierarchy view. Vertical position encodes abstraction, with the root at the top, the eight clusters beneath it and the individual terms at the bottom, so height on the screen answers the question of how general a term is.
Strata view. The same three levels become horizontal bands and the connecting lines are suppressed, which produces a reading surface where the words dominate instead of the web between them.
The third view compares two words, and it is the only one of the set that a static diagram genuinely cannot replace. Given a second term, the map divides into three zones holding what belongs to the first word alone, what the two words share, and what belongs to the second word alone, and it then reports the shared term with the fewest connections as the least obvious bridge between them.
Getting there required abandoning my first two attempts, and the reason is worth recording. I tried deriving the shared zone on the client by matching spelling between the two expansions, then by measuring graph distance between the two roots, and both attempts measured zero shared terms in testing. A headline feature cannot depend on whether an overlap happens to occur, so comparison became a dedicated server mode with its own schema, in which the model answers only the question of which zone a term belongs to while the placement and the accounting stay deterministic. The measured round trip is a little under fourteen seconds on local hardware.
The same release finally made the map readable on a phone. Row width had been a hardcoded constant, so a crowded map grew sideways, the fit-to-screen scale collapsed and the labels became unreadable. Deriving row width from the aspect ratio of the whole layer instead took a phone from 38 readable labels to all 73.
What these figures cannot show
Two limits apply to the pictures in this post, and both of them are measurements rather than opinions. The comparison view needs the local server, so there is no offline figure of it here and I have described it in words instead. The two axis figures above are screen captures rather than product exports, because the image export path produced byte-identical files for the hierarchy and strata views, both exactly 4,372,334 bytes, so the export cannot currently distinguish between them. Why it collapses the two is not yet established.
The two map posters at the top, by contrast, are not screen captures at all. They come from the product's own image export, at fixed 19 pixel type with the legend and the confirmation accounting rendered into the file, which is why they are 5010 by 4104 pixels and legible when you open them at full size.
Where this leaves the tool
KMAP is not a modeling tool and it does not pretend to be one. It is an explanation instrument for teaching and consulting, built on the rule that the model writes a draft and a person decides what is true, and the entire visual language exists to keep those two categories separate on screen. The current build passes 138 automated checks with no console errors, which tells you that the thing behaves, and tells you nothing at all about whether the content is correct.
Which brings me to the only warning that matters. Seventy two of the 73 terms on this map are unreviewed drafts, the dashed outlines say so in the picture, and if you plan to use any of this in coursework or in a report, confirm it against your own standards first. I would rather publish a map that admits what it has not verified than a cleaner one that quietly does not.
댓글
댓글 쓰기