---
tags: 
  - note
type: "note"
univers: PERSO
projects:
  - "PROJET"
date: "2026-08-02"
priority: 10
---
# Les types de page et de note

Votre instinct est le bon, et il rejoint exactement la logique qu'on a posée avec les tags `hub`/`outil`/`notion` sur les valeurs des arts martiaux. Quelques principes pour trancher proprement.

## Critère pour décider : `type` ou simple propriété ?

Un nouveau `type` à part entière ne se justifie que si la page a besoin d'une **structure de champs différente** et/ou alimente un **workflow/dashboard spécifique**. Par exemple :

*   `contact` a besoin de `téléphone`, `email`, `dernier-contact` — des champs qu'une note "Victor Hugo" n'aura jamais.
*   `event` a besoin de `date`, `lieu`, `participants`.
*   `projet` a besoin de `statut`, `échéance`, `avancement`.

Une note sur Victor Hugo, sur un lieu, ou une note "ressource" n'a **pas de structure de champs fondamentalement différente** d'une note classique — elle a la même anatomie (définition, notions liées, contexte). Elle ne mérite donc pas un `type` dédié, juste une classification en plus.

## Ma proposition : deux propriétés distinctes, pas une seule

Vous mélangez en fait deux besoins différents dans votre question, et je pense qu'il vaut mieux les séparer :

**1\. `nature`** — ce que la note *est fondamentalement*, une classification à choix unique (mutuellement exclusive) :

```yaml
---
type: note
nature: personne
tags: [litterature, xixe-siecle]
---
# Victor Hugo
```

Valeurs possibles : `personne`, `lieu`, `notion`, `outil`, `tache`, `hub`... (vous retrouvez ici exactement le vocabulaire qu'on a défini pour les arts martiaux — c'est cohérent).

**2\. Un statut de "promotion"** — orthogonal à la nature, car une note peut être *à la fois* une note sur une personne *et* promue comme ressource de référence. Ce n'est pas une catégorie, c'est un signal de qualité/maturité :

```yaml
---
type: note
nature: personne
ressource: true
tags: [litterature, xixe-siecle]
---
# Victor Hugo
```

Pourquoi séparer les deux ? Si vous encodez "ressource" comme une valeur de `nature` au même niveau que "personne"/"lieu", vous vous bloquez le jour où une note sur un lieu (ex. un musée bien documenté) mérite aussi d'être promue "ressource" — vous seriez obligé de choisir entre les deux valeurs alors qu'elles ne s'opposent pas.

## Pourquoi `personne` (nature) ≠ `contact` (type)

C'est un bon réflexe d'avoir distingué les deux dans votre question, et ça mérite d'être explicite : la différence n'est pas le sujet ("une personne") mais **la relation que vous avez avec elle**.

*   `contact` = quelqu'un que vous connaissez réellement, avec qui vous interagissez (champs : téléphone, dernier échange...).
*   `nature: personne` = une note de type encyclopédique sur quelqu'un que vous n'avez jamais rencontré (Victor Hugo, un chercheur cité, un maître d'arts martiaux historique) — c'est une note de référence, pas une fiche relationnelle.

## Interroger tout ça dans SilverBullet

Avec cette structure, vous pouvez requêter facilement sans avoir démultiplié vos `type` :

```
${query[[from index.tag "note" where nature = "personne"]]}
```

```
${query[[from index.tag "note" where ressource = true]]}
```

```
${query[[from index.tag "note" where nature = "lieu" and ressource = true]]}
```

## Récapitulatif

| Besoin | Où le mettre |
| --- | --- |
| Structure de champs vraiment différente + workflow dédié | Nouveau `type` |
| Classification du sujet de la note (personne, lieu, notion, outil...) | `nature` (valeur unique) |
| Statut/qualité transversal (ressource, brouillon, mature...) | Propriété séparée, booléenne ou libre |
| Relation ponctuelle à un autre concept | Simple lien `[[...]]`, pas de propriété |

Ça vous garde un `type` court et stable (5-6 valeurs max), tout en gardant une granularité fine et interrogeable pour tout le reste.