129 lines
3.4 KiB
Plaintext
129 lines
3.4 KiB
Plaintext
=====================
|
|
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
|
|
-----
|
|
|
|
- finish view for kws
|
|
- give better visual id to broader and narrower regions
|
|
- better stylesheet
|
|
|
|
- cleanup, move browser stuff to browser package, etc.
|
|
|
|
A faire :
|
|
|
|
- Assurer l'indexation des equivalents dans le searchable text
|
|
|
|
- dans la vue kw: Afficher aussi les equivs de chaque kw associé
|
|
+ les notes hist et scope ?
|
|
|
|
- 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)
|
|
|
|
- Plein d'autres trucs, certainement, comme écrire des tests et préparer
|
|
l'i18n
|
|
|
|
|
|
- vocabulaire pour autocomplete
|
|
cf vocab pour les contacts
|
|
+ exploiter ce vocab dans une vue pour le thesaurus
|
|
... mh, ça semble déjà exister
|
|
|
|
questions pour demain
|
|
----------------------
|
|
|
|
- tiens, le package mailcontent n'apparait plus dans le portal_setup
|
|
- on vire le champ description d'un kw ?
|
|
|