summaryrefslogtreecommitdiffstats
path: root/docs/notes.txt
blob: 30cb1d8e774c625b39beeb67aa5d2b02d1c56e00 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
=====================
Feuille de route PFWB
=====================

Thesaurus
=========

Nom de leur DB: Tabelio

Objet KW
--------

Relations pour chaque KW:

- BT/NT: Broader-Narrower (Parent-enfant)
- EQ/UF: equiv(/inverse) ex: initiales, acronyme, etc.
- RT: Lien sémantique
- LT: réflexif (à priori pas besoin)
- NH: note historique

Un enfant peut avoir plusieurs parents => On garde une relation pour
parent-enfant, pas d'arborescence de type conteneur.

La relation EQ/UF devrait pouvoir se stocker sous la forme d'un champ de
l'objet KW (peut-être sous la forme d'une table si une note doit pouvoir
être associée à la relation).

RT: relation.

NH: champ de l'objet.

Résumé :

- champ ID
- champ Titre (dénomination du KW)
- champ Description (NH)

- champ (multi texte) EQ/UF

- champ Enfant (relation -> NT)
- champ RT (relation)

Relation parent/enfant :
Je choisis de placer la relation dans le sens suivant:
l'enfant stocke la relation 'parent' dans 1 de ses champs.
La raison est que lorsque l'on crée un nouvel objet, c'est souvent pour
l'ajouter à partir d'un point d'accroche existant (un parent).
Il est plus facil de stocker la relation dans l'objet créé que de
remonter à l'objet parent pour créer la nouvelle relation une fois
l'objet enfant lui-même créé.


Le widget
---------

Un champ texte de type autocomplete pour initier le widget.

+--------------------------------+
| search:                        |
| + - <KW>                       |
| | - <KW>                       |
| | - ...                        |
+--------------------------------+

Puis un widget de la forme:

+--------------------------------+
| search:                        |
| + - <KW>                       |
| | - <KW>                       |
| | - ...                        |
+--------+--------------+--------+
| - <BT> | **Theme KW** | - <NT> |
| - <BT> +--------------+ - <NT> |
| - ...  | - <RT>       | - ...  |
|        | - <RT>       |        |
|        | - ....       |        |
+--------+--------------+--------+
|              [cancel] [choose] |
+--------+--------------+--------+


Importations
------------

- fichier d'import : perso.entrouvert.org/~fred/thesaurus.json
  page d'import : <thesaurus_url>/import_json
  Le fichier doit se trouver sur /tmp/thesaurus.json

TODO
-----

- cleanup, move browser stuff to browser package, etc.

A faire :

- Assurer l'indexation des equivalents dans le searchable text

- Intégrer ce qu'on a fait dans de dmsdocument et créer le widget adapté
  pour le edit (+view?) du document.

- on pourrait peut-être voir si on attribue un workflow aux keywords
  (voire même aux thésaurus, je vois pas l'intérêt pour ces conteneurs
  qui sont de toute façons amenés à être utilisés, et ne sont pas soumis
  à un processus éditorial)


- vocabulaire pour autocomplete
    cf vocab pour les contacts
    + exploiter ce vocab dans une vue pour le thesaurus
    ... mh, ça semble déjà exister

TOUJOURS A FAIRE
================

- Assurer l'indexation des equivalents dans le searchable text

- bug "invalid clone vocabulary"
- 'employé pour' dans autocomplete

- Ajouter broader dans vue d'édition