PropertyExchangeFolder — the folder structure #

The central idea: the folder structure is the data model. No system of artificial database IDs, but a speaking hierarchy in which the location of a file already says what it refers to. Documents are filed as high as necessary, as precise as possible.

The tree #

ROOT/
├── PROPERTIES/
│   └── <property-slug>/                     ANCHOR: parcel number
│       ├── masterdata.xml
│       ├── <documents>.pdf
│       └── BUILDINGS/
│           └── <building-slug>/             ANCHOR: coordinates
│               ├── masterdata.xml
│               ├── <documents>.pdf
│               └── UNITS/
│                   └── <unit-slug>/         ANCHOR: floor + position
│                       ├── masterdata.xml
│                       └── <documents>.pdf
├── PERSONS/
│   └── <person-slug>/                       ANCHOR: name + date of birth
│       ├── masterdata.xml
│       └── <documents>.pdf
└── COMPANIES/
    └── <company-slug>/                      ANCHOR: commercial register
        ├── masterdata.xml
        └── <documents>.pdf

Levels and their anchors #

Every entity has an anchor — a trait that never changes and keeps its identity stable, even as names, owners or usage shift over time.

Slug rules #

The slugs are deliberately strict so they stay cross-platform and machine-readable:

• only [a-z0-9-] — lowercase letters, digits, hyphen
• no spaces, no umlauts (ae/oe/ue/ss)
• hyphen as the separator
• as short as is unambiguously necessary

Filing rules #

Documents belong where they refer to — and specifically at the most precise level that applies. A heating-cost statement for a single flat goes with the unit, a heat-supply contract for the whole house with the building, a land-register extract with the property.

Why speaking folders instead of IDs? Because the structure stays understandable without special software — in the file manager, in the backup, in ten years. That is data sovereignty in practice: you still understand your data even when the program is long forgotten.

Internationalization #

For international use, each level can additionally carry a language-independent number (e.g. 2_1_PROPERTIES). A parser then finds the right folder via the number, regardless of the linguistic name — machine-readable and human-readable at once.