-
Notifications
You must be signed in to change notification settings - Fork 0
Data Model and IDs
GitPKM treats CSV files as relational tables and Markdown files as narrative/knowledge pages.
For strict implementation rules, see Schema Contract.
Stable IDs are the bridge between CSV, Markdown, and scripts.
Examples:
person_alex
org_learning_hub
prog_career_mentorship
- Use descriptive, human-readable IDs.
- Avoid numeric-only primary IDs in source files.
- Do not change IDs after creation unless required for a migration.
Regex contract:
^[a-z][a-z0-9]*(?:_[a-z0-9]+)*$- Entity tables:
people.csv,organizations.csv,programs.csv - Relationship tables:
participations.csv,releases.csv
Dataset names are treated literally by the tooling.
Examples:
-
new person "Alex"writes toperson.csv -
new people "Alex"writes topeople.csv
The system does not auto-singularize or auto-pluralize dataset names.
That same exact-name rule applies to:
- note
typevalues - inferred foreign-key column names
- default relationship IDs in the CLI
id,person_id,program_id,role
part_alex_mentee,person_alex,prog_career_mentorship,mentee
part_taylor_mentor,person_taylor,prog_career_mentorship,mentorUse direct foreign keys on entity tables for simple one-to-one and one-to-many relationships.
Use relationship tables when the relation itself needs structure.
Typical cases:
- many-to-many relationships
- relationship metadata such as role, dates, status, source, or confidence
- relations that need their own stable ID and history
- relations involving more than two entities
To improve GitHub web readability, include helper columns like:
-
title_id+title_name -
platform_id+platform_name
IDs remain the source of truth.
Each entity may have a note with matching frontmatter:
---
id: person_alex
type: people
---Use relative Markdown links by ID label:
[person_alex](../people/person_alex.md)
[prog_career_mentorship](../programs/prog_career_mentorship.md)
Write inline links as [id](relative/path/to/id.md).