ph-submissions icon indicating copy to clipboard operation
ph-submissions copied to clipboard

Evaluation de leçon: Concevoir une recherche en sciences humaines en termes de données

Open spapastamkou opened this issue 2 years ago • 26 comments

Le Programming Historian en français a reçu la leçon "Concevoir une recherche en sciences humaines en termes de données (et ne pas mourie en essayant)" de @digitalkosovski . Cette leçon est maintenant en cours d'évaluation. Une prévisualisation est disponible ici:

http://programminghistorian.github.io/ph-submissions/fr/en-cours/originales/concevoir-recherche-donnees-nodegoat

J'assume le rôle de rédactrice en charge du suivi du processus de l'évaluation. Dans ce cadre, je vais solliciter deux relectures auprès de la communauté et coordonner les échanges qui auront lieu dans cet espace. Les relecteurs / relectrices peuvent utiliser la numérotation des lignes fournie dans l'aperçu pour organiser leurs commentaires, si cela leur convient, tout en restant libres de présenter leur évaluation de la manière qui leur semble la meilleure.

Tout membre de la communauté peut faire un retour constructif sur ce fil de commentaires, après avoir pris connaissance de nos consignes aux évaluateurs et évaluatrices et accepté notre politique contre le harcèlement (voir ci-dessous). Nous demandons que toutes les relectures cessent après réception de la seconde évaluation formelle, pour que l'auteur puisse travailler sur la révision de son texte. Le rédacteur l'annoncera sur ce fil quand cette étape aura été atteinte.

La discussion s'organise au niveau de Github. Si quelqu'un préfère de discuter de manière privée, merci de m'envoyer un message électronique. Vous avez toujours la possibilité de vous tourner vers notre médiatrice Hélène Huet si vous avez le sentiment qu'une médiation est nécessaire. Ceci ne risque d'avoir aucune incidence négative sur l'évaluation de cette leçon.

Politique contre le harcèlement

Vous trouverez ci-dessous les principes du Programming Historian en français qui doivent inspirer les échanges entre évaluateurs et évaluatrices, auteur(e)s, rédacteurs et rédactrices, ainsi que toute personne contribuant à nos forums publics.

Le Programming Historian en français tient à garantir un environnement académique ouvert à la communauté, qui offre la pleine liberté d’explorer minutieusement des idées, poser des questions, faire des suggestions ou demander des clarifications. Il fournit aussi un espace libre de toute discrimination envers les personnes contribuant au projet indépendamment du genre, de l’orientation sexuelle, des situations d’handicap, de l’apparence physique, de la masse corporelle, de l’origine, de l’âge, de la religion ou de l’expérience technique. Nous ne tolérons aucune forme d’harcèlement ou d’attaque personnelle contre les membres de la communauté. Les personnes qui violent ces règles sont susceptibles d’être expulsées de la communauté à la discrétion du conseil éditorial. Toute personne en mesure de témoigner de tels comportements ou qui en est la victime peut contacter notre dispositif de médiation (Hélène Huet). Merci de nous aider à créer un espace d’échange et de discussion sûr.

Modèle de cession non-exclusive des droits d'exploitation pour les auteurs (à déposer sous forme de commentaire dans ce fil).

Je [prénom, nom] auteur(e) cède à ProgHist Ltd de manière non-exclusive notamment le droit de publier le tutoriel dont il est question dans ce ticket (y compris le résumé, les tables, les illustrations, les données, et des ressources supplémentaires) sous licence CC-BY.

spapastamkou avatar Mar 01 '22 12:03 spapastamkou

A présent il existe un problème d'affichage de la deuxième table de la leçon qui a une largeur considérable et dont une partie n'est pas visible à l'affichage. Je m'emploie pour la rendre scrollable à l'horizontale et signalerai ici quand ce sera bon.

spapastamkou avatar Mar 01 '22 12:03 spapastamkou

Merci, Sofia.

Je Agustin Cosovschi auteur(e) cède à ProgHist Ltd de manière non-exclusive notamment le droit de publier le tutoriel dont il est question dans ce ticket (y compris le résumé, les tables, les illustrations, les données, et des ressources supplémentaires) sous licence CC-BY https://creativecommons.org/licenses/by/4.0/deed.fr.

On Tue, Mar 1, 2022 at 1:34 PM Sofia Papastamkou @.***> wrote:

A présent il existe un problème d'affichage de la deuxième table de la leçon qui a une largeur considérable et dont une partie n'est pas visible à l'affichage. Je m'emploie pour la rendre scrollable à l'horizontale et signalerai ici quand ce sera bon.

— Reply to this email directly, view it on GitHub https://github.com/programminghistorian/ph-submissions/issues/459#issuecomment-1055397799, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKYIBNTODUJKZENWG56G6SDU5YFEZANCNFSM5PT3KKZQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

-- Agustín Cosovschi Ph.D in History Research Assistant (Université Paris Nanterre) and SSHRC-funded Postdoctoral Fellow (University of British Columbia) https://acosovschi.com/

digitalkosovski avatar Mar 01 '22 13:03 digitalkosovski

@digitalkosovski Je vous remercie pour ce tutoriel clair, bien écrit et facile à suivre. J'ai formaté le fichier md et j'ai fait une relecture préliminaire de votre leçon.

  1. Avant toute chose, je vous fais une liste de quelques modifications apportées à ce stade par mes soins:
  • par rapport au texte original, j'ai fait silencieusement (= sans vous interpeller pour les faire) quelques corrections de coquilles / petites modifications en accord avec l'écriture inclusive
  • j'ai ajouté un sous/titre introduction à votre premier paragraphe pour plus de clarté dans l'organisation de la leçon
  • j'ai mis en gras les titres de trois tables (et donc intégré dans le corps de texte) en enlevant les niveaux de titres qui faisaient que les tables apparaissaient dans la table de matières comme des sous-parties séparées
  • j'ai renommé les fichiers des captures d'écran qui accompagnent la leçon avec un nom de fichier signifiant (Fig étant très générique et pouvant générer des confusions dans un dépôt qui accueille les fichiers de plusieurs leçons, j'ai utilisé tout simplement nodegoat avec une numérotation séquentielle (par ex. nodegoat-01.png). Si vous souhaitez renommer ces fichiers en utilisant le slug de la leçon ou autre nom descriptif, vous pouvez le faire, mais merci de penser à modifier dans ce cas aussi le nom des fichiers correspondants à l'intérieur du fichier markdown, sinon les liens vers les images ne fonctionneront pas. De même, pour l'ensemble de ces modifications, vous pouvez intervenir vous-même, si vous le souhaitez, pour les adapter selon comme vous pensez mieux pour votre texte.
  1. Ensuite, j'aimerais vous proposer de faire des ajouts, modifications ou précisions (lorsque des numéros de paragraphes sont mentionnés, se référer à la prévisualisation de la leçon):
  • [x] modifier légèrement le titre de la leçon, de manière qu'il puisse être facilement compréhensible et pertinemment indexé: par exemple, Concevoir une recherche en sciences humaines en termes de données à l'aide de nodegoat. J'ai déjà façonné le slug dans ce sens, pour que la leçon soit bien indexée dans le web, mais cela aiderait que l'intitulé le soit aussi. Vous pouvez peut-être glisser la petite phrase amusante dans l'introduction pour ne pas trop s'éloigner de votre proposition initiale?
  • [x] ajouter des titres aux images, en les insérant directement dans les liens vers les images que j'ai insérés dans le texte (à la place de: "Sans titre"): en l'état, aucune capture n'a de titre, par conséquent les légendes ne comportent pas d'informations sur les images affichées.
  • [x] préciser quelle version de nodegoat a été utilisée pour la réalisation de la leçon et des captures d'écran (version actuelle: 7.3)
  • [x] insérer des liens vers des ressources pertinentes en français et libres d'accès (le plus souvent cela peut être Wikipédia, mais à vous de voir) pour expliquer certains termes mobilisés dans le texte:
    • [x] paragraphe 6, première phrase: données
    • [x] paragraphe14: jeu de données
    • [x] paragraphe 18: base de données (et peut-être sans italique?)
  • [x] ajouter, la première fois que nodegoat est évoqué dans le texte, une référence pour citer le logiciel: Bree, P. van, Kessels, G., (2013). nodegoat: a web-based data management, network analysis & visualisation environment, http://nodegoat.net from LAB1100, http://lab1100.com Vous pouvez enlever par la suite les références directes à LAB1100 dans le texte (par ex., paragraphes 28 et 29) puisque l'information sur les créateurs aura été fournie correctement via la citation et est d'ailleurs accessible via le site web auquel un lien dans une autre partie du texte renvoie.
  • [x] quand Excel est évoqué, le remplacer plutôt par tableur si possible: il s'agit d'une application propriétaire et ce qui intéresse ici fondamentalement est le côté tableur
  • [ ] Remarques sur les tables 2 auteurs et 3 maison d'édition, paragraphes 25 et 26:
    • [ ] table 2 auteurs: j'aurais tendance à proposer pour cette table-ci, puisque l'objet/entité est l'auteur, de distinguer une colonne nom et une colonne prénom pour avoir une colonne = une donnée.
    • [x] table 3 maison d'édition: modifier l'intitulé de la colonne Maison d'édition à Nom ou quelque chose de la sorte (puisque on sait déjà que l'objet de la table est Maison d'édition, faire comme pour la table 1 où on n'a pas colonne ouvrage, mais titre). Ne pas donc avoir l'objet/entité comme attribut pour éviter la confusion.
  • [x] paragraphe 30: ajouter "espace de travail" entre parenthèses à la suite de "domaine" pour comprendre plus facilement de quoi il s'agit (en donnant une alternative au termes propres au logiciel)?
  • [ ] paragraphe 35, au sujet de la phrase suivante: chaine de caractères, numéro, date ou autre
    • [x] remplacer "numéro" par: nombre entier
    • [x] ajouter entre parenthèses les termes correspondants en anglais de l'interface de nodegoat lorsqu'ils sont évoqués en français directement
    • [ ] rappeler - éventuellement, et si vous êtes à l'aise - que dans d'autres SGBD on peut trouver d'autres termes pou désigner les mêmes choses, par ex. various characters (VARCHAR) pour chaîne de caractères. (Cela pourrait aussi être le cas lorsque vous parlez d'objets que nous pouvons trouver aussi comme entités). En ce sens, la lecture du tutoriel sur Heurist, que nous publierons prochainement, pourrait vous être utile au moment de la finalisation de votre leçon.
  1. Enfin, j'ai quelques commentaires sur le fond:
  • [x] Dans l'introduction, paragraphe 4, point 2: il me semble que parler de base de données orientée objet peut prêter à la confusion, car la leçon se concentre davantage sur les modèles relationnels.
  • [ ] Sur l'ensemble de la partie Penser en termes de données: un défi conceptuel: il me semble qu'il y a intérêt à renforcer un peu cette partie en références, sans forcément l'augmenter en volume. Jean-Philippe Genet, en français, ou encore Manfred Thaller (il existe des textes aussi en anglais surtout dans son blog Digital Ivory Tower sur hypotheses) ont parlé de ce qui est décrit dans votre texte par le terme de traduction pour désigner le passage à des données structurées et exploitables à des fins d'analyse via l'utilisation de logiciels. Serge Abiteboul a parlé du triangle données-informations-connaissances dans sa leçon inaugurale au Collège de France, en libre accès sur Books d'OpenEdition; Johanna Drucker sur les data versus capta; et le classique de Lemercier et Zalc sur les méthodes quantitatives peut aussi offrir des pistes sur les méthodes d'analyse possibles à appliquer lorsque nous travaillons avec des données structurées (ce qui est un des avantages présentés dans votre dernier paragraphe).
  • [x] paragraphe 12: il est très clair que le projet de recherche est hypothétique, mais néanmoins est-il possible de donner quelques pistes sur quoi cela pourrait porter pour nécessiter la création d'une base de données? Pour inspirer le lectorat (il y a en qui pourraient se poser la question pourquoi ne pas faire une simple bibliothèque dans Zotero). Vous évoquez par ex. plus bas qu'il est possible de travailler sur la circulation des livres.
  • [ ] la figure 1 correspond au modèle conceptuel des données et la figure 2 s'approche du modèle logique, mais ces phases ne sont pas clairement nommées dans le texte (on peut y ajouter le modèle physique), qui pourtant les décrit. Il serait peut-être utile de le faire. Dans tous les cas, je pense qu'il sera besoin, peut-être à un stade ultérieur, de produire aussi une capture avec le modèle logique des données (pour avoir au moins l'identifiant dans chaque cas décrit, sinon aussi le type de la donnée concernée à chaque fois: integer, various characters etc) pour initier le lectorat aux bonnes pratiques de la modélisation (voire à la nécessité de structurer les données d'une certaine manière, sinon cela ne marchera pas).
  • [ ] paragraphe 27:
    • [ ] peut-être évoquer brièvement quel est l'intérêt pour relier les tables: croiser les données de manière pertinente et rapide.
    • [ ] "Ce type d’opération se fait souvent sur une application comme Excel qui permet de connecter des tableurs multiples" => il me semble que c'est là où les tableurs atteignent leurs limites et qu'on est ainsi amené à faire recours aux bdd.
  • [x] Pour la fin de la leçon: il serait bien de rappeler brièvement l'importance de sauvegarder tout de même ses données; aussi rappeler les possibilités qu'offrent pour l'analyse les bases de données.

Je vous invite donc:

  • à prendre connaissance de la partie 1 de ce commentaire et le cas échéant de réajuster certaines des modifications, si vous ressentez le besoin;
  • à vous inspirer de ce que je vous propose dans la partie 2 pour revoir le texte et le modifier à votre guise, ce qui permettra de proposer aux évaluateur/évaluatrices un texte mis à jour - et on peut en discuter bien sûr si besoin;
  • à lire les commentaires sur le fond, mais peut-être qu'il serait plus pertinent et à la fois pratique de les revoir à la lumière des évaluations qui seront faites et, le cas échéant, en tenir compte au stade des modifications finales.

Une fois donc que vous aurez pu tenir en compte les parties 1 et 2, nous pouvons lancer les évaluations. Je reste à votre disposition pour quoi que ce soit.

spapastamkou avatar Mar 01 '22 17:03 spapastamkou

@digitalkosovski Merci pour le commentaire sur la cession des droits!

spapastamkou avatar Mar 01 '22 17:03 spapastamkou

@spapastamkou I've changed the CSS file in this repo as well (without PRs or anything); so go ahead and edit the file to include HTML and fingers crossed that it works in the preview.

<div class="table-wrapper" markdown="block">
 TABLE
</div>

jenniferisasi avatar Mar 01 '22 18:03 jenniferisasi

@jenniferisasi Will do, thanks a lot!

spapastamkou avatar Mar 01 '22 18:03 spapastamkou

Ha, so we got the scroll option... but now the format is off 😅 one step at a time

update: took down the div but didn't work either. Looking for solutions, it has to do with markdown not liking being wrapped in HTML

jenniferisasi avatar Mar 01 '22 19:03 jenniferisasi

Merci beaucoup pour tous les commentaires et suggestions. Je travaillerai sur tout ce qui concerne la partie 1 et 2 d'ici la semaine prochain afin de pouvoir envoyer le tutoriel à évaluation dès que possible.

digitalkosovski avatar Mar 02 '22 08:03 digitalkosovski

Bonjour,

Juste un mot pour m'excuser de ce retard. Je vous enverrai une nouvelle version avec les modifications suggérées dans les parties 1 et 2 de vos commentaires d'ici la fin de la semaine.

digitalkosovski avatar Mar 28 '22 09:03 digitalkosovski

Merci @digitalkosovski pour cette mise à jour, on est donc dans l'attente de la version revisée, on pourra continuer le processus d'évaluation par la suite.

spapastamkou avatar Mar 28 '22 21:03 spapastamkou

Pour information, le problème du tableau a été résolu, il est bien scrollable!

spapastamkou avatar Mar 28 '22 21:03 spapastamkou

Hello all,

Please note that this lesson's .md file has been moved to a new location within our Submissions Repository. It is now found here: https://github.com/programminghistorian/ph-submissions/blob/gh-pages/fr/en-cours/originales/

A consequence is that this lesson's preview link has changed. It is now: http://programminghistorian.github.io/ph-submissions/fr/en-cours/originales/concevoir-base-donnees-nodegoat

Please let me know if you encounter any difficulties or have any questions.

Very best, Anisa

anisa-hawes avatar Apr 07 '22 21:04 anisa-hawes

@digitalkosovski Je viens de finir de vérifier les premières modifications que vous avez apportées après mon retour préliminaire et dont je vous remercie. J'ai coché les cases de la partie 2 de mon commentaire ci-haut en fonction. J'ai vu que vous avez modifié le titre dans les métadonnées de la leçon, et je vous en remercie, mais il faudra peut-être le revoir, pour éviter qu'il soit trop long, l'alléger en ponctuation et, aussi, je crains qu'il vaudra mieux éviter le second degré pour rester dans le sryle habituel du PH. Mais nous aurons le temps pour revoir cela ensemble: pour le moment, je me concentre sur la recherche d'évaluateurs et reviens vers vous dès que j'aurai un peu plus de nouvelles.

spapastamkou avatar Apr 18 '22 20:04 spapastamkou

Marie Delcourte Debarre a accepté d'être évaluatrice de cette leçon. J'ajouterai ici son nom d'utilisatrice GitHub dès que je l'aurai reçu.

C'est donc @MDelDebarre la première évaluatrice de cette leçon.

spapastamkou avatar Apr 28 '22 06:04 spapastamkou

Octave Julien @octave-julien et Solenn Huitric @shuitric évalueront aussi cette leçon. Nous prévoyons ainsi, de manière large, d'avoir les retours vers la fin juin (notez cela @MDelDebarre, si jamais cela vous arrange aussi). Merci à tous les trois!

spapastamkou avatar May 13 '22 11:05 spapastamkou

Bonjour,

Merci à @digitalkosovski pour cette proposition de leçon et à @spapastamkou pour tout son travail. Voici mon évaluation de la leçon.

Remarques générales

Comme le montre son plan, l'article se propose d'introduire le lecteur à trois choses : la question des données dans une recherche en histoire, le modèle des bases de données (BDD) relationnelles, et le logiciel nodegoat. Ce triple objectif parait très ambitieux pour un article de la taille de ceux publiés dans le Programming historian. En effet, chacune des parties appelle de nombreux développements, précisions et nuances (voire des corrections). Même si elles ne prétendent que constituer une introduction à l'un de ces sujets, il manque des éléments clés pour leur compréhension. Il faudrait sinon réduire ces ambitions, et se concentrer sur l'une des parties.

Remarques sur le fond

1) "Penser en termes de données : un défi conceptuel"

Cette partie illustre bien l'alternative évoquée ci-dessus. Elle est soit trop rapide, soit trop longue. Rappeler l'intérêt du traitement des données pour les historien·nes est bienvenu dans le cadre de cet article, mais si l'on veut développer cette idée (si tant est que le Programming Historian est le lieu pour cela), il faut aller plus loin dans la réflexion. L'idée que les données sont construites peut être étayée en renvoyant à la notion de capta (Johanna Drucker) ou d'obtenues (Bruno Latour).

D'autres questions ou enjeux pouvaient être abordés dans cette première partie, pour justifier l'usage d'une base de données ou pour mieux l'aborder, par exemple (liste non exhaustive) :

  • l'objectif d'une analyse quantitative
  • la représentativité du corpus étudié
  • l'utilisation de données tirées directement des sources, déjà structurées : l'hypothèse n'est pas envisagée et elle est même écartée implicitement par l'attention portée à la construction des données, alors qu'une base de données peut reprendre des informations élémentaires présentes dans les sources (quantités et types d'objet dans un inventaire, par exemple).

2) Base de données et modèle de données

L'exemple de la base de données de livres dissidents permet de bien faire comprendre la nécessité et l'interêt d'une base relationnelle. Mais si cette partie vise à être une introduction à ce modèle, il manque des choses dont on ne peut pas faire l'économie.

Il faut d'abord préciser ou revoir la définition des notions "base de données" et "relationnelle". Il existe de nombreuses définitions françaises de BDD (Georges Gardarin ou Marc Humbert, par ex.) mais celle au début du ¶ 18 ne convient pas, car elle manque de précision. Le ¶ précédent laisse penser qu'une BDD est nécessairement composée de plusieurs tableaux, ce qui est faux. C'est le propre des BDD relationnelles comme il l'est d'ailleurs expliqué au ¶ 18.

L'article présente certaines des notions clés (enregistrement, attribut) mais il en manque d'autres, par exemple la cardinalité. Cette notion de cardinalité est absente dans l'article alors qu'elle est absolument incontournable, et que celles et ceux qui se lancent dans la construction d'une BDD doivent en être conscients dès le départ (par exemple, comment modéliser en même temps, sans redondance, le fait qu'un livre puisse être écrit par plusieurs auteurs à la fois, et qu'un auteur a pu écrire plusieurs livres ? Ou qu'il puisse être coédité et publié dans différentes villes ?). Idem pour les notions de clés primaire et étrangère. La notion d'atomicité est évoquée au début ("unités discrètes" ¶6), et elle est illustrée dans les tableaux fournis comme exemple, mais il faut insister dessus car elle est centrale dans le processus de modélisation et elle conditionne les analyses qu'on peut ensuite tirer de la BDD. Toujours dans la terminologie, il faudrait indiquer (voire adopter) le terme de "table" qui désigne un tableau dans le modèle relationnel. Attention aussi à la confusion entre "tableur" et "tableau" (¶ 23)

Comme l'a indiqué Sofia, il faudrait peut-être préciser qu'on distingue habituellement les modèles conceptuel, logique et physique des données.

L'équivalence posée entre table et objet ne se vérifie pas toujours : on peut utiliser une table distincte pour enregistrer des attributs multiples (par ex. si on avait des ouvrages collectifs avec des articles dans différentes langues).

Il y a à mon sens une erreur dans la modélisation proposée comme exemple : la ville de parution est celle de la maison d'édition, et devrait donc apparaitre dans cette table.

Revoir aussi l'exemple du ¶ 16 : le tableau ne donne aucune info (en tout cas pas explicitement) sur les choix de traduction et sur la taille des villes de naissances des auteurs.

Au ¶ 27, il est dit qu'un tableur comme Excel permet de connecter des tableaux multiples pour reproduire cette logique. C'est certes possible, mais très incommode, et c'est pour cela qu'on privilégie plutôt les systèmes SQL pour créer une BDD relationnelle. Dans le même paragraphe, je ne suis pas sûr qu'on puisse qualifier chaque tableau de "jeu de données". Je dirais plutôt que le jeu de données est composé de ces différents tableaux.

3) Construire et gérer sa base de données avec nodegoat

L'expression "orienté objet" me parait très ambiguë et devrait peut-être être évitée, ou explicitée. L'article semble faire une équivalence entre "orienté objet" et "relationnel", ce qui n'est pas ce qui est dit sur la page de présentation de logiciel. De plus, en programmation (et pour beaucoup de lecteurs du PH), "orienté objet" signifie tout autre chose.

Cette présentation de nodegoat est intéressante et c'est sans doute ce qui devrait être développé pour être au cœur de l'article.

Il faudrait que le lecteur puisse savoir dans quelle mesure nodegoat permet de résoudre les problèmes traditionnels de modélisation (cardinalité n à n, par ex., données floues).

Il serait utile de développer les limites de l'outil (système propriétaire, en ligne) et ses caractéristiques les plus originales :

  • Possibilité d'utiliser les métadonnées Dublin Core et CIDOC CRM (et d'autres s'il y en a)
  • Représentation des données sous forme de graphe
  • Gestion des données spatiales, temporelles, bibliographiques
  • Système de requêtes
  • API
  • etc.

Corrections de forme à apporter

Problèmes de syntaxe

¶ 9 "[Nous] les chercheur(e)s en sciences humaines avons..."

¶ 21 : "Tout cela dépend de quels sont leurs attributs"

"ce qui dépend à la fois des questions que nous nous posons..." Le "à la fois" suppose un 2e terme après "des questions"

¶ 25 : "nous devons définir qu’est-ce qu’un ouvrage"

¶ 50 : "pour exploiter ces données avec d’autres utiles."

Problèmes d'orthographe

¶ 9 Forme inclusive incorrecte : "Les chercheur(e)s en sciences humaines avons..."

Formulation à clarifier ou alléger, choix des termes

¶ 9 Traduction pas claire (verbe indiquer inapproprié) : "sans forcément pouvoir indiquer un dataset tel que l’on le conçoit traditionnellement"

¶ 12 Fusionner les phrases 2 et 3 ?

¶ 14 "file" -> "ligne"

¶ 40 Peut-on vraiment traduire "geometry" par "pays" ? Cette catégorie ne s'applique-t-elle pas plus généralement à des espaces, à différentes échelles ?

¶ 44 "Si nous faisons click" -> "si nous cliquons...", "en cliquant..."

Style oral

¶ 16 "comme ça" -> " comme cela", "pourquoi on voudrait faire cela" -> "pourquoi voudrait-on ..."

Illustrations

¶ 39 La bulle "preferencias del sistema" est visible dans la capture d'écran

Les captures d'écran seraient plus lisibles avec un zoom sur l'interface de nodegoat.

octave-julien avatar Jul 07 '22 13:07 octave-julien

Merci beaucoup, @octave-julien d'avoir soumis ici votre évaluation. Dès que nous aurons celles de @MDelDebarre et de @shuitric, nous procéderons à une synthèse et il pourrait y avoir des échanges avec @digitalkosovski.

spapastamkou avatar Jul 08 '22 15:07 spapastamkou

Bonjour @MDelDebarre et @shuitric, avez-vous peut-être eu l'occasion d'avancer avec vos évaluations? La coupure de l'été approche à grands pas, et j'aimerais pouvoir faire un retour synthétique à @digitalkosovski dans des délais qui lui permettront de revoir l'article à la lumière de celles-ci sans pression. Je reste à votre disposition si nécessaire. Merci beaucoup!

spapastamkou avatar Jul 13 '22 14:07 spapastamkou

Bonjour,

Je vous remercie également pour cette leçon qui aborde un enjeu important pour la recherche en histoire. Je reprends de façon condensée mes remarques de lectures mais je rejoins l'essentiel des points déjà soulevés par @octave-julien.

Remarques générales sur l'ambition de la leçon

Je me demande également si la leçon ne serait pas plus efficace en choisissant entre ce qui me semble être les deux objectifs principaux: présenter le raisonnement en termes de données / introduire aux bases de données relationnelles via l'outil nodegoat. La première partie a fait l'objet de discussions/publications en histoire dont il est difficile de rendre compte de façon si rapide (cf. les travaux de F Clavert ou de F Beretta parmi d'autres). De mon point de vue, il a un enjeu qui n'est pas anodin à expliciter les liens entre la façon dont on utilise nos sources et le raisonnement par données (j'espère que la formulation est claire). Cet enjeu déborde la question des BDD telles que présentées dans la leçon.

Si cette première partie est maintenue, il me semble qu'il faut a minima ajouter une précision sur la temporalité de ce travail de structuration en données. A la lecture de la leçon, on peut estimer qu'il faut concevoir ce travail d'identification des données à saisir en amont de la consultation des sources et c'est d'ailleurs la critique la plus souvent adressée par les collègues réfractaires à ce type de travail. Il me semble que cette structuration peut/doit intervenir après un premier travail de familiarisation avec le corpus de sources et, qu'une fois les principes maîtrisés, il est possible d'intervenir après coup sur la première structuration conçue.

Etant donné le profil a priori du public de Programming historian, n'est-il pas plus important de concentrer la leçon sur le deuxième objectif? Cela permettrait de développer davantage certains points comme mentionnés par @octave-julien. Je suis d'accord sur l'idée que la présentation de l'outil - claire par ailleurs - peut ne pas entrer suffisamment dans le détail si l'on souhaite que les futur.es utilisateur.rices soient autonomes et puissent notamment anticiper les questions de cardinalité et de requêtes. Je pense que pour convaincre une personne de saisir ses données dans un outil, il faut également lui montrer ce qu'elle peut en obtenir en termes d'exploration.

Remarques de formes

[je liste l'ensemble des remarques/coquilles relevées, certaines sont communes à celles mentionnées par @octave-julien]

¶ 9 problème d'énonciation dans la citation - "Les chercheur(e)s en sciences humaines avons" ¶ 11 "concevoir la recherche en termes de données offre des avantages non seulement techniques et pratiques, mais aussi conceptuelles" -> "conceptuels" ¶ 12 "c'est souvent préférable" -> "il est souvent préférable" ¶ 14 "file" -> "ligne" ¶ 16 "Pourquoi on voudrait faire cela?" -> Pourquoi voudrait-on faire cela? ¶ 16 "auteures" -> "auteurs"? ¶ 18 répétition "nous devons définir quels sont quels sont les objets, quels attributs ils contiennent et comment ils se connectent les uns aux autres" -> "nous devon définir les objets, les attributs qu'ils contiennt et la façon dont ils se connectent les uns aux autres". ¶ 27 "de manière telle" -> "de telle manière"; "spécifiquement conçu pour faciliter ce processus aux chercheurs" -> "spécifiquement conçu pour faciliter ce processus pour les chercheurs" ¶ 44 "si nous faisons click" -> "si nous cliquons sur"

shuitric avatar Jul 15 '22 09:07 shuitric

Merci @shuitric !

spapastamkou avatar Jul 15 '22 13:07 spapastamkou

Cher @digitalkosovski, je travaille actuellement sur les deux évaluations reçues pour votre leçon et je déposerai ici les principales recommandations de modifications qui peuvent en émaner d'ici à la fin de la semaine en cours. Encore merci pour ces relectures.

spapastamkou avatar Aug 29 '22 21:08 spapastamkou

Cher @digitalkosovski, tous, vous trouverez ci-dessous des recommandations détaillées sur les points à revoir/modifications à effectuer afin de produite la version finale de votre leçon. Elles s'appuient sur les évaluations reçues, qui sont largement concordantes entre elles et offrent des instructions (que j'espère claires et détaillées) pour effectuer le travail de remaniement. Si quelque chose n'est pas clair, n'hésitez pas à m'interpeller. Merci à nouveau à tous pour votre travail autour de cette leçon.

Forme

Je vous propose de profiter de ce travail de signalement de coquilles/problèmes de syntaxe/choix de traduction dans les évaluations pour que la version finale du texte soit la plus "propre" possible. Je vous renvoie pour cela à la dernière partie de chacune des relectures qui listent des suggestions concernant des problèmes de forme. Je reprends ci-dessous ces suggestions en ajoutant les miennes (le plus souvent en italiques). Vous y trouverez le no de paragraphe, la phrase ou mot en question puis la suggestion de modification précédée d'une flèche:

¶ 9 Les chercheur(e)s en sciences humaines avons => Nous les chercheur(e)s en sciences humaines avons ¶ 9 Traduction pas claire (verbe indiquer inapproprié) : "sans forcément pouvoir indiquer un dataset tel que l’on le conçoit traditionnellement" => remplacer indiquer un dataset par renvoyer à un jeu de données ¶ 11 "concevoir la recherche en termes de données offre des avantages non seulement techniques et pratiques, mais aussi conceptuelles" -> "conceptuels" ¶ 12 "c'est souvent préférable" -> "il est souvent préférable" ¶ 12 Si nous voulions consigner des informations sur ces livres. Nous le ferions de manière intuitive dans un tableur, comme ça => Si nous voulions consigner des informations sur ces livres, nous le ferions de manière intuitive dans un tableur, comme cela ¶ 14 "file" -> "ligne" ¶ 16 "Pourquoi on voudrait faire cela?" -> Pourquoi voudrait-on faire cela? ¶ 16 On rencontre à la fois "auteures" et "auteurs" comme sujet => remplacer partout par auteur(e)s ¶ 18 répétition "nous devons définir quels sont quels sont les objets, quels attributs ils contiennent et comment ils se connectent les uns aux autres" -> "nous devons définir les objets, les attributs qu'ils contiennt et la façon dont ils se connectent les uns aux autres". ¶ 21 : qu’est-ce que chacun de ces objets contient comme information => ce que chacun de ces objets contient... ¶ 21 : "Tout cela dépend de quels sont leurs attributs" => remplacer par Tout cela dépend de leurs attributs ¶ 21 : "ce qui dépend à la fois des questions que nous nous posons..." Le "à la fois" suppose un 2e terme après "des questions" Merci de noter aussi que nous rencontrons à deux reprises "dépend". La phrase au lieu de: "Tout cela dépend de quels sont leurs attributs, ce qui dépend à la fois des questions que nous nous posons" pourrait prendre par exemple la forme suivante: "Tout cela dépend de leurs attributs, qui sont définis selon les questions que nous nous posons."
¶ 27 "de manière telle" -> "de telle manière" ¶ 27 "spécifiquement conçu pour faciliter ce processus aux chercheurs" -> "spécifiquement conçu pour faciliter ce processus pour les chercheurs" ¶ 35 définir qu’est-ce qu’un ouvrage => définir ce qu'est ¶ 37 après avoir défini qu’est-ce qu’un ouvrage => ce qu'est ¶ 44 "si nous faisons click" -> "si nous cliquons sur" ¶ 50 : "pour exploiter ces données avec d’autres utiles." => remplacer utiles par outils

Recommandation sur la première partie

Pour rappel, cette partie a été ajoutée à votre proposition de leçon initiale suivant ma propre recommandation: cette dernière a été faite, d'une part, pour expliciter le titre que vous proposez, d'autre part, parce que nous souhaitons que les leçons du PH offrent aussi une approche théorique sur la méthode, avant d'être des tutoriels initiant à tel ou tel outil. Mais le sujet est vaste et les évaluations concordent sur le besoin de faire des choix. Je pense que la meilleure solution consiste à revoir cette partie pour: a) la supprimer comme sous-partie autonome b) l'intégrer à l'introduction sous forme de problème - le titre actuel de la s/partie pourrait par ex. être formulé sous forme de question dans l'intro pour ensuite développer davantage c) en garder l'essentiel et, de préférence, la réduire, tout en tenant compte des suggestions faites dans les évaluations la concernant (dans les 2 premiers paragraphes de celle de SH, dans la partie dédiée de celle d'OJ). Concrètement, cela reviendrait à garder la définition des données et votre métaphore de traduction, à souligner l'aspect "données construites" à l'aide des références proposées dans les évaluations et, enfin, à évoquer des exemples d'usages variés (plusieurs en sont évoqués dans les évaluations) (peut-être remanier/synthétiser vos deux derniers paragraphes?).

Ce type de réorganisation devrait s'accompagner d'un réajustement du titre de la leçon où l'accent est actuellement mis sur la conception d'une recherche en termes de données. Je tente une proposition, mais peut-être que vous avez déjà des idées: "Des sources aux données: concevoir sa recherche en sciences humaines à l'aide de nodegoat"

Partie base et modèle de données

Je vous soumets ici les principaux points à revoir quant à cette partie:

  • [x] Renforcer la définition de ce qu'est une base de données (à l'aide de références bibliographiques si possible, par exemple celle-ci proposée par OJ est disponible en ligne et offrirait par ailleurs une bonne lecture à celles et ceux qui souhaitent en savoir plus sur les bdd).

  • [x] Aborder la notion de cardinalité. Si vous ne souhaitez pas attaquer de manière frontale les termes techniques, vous pourriez introduire votre audience à la notion de manière douce en parlant des types de relations qui peuvent exister entre vos objets (et les tables qui correspondent) et qui conditionnent la manière dont sera interrogeable la bdd. La référence du précédent commentaire donne des éléments, tout comme cette notice de Wikipédia. Il serait possible même de le faire en explicitant les relations entre les tables de votre modèle. Vous pouvez en dire une ou deux phrases dans cette partie et montrer comment ces restrictions sont implémentées dans nodegoat dans la partie suivante lorsqu'on crée une bdd (au moment où on définit les liens entre les objets dans nodegoat). Cela pourrait être l'occasion de démontrer un des avantages de nodegoat: la simplification de la conception d'une bdd, puisqu'elle peut se faire aussi de manière empirique: si je sais que les livres de ma bdd peuvent avoir été écrits d'un ou plusieurs auteur(e)s, ce qui correspond à une cardinalité de 1,N, je cocherai "mutliple" à mon objet "auteur" dans nodegoat (cf. commentaires sur partie 3). Si jamais cela n'est pas très clair, il est tout à fait posible de s'adresser aux concepteurs de nodegoat ou renvoyer à l'une de leurs billets en ligne sur le site du logiciel (ou de recourir à la documentation?).

  • [ ] Revoir la pertinence des questions posées dans le paragraphe 16 pour qu'elles soient alignées au modèle des données présenté, car les exemples donnés semblent correspondre peu (les deux évaluations en rappellent l'importance). En parcourant le modèle actuel, je peux penser à l'exemple de la première langue de parution du livre d'un auteur, si différente de son pays d'origine et de sa nationalité: cela pourrait peut-être indiquer qqch d'intéressant pour l'analyse que nous souhaiterions faire de ces données dans une recherche en histoire?

  • [x] Pour le modèle des données, il serait intéressant de tenir compte du cas des co-auteurs, comme le suggère OJ, pour entre autre aussi noter pourquoi une bdd aide à gérer des problèmes de redondance des données qu'il est possible (inévitable?) d'avoir avec un tableur

D'une manière générale, je vous invite à profiter des commentaires détaillés d'OJ sur cette partie, qui peuvent vous guider à la retravailler. Si quelque chose n'est pas clair, nous pouvons en discuter davantage ici ou par correspondance électronique.

Aussi, vous pouvez tirer profit des publications des concepteurs de nodegoat et renvoyer à celles-ci. Il existe sur le blog du site web du logiciel des billets sur la modélisation des données, y compris sur les modèles conceptuel, logique et physique. Enfin, il me semble inévitable de produire de nouvelles images là où le remaniement du texte aura provoqué des modifications à ce que est illustré dans les images.

Partie construire et gérer ses bases de données avec nodegoat

  • [x] ¶ 28: "nodegoat est un logiciel en ligne qui permet aux chercheurs de construire leurs bases de données à partir de leur propre modèle de données et conserver ces données en ligne". => Ajouter que l'export des données et leur sauvegarde en local sont possibles, voire recommandés (bonne pratique!).

  • [x] ¶ 28: Pour éviter tout malentendu autour du terme orienté objet, je vous propose de reformuler la phrase suivante:
    "L’approche du logiciel est ce que l’on appelle « orienté-objet » qui correspond à ce que l’on a proposé ici pour conceptualiser notre recherche : l’idée centrale est que les personnes, les groupes et les choses peuvent tous être traités comme des « objets » connectés par des relations diverses" Elle pourrait prendre la forme suivante (ou quelque chose de la sorte):

L’approche du logiciel correspond à ce que l’on a proposé ici pour conceptualiser notre recherche : l’idée centrale est que les personnes, les groupes et les choses peuvent tous être traités comme des « objets » connectés par des relations diverses

  • [x] Montrer où on peut implémenter des restrictions dans les relations qui correspondent à définir les cardinalités de notre modèle. Il me semble qu'il est possible de le faire dans le cadre des ¶¶ 42 et 43 (si on définit la relation entre les objets auteur(e)s et livres, il est possible de cocher, par exemple, multiple, pour désigner qu'un livre peut avoir plusieurs auteurs, ce qui revient à avoir une cardinalité 1,N (un livre = 1 ou plusieurs auteurs). L'exemple du modèle que vous fournissez est 1 livre = 1 auteur, du coup on aurait à cocher unique pour l'objet auteur, mais cela exclurait du coup les livres issus de plusieurs auteur(e)s et rendrait le modèle problématique pour une recherche en évolution, lorsque le cas se présenterait (c'est pourquoi il serait souhaitable de prévoir ce cas dans votre modèle, cf. remarque formulée dans la 2e partie)

  • [x] Données incertaines (les données floues évoquées par OJ?): comment les gérer? C'est un des avantages de nodegoat également, par exemple gérer les dates incertaines (date de naissance d'un auteur, ou date de parution - parfois on a des ouvrages sans date) qui sont des cas fréquent dans les recherches en histoire.

  • [x] Evoquer les limites: pas complètement ouvert à l'utilisation, possibilité d'avoir une seule bdd pour un compte d'utilisateur (modèle éco mixte), sauf si l'institution à laquelle on appartient peut garantir l'accès.

N'hésitez pas à développer un peu plus cette partie, qui s'indique pour faire comprendre par la pratique ce qui est énoncé dans l'actuelle partie 2. Encore merci et je reste à votre disposition.

spapastamkou avatar Sep 05 '22 08:09 spapastamkou

Cher @digitalkosovski, avez-vous eu connaissance du retour ci-dessus? N'hésitez pas s'il y a des points que vous souhaiteriez discuter davantage. Aussi, un grand merci d'avance si nous pouvons voir comment vous comptez procéder par la suite:-)

spapastamkou avatar Sep 23 '22 12:09 spapastamkou

Bonjour Sofia,

Merci beaucoup pour ce message et pour les recommendations très détaillées. Je suis en principe d’accord avec la plupart des commentaires, y compris avec votre proposition de nouveau titre.

Par contre, comme vous le savez, je viens de déménager en Grèce et de prendre un nouveau poste à Athènes, autrement dit ce mois-ci je suis particulièrement occupé par un nombre de questions administratives, logistiques et formelles qui malheureusement m’empêchent encore de travailler au rythme que je voudrais.

Je reviendrai vers vous dans quelques semaines avec une idée plus claire de quand je pourrai réaliser ces corrections et vous envoyer une nouvelle version.

Je vous remercie par avance pour votre compréhension.

Bien à vous, Agustin

digitalkosovski avatar Sep 23 '22 13:09 digitalkosovski

Bonjour Sofia,

Merci beaucoup pour ce message et pour les recommendations très détaillées. Je suis en principe d’accord avec la plupart des commentaires, y compris avec votre proposition de nouveau titre.

Par contre, comme vous le savez, je viens de déménager en Grèce et de prendre un nouveau poste à Athènes, autrement dit ce mois-ci je suis particulièrement occupé par un nombre de questions administratives, logistiques et formelles qui malheureusement m’empêchent encore de travailler au rythme que je voudrais. Je reviendrai vers vous au debut du mois d’octobre avec une idée plus claire de quand je pourrai réaliser ces corrections et vous envoyer une nouvelle version.

Je vous remercie par avance pour votre compréhension.

Bien à vous, Agustin

Le 5 sept. 2022 à 11:36, Sofia Papastamkou @.***> a écrit :

 Cher @digitalkosovski, tous, vous trouverez ci-dessous des recommandations détaillées sur les points à revoir/modifications à effectuer afin de produite la version finale de votre leçon. Elles s'appuient sur les évaluations reçues, qui sont largement concordantes entre elles et offrent des instructions (que j'espère claires et détaillées) pour effectuer le travail de remaniement. Si quelque chose n'est pas clair, n'hésitez pas à m'interpeller. Merci à nouveau à tous pour votre travail autour de cette leçon.

Forme

Je vous propose de profiter de ce travail de signalement de coquilles/problèmes de syntaxe/choix de traduction dans les évaluations pour que la version finale du texte soit la plus "propre" possible. Je vous renvoie pour cela à la dernière partie de chacune des relectures qui listent des suggestions concernant des problèmes de forme. Je reprends ci-dessous ces suggestions en ajoutant les miennes (le plus souvent en italiques). Vous y trouverez le no de paragraphe, la phrase ou mot en question puis la suggestion de modification précédée d'une flèche:

¶ 9 Les chercheur(e)s en sciences humaines avons => Nous les chercheur(e)s en sciences humaines avons ¶ 9 Traduction pas claire (verbe indiquer inapproprié) : "sans forcément pouvoir indiquer un dataset tel que l’on le conçoit traditionnellement" => remplacer indiquer un dataset par renvoyer à un jeu de données ¶ 11 "concevoir la recherche en termes de données offre des avantages non seulement techniques et pratiques, mais aussi conceptuelles" -> "conceptuels" ¶ 12 "c'est souvent préférable" -> "il est souvent préférable" ¶ 12 Si nous voulions consigner des informations sur ces livres. Nous le ferions de manière intuitive dans un tableur, comme ça => Si nous voulions consigner des informations sur ces livres, nous le ferions de manière intuitive dans un tableur, comme cela ¶ 14 "file" -> "ligne" ¶ 16 "Pourquoi on voudrait faire cela?" -> Pourquoi voudrait-on faire cela? ¶ 16 On rencontre à la fois "auteures" et "auteurs" comme sujet => remplacer partout par auteur(e)s ¶ 18 répétition "nous devons définir quels sont quels sont les objets, quels attributs ils contiennent et comment ils se connectent les uns aux autres" -> "nous devons définir les objets, les attributs qu'ils contiennt et la façon dont ils se connectent les uns aux autres". ¶ 21 : qu’est-ce que chacun de ces objets contient comme information => ce que chacun de ces objets contient... ¶ 21 : "Tout cela dépend de quels sont leurs attributs" => remplacer par Tout cela dépend de leurs attributs ¶ 21 : "ce qui dépend à la fois des questions que nous nous posons..." Le "à la fois" suppose un 2e terme après "des questions" Merci de noter aussi que nous rencontrons à deux reprises "dépend". La phrase au lieu de: "Tout cela dépend de quels sont leurs attributs, ce qui dépend à la fois des questions que nous nous posons" pourrait prendre par exemple la forme suivante: "Tout cela dépend de leurs attributs, qui sont définis selon les questions que nous nous posons." ¶ 27 "de manière telle" -> "de telle manière" ¶ 27 "spécifiquement conçu pour faciliter ce processus aux chercheurs" -> "spécifiquement conçu pour faciliter ce processus pour les chercheurs" ¶ 35 définir qu’est-ce qu’un ouvrage => définir ce qu'est ¶ 37 après avoir défini qu’est-ce qu’un ouvrage => ce qu'est ¶ 44 "si nous faisons click" -> "si nous cliquons sur" ¶ 50 : "pour exploiter ces données avec d’autres utiles." => remplacer utiles par outils

Recommandation sur la première partie

Pour rappel, cette partie a été ajoutée à votre proposition de leçon initiale suivant ma propre recommandation: cette dernière a été faite, d'une part, pour expliciter le titre que vous proposez, d'autre part, parce que nous souhaitons que les leçons du PH offrent aussi une approche théorique sur la méthode, avant d'être des tutoriels initiant à tel ou tel outil. Mais le sujet est vaste et les évaluations concordent sur le besoin de faire des choix. Je pense que la meilleure solution consiste à revoir cette partie pour: a) la supprimer comme sous-partie autonome b) l'intégrer à l'introduction sous forme de problème - le titre actuel de la s/partie pourrait par ex. être formulé sous forme de question dans l'intro pour ensuite développer davantage c) en garder l'essentiel et, de préférence, la réduire, tout en tenant compte des suggestions faites dans les évaluations la concernant (dans les 2 premiers paragraphes de celle de SH, dans la partie dédiée de celle d'OJ). Concrètement, cela reviendrait à garder la définition des données et votre métaphore de traduction, à souligner l'aspect "données construites" à l'aide des références proposées dans les évaluations et, enfin, à évoquer des exemples d'usages variés (plusieurs en sont évoqués dans les évaluations) (peut-être remanier/synthétiser vos deux derniers paragraphes?).

Ce type de réorganisation devrait s'accompagner d'un réajustement du titre de la leçon où l'accent est actuellement mis sur la conception d'une recherche en termes de données. Je tente une proposition, mais peut-être que vous avez déjà des idées: "Des sources aux données: concevoir sa recherche en sciences humaines à l'aide de nodegoat"

Partie base et modèle de données

Je vous soumets ici les principaux points à revoir quant à cette partie:

Renforcer la définition de ce qu'est une base de données (à l'aide de références bibliographiques si possible, par exemple celle-ci proposée par OJ est disponible en ligne et offrirait par ailleurs une bonne lecture à celles et ceux qui souhaitent en savoir plus sur les bdd).

Aborder la notion de cardinalité. Si vous ne souhaitez pas attaquer de manière frontale les termes techniques, vous pourriez introduire votre audience à la notion de manière douce en parlant des types de relations qui peuvent exister entre vos objets (et les tables qui correspondent) et qui conditionnent la manière dont sera interrogeable la bdd. La référence du précédent commentaire donne des éléments, tout comme cette notice de Wikipédia. Il serait possible même de le faire en explicitant les relations entre les tables de votre modèle. Vous pouvez en dire une ou deux phrases dans cette partie et montrer comment ces restrictions sont implémentées dans nodegoat dans la partie suivante lorsqu'on crée une bdd (au moment où on définit les liens entre les objets dans nodegoat). Cela pourrait être l'occasion de démontrer un des avantages de nodegoat: la simplification de la conception d'une bdd, puisqu'elle peut se faire aussi de manière empirique: si je sais que les livres de ma bdd peuvent avoir été écrits d'un ou plusieurs auteur(e)s, ce qui correspond à une cardinalité de 1,N, je cocherai "mutliple" à mon objet "auteur" dans nodegoat (cf. commentaires sur partie 3). Si jamais cela n'est pas très clair, il est tout à fait posible de s'adresser aux concepteurs de nodegoat ou renvoyer à l'une de leurs billets en ligne sur le site du logiciel (ou de recourir à la documentation?).

Revoir la pertinence des questions posées dans le paragraphe 16 pour qu'elles soient alignées au modèle des données présenté, car les exemples donnés semblent correspondre peu (les deux évaluations en rappellent l'importance). En parcourant le modèle actuel, je peux penser à l'exemple de la première langue de parution du livre d'un auteur, si différente de son pays d'origine et de sa nationalité: cela pourrait peut-être indiquer qqch d'intéressant pour l'analyse que nous souhaiterions faire de ces données dans une recherche en histoire?

Pour le modèle des données, il serait intéressant de tenir compte du cas des co-auteurs, comme le suggère OJ, pour entre autre aussi noter pourquoi une bdd aide à gérer des problèmes de redondance des données qu'il est possible (inévitable?) d'avoir avec un tableur

D'une manière générale, je vous invite à profiter des commentaires détaillés d'OJ sur cette partie, qui peuvent vous guider à la retravailler. Si quelque chose n'est pas clair, nous pouvons en discuter davantage ici ou par correspondance électronique.

Aussi, vous pouvez tirer profit des publications des concepteurs de nodegoat et renvoyer à celles-ci. Il existe sur le blog du site web du logiciel des billets sur la modélisation des données, y compris sur les modèles conceptuel, logique et physique. Enfin, il me semble inévitable de produire de nouvelles images là où le remaniement du texte aura provoqué des modifications à ce que est illustré dans les images.

Partie construire et gérer ses bases de données avec nodegoat

¶ 28: "nodegoat est un logiciel en ligne qui permet aux chercheurs de construire leurs bases de données à partir de leur propre modèle de données et conserver ces données en ligne". => Ajouter que l'export des données et leur sauvegarde en local sont possibles, voire recommandés (bonne pratique!).

¶ 28: Pour éviter tout malentendu autour du terme orienté objet, je vous propose de reformuler la phrase suivante: "L’approche du logiciel est ce que l’on appelle « orienté-objet » qui correspond à ce que l’on a proposé ici pour conceptualiser notre recherche : l’idée centrale est que les personnes, les groupes et les choses peuvent tous être traités comme des « objets » connectés par des relations diverses" Elle pourrait prendre la forme suivante (ou quelque chose de la sorte):

L’approche du logiciel correspond à ce que l’on a proposé ici pour conceptualiser notre recherche : l’idée centrale est que les personnes, les groupes et les choses peuvent tous être traités comme des « objets » connectés par des relations diverses

Montrer où on peut implémenter des restrictions dans les relations qui correspondent à définir les cardinalités de notre modèle. Il me semble qu'il est possible de le faire dans le cadre des ¶¶ 42 et 43 (si on définit la relation entre les objets auteur(e)s et livres, il est possible de cocher, par exemple, multiple, pour désigner qu'un livre peut avoir plusieurs auteurs, ce qui revient à avoir une cardinalité 1,N (un livre = 1 ou plusieurs auteurs). L'exemple du modèle que vous fournissez est 1 livre = 1 auteur, du coup on aurait à cocher unique pour l'objet auteur, mais cela exclurait du coup les livres issus de plusieurs auteur(e)s et rendrait le modèle problématique pour une recherche en évolution, lorsque le cas se présenterait (c'est pourquoi il serait souhaitable de prévoir ce cas dans votre modèle, cf. remarque formulée dans la 2e partie)

Données incertaines (les données floues évoquées par OJ?): comment les gérer? C'est un des avantages de nodegoat également, par exemple gérer les dates incertaines (date de naissance d'un auteur, ou date de parution - parfois on a des ouvrages sans date) qui sont des cas fréquent dans les recherches en histoire.

Evoquer les limites: pas complètement ouvert à l'utilisation, possibilité d'avoir une seule bdd pour un compte d'utilisateur (modèle éco mixte), sauf si l'institution à laquelle on appartient peut garantir l'accès.

N'hésitez pas à développer un peu plus cette partie, qui s'indique pour faire comprendre par la pratique ce qui est énoncé dans l'actuelle partie 2. Encore merci et je reste à votre disposition.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

digitalkosovski avatar Oct 11 '22 07:10 digitalkosovski

Bonjour @digitalkosovski, merci pour cette mise à jour. J'avais bien vu votre message et je comprends bien évidemment les raisons. En revanche, vous évoquez le début du mois d'octobre dans votre dernier commentaire, s'agit-il peut-être d'une erreur? Est-il possible pour vous de viser la mi-novembre pour finir avec les corrections? Merci beaucoup.

spapastamkou avatar Oct 12 '22 07:10 spapastamkou

Bonjour @spapastamkou et désolé pour ma réponse tardive. En fait j'avais voulu dire "fin octobre", mais je me suis visiblement trompé, je m'excuse.

Je commence à retravailler le texte dans les prochains jours, j’espère donc tout finir pour la mi-novembre.

A bientôt !

digitalkosovski avatar Oct 25 '22 06:10 digitalkosovski

Merci @digitalkosovski ! Cela tombe très bien car bientôt je vais entrer en berne, quant à mes acitvités au PH, pendant quelques mois. Nous sommes encore dans des délais très raisonnables et nous pourrons travailler sans pression. A très prochainement!

spapastamkou avatar Oct 25 '22 15:10 spapastamkou

Bonjour,

Juste un mot pour vous dire que je suis en train de travailler sur la correction de cette leçon et j’espère pouvoir vous l'envoyer vers la mi-décembre au plus tard. Je m'excuse encore une fois pour ce retard par rapport à la date originale que nous avions convenu pour octobre-novembre.

A bientôt !

digitalkosovski avatar Nov 30 '22 16:11 digitalkosovski

Bonjour @digitalkosovski, je reviens vers vous conformément à votre dernière mise à jour concernant l'envoi du corrigé de votre article pour la mi-décembre. Pouvez-vous me dire où vous en êtes où avec la la version corrigée, s'il vous plaît? J'en aurais besoin dans les meilleurs délais afin de pouvoir travailler de mon côté aussi. Merci d'avance!

spapastamkou avatar Dec 12 '22 16:12 spapastamkou