Can Abstract Location Modeling Make You a Real Technical Expert?

Model: Abstracting Reality

When we consider programming as a domain, we can try to abstract the surrounding space into a model that can be stored as data. The concept of "where" varies dramatically depending on context: a family member may answer "living room", a traveler may answer a city, a delivery service may need a district, and a logistics system may need a province or country.

Modeling Position

In code, the same notion of position can be represented in several ways:

A GEO coordinate with longitude and latitude for location‑based advertising.

An indoor location such as bedroom, kitchen, or living room for smart‑home devices.

A building floor (e.g., basement, first floor) for package delivery.

A city district for determining quarantine zones.

A province or state for calculating shipping costs.

Because the meaning of "position" changes with the audience, collaborative modeling helps reduce ambiguity. A simple IP‑lookup API might return a JSON structure like the following:

{
  "address": "CN|北京|北京|None|CHINANET|1|None", // detailed address
  "content": {
    "address": "北京市",
    "address_detail": {
      "city": "北京市",
      "city_code": 131,
      "province": "北京市"
    },
    "point": { "x": "116.39564504", "y": "39.92998578" }
  },
  "status": 0 // result code
}

Having such classifications raises the question: does mastering these categories make us experts in geographic modeling?

New Abstract Concept: Administrative Divisions

Administrative divisions can be viewed as hierarchical layers. In China there are 34 first‑level units (23 provinces, 5 autonomous regions, 4 municipalities, 2 special administrative regions). Other countries have different hierarchies, e.g., Russia’s federal districts, Chechen Republic, etc., and the United Kingdom includes colonies, islands, and parishes. A generic hierarchy can be expressed as:

Level‑1 administrative unit

Level‑2 administrative unit

Level‑3 administrative unit

Level‑4 administrative unit

Level‑5 administrative unit

Each country can therefore report how many levels it uses and the names of those levels.

Abstraction: Solving Problems with Simpler Models

Higher‑level abstractions make problem solving easier, but they incur a cost. Different abstraction strategies include:

Analogy: province‑city‑district‑street → administrative region.

Classification: map analogies to first, second, third‑level administrative units.

Meta‑model: combine analogies and classifications into a hierarchical tree.

From a coding perspective, the implementation cost grows dramatically with deeper abstraction layers. Simple analogies are the cheapest.

Full Set vs. Abstract Model

When building a location model, constructing a complete set of possible locations has the lowest implementation cost because the attribute space is limited and changes slowly. However, other domains (e.g., smart‑home devices) can grow indefinitely. OpenHAB’s location hierarchy is an example of a full set:

Location:
- Indoor
- Building: Garage, House, SummerHouse
- Floor: Attic, Basement, GroundFloor, FirstFloor, SecondFloor, ThirdFloor
- Room: Bathroom, Bedroom, BoilerRoom, DiningRoom, Entry, FamilyRoom, GuestRoom, Kitchen, LaundryRoom, LivingRoom, Office
- Corridor
- Apartment
- Outdoor: Carport, Driveway, Garden, Patio, Porch, Terrace

With such a taxonomy, an expert can abstract, classify, and extract a meta‑model.

Abstract Behavior

Once an abstract model exists, we can define a domain‑specific language (DSL) to describe interactions. OpenHAB’s Rule DSL illustrates this:

rule "Start wake up light on sunrise"
when
  Channel "astro:sun:home:rise#event" triggered
then
  switch(receivedEvent.getEvent()) {
    case "START": {
      Light.sendCommand(OFF)
    }
  }
end

Elevating the problem to this level simplifies implementation and enables integration with voice‑controlled devices.

Meta‑Model: A Type System

Introducing devices creates a domain‑specific type system where each device has a name, attributes, and capabilities. For example, a living‑room light can be described as:

#Room
name: 灯
location: Indoor::Room::LivingRoom
category: Lightbulb
property: [
  { name: 'light', type: Lighting, value: 38 },
  { key: 'color', type: ColorItem, value: '#123456' }
]

Values can be of types such as Color, Number, Int, Image, Location, DateTime, Switch, etc. A Switch belongs to OnOffType, which includes state and command sub‑types. This recursive classification leads to a costly but expressive type system.

Cost of Building Abstractions

The purpose of building models is either to facilitate everyday communication or to preserve knowledge for future generations. A true expert can quickly draw analogies across domains, much like a top student excels in learning and exams.