# Module 1 ## Prise de note notion de supports (papiers ou numériques) dans lesquels des informations sont stockées au fil du temps – contrairement au cas d’un mémoire ou d’un article où c’est la logique de l’argumentation qui structure le contenu ### Un cahier pour chacun, et tous à prendre des notes \! Annotation d’un document lu/analysé... Ou feuilles volantes \-\> indexation ?... Est-ce seulement possible de leur donner de l’ordre a posteriori ? Sinon, est-ce vraiment complémentaire à la mémoire ? _Interview de matheuse_ : papier vs tableau pour ses brouillons... (garder les traces ou pas, mais facilité du travail de groupe) \-\> feuilles volantes, datées et numérotées Quand et comment remettre de l’ordre ? Notion de fin de séance (journée) \-\> jeter ou mettre au propre et archiver (au moins jusqu’à la publication d’un papier) \-\> après, garder les pistes intéressantes qui n’ont pas abouti (même si elle les oublie ensuite... Pas d’index fort). Recherche biblio et lecture scq... Les publications qu’elle veut ***étudier*** vraiment, elle les imprime, pour les gribouillages. Rangement dans le même genre de pochettes. (Pour les livres, elle glisse des bouts de papiers entre les pages.) Il y a aussi un équivalent électronique de ces chemises. Pas de versionnement. A fait sa thèse avant l’ordi \-\> son émergence n’a pas changé bcp sa manière de fonctionner. Pas de formation formelle, et les nouveaux font naturellement pareil. _Interview de neurophysio_ : imagerie cellulaire, élec... **cahier de manip** \-\> on note la luminosité (mesurée et affichée sur ordi), la puissance du laser, la température (résistance) \-\> faire gaffe à l’évolution (ces réf vont dans la marge) \+enregistriments numériques ? _Interview d’historienne : sur Alexandre de **Humboldt**_ en Italie (1805), savant allemand (connu pour ses expéditions en amériques centrales, un des derniers aristo dans son genre) ; carnet mystérieux car rangé avec les autres \! Pas de structure chronologique / narrative, sauf pour les mesures (datées, situées). Météorologie, notes biblio / thématiques, et **bosse à la bibliothèque vaticanes sur des documeents mexicains \! Notes à l’encre** (moment ? Elles ***n’ont pas pu être consignées sur le vif***.) \-\> une feuille volante a été conservée avec : écrite au crayon à papier \! Et on retrouve la transcription correspondante. Temps de travail / sélection entre l’initiale et la transcription. “Aspect collectif des données” \-\> source d’info, division du travail. Chance : une éruption volcanique \! Mais en fait, il recopie un collègue à qui il avait délégué la prisse de note du moment. Aussi un grand cahier ? (il s’intéresse au codex pré-colombien) il bosse un jour, un autre plus tard (la rupture ne fait pas peur, mais **note** juste **les GoTo**) _Interview d’historienne contemp_ : notes dans les archives ? Des dossiers récupérés... (“je suis une personne très scolaire”) annote complètement le dossier, et/ou en faisant des résumés (**garder des “citations”** \!) \-\> **marquer aussi “document sans intérêt”**. Ça c’est l’approche initiale... Puis vint l’informatique, mais la prise de note a peu changé. C’est la numérotation auto des notes qui est une grande aide \! Elle note aussi ce qui ne l’intéresse pas directement. Pour la phase de synthèse, comment s’y retrouver ? À l’époque papier, une synthèse par semaine, avec un “fichier papier” qui indique les documents intéressants (parfois incohérents sur des dates...) \-\> 20 ans de recherches pratiquement inutilisables... Découvertes de trésors successifs, donc bon. Chercher un nom sur l’ordinateur \-\> 150 fichiers (de tailles diverses), encombrant... Mais le bon historien fait de l’archive sans arrêt. Darwin **notait à part ses observations et ses spéculations, dans différents carnets**. Après des années de carnets, il se met à couper les pages pour les mettre dans des classeurs \! Plusieurs années de travail sur ces classeurs avant de les publier. (A continué à faire des carnets, et des “notes” à classer.) \[An introduction to scientific research, E. Bright Wilson\] Tenir un bon cahier d’expé, c’est une règle souvent violée, et qui reçoit naturellement sa rétribution négative ; seule loi consensuelle chez les chercheurs ? Matériellement, le cahier doit être résistant (coucou les chimistes). Il est intolérable d'utiliser sa mémoire ou des fragments de papier pour l'enregistrement primaire \[des observations\], du fait de l'inévitabilité des erreurs et des pertes. \=\> les écritures au crayons se détériorent trop rapidement Garder l’auteur et les dates couvertes. Garder 8 pages pour une tables des matières. Ne pas être inutilement dense... Dire quel appareil. Une description assez complète de l'appareil devrait être conservée. Ensuite, ***lorsque des modifications sont apportées à l'appareil, elles doivent être décrites immédiatement dans le cahier.*** Étalonnage, corrections... Étudier celui d’un autre chercheur. **Pouvoir _relier ses articles à ses carnets_ \!**\!\! But de l’expé, ccl° ; on note aussi ce qu’on voit, mais qu’on ne comprend pas. Consigner même les mauvaises expé, pour l’exemple au moins. Données brutes, plutôt que des transformations. Noter les unités \! Dans l’optique d’un brevet, avoir un témoin qui comprend mais n’est pas impliqué, pour authentifier régulièrement. **Les _ajouts ultérieurs_ doivent être fait dans une autre couleur.** Les éventuelles feuilles volantes doivent avoir des codes/noms qui les reconnectent directement à un cahier de référence. “Si l'on exige trop de la nature humaine, le système ne fonctionnera pas.” ### Aperçu historique (jusque là, c’était de la philo...) Matériel et organisation (tab des mtr, index \-\> marchent pour des notes \!)... (/\!\\ pdv occidental \!) tablette d’argile, de cire, volumen (-3K \-\> 4e), ~~codex~~ cahier de notes, remplis de *lieux communs* (passages les plus intéressants), fiche (19e, burocratie \! Tjrs utilisé en scs sociale), post-its, ordinateurs et tablette. Plus dur de retrouver un passage dans un ouvrage à l’épooqie du volumen (“explicare”=dérouler \+ pas d’espace ; on travaille tjrs sur 1 rouleau à la fois-\>ni commentR ni prizdeNot). Pas de “**lecture nomade**”. Au IIe, Eumène II (Pergame) vs Ptomélémé épiphane (Alexandrie) \-\> concurrence de bibliothèque, fin des exports de papyrus, développement du parchemin \! **Début de paragraphe** en rouge (*rubrication*) ; pour des raisons de coût, la couleur sera remplacée par des espace à l’apparition de l’imprimerie. Eusèbe de Césarée \-\> canon eusébien pour faciliter la comparaison des évangile (1e références croisées \!? Graphiques, ms Flavius Jo faisait du recoupmt de sources, et des tentatives d’écriture sur 4 col avait déjà eu lieu). En chine : “florilège” de citation, pour préparer ses concours. Dès le IXe, impression sur du papier. Dans le codex émerge la notion de page, mais pas encore d’espace (VII). (txt dissocié de la parole et son rythme, cf Colette Sirat) Puis arrive la ponctuation, la tab d matr, le titre courant, la marque de §, pagin°, index (XIII). Notes à “**ranger dans la bonne case**” (pvr être reclassée, ou coller, c’est un avantage) \-\> on peut aussi découper des pages dans des livres :-) Notes de code informatique pour la neuro-chimie... \=\> trois mots-clés en bas de page... Sys. De J.Locke : première lettre et première voyelle, et crée un index où il note toutes les pages qui collent. Pour Christope, ça donne : COde, NeurO, CAlcium, COurs... Bref, c’est plus facile sur ordi. Réorg plus facile. On veut la Flex d’org°, de l’Archivage fiable et une Indexation puissante. ### Langage de balisage léger Fichier texte : n’a de sens qu’avec un **éditeur de texte** (gedit, textedit) \-\> faciliter que la lecture/écriture... Mais pas encore du **traitement de texte** \! Mais les .odt et .docx ***ne sont pas*** des formats texte \! (c’est un format multi-modal, un “document” riche a priori, on a des “fontes” en vue de l’impression concrète, etc.) Problème : plus de navigation hyperlien, ni emphase, ni commentaire (mutli-user). Solution : les langages de balisage \! Pas directement lu par un humain (html), commentaire dans ce code qui ne seront jamais affichés... Par le **logiciel de rendu**. Mais la “source” reste au format texte. Lgg de balisage léger : syntaxe simple, aisé à saisir et à lire ds sa forme “non formaté”. \=\> Markdown, wikitexte, reStructuredText (doc python, en .rst) **Démonstration markdoc.** Gitlab affiche le md en html (conversion à la volée) Un hyperlien : \[Lien de md+pandoc\](https://encit1.epfl.ch/markdown-pandoc) qui ne marche pas :/ Pour macos, voir macdown ou atom ? (éditeurs markdown) **Démonstration pandoc.** Jupyter et rstudio utilisent pandoc. (Ensemble de modules d’écriture et de lecture... Il étend la syntaxe de md, laquelle n’est d’ailleurs pas tjrs en CommonMark.) *J’installe via brew.* Le bon lien, enfin \! [https://www.jdbonjour.ch/cours/markdown-pandoc/](https://www.jdbonjour.ch/cours/markdown-pandoc/) Voir aussi :TinyTex “Yihui Xie, auteur du remarquable package R "bookdown", a mis au point une version allégée de LaTeX, TinyTex ("[A lightweight, cross-platform, portable, and easy-to-maintain LaTeX distribution based on TeX Live](https://yihui.name/tinytex/)").” \[Voir surtout [blog.insileco.io](https://blog.insileco.io/2023/04/02/academic-writing-with-markdown-visual-studio-code-and-zotero/#visual-studio-code) qui devrait m'aiguiller sur un usage local de latex, vu que j'arrivais pas à installer mactex.\] #### **Text Encoding Initiative (osef)** Question de la pérennité de l'information scientifique. (de péremption, aussi, non ?) La TEI est une technique de **balisage de données** \~en vue de *recherches avec __désambigüation__*. —\> baliser des personnages, des langues de citation, des catégories grammaticales, des passages barrés... —\> codage **standard**, affranchissant ainsi ses utilisateurs de toute ***dépendance logicielle***. Normalisation n'est pas synonyme de fermeture : évolutif / extensible “Dictionnaire de basiles”, appuyé sur XML... Qui simplifie SGML=standard generalized markup lgg ; **éditeurs** tels que **XML Copy Editor**. Certains logiciels incluent un **convertisseur** ; on peut citer : le logiciel TXM, ou Odette permet de passer d'un document en traitement de texte à des données en XML/TEI. (Laurent Romary) Fun fact : les sciences humaines ont quand même une prétention à parler de causalité, parfois. Un résultat en SHS équivaut toujours à une collection / conjonction d'observations/sources que l’on peut “confirmer ou infirmer”. Ou sinon, c’est “l’analyse d’une source” le résultat. **Comment représenter ces contenus si différents ?** (bref) langage commun aux chercheurs travaillant sur des sources numériques et leur permettant de facilement mettre en commun les résultats de leurs travaux “Le fruit de leurs recherches et les analyses qu'ils en tirent peuvent être diffusés de façon transparente et lisible par d'autres collègues _partageant **le même cadre conceptuel**_ [5](https://lms.fun-mooc.fr/courses/course-v1:inria+41016+self-paced/courseware/2bfe60a86fed4994b5493a220c38eb69/13f6fd96266746a0bd9d717a12f1f835/#fn5).” Transformer le texte avant même de le lire... L’en-tête permettra d’avoir l’historique des travaux menés sur le document. Bien s’appuyer sur la doc° (genre, comment on encode les silences dans des retranscrip° d’audio) Idéalement, les membres d'un projet collaboratif maintiennent un manuel de **codage**. (Laurent Romary tjrs : viser la repro d’abord pour soi-même) How : éditeur XML (comme Oxygen) où on met le schéma des directives de la TEI. On manipule les documents encodés avec XLST (ça parle aussi de diffusion, mais osef) ### Pérennité et évolutivité des notes \-\> versionnement Nos notes évoluent : corrections, ratures, remarques... En traitement de texte, ça se fait bien. Mais le format sous-jacent nous aide pas ; pas de raison de mélanger “sauvegarde” matérielle et système de versionnement. Système type DokuWiki... On ne modifie qu’une page à la fois. Si sépare vraiment le versionnement, on a tous les changements, on peut les afficher, et on peut bosser sur plusieurs fichiers simultanément (crucial pour le logiciel). Intéressant dans un cadre collaboratif notamment. (*À ce moment précis, j'obtiens l'accès au gitlab et copie donc une partie de mes notes ici, pour la gloire de la méta.*) #### git/hub/lab Notion d'historique : faire des svgrd régulière avec des noms suffisament précis... "mon\_document\_final\_final" Les mails sont pas mieux. Gestionnaire de versions: - Conserve sans qu'on se casse le crâne sur les dossiers - Synchronisable avec une machine distante - Fusion facilitée Git créé par Linux ; utilisaient du propriétaire avant. On se synchronise soi-même, et on précise sur quels sous-dossiers. Concept1 : les "moments-clés", ou checkpoints/snapshots. Car on ne veut pas garder une granularité d'historique trop fine... `git add`... ou plutôt `git commit`, non ? L'historique ne sera pas complètement linéaire, mais il devrait y avoir une ligne principale. Cet historique est fait à une granularité "projet". Chaque version du projet ("commit" ou "révision") est identifiée par un SHA1. `diff` et `checkout` à connaître aussi. Now, comment "sauvegarder" cet historique ? Juste un serveur ? Créer d'abord à distance, cloner, bosser. Ensuite, on push chaque fois qu'on est satisfait : c'est la sauvegarde. Les "petites erreurs" qui forment des branches alternatives ne sont a priori pas transmises. Mais si besoin, on peut. Now, avec plsrs users :smiling_imp: Les "branches masters" des différents users ne sont plus les mêmes. On push régulièrement, et on pull dès qu'on se remet à bosser, ça marche tant qu'on bosse en différé. Mais si on bosse simultanément, c'est le premier qui push qui a raison\*. L'autre ne pourra plus push sur la master :'( On doit pull d'abord, et là, soit la vie est belle, soit il y a des conflits. C'est l'humain qui règle le conflit. Ce conflit (réglé) restera visible dans l'historique (ce qui facilitera le pull de l'autre belligérant). \*Notons que c'est celui qui résout le conflit qui a finalement raison. Le serveur sert d'intermédiaire ici, mais on peut faire de l'échange direct à deux. Pour éviter les conflits... ne pas faire du micro-ménage pour rien : espaces, indentations... ça multiplie les conflits. Séparer les commits de fond et de forme, donc ! Faire des petits commits logiques, bien regarder avec status diff et add. (On **doit** souvent faire plusieurs commits de suite.) Aussi, on ne peut pas gérer les conflits sur les formats inconnus... il faut privilégier le format texte ! `git log`pour voir l'historique des versions. (Il a pas expliqué `git merge` ! pour moi c'est synonyme de push...) -> il ne parle pas de la possibilité de maintenir lontemps plusieurs "branches", pour quand même les fusionner à la fin. C'est une façon de bosser à plsrs, manifestement. (Exemple intéressant : si je bosse dans le train, hors connexion.) **GitHub, GitLab** : Hébergement gratuit de projets publics, mais surtout interfaces web (navig°, édi°, etc) gestion des permissions des utilisateurs -> c'est aussi un réseau social, en un sens. (Issues et corre°, émulation, commu, revue de code...) Introduisent la notion de Fork et de "pull request". Propose de l'intégration continue, l'envoie vers des archives. Modèle économique : - GitHub : code propriétaire Payant pour le privé (hors étu/aca) - GitLab : logiciel libre une instance gitlab.com qui fournit des fonctionnalités similaires gratuites, mais surtout une deuxième version (d'entreprise), en avance de qq mois, payante. Tout le monde peut créer son instance ! Les entreprises investies peuvent influencer le dvpt de GitLab. Pour choisir, il faut savoir ce qu'on veut en matière de perrenité et de portée. GitHub est le plus gros réseau social, je dois y aller... Mais on n'est plus souverain !!! (voir aussi FramaGit, SourceForge, etc., mais plutôt chercher ce qui va "coller" à mon environnement de travail quotidien : Rstudio, JupyerLab-git, diverses extensions...) (Le tuto libreoffice me laisse comprendre que ce n'est pas ouf pour le versionnement.) ### Étiquette et indexation "*Plus grande est la qtt d'objets amassée, plus petite est leur utilité*" Leibniz Besoin d'ordonner, de s'y retrouver... moteur de recherche ? Pour les notes papier, on a la méthode de J.Lock. On peut repenser à l'armoire de Leibniz... Mais ça ne fonctionne que si l'on n'a qu'un seul "type" de document. Now, images, textess, autres datasets... Tout peut s'étiquetter. Moteur de recherche de bureau : DocFetcher (inter-plateforme). Avec un mot, on est souvent submergés par les résultats. "Travail de l'indexeur d'un livre" qui doit identifier le concept dans ses bonnes invocations. Markdown pas vraiment fait pour étiquetter des mots-clés, mais on peut le faire en commentaire. `` Mais commment mettre des étiquettes à une image ? Il faut aller dans les méta-données (une solution : ExifTool). \=\> **champs commentaire** ! EXIF = exchangeable image file format (facile d'accès sur Mac sans plus d'outil) NB. : il met ses étiquettes entre `:deux-points:` mais je crois que ça n'est qu'une *convention*. #### Docfetcher C'est open source, j'installe. => mais MacOs ne veut pas l'ouvrir. Zut. ~~Par ailleurs, la recherche du Finder n'exploite pas les mots-clés... :/~~ Si ! Mais tu peux lui laisser au moins 24h pour indexer... J'avorte la mission, du coup. (En fait, l'utilisation de "mots-clés" ne me semble vraiment pas être un bon moyen de trier ses documents. On devrait gérer soi-même une arborescence de fichier, quitte à subir "l'arbitraire" de la succession des embranchements, qui m'agace (task/xpo/measure/model... ici, ça peut se hiérarchiser), mais le problème des mots-clés, c'est leur manque de *typage*, et donc de hiérarchie implicite : or il y a des mots-clés ambigus, et j'ai bien peur que rajouter des préfixes ou des suffixes de typages ne soit pas une bonne idées...) (Par ailleurs, la gestion de son arborescence a le mérite de permettre une utilisation claire des fichiers par mes algos, à condition d'avoir une convention de nommage des fichiers — et il en faut toujours une, l'arborenscence perment de situer l'arbitraire de la convention à un plus haut niveau, plutôt que ``polluer'' les noms de fichiers...) - exiftool ne veut pas non plus s'ouvrir De toute façon, je n'avais pas d'intérêt à l'installer vu que je n'exploite pas ou peu les méta-données... Sa démo me montre que je n'en ai même pas besoin. (Néanmoins, penser à **renseigner la provenance** des images qu'on télécharge, c'est important.) (Pour constater qu'on est au cœur du brocoli, [voir ce que font des galleries d'images en terme de moteur de recherche personnel](https://blog.pics.io/how-to-search-for-files-by-metadata-best-practices/#advanced-metadata-search)) (Je découvre le concept d'apparât savant ou "appareil critique" d'un livre/article.) J'ai testé grep, ils l'évoquent, mais ma recherche (visant les méta-données) ne m'a pas donné satisfaction... "Une version plus sophistiquée de grep est fournie par le programme cgvg." - une alternative à DocFetcher et SpotLight : Recoll ? semble être un usine à gaz... "Recoll is a full text search application, which means that it finds your data by content rather than by external attributes (like the file name). You specify words (terms) which should or should not appear in the text you are looking for, and receive in return a list of matching documents, ordered so that the most relevant documents will appear first." => j'arrive pas à choisir un dossier de recherche... et n'évoquent pas les metadata d'images... (mais le cours dit qu'il fait...) En plus de l'EXIF, y'a d'autres formats de méta-données. L'Extensible Metadata Platform (XMP) introduit poour les pdf, par ex., qui contient un champs keywords !