Finding Meaning in a Mesh
Once Human Atlas can separate and select visible pieces, the next problem is not spatial but semantic: how can a reader reach a meaningful structure without hunting through an inventory of geometry? This chapter follows the route from a name or direct pointer pick to a concept selection, its member pieces, the details surface, and optional browser tools. The practical result is a distinction between identifying a structure, explaining it, and changing the interface around it.
Search starts from concepts, not raw geometry
A raw mesh identifier can point to an element, but it is a poor first question for most readers. Human Atlas therefore searches the named-concept collection. A query is trimmed and compared without regard to letter case against concept names and atlas identifiers. With no query, the interface offers a small set of familiar starting structures. With a query, it returns matching concepts, sorts the visible results by name length, and limits the list to 80 matches.
This design reduces the cognitive cost of a large catalogue without discarding the source relationship underneath. A reader can type “femur,” “heart,” or an atlas identifier and receive a named result instead of needing to know which source mesh IDs make up that structure. The result still reports how many pieces it contains. Naming provides the route in; the manifest's element list provides the underlying answer.
The search behavior is intentionally simple. It is a substring match over names and IDs, not a claim that the application understands every synonym, spelling variation, or clinical context. A short result list is also not evidence that the atlas contains only those structures. The interface tells the reader when it is showing a limited set of matches and invites refinement. That is a useful boundary for a catalogue whose purpose is direct navigation rather than a general-purpose medical search engine.
A blank query's curated starting set serves a different purpose from a query match. It gives a reader who has not yet chosen a term a few major structures to inspect, making the search panel an entry point rather than an empty text box. Once a term is entered, the application returns the matching concept records. In both cases, the selectable object is a concept, not a raw binary range.
The difference between a concept result and a mesh result becomes useful in an ordinary inspection sequence. A reader might begin with “liver,” choose the named concept, see that the selection contains many pieces, and then open isolation to understand the selected set without the rest of the body. If one member in that set is more interesting, the included-structures list can make that piece the next direct selection. The route moves from a human-readable name to a bounded set of geometry and then back to a more specific part, without requiring the reader to know the element IDs in advance.
The search panel also preserves the distinction between matching and ranking. The application can find concepts whose names or IDs contain the query, and it sorts the visible matches by name length so shorter candidates appear first. That is a navigation convenience, not an assertion that the first result is the medically most important interpretation. The reader still needs the name, piece count, system context, and details surface to understand what was selected.
One result can select many pieces
Choosing a concept sets the scene's selected list to the concept's element IDs. The detail surface opens and reports the chosen name, its display system, its atlas reference, and the number of selected pieces.