84 lines
4.3 KiB
Markdown
84 lines
4.3 KiB
Markdown
---
|
|
profile: entities
|
|
outbound:
|
|
entities: [depends-on, required-by, runs-on, hosts, uses, produces, consumes, maintains, owns, authored, alternative-to, implements, part-of, composition, supersedes, derived-from, adapted-from, see-also]
|
|
concepts: [implements, exemplifies, rests-on, applies-when, operates-on, invokes, authored, alternative-to, see-also]
|
|
sources: [evidenced-by, defined-in, see-also]
|
|
comparisons: [compares-with, see-also]
|
|
required_by_stack: false
|
|
---
|
|
|
|
# kb/entities/ - Collection Contract
|
|
|
|
Concrete things that exist: a project, a deployed system, a CLI tool, a technology, a person or
|
|
an organization. If it can be pointed at, it is an entity.
|
|
|
|
**Quality goal:** pointability + currency - a reader should come away knowing what the thing
|
|
is, where it actually is, and whether that is still true. An entity page that describes a
|
|
system correctly but names no host, path, version or status has not earned its keep.
|
|
|
|
Inherits [kb/CONTRACT.md](../CONTRACT.md) for the rules the stack enforces - linking mechanics,
|
|
provenance, citation, the confidence machinery - and
|
|
[kb/CONVENTIONS.md](../CONVENTIONS.md) for what this instance decided: language, naming forms,
|
|
tone, relationship labels, the confidence rubric. Neither is restated here.
|
|
|
|
## Types offered
|
|
|
|
`entity` (`tools/wikitool types describe entity`). The `entity_type:` field selects the area:
|
|
|
|
| Area | Holds |
|
|
|------|-------|
|
|
| `projects/` | Codebases and initiatives, named after their repository or common name |
|
|
| `systems/` | Deployed and running systems, given a descriptive name |
|
|
| `tools/` | CLI and desktop tools, named as the tool names itself |
|
|
| `technologies/` | Protocols, languages, formats, in their standard spelling and capitalization |
|
|
| `people/` | People and organizations, by full name or common handle |
|
|
|
|
These are areas, not collections: they inherit this contract and carry no `COLLECTION.md`.
|
|
|
|
## Per-area emphasis
|
|
|
|
- **Projects** - purpose, status, language/stack, owner, repository, dependencies on other
|
|
projects and systems, architectural decisions.
|
|
- **Systems** - purpose, components, dependencies, configuration locations, deployment,
|
|
operational status, monitoring.
|
|
- **Technologies** - purpose, use cases, trade-offs, version compatibility, which projects and
|
|
systems use it.
|
|
- **Tools** - purpose, installation, usage, notable options, which projects use it.
|
|
- **People** - role, affiliation, and the projects or decisions they are connected to. Nothing
|
|
personal beyond what the source states.
|
|
|
|
## Authorised labels
|
|
|
|
The `outbound:` block above is what `wikitool lint` and `xref add` check: which labels a page in
|
|
this collection may use, per destination. The catalogue they are drawn from - and what each one
|
|
asserts - is [instructions/link-taxonomy.md](../../instructions/link-taxonomy.md), which binds
|
|
nothing on its own.
|
|
|
|
Operational labels dominate here because an entity's relationships are mostly to other concrete things. `implements` points *out* to a concept; the concept does not point back unless that direction is a statement of its own.
|
|
|
|
Three of these carry a caveat this area produces more often than the others. `authored` belongs
|
|
on a person page pointing at what they made, and it is the label a dead or departed creator
|
|
takes - `owns` claims someone answers for the thing *now*. `alternative-to` is self-dual and is
|
|
written **once per pair**, never from both ends: a set of interchangeable tools is where a
|
|
mirrored clique grows fastest. `derived-from` and `adapted-from` are here for the fork and the
|
|
re-implementation - one tool worked up out of another - which is a lineage claim the operational
|
|
labels cannot make.
|
|
|
|
Adding a label here is a deliberate contract change, not a way around a refusal.
|
|
|
|
## Outbound linking
|
|
|
|
An entity links to the technologies it uses, the systems it runs on, the projects that depend
|
|
on it, and the concepts it implements.
|
|
|
|
An entity that mentions a concept without linking it is incomplete; the concept page is where
|
|
the *why* lives, and the entity page should not restate it.
|
|
|
|
## What does not belong here
|
|
|
|
- A pattern, protocol, architecture or decision - those are concepts, even when only one entity
|
|
uses them.
|
|
- A page about a source document - that is a `source` page in `kb/sources/`.
|
|
- Singular naming is required: `HA Integration.md`, not `HA Integrations.md`.
|