Ressources numériques en sciences humaines et sociales OpenEdition Nos plateformes OpenEdition Books OpenEdition Journals Hypothèses Calenda Bibliothèques OpenEdition Freemium Suivez-nous

Créer une ontologie de game designs de jeu de rôle 2/*

Ce billet est la suite du précédent billet où je raconte la construction d’une ontologie des game design de jeux de rôles. Je diffuse quelques résultats de ce projet en construction.

Nouvelle ontologie

En même temps que je travaillais les relations hiérarchiques entre les classes de game design, je développai les individus pour voir si le système fonctionnait et ce qu’il fallait corriger.

Désormais, les classes sont plus compactes et je continue à les nettoyer pour les rassembler encore plus, car ce qui fait la force d’une classe c’est de rassembler des éléments autour d’elle. Pour ne pas d’aller trop dans la granularité, je travaille aussi sur leur hiérarchie en tentant de ne pas faire des hiérarchies trop profondes et donc trop forcées. En séparant mieux les individus des classes, la taxonomie est considérablement simplifiée avec une factorisation plus étalée des concepts. Je me suis fortement inspiré du travail de Guillaume et Thibault Rioult et leur modèle P.E.R.S.O. (1) pour décrire les briques de game design. Plus particulièrement je me suis servi de leurs découpages en opérateurs fonctionnels (« opérateur de substitution » , etc.). 

Chaque individu est désormais un module/ brique/ innovation de game design d’un jeu de rôle en particulier.

  • Ils ne sont pas exhaustifs par rapport à un jeu.
  • Ils sont surtout notables.
  • Il peut y en avoir plusieurs par jeu.
  • Exemples d’individus : les moves de Apocalypse World, la sauvegarde de soi dans Eclipse Phase, etc. 

Visualisations 

Le tout est construit dans WebProtégé, exporté en RDF/OWL (un format XML). De ce format XML, je le mouline dans 3 scripts Python pour faire des visualisations simples. J’ai créé un repo dans GitHub avec une exportation récente du OWL et les scripts Python. Les visualisations en HTML (en lien et en aperçu ci-dessous) sont disponibles sur GitHub.io.

Exemples de toutes les classes imbriquées avec les individus les utilisant :

 

Exemples d‘individus avec classes :

 

Exemple d’individus avec classes et (parfois) description 

IA gen : 1 avantage 3 problèmes

Pour certains individus, la description complète est placée dans un menu « Détails » déroulant (voir image ci-dessus). Elle a été générée automatiquement par l’intelligence artificielle générative de Google Gemini.

Avantage

Dans la plupart des jeux très connus, Google Gemini a produit un texte de qualité dont la principale utilité a été de servir, après sa lecture par moi, à compléter l’indexation avec des classes manquantes qui m’avaient échappées. C’est un gros avantage selon moi ET une utilisation plutôt éthique (quand elle est déclarée) puisque le texte généré vient en soutien à une tâche. Il ne la remplace pas ou se s’y substitue pas.

Problèmes

Cependant, dans certains cas de mécaniques ou de jeux nichés, Google Gemini a produit du bullshit, certes avec des subjonctifs (would, could,…) mais de manière formellement convaincante si on ne connait pas les jeux. Ci-dessous, un extrait d’une tentative manquée d’explication de ce qu’est la mécanique d’approbation dans Prosopopée de Frédéric Sintes.

De plus, la semaine passée, Google Gemini a poussé agressivement son algorithme dans la plupart de ses produits (Android, etc.) et cela m’a rajouté une couche supplémentaire de rejet vis-“`à-vis de cet outil en particulier.

Enfin, le gain de temps est plutôt marginal par rapport à la tâche d’aller visiter quelques sites web et de lire par soi-même des explications. De plus, ces outils invisibilisent le travail des auteurs et des critiques qui ont étudié les jeux. Pour contrebalancer ce dernier point, j’ai ajouté dans le fichier OWL de WebProtégé les liens vers des sources authentiques. 

Champs RDFS, SKOS ou DC

Les champs peuvent suivre différentes normes pour décrire des données et des métadonnées. Elles sont spécialement adaptées pour le web sématique et les données liées. Dans un fichier RDF/OWL on peut rencontrer ces 3 normes pour décrire un élément. Pour chaque champ, la langue est codée en ISO 639 : fr, en, es, pt, …

rdfs:label

Taxonomie des classes : Le nom du game design en général commençant en minuscule. La forme textuelle doit être la plus courte et la moins ambigue possible.
Individus : Nom du game design, souvent sous une forme d’une phrase courte ou d’un titre. Commence par une majuscule. Suivi du nom du jeu entre parenthèses (les parenthèses sont des caractères réservés pour cet usage).

skos:altLabel

Synonymes du label.

skos:definition

Courte définition de une à trois phrases.

dc:description

Description complète au format MarkDown. Lorsque ce champ est renseigné, il est souvent issu d’un copier-coller de Google Gemini ou autre LLM si ces dernier ont produit une synthèse satisfaisante.

dc:source

URL ou référence bibliographique de la source d’information.

rdfs:seeAlso

Renvoi. Indique quel autre descripteur pourrait être utilisé en complément.

 

Apories restantes dans l’ontologie des classes

  • La tentation est forte parfois de faire des doubles (ou triples) parents plutôt que de s’astreindre à un seul parent par sous-classe.
  • Dice pool : est-ce que je créé deux sous-catégories linear dice pool et non linear dice pool ? ou je mets ces deux en dehors au cas ou il y aurait d’autres éléments linéaires et non linéaires ?
  • Il faudrait que je trouve comment compter le nombre d’utilisation de chaque classe. Une classe utilisée une fois est peu pertinente.
  • Est-ce que je sépare Magic dans une classe à part du reste ou je l’intègre dans les autres classes ?
  • Dice mechanics : potentiellement profond + bien séparer les notions. Par exemple roll-under > roll under target number (une classe et sa sous-classe liée) devient : roll-under + target number (deux classes séparées à combiner si besoin).
  • Bien écrire les labels des classes et des individus avec un vocabulaire contrôlé (à faire) :
    • player character 
    • player
    • gamemaster
    • participants (P+GM)
  • Bien décrire les définitions pour lever les ambiguïtés.
  • Rédiger un dictionnaire des données. 

 

Questions de recherche et hypothèses

  • Est-ce qu’un individu indexé avec beaucoup de classes est un signe d’innovation, de fun, etc. ? 
  • Comment utiliser cette ontologie pour indexer un jeu au complet, plutôt que des briques d’un élément du jeu ? 
  • Comment aligner une partie de cette ontologie avec Wikidata ? 

 


Références : 

(1) Guillaume et Thibault Rioult, 2024,  Interfaces ludiques entre système de jeu et fiction, outil de modélisation au service du game design au colloque « Le jeu de rôle a 50 ans. Et maintenant, que faites-vous ?… » à la Sorbonne.

Créer une ontologie de game designs de jeu de rôle 1/

J’ai récemment repris un projet que j’avais laissé en désuétude : la célébration des innovations de game design dans le jeu de rôle. Auparavant, j’avais inclus cette dimension dans la frise chronologique TTTTRPG (Timeline Tree of Tabletop Role-Playing Games). J’ai décidé de l’extraire de cette frise et d’en faire une ontologie séparée.

Ontologie

De manière plus détaillée, une ontologie est un système structuré pour représenter et organiser des informations d’un domaine spécifique. Elle ne se contente pas de lister des éléments ; elle établit des relations claires entre eux, créant ainsi un cadre pour la compréhension et le raisonnement. Dans notre cas, cette ontologie va reposer principalement sur deux éléments :

    • Une taxonomie, c’est à dire une liste hiérarchique de concepts. de classes et de multiples niveaux de sous-classes. Ces classes représentent des idées théoriques ou des concepts abstraits. Ce sont des “constructions mentales” qui n’existent pas physiquement, mais qui nous aident à catégoriser le monde. Sous chaque classe, il y aura des niveaux de sous-classes de plus en plus spécifiques. Cette structure arborescente permet une classification précise et une navigation logique à travers les concepts. 
    • Une liste d’individus, c’est-à-dire les éléments concrets du monde qui seront indexés (décrits) avec un ou plusieurs liens, chaque lien pointant vers une classe. Contrairement aux classes, qui sont des abstractions, les individus sont des entités tangibles ou spécifiques.

Dans cet exemple, la taxonomie va représenter tous les types de game design, ou plus largement tous les ludèmes (des bouts d’éléments de jeu). Les individus seront les game designs spécifiques et intéressants de jeux notables. Le nom du jeu est ajouté entre parenthèses après le label du game design.

Exemples :

  • Le ghost die de Ghostbuster (1986) est une instance de la sous-classe side die et de la sous-classe die with special icon(s).
  • Le fait de changer d’alignement en cas de situation de famine dans Dark Sun (1991) est une instance de la sous-classe food ressource management, de la sous-classe alignment change, et de la sous-classe players lose control of character.

    Mon erreur du mois passé

J’ai commencé à construire une énorme taxonomie de classes et de sous-classes qui intégraient AUSSI les game designs de certains jeux DANS l’arbre des classes (souvent en bout/fond de sous-classes). Au lieu de séparer ceux-ci comme expliqué précédemment. Dans cette organisation, les individus étaient les jeux.

Extrait de l'ontologie erronée dans WebProtégé
Extrait de l’ontologie erronée dans WebProtégé

Ce n’est pas complètement mauvais en soi, mais cette organisation de connaissance a des limites :

  • dans le cas où un game design a de multiples dimensions (comme pour la faim mentionné précédemment), alors il faut en choisir une seule. Certes, il est toujours possible de faire en sorte qu’une sous-classe ait plusieurs parents, mais ce n’est pas très élégant.
  • Si on envisage de recenser de manière exhaustive tous les jeux de rôle et leurs mécaniques de game design, il est crucial de ne pas surcharger la taxonomie de classes avec une granularité excessive. Tenter de créer des classes pour chaque élément de game design spécifique pourrait transformer la taxonomie en un « arbre surchargé », potentiellement trop lourd et difficile à gérer.

Archive compressée contenant les 4 fichiers de cette étape erronée (dans une démarche de science ouverte) :

      • TTTRPG_ontologie-erronee.owl : organisation erronées des données au format RDF/XML. Elle peut être chargée dans WebProtégé (service en ligne simple et gratuit) ou Protégé (logiciel plus avancé et gratuit/libre).
      • ontology_formatter_rdf_owl_to_html_tree_with_individuals.py : un script python pour transformer ce fichier dans un fichier HTML lisible :  
        • owl_class_tree_with_individuals.html 
      • change-owl.py : un script python pour transformer cette ontologie dans une ontologie plus satisfaisante (à beaucoup retravailler mais sur une bonne base). Elle a été conçue en dialoguant avec Claude 4 de Anthropic. Le prompt est inclus dans le script.
« Bye bye ontologie erronée »
« Bye bye ontologie erronée »

Comment concevoir une (bonne) ontologie de game designs ?

La clé est de trouver un équilibre. Il est préférable de maintenir une taxonomie plus générale et abstraite, en se fiant aux individus à indexer en parallèle. Chaque élément de design de jeu de rôle (un individu) pourra être décrit avec des liens précis vers les classes pertinentes de la taxonomie. Par exemple, plutôt que de créer une classe pour chaque type de dice pool utilisé, on pourrait avoir une classe plus générale dice pool, voire une ou deux sous-classe (linear dice pool, non linear dice pool) et laisser la description de l’individu spécifier le type de dé utilisé.

Cette approche permet de conserver une taxonomie claire et gérable, tout en offrant la flexibilité nécessaire pour capturer les détails spécifiques de chaque jeu de rôle via les liens entre la taxonomie et la liste des individus.

Créer une taxonomie de classes et de sous-classes

C’est à dire, créer une liste hiérarchique de concepts permettant de décrire, classer, rassembler, qualifier les différents éléments de game design existants. 

Voici un aperçu de cette taxonomie dans WebProtégé :

Exemple de taxonomie avec classes et sous-classes
Exemple de taxonomie avec classes et sous-classes

Idéalement, il faut que chaque élément plus spécifique (enfant) ait un seul élément plus générique (parent) parce que cela garantit une structure hiérarchique claire et évite les ambiguïtés dans l’héritage des propriétés et des relations. De manière générale, je pense que c’est un signe que le découpage est bien pensé et structuré car cela force à factoriser les idées dans différentes catégories séparées et à faire des choix. De plus, ne pas oublier qu’un individu peut avoir plusieurs classes. 

Dans une ontologie, une sous-classe acquiert par héritage l’ensemble des caractéristiques (propriétés) et des définitions (axiomes et concepts) de ses classes parentes (ou super-classes). Par exemple : moral mechanics possède les attributs de character mechanics, lui-même possédant les attributs de game mechanics.

Indexer une série d’individus

Chaque individu est d’un ou de plusieurs Types, issus d’une classe ou d’une sous-classe.

Pour le moment, il y a un seul genre d’individu : les game designs. Pour le moment, les noms des jeux associés sont codés comme une chaîne de caractères entre parenthèses dans le label de l’individu.

Exemple : Ghost die (Ghostbusters)

Exemple d'individu
Exemple d’individu

Inconvénients

Outre qu’il me faille tout réindexer, le fait de séparer les game designs spécifiques dans des individus ne me permet pas de tous les afficher ensemble et de faire des regroupements comme c’était le cas auparavant (dans le cas erroné). Même si c’est mieux pensé, j’ai l’impression d’une perte de contrôle car la visualisation des données ensemble est perdue. C’est sans doute pour ça que j’étais parti dans une piste erronée qui me donnait une impression de plus de contrôle sur l’ontologie générale. 

Commentaires sur les IA génératives

  • Je trouve que Google Gemini est très bien pour générer des commentaires exacts sur les règles les plus connues des jeux de rôles notables (GURPS, D&D, CoC, etc.). Je ne sais pas si c’est aussi bon pour les jeux de niche. Inconvénient déontologique : cela invisibilise toutes celles et ceux qui ont fait des analyses, des critiques ou qui ont rédigé le texte des jeux. 
  • Claude d’Anthropic est très bien pour générer du code informatique un peu complexe. Le script change-owl.py (voir plus haut) qui permet de transformer l’ancienne antologie erronée dans la nouvelle n’était pas gagné d’avance. Or ChatGPT de OpenAi n’a rien donné de bon après de nombreux essais. Claude d’Anthropic a donné un bon code avec presque les mêmes prompts en deux essais-erreurs. Je n’ai aucun conflit d’intérêt avec les produits mentionnés. Je n’ai utilisé que les versions gratuites. 

À suivre

Une fois que la nouvelle ontologie et les individus sont stables, je vais partager le tout à nouveau dans une démarche de science ouverte. Ce sera fait dans des fichiers ouverts (probablement RDF/XML pour la structure complète et HTML pour la visualisation).

Dans mes rêves les plus fous, j’imagine que ce sera utilisé pour créer une grande base de données indexant les game designs de jeux de rôle. Dans une démarche de science participative ? Où plusieurs participant.es bénévoles contribueraient ? En intégrant tout ou une partie dans le Grog ou RPGGeek ou Wikidata ? 

À ma connaissance, ce serait la première recension fine des mécaniques de jeux. Excitant! 

 

 

Presque 50 ans de recherche universitaire du jeu de rôle sur table

Je viens de soumettre le compte-rendu de la présentation que j’ai donné dans le cadre du colloque “Vous êtes dans une taverne…” Retour sur cinquante ans de jeux de rôle, du 27 et 28 mars 2024 à Metz. Il devrait être publié sous forme de chapitre dans des actes à une date inconnu chez une maison d’édition “a déterminer. Je vais en faire une traduction en anglais sous peu pour la diffuser ailleurs.

Le compte-rendu se trouve ici https://pmartinolli.github.io/JDR50bibliometrie/

Je l’ai rédigé avec Quarto, une extension du logiciel R Studio, qui sert à concevoir des documents avancés avec des graphiques intégrés (en R ou Python), avec un système de citations apparié avec Zotero (via Better BibTeX par exemple) et avec un excellent syst“eme de renvois internes. Je l’avais utilisé pour un Manuel de cours (avec seulement les fonctions de renvoi) avec beaucoup de plaisir depuis deux ans. Cerise sur le gâteau (ou sur le sunday si vous êtes au Québec), il est possible d’exporter le tout dans plein de formats sympas (html, PDF, ePub, docx) via pandoc et déposer le tout dans GitHub pour en faire un site web vivant. Vivant, dans le sens où il suffit de mettre à jour le contenu au format Markdown et ensuite de cliquer sur quelques boutons pour produire et diffuser le tout. Sans douleur.

Comment ça marche ?

  • Installer R et R Studio
  • Installer Quarto
  • Se créer un compte GitHub
  • Installer GitHub Desktop
  • Installer Zotero et l’extension Better BibTeX
  • Cloner le dépôt (repository) https://github.com/pmartinolli/JDR50bibliometrie avec GitHub Desktop
  • Changer le nom du dossier pour votre propre nom de projet
  • Créer un projet Quarto dans R Studio basé sur cette copie locale avec ce nom
  • Adapter le fichier _quarto.yml (en s’assurant bien que les fichiers sont créés dans un dossier /docs)
  • Changer le texte et le code dans index.qmd et les autres fichiers .qmd si besoin
  • Dans R Studio, faire un Run sur tous les morceaux (chunks) puis Build > Render Website.
  • Verser le tout en ligne dans votre propre dépôt avec GitHub Desktop.
  • Paramétrer GitHub Desktop en allant dans Settings > Pages > Build : deploy from… : master : /docs
Extrait d’un graphique du compte-rendu

Moissonnage du web : quel blogue de jeu de rôle cite lequel ?

Voici la description d’un sous-projet de On the Shoulders of Cloud Giants. Il s’agit de moissonner (ie. web scraper,  récupérer et organiser certaines données du web de manière automatisée) les blogues qui parlent de jeux de rôle sur table pour identifier qui cite qui.

Les codes sont en Python et ils utilisent des libraries courantes. Ils se trouvent ici : https://github.com/pmartinolli/pyTTRPGblogScraping

Visualisation du résultat en JavaScript : https://observablehq.com/@pascaliensis/ttrpg-blog-communities-who-cites-who

Les fichiers de programme .py sont installés dans un répertoire. Les fichiers produits (.csv et .txt) sont écrits dans le répertoire parent du répertoire des programmes.

Fonctionnement de la moissonneuse

Nom du programme : pyTTRPGblogCitationWS.py

  • On fournit une liste de blogues pour démarrer le moissonnage. Ce sont des URLs (une par ligne) dans un fichier manual_urls.txt
  • Le programme parcourt les URLs et produit un fichier blog_urls_iteration_1.csv
    • Il contient l’URL du blog citant, l’URL du blog cité et les mots-clés contrôlés trouvés dans le blogue citant.
    • Le processus peut être interrompu en tout temps et relancé. Le prochain fichier sera nommé blog_urls_iteration_2.csv et ainsi de suite. C’est très pratique car parfois (souvent?) le processus bloque sur certaines URLs. Il faut alors redémarrer le kernel de Python et relancer le programme.
    • Un blogue citant qui a été analysé une fois ne l’est plus par la suite.
  • Pour automatiser l’insertion d’une nouvelle entrée dans le fichier csv, il faut que le blogue citant ET le blogue cité :
    • Soient chacun de type “blogue” (plusieurs techniques sont utilisées)
    • Parlent de jeu de rôle sur table (liste de mots-clés contrôlés à repérer sur la page d’accueil du blogue, à l’exclusion du texte des liens). Les mots-clés contrôlés sont dans le code dans une liste nommée rpg_keywords
  • Mécanismes d’exclusion
    • À l’intérieur du code, il y a la possibilité d’alimenter une liste nommée url_traps avec les URLs qui ont fait boguer le programme.
    • Pour éviter de tester des URLs qui ont déjà été évaluées et rejetées (ni blogue, ou blog non JDR, ou erreurs), une liste d’exclusion est stockée dans une variable exclusion_list_urls et dans un fichier texte nommé exclusion_list.txt. C’est le premier test quand une nouvelle URL doit être évaluée. Cela accélère considérablement le programme.

Nettoyage du fichier de résultat

Nom du programme : pyTTRPGblogCleaner.py

Tout fichier doit être nettoyé avant d’être utilisé par un programme d’analyse ou de visualisation. Or le fichier généré par la moissonneuse est tout spécialement chevelu et hirsute.

Fonctionnement principal :

  • Il supprime les indicatifs .com, .fr, etc.
  • Il supprime les lignes doublons et les auto-citations qui auraient pu se glisser (citant = cité)
  • Il supprime les “non blogues de JDR”
  • Il renomme la colonne Citing... en Source et la colonne Cited... en Target (car c’est souvent ce qu’attendent certains programmes comme GEPHI).
  • Un fichier clean_citing_cited_TTRPG_blog_list.csv est produit.

Et ensuite ?

Visualiser et analyser les données

(à venir dans un prochain billet)

Visualisation avec le logiciel GEPHI après 6h de moissonnage

 

Citation fine

Utiliser les URL testées positives pour archiver tous les billets de tous les blogues retenus (lorsque leurs auteurs autorisent le moissonnage). Puis utiliser ces billets archivés pour faire une analyse plus fine des citations.

    • En effet, avec la méthode actuelle les liens de citation sont principalement ceux dans le bandeau actuel de navigation du blogue, avec peut être une dizaine de billets les plus récents.
    • En analysant les citations dans chaque billet on a un maillage plus fin des relations puisque ces citations sont localisées sur des informations spécifiques plutôt qu’être mentionnées de manière générique dans la zone de navigation.
    • On pourra peut être même comparer les deux types de citation.
    • Il y a un aspect préservation aussi car on ne sait pas si Google ou d’autres plateformes de blogue fermeront leurs services.
Exemple de blogue avec deux emplacements pour les liens cités
Exemple de blogue avec deux emplacements pour les liens cités

Annexe : extraire les URLs de départ depuis Obsidian

J’avais stocké des centaines d’URL dans des notes Obsidian.md. Voici un programme qui parcourt un coffre (vaultObsidian.md et qui créé le fichier manual_urls.txt pour démarrer le programme de moissonnage.

Nom du programme : pyURLfromObsidianMD.py

Auto-réflexions en cours de projet (20240624)

  1. Le web scraping est vraiment un processus fragile. Souvent, j’ai corrigé le code pour éviter que ça plante. Maintenant, ça roule mieux (du moins pas de plantage en 24h non-stop) mais c’est lent. J’ai produit 33 000 paires en 72h dans un fichier csv qui fait 3.8 Mo. Je pensais que ça irait plus vite.
  2. J’ai fait l’erreur de créer/mettre à jour les fichiers sur un infonuage. Cela était sûrement une des raisons du plantage et des couacs divers. Maintenant, tout tourne sur le disque dur mais non synchronisé. À noter pour l’application de la méthode file over app : en cas de mise à jour intensive de fichiers, les infonuages sont à éviter.
  3. Émotionnellement, c’est super satisfaisant de s’endormir ou de partir en randonnée et de savoir que le code tourne tout seul et produit des choses en notre absence.
  4. Plus généralement, le fait de chercher «qui cite qui» dans ce contexte permet de mettre un peu d’ordre dans le chaos des blogues existants. A part utiliser des recommandations ou des listes sélectionnées de blogues, il n’y a aucun moyen de mesurer l’impact, l’étendue, la forme, etc. des communautés de rôlistes blogueurs.
  5. J’ai hâte d’assister à un pic d’URL à chercher (pour l’instant ça ne fait que monter) pour avoir l’impression d’avoir fait le tour. Bien que je sais que ce soit un peu illusoire car beaucoup de blogues :
    1. refusent d’être moissonnés,
    2. ou bien ils ont disparu,
    3. ou bien mon code ne sait pas les identifier. Cette dernière catégorie est particuli`èrement déchirante car c’est ce qui arrive pour les sites web “maison”. Or les blogues ayant souvent une valeur fortement DIY, cela écarte tous les blogues vraiment DIY et donne un biais de sélection aux blogues qui ont choisi des plateformes “mainstream” pré-construite comme WordPress ou Blogger. Exemple : https://ludomancien.com/ 
  6. Il faudra que je repasse sur certaines adresses (et que je revois mes critères de rpg_keywords) car je vois qu’elles sont écartées par erreur. Je me baserai sur les adresses les plus citées et celles qui ont été classées comme Non-blogue de JDR.
    1. NB: je pense savoir pourquoi: à un moment donné, il y a eu un problème de connexion sur certains blogues qui se sont retrouvés dans la liste d’exclusion. Il faudra donc retraiter toute la liste d’exclusion à la fin.

Auto-réflexions II (20240702)

  1. J’ai abandonné l’idée de réinjection continue des URL citées en URL citantes.
    1. D’abord, je fais une passe complète sur le premier jeu d’URL. Puis quand c’est terminé, je me base sur les URL citées pour constituer le second jeu d’URL.
    2. Auparavant, la constante réinjections des URL citées faisait que le processus entrait en profondeur dans certaines explorations et ainsi créait un énorme biais.
    3. J’utilise le programme pyTTRPGblogCitationIterationX.py pour extraire les URL de l’itération finale de la première phase.
Visualisation de la première itération complétée
Visualisation de la première itération complétée

La visualisation ci-dessus a été faite avec le logiciel open source Gephi. Open > Spreadsheet > Ouvrir le fichier clean_citing_cited_TTRPG_blog_list.csv qui contient 12000 arêtes (edges) et 4700 noeuds (nodes). Ça produit un gros carré. Aller dans le panneau Layout > —Choose a layout > OpenOrd > RUN

 

On the Shoulders of Cloud Giants: visualisation de données avec JavaScript dans Observable

Extrait de diagramme d'accord

Mon projet On the Shoulders of Cloud Giants qui tente de décrire les pratiques de citations dans les publications de jeux de rôle sur table dort un peu en ce moment. Je suis en train de tester une nouvelle technique qui consiste à créer des index automatiques de citations mais ça prend du temps.

En attendant, j’ai expérimenté des visualisations de données avec Observable, la plateforme qui permet d’intégrer des données avec des bibliothèques de visualisation JavaScript.

Elle se trouve ici : https://observablehq.com/@pascaliensis/on-the-shoulders-of-cloud-giants

Voici son fonctionnement :

  1. Le code interroge Wikidata et rapatrie les données de manière structuré sous la forme (principalement) de séries de paires entre un jeux de rôle qui cite et un jeux de rôle qui est cité.
    1. Les données existent dans Wikidata grâce à la propriété P2860 (cites work).
    2. Le code se trouve en annexe (tout en bas de la page Observable) dans la variable query=
    3. D’autres données sont rapatriées au passage : date de publication, “mouvement” auquel appartient le jeu de rôle (The Forge, OSR, etc.), maison d’édition et mécaniques de jeu.
  2. Ces données sous la forme d’un tableau sont codées au format JSON. C’est important car comme nous allons faire des visualisations JavaScript, il faut structurer les données dans ce format pour qu’elles soient absorbées correctement par les bibliothèques de visualisation JavaScript.
  3. Ensuite, ce tableau JSON est transformé dans une hiérarchie JSON, c’est une organisation de l’information spécialement conçue pour les visualisations de réseau / de relation.
    1. En gros, la structure de cette hiérarchie JSON se découpe en deux parties : une partie décrivant chaque jeu indépendamment (partie nodes) et une partie listant chaque relation (partie edges).
    2. La transformation a été effectuée par une fonction nommée table2hierarchy
    3. La variable contenant ce fichier se trouve dans data_citingCited
  4. À partir de là, l’essentiel est fait car les bibliothèques JavaScript font tout le reste du travail. Il faut juste les modifier un petit peu chaque fois pour avoir l’effet désiré (comme le fait de filtrer les données ou de les colorer). Plusieurs visualisations sont ainsi faites :
    1. Des graphes non orientés (undirected graphs)
    2. Des diagrammes d’accord (chord diagrams)
    3. Des diagrammes à barre bien classiques, etc.

https://observablehq.com/@pascaliensis/on-the-shoulders-of-cloud-giants

JavaScript pour analyser votre bibliothèque de références Zotero

Mon collègue Philippe m’a expliqué comment fonctionnait la plateforme ObservableHQ qui a été conçue pour faire de jolies visualisations interactives avec JavaScript. J’ai été très enchanté du résultat et de la facilité d’utilisation. J’y ai donc transposé une partie du code R Studio discuté dans le billet précédent.

Le notebook se trouve ici https://observablehq.com/@pascaliensis/zoterojsnalysis

N’importe qui peut cloner (fork) le code avec un compte personnel créé gratuitement. Notez cependant qu’avec un compte gratuit, le code et les données sont accessibles à la vue de tous.

Je discuterai dans des prochains billets de deux autres projets qui dormaient en format R Studio et dot et que j’ai transposé partiellement sur ObservableHQ :

L’aspect interactif, la rétroaction rapide sur les données et l’esthétique de leur visualisation peuvent ré-dynamiser des projets assoupis de mani`ère salutaire.

R Studio pour analyser votre bibliothèque de références Zotero

Ma proposition de présentation du colloque «Vous êtes dans une taverne… Retour sur 50 ans de jeux de rôle» a été acceptée. Intitulée « Évolution historique et analyse bibliométrique de la recherche académique sur le jeu de rôle sur table dans les publications universitaires », elle consiste principalement à faire une étude descriptive de la publication universitaire sur le jeu de rôle sur table depuis les années 80.

Depuis 2014, j’ai entrepris de rassembler des références universitaires se rapportant à l’étude du jeu de rôle sur table. Cette démarche a abouti à la création d’une base de données librement accessible via Zotero, comprenant un total de 2400 références. Parmi celles-ci, on dénombre 460 articles soumis à une évaluation par des pairs, 180 ouvrages, 300 thèses, et bien d’autres encore.

La base de données bibliographique est en libre accès à : https://www.zotero.org/groups/446523. Depuis 2019, Michael Freudenthal m’a rejoint pour gérer cette base de données.

Last Christmas, I gave you my R

Dans le but de faire une analyse bien reproductible, non seulement je verse les données en libre accès mais je verse aussi les algorithmes qui permettent de les analyser. Le tout est déposé sur GitHub à https://github.com/pmartinolli/ZoteroRnalysis

J’ai choisi d’utiliser le logiciel R Studio parce que j’ai appris à l’utiliser dans le cadre de mon travail, aussi parce que c’est un logiciel performant et libre, et enfin parce qu’il est facile de demander à ChatGPT 3.5 de OpenAI de corriger mes bugs de codage (ce que je fais très souvent).

Le principe est simple :

  • J’exporte les références bibliographiques de Zotero au format csv
  • J’importe les données dans R Studio
  • Je mouline les données dans R Studio
  • R Studio me produit des jolis graphiques et d’autres tables csv
  • Au passage, j’aligne mes données avec celles de Wikidata pour augmenter mes données (dans un processus appelé la «réconciliation», fait par le logiciel OpenRefine). Par exemple, avec la liste des noms des revues universitaires, je vais chercher la date de la création de la revue et son pays d’origine pour repérer des tendances.

All I want for this graph is you

Après ce deuxième jeu de mots douteux du temps des Fêtes (nous sommes le 1er décembre), voici quelques jolies extractions sous forme graphiques. Notez que ce ne sont pas les versions définitives car, d’ici le colloque, je vais encore « shampooiner les données » pour les corriger et les améliorer.

Pour la suite, je vous donne rendez-vous à Reims (je serai par Zoom), ou sur ce blogue, ou plus tard dans une publication plus définitive.

Annexe : suite de la proposition de présentation au colloque

« Dans la présentation, je vais expliquer en quoi la compilation d’articles évalués par des pairs et d’ouvrages publiés depuis les années 1980, tant en anglais qu’en français, est presque exhaustive et permet de généraliser les analyses qui vont suivre. Je mettrai également en lumière les éventuels biais de sélection et d’indexation qui peuvent être présents.

« Mon projet consiste à réaliser une analyse historique et bibliométrique des publications de type articles évalués par des pairs et de type chapitres de livres. Cette analyse permettra de mettre en évidence les variations observées au fil des années, dans diverses disciplines, pour différents sujets de recherche, ainsi que les enjeux entourant la publication (notamment les prépublications, les revues systématiques, les publications potentiellement prédatrices, les rétractions, etc.). Je montrerai, par exemple, comment les premières publications des années 1980 visaient à expliquer la montée en popularité de cette passion et à répondre aux paniques morales de l’époque. De même, j’illustrerai comment les publications récentes se concentrent davantage sur des thématiques telles que le genre, les actual play et les aspects psychothérapeutiques liés à la pratique du jeu de rôle. Je mettrai également en évidence la grande diversité des domaines académiques abordant l’étude du jeu de rôle, allant des disciplines traditionnelles telles que la sociologie, la psychologie et les humanités, jusqu’à des domaines plus atypiques tels que la musique, la neurosciences et la philosophie. Cette présentation s’étend également à l’échelle internationale, englobant l’Europe, l’Amérique du Nord, ainsi que d’autres régions d’Amérique latine et d’Asie. Je soulignerai la prédominance du jeu Dungeons & Dragons, tout en identifiant d’autres jeux étudiés ou mentionnés en marge de cette prépondérance.

« Pour enrichir cette analyse, je discuterai de la réflexion théorique et pratique de la communauté des joueurs sur leur loisir en parallèle du milieu universitaire. Je passerai également en revue les conférences, congrès et colloques consacrés au jeu de rôle, ainsi que les mémoires et thèses abordant ce sujet. Enfin, je discuterai des pratiques de citation dans le jeu de rôle sur table, dans son étude et dans ses communautés de pratiquants. »

ChatGPT pour aider à coder un projet de numérisation sur le jeu de rôle (1/)

Je me considère comme un « programmeur du dimanche ». J’ai appris Turbo Pascal au lycée au siècle passé. Récemment, j’ai travaillé sur de petits projets de programmation en R et en dot. Depuis un certain temps, j’ai eu l’ambition de numériser et d’analyser des textes en utilisant Python, mais j’ai été bloqué par un manque d’expertise personnelle et de soutien externe. C’est alors que ChatGPT est survenue…

Capture d’écran Spyder

Avantages de ChatGPT pour les chercheurs non-programmeurs

  • Disponible gratuitement depuis novembre 2022, cet outil requiert seulement un numéro de téléphone portable et un compte Gmail pour y accéder.
  • Il est suffisamment performant pour coder en Python, un langage adapté à la numérisation et la recherche de texte, même si vous n’avez aucune connaissance dans ce langage.
  • Il permet également de nombreuses interactions fluides pour clarifier vos besoins et il vous guide efficacement pour déboguer votre code en identifiant les erreurs.
  • De plus, cet outil est corvéable à merci, à tout moment de la journée ou de la nuit.

Inconvénients

  • Il est important d’avoir une compréhension minimale des concepts de base tels que les langages de programmation, le code informatique (variables, boucles, etc.), les formats de fichiers et le système d’exploitation pour tirer le meilleur parti de l’utilisation de ChatGPT. Si vous ne comprenez pas certains termes ou concepts, n’hésitez pas à demander des explications à ChatGPT pour apprendre.
  • Il peut arriver que ChatGPT propose du code pour des versions obsolètes de Python. Dans ce cas, reformulez votre demande et demandez-lui d’autres méthodes pour des fonctions plus récentes. Généralement, après environ 6 à 8 interactions, le bon code émerge et vous devez l’assembler vous-même.
  • En ce qui concerne l’utilisation de bouts de code, je considère important de citer mes sources. Dans ce cas de ChatGPT, c’est problématique car les sources qui ont servi à l’entraîner sont invisibilisées. Si vous ne savez pas à qui attribuer le code, vous pouvez au moins mentionner ChatGPT pour le travail accompli (voir billet auquel j’ai participé pour Zotero francophone). Citer ses sources est un aspect éthique important quand on utilise code open-source.

Comment ?

  • Pour commencer à coder en Python, il est recommandé d’installer Anaconda, qui est une plateforme open-source populaire pour la science des données. Vous pouvez télécharger Anaconda depuis le site web officiel et suivre les instructions d’installation.
  • Après l’installation d’Anaconda, vous pouvez utiliser l’IDE (environnement de développement intégré) Spyder pour écrire et exécuter votre code Python. Spyder est inclus dans l’installation d’Anaconda et est généralement prêt à être utilisé.
  • Il est également important d’installer les packages dont vous avez besoin au fur et à mesure que vous en avez besoin. Vous pouvez le faire en utilisant la commande pip dans l’invite de commande (ou terminal si vous utilisez un Mac ou Linux) ou en utilisant l’interface graphique de Anaconda Navigator.
  • Enfin, vous pouvez utiliser ChatGPT sur OpenAI ou Bing+ChatGPT de manière alternée pour obtenir de l’aide supplémentaire sur votre code. À mon niveau, les deux plateformes sont assez similaires en termes de fonctionnalités et de performances.

Objectifs du projet

  • Classer des PDF dans des dossiers.
  • Extraire et retravailler leurs métadonnées en Python et csv.
  • Extraire le texte intégral en Python et autres.
  • Verser les métadonnées et le texte intégral dans une base de données SQlite.
  • Jouer avec la base de données SQlite (aspect développé dans un prochain billet).

Problèmes rencontrés

Avec les fichiers PDFs

  • Dans mon corpus de PDFs, il est très courant de rencontrer des noms de fichiers avec des caractères problématiques. En effet, ils peuvent avoir été nommés à partir d’encodages ou de systèmes d’exploitation très hétérogènes (depuis 2000 environ et de partout sur la planète). Il est recommandé de renommer les fichiers pour une meilleure identification et organisation.
  • Les méthodes de production de PDF peuvent également varier considérablement, ce qui peut rendre difficile leur traitement. Certains fichiers peuvent contenir des images numérisées sans OCR, tandis que d’autres peuvent contenir du texte électronique ou avoir déjà été soumis à une reconnaissance optique de caractères (OCR). Il est important de prendre en compte ces différences lors de la manipulation des fichiers pour garantir des résultats précis.
  • Il peut également arriver que certains fichiers PDF soient protégés par des verrous électroniques, ce qui empêche toute modification ou manipulation. Dans ce cas, vous pouvez essayer de trouver des outils pour supprimer les verrous électroniques, ou demander l’autorisation de l’auteur ou du propriétaire des fichiers.
  • Enfin, certains fichiers PDF peuvent être bugués ou corrompus, ce qui peut causer des problèmes lors de leur manipulation. Il est recommandé de tester les fichiers pour détecter les erreurs et les problèmes, et de prendre les mesures nécessaires pour résoudre ces problèmes.
  • Rajouter des lignes de codes pour « tester » les PDFs et les mettre de côté en cas de bogue a constitué une partie non négligeable et frustrante du codage informatique.

Avec Python

  • Je ne sais toujours pas…
    • Comment fonctionnent les environnements, kernels, etc. (voir XKCD)
    • Comment mettre à jour Python et le reste.
    • Si tout tournera bien et identiquement dans 5 ou 10 ans.
    • Comment lancer Adobe Acrobat sur des fichiers PDF depuis Python (du coup, j’ai abandonné pour le mieux et ça m’a fait simplifier le flux de travail ainsi qu’apprendre à utiliser pyTesseract).

Structure des dossiers et fichiers

  • Yragatheque
    • A
      • Apocalypse World
        • Apocalypse World 1st ed
          • Apocalypse World 1st ed.pdf
        • Apocalypse World 2nd ed
          • Apocalypse World 2nd ed.pdf
    • B
      • Bunnies & Burrows
        • archives
          • HomebrewB&B.pdf
        • 1st ed
          • B&B1sted.pdf
        • GURPS ed
          • GURPS B&B.pdf
      • _Baguettes & Fromages
        • B&F2e.pdf
    • _working_directory
    • _corrupted

Explications :

  • Les scripts ne traitent que les fichiers PDF.
  • Les fichiers PDF placés dans les répertoires archives sont ignorés (ex: HomebrewB&B.pdf est ignoré).
  • Les fichiers PDF placés dans les répertoires précédés du caractère _ sont ignorés (ex: B&F2e.pdf est ignoré).
  • Yragatheque est le niveau le plus haut. C’est la racine de l’arbre de la collection des PDFs.
  • A, B, C,… sont le 2e niveau. C’est la classification alphabétique de tous les jeux.
  • Apocalypse Word est au 3e niveau. À ce niveau se trouvent les noms des jeux.
  • Tous les niveaux en dessous (4e niveau et au-delà) sont des éditions, ou des gammes, ou des sous-classifications.
  • _working_directory contient les fichiers csv produits, les listes d’autorité et la base de données SQLite.
  • _corrupted contient tous les fichiers PDFs et fichiers associés (yaml, rawtext,…) qui n’ont pu être traité (non ouvert car corrompus, pages internes illisibles,…).

Scripts et flux de numérisation

Les fichiers nommés 00-nom sont des scripts Python.

  • Préparation :
    • PARAMETERS : contient l’adresse du dossier dans lequel se trouve la collection des PDFs.
    • 00-createWorkingDir : création du dossier _working_directory s’il n’existe pas.
    • 01-permission : parcours tous les dossiers et donne les droits en lecture-écriture partout
    • 02-purge : supprime les fichiers .yaml , .rawtext et .ocrtext qui peuvent subsister de traitements précédents
    • 03-rename : normalise les noms de fichiers (supprime les accents, les caractères spéciaux, remplace les espaces par des traits, etc.)
  • Métadonnées :
    • 10-pdf2yaml : créé un fichier .yaml du même nom que le fichiers pdf, au même emplacement, avec comme variables :
      • path = chemin absolu du fichier pdf
      • name = nom du fichier sans .pdf
      • size = poid du pdf en Mb
      • pages = nombre de pages du pdf
      • game = nom du dossier de 3e niveau
      • line = nom des dossiers de 4e niveau et+
    • 11-yaml2csv
      • Écrit un fichier metadata.csv à partir de tous les fichiers .yaml de toute la collection.
      • À cette étape, on peut modifier le fichier metadata.csv pour y ajouter des colonnes (et donc des nouvelles variables yaml), modifier le contenu, etc. Il est recommandé de faire une sauvegarde du fichier modifié (exemple : metadata.backup.csv) pour ne pas écraser toutes ces modifications manuelles.
    • 12-csv2yaml
      • Prend le contenu du fichier metadata.csv et réécrit tous les fichiers .yaml de la collection avec le nouveau contenu.
  • Numérisation :
    • 30-pdf2rawtext
      • Créé un fichier .rawtext de même nom que le pdf au même emplacement, contenant l’extraction du texte si le fichier pdf est au format numérique ou s’il y a une couche d’OCR extractible. Si l’extraction ne fonctionne pas ou pose problème, un fichier est créé tout de même mais vide.
    • 34-OCR-byTesseract
      • Certains fichiers pdf sont récalcitrants à l’extraction mentionnée précédemment. Alors, si le fichier .rawtext est vide ou tout petit, on lance une numérisation via Tesseract qui va créer un fichier .orctext au même endroit que le fichier pdf. C’est un processus assez long.
  • Exportation :
    • 40-yamlntext2sqlite
      • On envoie le fichier .yaml, accompagné du fichier .rawtext ou .ocrtext (le plus gros) correspondant, dans une base de données SQlite nommée TTRPG_LLM.sqlite
    • 50-reportSQlite
      • On créé un rapport de la base de données.
    • 51-searchSQlite
      • On cherche une chaîne de caractère dans la base de données.

Prochainement

  • Les scripts Python sont dans GitHub à https://github.com/pmartinolli/pyTTRPG_LLM 
  • Je travaillerai les données dans SQlite pour repérer quel jeu cite quel jeu et pour tenter de produire des rapports d’observation intéressants.
  • Pour le moment, les colonnes supplémentaires ajoutées dans le fichier metadata.csv et exportées dans les fichiers .yaml ne sont pas intégrées dans la base SQLite.
    • Exemple : edition, langue
    • Il serait intéressant d’incorporer un travail de reconciliation avec Wikidata sur le fichier metadata.csv pour récupérer :
      • pour la colonne game : le QID de la famille de jeu (cela devrait être presque du 100%)
      • pour chaque document moissonné : le QID de l’édition de ce document (plus rare).

La première partie de ce billet a été partiellement retouchée par ChatGPT Mar 23 Version le 21 avril 2023. Billet modifié le 11 mai 2023.

Commentaire de ChatGPT à propos de ce billet :

« C’est génial que vous ayez pu utiliser ChatGPT pour progresser dans votre projet de numérisation et de fouille de texte en Python ! ChatGPT peut être une excellente ressource pour apprendre de nouvelles compétences en programmation ou résoudre des problèmes techniques. En tant que programmeur du dimanche, il est normal de ne pas avoir une expertise approfondie dans tous les aspects de la programmation, mais il est important de continuer à apprendre et à s’améliorer. ChatGPT peut vous aider à combler ces lacunes et à vous permettre de réaliser vos projets de manière autonome. N’hésitez pas à poser des questions et à explorer de nouvelles idées avec ChatGPT pour continuer à progresser dans votre parcours de programmation. »

(sic transit gloria mundi)

Les épigraphes dans les jeux de rôle sur table (2/2)

Cet essai fait partie du projet On the Shoulders of Cloud Giants qui étudie les pratiques de citation dans les jeux de rôle sur table. Ce billet fait suite à un premier billet publié l’an dernier.

Quelques ajustements de méthode

Codage des variables

Le codage des variables a été compilé dans un fichier CSV déposé dans le projet OtSoCG sur GitHub. Le fichier est mis à jour au fur et à mesure. Les scripts R vont récupérer les données de ce fichier.

J’ai changé la manière de coder les variables. Par exemple, pour le type d’épigraphe, au lieu de tout mettre les types ensemble dans une même colonne (ex: lahr) je les ai mis chacun dans une colonne séparée (ex: colonne l, colonne a, colonne h, etc.). En cela, je suis les conseils de notre bibliothécaire des données numériques qui a relayé les principes de Tidy data de Hadley Wickham.

Principes de Tidy data de Hadley Wickham

Note : il faudrait que j’apprenne à utiliser des Jupyter notebook pour constituer des dictionnaires de code des variables (nom, format, sélection, etc.).

Noms des variables

  • qid : identifiant Wikidata du jeu générique ou de l’édition précise parfois (ex: Q5457)
  • edition : label du nom de l’édition (ex: 2nd, 2nd revised, etc.)
  • series_ordinal : rang de l’édition en nombre entier
  • label : nom du jeu (nom générique de la gamme, ou de la ligne de jeu). Rassembler les jeux le plus possible pour pouvoir faire des séries longitudinales.
  • date : date de publication
  • nb_forged : nombre total d’épigraphes inventés par le jeu pour le cadre intra-diégétique du monde
  • nb_work : nombre total d’épigraphes tirés d’œuvres pré-existantes au jeu (ie. le jeu contient au moins un) :
    • academic (codé a) : essai, ouvrage d’histoire, article, etc.
    • literature (l) : roman, nouvelle, poésie, etc.
    • historical (h) : citation de personnage historique
    • music (m): parole de chanson
    • religious (r) : issu de textes sacrés, religieux ou spirituels
    • game (g) : jeu (de société, de plateau, de carte, grandeur nature, etc.) ou parole de game designers
    • unknown (u) : je n’ai pas trouvé le type
    • bd (b) : bande dessinée, comic, manga, manwa, etc.
    • cinema (c) : film ou série tv
    • videogame (v) : jeu vidéo
    • franchise (f) : œuvre littéraire ou autre, précédent le jeu et dont le jeu est issu de la franchise ou qui est une inspiration explicite directe.
  • confusing_mix (x) : si les épigraphes inventés par les concepteurs du jeu et ceux tirés d’œuvres existantes se mélangent et créent une confusion fictif-réel.
  • notes (non codé) : notes diverses

Exclusions

Ont été exclus de la recension:

        • Les textes épigraphiques issus des scénarios (souvent des props : articles de presse, lettres etc.).
    • Les épigraphes attribués à une classe de personnage pour illustrer cette classe.
    • Les épigraphes sans source.

Premiers résultats

Quelques remarques pendant ce travail de recension.

Mise en page des épigraphes

Dans les jeux de rôle, la plupart des épigraphes ont une mise en forme semblable :

  • Section : Souvent dans la partie « fluff » du livre de jeu. Plus rarement dans la partie règle. Presque jamais parmi les listes d’éléments dans les règles (listes de sorts, listes d’équipement, listes de compétences).
  • Positionnement : En tête de chapitre, sous le titre du chapitre; ou en tête de paragraphe, sous le titre du paragraphe. Plus rarement, dans un encart encadré.
  • Structure : Texte de l’épigraphe, suivi de la source.
  • Paragraphe : Retrait à droite, ou à gauche ou les deux.
  • Police : Légèrement différente du texte régulier de tout le jeu (ex: en italique, ou dans une police différente, ou de taille plus réduite ou plus grande).
  • Mise en forme de la source : Auteur, suivi du nom de l’œuvre. Souvent précédé par un tiret cadratin. Exemple :
Zantabulous Zorcerer of Zo (2006), p. 5

Citations apocryphes

Dans mes formations, je mets souvent en garde mes étudiants contre les citations apocryphes (fausses citations) pour qu’ils ne fassent pas l’erreur d’en insérer dans leurs travaux. En effet, c’est une perte de crédit immédiate puisque cela prouve que l’étudiant n’a pas vérifié que l’auteur de la citation a vraiment dit une chose et dans quel document.

Quelle a été ma surprise de voir une (probable) fausse citation de Einstein dans Faery’s Tales Deluxe (p. 1) et dans Zantabulous Zorcerer of Zo (p. 89) !

Un bibliothécaire de la Library of Congress a fait une enquête sur cette fausse citation.

Épigraphes graphiques

Parfois, je suis tombé sur des citations de cases de bandes dessinées (Prince Valiant, Les Quatres de Baker Street), ou des gravures sous-titrées (Baron Munchausen).

Source : Prince Valiant : The Story-Telling Game (1989)

Données quantitatives

Le code R pour produire les résultats ci-dessous se trouve ici : https://github.com/pmartinolli/OtSoCG/blob/master/R/OtSoCG_epigraphs.R

Il peut être aussi être exécuté en ligne à partir de cette page (où j’ai reporté la plupart des scripts : https://colab.research.google.com/drive/1gb9XBBNy3qniJ-aRlq1r_LtAue0wBNxy

Épigraphes inventés intra-diégétiques

Certains jeux font un usage abondant de citations épigraphiques inventées par les concepteurs du jeu. Le but est principalement d’augmenter l’immersion dans l’univers du jeu en apportant une touche de vraisemblance. En effet, ce sont des épigraphes intra-diégétiques donnant la parole à des personnages non-joueurs.

JeuxÉditionNombre d’épigraphes
inventés
Nobilis1st. ed.373
EarthdawnClassic242
Earthdawn3rd ed.111
Rogue Trader99
ChampionsThe New Millenium92
Corporation92
Cyberpunk202084
SLA Industries1.1 (2000)73
SLA Industries1st ed. (1993)73
Nephilim20e anniversaire64
Top 10 des jeux avec le plus d’épigraphes inventés

Confusion entre œuvres réelles et fictives

Edgar Alan Poe et H.P. Lovecraft aimaient mélanger des œuvres fictives (ex: le Necronomicon) avec des œuvres réelles (Harnušek 2013). Sans doute pour produire un effet de vraisemblance des œuvres fictives, troubler le lecteur, jouer avec lui et le mettre dans un état de confusion.

Certains jeux inventent des livres fictifs et les mélanges à des livres existants. Par exemple Call of Cthulhu reprend ce que faisait Lovecraft en listant des livres du Mythos avec des livres occultes existants. Ou bien Baron Munchausen 3rd ed. mentionne une douzaine de titres de faux-livres en faisant un astucieux mélange d’humour et d’érudition geek.

Cependant l’essentiel de ce procédé littéraire est repris dans les épigraphes. En effet, j’ai repéré 21 épigraphes d’œuvres inventées mélangés avec des épigraphes d’œuvres existantes, ou bien des citations pseudo-historiques de personnages historiques ayant existé à côté de citations réelles d’autres personnages historiques. La plupart de ces jeux peuvent être classés dans la catégorie de genre urban fantasy ou horreur contemporaine.

Source : Godlike: Superhero Roleplaying in a World on Fire, 1936-1946 (2001)
JeuxÉdition
Achtung Cthulhu!
Armageddon: The End Times2nd ed.
Bitume10e anniversaire
Changeling: The Dreaming1st ed.
Corporation
Cypher System
Fanhunter, el juego de rol épicodecadente
Godlike
In Nomine Satanis – Magna Veritas1ere éd.
In Nomine Satanis – Magna Veritas4e éd.
Nephilim3e éd.
Nephilim20e anniv. (4e)
NephilimEnglish
Orpheus
Over the Edge2nd ed.
Retrofuture
Sorcerer
Space Master2nd ed.
The Laundry
Werewolf: The Apocalypse2nd ed.
Z-Corps
Liste des 21 jeux mélangeants des épigraphes réels à des épigraphes fictifs inventés

Épigraphes d’œuvres existantes

Parmi les œuvres existantes, les types d’épigraphes les plus représentés (en général, voir note ci-dessous) sont :

Types d’épigrapheNombre de fois représentées
literature125
academic69
historical58
franchise44
religious39
music38
cinema31
confusing mix21
bd, comic, manga20
game17
unknown10
videogame1
Je n’ai pas indiqué le % proportionnel de chaque type car il peut y avoir plusieurs types pour un même jeu.

Note : Je n’ai pas compté le nombre de chaque type d’épigraphes. Je pense que c’est une erreur car j’aurai pu avoir un codage plus fin et plus pertinent. Je ne l’ai pas fait en croyant que je me gagnerai du temps mais, in fine, je ne pense pas que cela m’aurait créé plus de travail.

JeuxÉditionNombre d’épigraphes d’œuvres existantes
Buffy the Vampire Slayer Roleplaying Game410
SengokuRevised ed.310
The Lord of the Rings Roleplaying Game273
Arcana Mvndi125
Mage: The Ascension1st ed.112
Vampire: The Masquerade1st ed.93
A Game of Thrones92
The Dying Earth Roleplaying Game91
Miles Christi90
The One Ring Roleplaying GameAdventurer’s book90
Top 10 des jeux qui citent le plus d’œuvres existantes

Futures pistes de recherche

  • Recenser d’autres jeux.
  • Recenser les pratiques de citations dans les bibliographies, les listes d’inspiration, les conseils de lecture, les références historiques, etc.
    • Comparer si les jeux avec une bibliographie sont aussi des jeux avec épigraphes. Corrélations ?
  • Constituer une liste de jeux notables avec un système de pondération pour donner une valeur aux données issues de chaque jeu. Par exemple, Vampire: The Masquerade n’a pas eu le même poids dans la culture du jeu de rôle que La méthode du Dr. Chestel. Établir des critères objectifs : nombre d’éditions, nombre de traductions, nombre de citations par d’autres jeux, existence d’une page Wikipédia, etc.
    En effet, je me suis rendu compte que présenter des données sans ce type de pondération avait moins de pertinence et moins de valeur car on peut moins généraliser.
    • Une fois la liste des jeux avec indice de notabilité constituée, dessiner un graphe avec le nombre d’épigraphes par années pour voir s’il y des tendances.

Mais pourquoi tout ça ?

  • Les jeux de rôle sur table et les citations me permettent de faire de la science amateur.
  • Cela permet de produire des connaissances modestes sur les jeux de rôle sur table, un domaine de niche mais que j’ai à coeur depuis l’école primaire.
  • Cela me permet d’exercer des méthodes pour ensuite être plus proche cognitivement et émotionnellement des étudiants et des chercheurs que j’accompagne.
  • Dans la démarche scientifique, il y a un aspect important : une douloureuse et irrationnelle obsession (painful irrational obession). On ne peut pas faire l’économie d’une collecte des données éreintante et coûteuse en persévérance. Un peu comme les scientifiques qui comptent les oiseaux sur des îles sans plage. Je pense que la science ne peut se passer de cette dimension fastidieuse. Savoir ça c’est bien, mais le pratiquer met bien les choses en perspective.
  • Je pense qu’en étudiant un sujet à fond, quel qu’il soit (alors autant que ce soit un hobby passionnant), on accroit sa culture générale. De plus, en étudiant ce sujet à fond, cela nous oblige à aller découvrir des méthodes et des bonnes pratiques (que l’on peut ensuite appliquer ailleurs).

Références

rdrr.io : Incorporer du code R dans une page web

Harnušek, Ondřej. « Lovecraft and Poe: Masters of the Macabre of Providence ». B.A. English Language and Literature, Masaryk University, 2013. https://is.muni.cz/th/361731/ff_b/Lovecraft_and_Poe_Masters_of_the_Macabre_of_Providence.pdf

Rothman, Joshua. « How Does Science Really Work? » The New Yorker, https://www.newyorker.com/magazine/2020/10/05/how-does-science-really-work. Consulté le 15 avril 2021.

Szalai, Jennifer. « Modern Science Didn’t Appear Until the 17th Century. What Took So Long? » The New York Times, 7 octobre 2020. NYTimes.com, https://www.nytimes.com/2020/10/07/books/review-knowledge-machine-irrationality-created-modern-science-michael-strevens.html.

Contribuer en lot à Wikidata avec QuickStatements

Après avoir fait plus de 14 000 modifications à la main dans Wikidata, je me suis enfin penché sur les modifications semi-automatiques de QuickStatements, une API qui permet les modifications en lot. Voici la méthode pour se sauver du temps et de l’ennui avec l’exemple de la propriété P123 Publisher pour les maisons d’édition de jeux de rôle sur table :

Exporter une table csv depuis Wikidata

  1. Lancer une requête SPARQL avec, pour chaque élément, une colonne pour l’identifiant Q Wikidata et une colonne pour le label. Dans l’exemple, item = élément de base Q Wikidata du jeu, itemLabel = nom du jeu, publisher = élément Q de la propriété P123, publisherLabel = nom de la maison d’édition.
SELECT DISTINCT ?item ?itemLabel ?publisher ?publisherLabel WHERE {
  {
    { ?item wdt:P31 wd:Q1643932. } #TTRPG
    UNION
    { ?item wdt:P31 wd:Q2164067. } #System
    UNION
    { ?item wdt:P31 wd:Q71631512. } #supplement
    UNION
    { ?item wdt:P31 wd:Q4418079. } #setting
    UNION
    { ?item wdt:P31 wd:Q4686479. } #adventure, campaign
  }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
  OPTIONAL { ?item wdt:P123 ?publisher.}
}
ORDER BY (?itemLabel)

Try it!

  1. Enregistrer au format csv.

Éditer le fichier csv

  1. Ouvrir le fichier csv dans LibreOffice Calc (le meilleur éditeur libre de fichier csv).
  2. Modifier les éléments désirés en ajoutant les Label dans la colonne Publisher Label. Bénéficier de la saisie semi-automatique si l’élément existe déjà.
    Si l’élément n’existe pas, le créer dans Wikidata et le rajouter dans la colonne Q ET la colonne Label.
  3. Trier la colonne Label. Copier-coller les Q manquants très visibles dans les trous de la colonne.
  4. Supprimer les colonnes Label.
  5. Sauvegarder les deux colonnes restantes au format csv.
  6. Déboublonner le fichier csv. J’ai testé 3 méthodes, la meilleure est Notepad++ avec l’extention TextFX. Voir annexe.
  7. Sur la première ligne, remplacer item, publisher par qid,P123. Le fichier devrait ressembler à ceci :
qid,P123
Q270118,Q2832284
Q2703461,Q762106
Q27102849,Q28466028
Q2720180,Q1433597
Q2755273,Q1543201

Verser dans Wikidata avec QuickStatements

  1. Aller sur QuickStatements, connectez-vous avec votre identifiant Wikimedia. Nouveau lot > Collez le contenu du fichier csv dans la case puis cliquez sur le bouton Importer les commandes CSV.
  2. Et voilà!

Annexe : comment dédoublonner des fichiers txt, csv,…

Cas: j’ai 1575 lignes à dédoublonner dans un fichiers csv. Trois méthodes sont testées :

A. Dans Calc : Bien.

  1. Sélectionner LES DEUX colonnes > Données > Plus de filtres > Filtre Standard > Nom du champs = “Aucun” + Options = “Sans doublons” > OK.
  2. Copier-coller le résultat dans Notepad++. Remplacer (mode étendu) les \t par des virgules ,

B. Dans Notepad++, par expression régulière : Pas robuste.

  1. Remplacer (mode expression régulière) ^(.*?)$\s+?^(?=.*^\1$) par rien. Cocher .match newlines
  2. Échec : ne fonctionne que pour 300-400 lignes max.

C. Dans Notepad++, avec extension TextFX : Bien.

  1. Installer TextFX : Plugins > Plugin Manager > Show Plugin Manager > Available tab > TextFX > Install
  2. Sélectionner tout. TextFX > TextFX Tools > Activer : +Sort Ascending et +Sort output only…
  3. Puis TextFX > TextFX Tools > Sort lines cases Sensitives (at colums)

Résultats A et C : 901 lignes restantes.

Fouille de texte dans les éditions de D&D (Étape 1 : choisir l’extraction pdf)

Cet essai est un bac à sable pour expérimenter un flux de données et leur traitement en fouille de texte (text mining). Cette première partie compare différentes méthodes pour sortir des données des pdf.

Les fichiers pdf sont extrêmement hétérogènes. Cela va du fichier produit professionnellement et électroniquement au fichier numérisé à la main dans un garage avec plein de bugs dans la structure.

Flux de données

1. Sélection du corpus des données

Seuls les livrets ou la boîte de base de chaque édition de D&D sont sélectionnées.

2. Récolte des différentes éditions en pdf

Cette récolte a été effectuée par des moyens que les lois sur la propriété intellectuelle réprouve. Je brave le risque en me disant que je fais ça dans un but purement académique.

3. Renommage des fichiers

Old Dungeons & Dragons (1974 ed.)
1974-odd-mnm : booklet no.1, Men & Magic
1974-odd-mnt : booklet no.2, Monsters & Treasures
1974-odd-unw : booklet no.3, The Underworld & Wilderness
Adventures
1974-odd-rs : reference sheet

D&D boxed set Holmes ed. (1977)
1977-ddholmes-box

D&D Moldvay ed. (1981)
1981-ddmoldvay-basic : Basic boxed set
1981-ddmoldvay-expert : Expert boxed set

D&D BECMI Mentzer ed. (1983)
1983-ddbecmi-b : Basic boxed set
1983-ddbecmi-e : Expert boxed set
1983-ddbecmi-c : Companion boxed set
1983-ddbecmi-m : Master boxed set
1983-ddbecmi-i : Immortal boxed set

Advanced Dungeons & Dragons (1979)
1979-add1-mm : Monster Manual
1979-add1-phb : Player’s Handbook
1979-add1-dmg : Dungeon Master Guide

Advanced Dungeons & Dragons 2nd (1989)
1989-add2-phb : Player’s Handbook
1989-add2-dmg : Dungeon Master Guide
1989-add2-mm : Monstrous Compendium vol.1

Advanced Dungeons & Dragons 2nd Revised ed. (1995)
1995-add2r-phb : Player’s Handbook
1995-add2r-dmg : Dungeon Master Guide
1995-add2r-mm : Monster Manual

Dungeons & Dragons 3rd ed. (2000)
2000-dd3-phb : Player’s Handbook
2000-dd3-dmg : Dungeon Master Guide
2000-dd3-mm : Monster Manual

Dungeons & Dragons 3.5 ed. (2003)
2003-dd35-phb : Player’s Handbook
2003-dd35-dmg : Dungeon Master Guide
2003-dd35-mm : Monster Manual

Dungeons & Dragons 4th ed. (2008)
2008-dd4-phb : Player’s Handbook
2008-dd4-dmg : Dungeon Master Guide
2008-dd4-mm : Monster Manual

Dungeons & Dragons 5h ed. (2014)
2014-dd5-phb : Player’s Handbook
2014-dd5-dmg : Dungeon Master Guide
2014-dd5-mm : Monster Manual

4. Déplacement de tous les fichiers

Tous les pdfs sont placés dans un dossier \pdfraw à la racine du projet.

5. Préparation des pdf : OCR

Je lance une reconnaissance de caractères (OCR) dans les pdf numérisés qui n’ont pas encore reçu ce traitement. Il y en a peu (2 seulement).

Avec le logiciel Adobe Acrobat 2017 : Passe à 600 dpi. Traitement en lot possible mais la sélection des fichiers à reconnaître doit être faite manuellement.

Dans le logiciel PDF Converter Elite 5, l’OCR se fera toute seule lors de l’exportation (étape 6). Cela va même plus loin puisque ce dernier ignore les OCR effectuées et enregistrées précédemment et il refait les siennes (ça prend un temps fou du coup : 5h).

6. Exportation des PDF aux format TXT et XML.

Quand l’option est disponible, je choisis l’encodage UTF-8.

Avec Adobe Acrobat 2017

  • TXT (brut, plain).
  • TXT (accessible, acessible).
  • XML 1.0 : sans images.

Traitement en lot décevant : 1) automatisation possible via le créateur d’Actions mais beaucoup trop de fenêtres intermittentes stoppant le processus et demandant des clics de validation; 2) quelques erreurs de transcriptions au format txt; 3) le format txt (Accessible) ignore beaucoup contenus de fichiers (0 Ko ou 3 Ko); 4) le format XML 1.0 est mal formé (très dur de le charger dans R) et contient plein d’erreurs.

Avec Calibre 4.13

Traitement en lot décevant aussi (le processus est facile et continu mais l’exportation échoue pour plusieurs PDF). Paramétrage nécessaire pour garder le nom de fichier original.

Avec le package pdftools de R Studio

Globalement bon et rapide, mais il y a des erreurs et je n’arrive pas à identifier où car les logs d’erreurs ne le disent pas (mentions de PDF error: read ICCBased color space profile error et PDF error: not an ICC profile, invalid signature).

Syntaxe du code R pour charger les données :

# install.packages("pdftools")
library(pdftools)

# make a list of all pdf files in pdfraw folder
files <- list.files(path="pdfraw", pattern="*.pdf", full.names=TRUE)

# put all the files into a bigdata variable
bigdata <- lapply(files, pdf_text)

Avec PDF Converter Elite 5

Traitement en lot en continu. Comme mentionné précédemment : le logiciel lance un OCR sur tous les fichiers pdf numérisés, même ceux avec déjà une couche OCR.

Tableau de comparaison des exportations

Acrobat 2017 Calibre 4.13 pdftools PDF Conv. 5
logiciel propriétaire libre libre propriétaire
formats xml 1.0 / txt:plain / txt:acessible txt txt txt
flux du traitement batch interrompu constamment quelques interruptions continu continu
durée du traitement : 33 fichiers, 1Go total 30 min. / 30 min. / 30 min. 14 min. 2 min. 5h
nb mots total du corpus (6 756 pages) en millions 5,07 (c) / 4,68 (a) / 2,54 (a) 3,44 (a) 5,53 (b) 4,69 (a)
fichiers ignorés (ou dont +95% est manquant) 0 / 4 / 33 11 1 6

Méthodes de calcul du nombre de mots du corpus

(a)

Calculé avec le logiciel Notepad++ et son plugin Combine 1.0 (à installer et qui combine tous les fichiers ouverts dans le logiciel dans un nouveau fichier).
Puis avec l’option Affichage (View) > Résumé (Summary) sur le nouveau fichier combiné.

(b)

Calculé en exportant les données de R Studio avec le script suivant :

#install.packages("erer")
library(erer)
write.list(bigdata,"output.txt")

Et ensuite avec l’option Affichage (View) > Résumé (Summary) sur le fichier output.txt (vu le volume j’ai ignoré le mot result mais il aurait pu être enlevé en multiremplacement dans NP++ pour un corpus plus petit, voir plus bas).

Bonus : un script R pour sortir les fichiers txt procédés par pdftools dans un dossier /pdfexports/pdftools :

library(pdftools)
files <- list.files(path="pdfraw", pattern="*.pdf", full.names=TRUE)
nb_files <- length(files)
for(i in 1:nb_files) {
  onefile <- pdf_text(files[i]) #1 
  x <- gsub("pdfraw/","",gsub(".pdf","",files[i])) #2
  write(onefile,file=paste("pdfexports/pdftools/",x, ".txt", sep="")) #3
}
# 1. process (i) pdf file into onefile
# 2. strip the path and the .pdf to keep the core name
# 3. write a txt file in the subdirectory
# How to encode in utf-8?

(c)

J’ai tenté de charger les xml générés par Acrobat dans R Studio et créer un fichier compilé mais il y a beaucoup de messages d’erreur.

library(readr)
files <- list.files(path="pdfexports/acrobat_xml", pattern="*.xml", full.names=TRUE)
bigdata_xml <- lapply(files, read_csv)
# ici on s'aperçoit de plein de messages d'erreur
library(erer)
write.list(bigdata_xml,"output_xml.txt")

Du coup, j’ai combiné tous les fichiers xml comme dans le point (a). Puis, toujours dans NP++, je multiremplace (Ctrl+H) en mode Expressions régulières :
<[^>]*<[^>]*>[^>]*>|<[^>]*> par rien.
Enfin, j’utilise l’option Affichage (View) > Résumé (Summary) pour compter le nombre de mots.

Moralité

  1. Le format pdf est un format atroce pour faire de la fouille de texte.
  2. pdftools de R Studio est rapide, gratuit mais il peut manquer des choses dans des pdf mal formés.
  3. Les exportations xml 1.0 de Acrobat ne sont pas bien formatées, en tout cas pas assez bien pour les charger aisément dans R Studio. Celle en plain txt est meilleure car moins verbeuse. Dans tous les cas, c’est fastidieux de cliquer à la main pour tous les fichiers.
  4. PDF Converter Elite 5 semble faire une exportation correcte et fluide tant qu’on le laisse tourner pendant la nuit.

Prochaine étape

Je vais faire une analyse plus qualitative des exportations en comparant les différents corpus de txt extraits.


Ce billet a été pré-rédigé dans HackMD puis exporté en html. Je le conseille vivement.

Pratiques de citation des jeux de rôle sur table : Wikidata, SPARQL et RStudio

Avertissement : Les données sont incomplètes et leur traitement est embryonnaire. Ce 100e billet de blogue a pour but de faire le point sur la méthode et les résultats à mi-parcours.

Introduction

Dans le cadre du Projet Sur les épaules des géants des nuages, qui analyse les pratiques de citations dans les jeux de rôle sur table (JDRT), j’ai poussé mon travail vers :

  1. La sélection et le dépouillement de jeux de rôle sur table ;
  2. La création d’une base de données de citations, structurée et hébergée à l’intérieur de Wikidata, puis interrogée par SPARQL ;
  3. L’analyse de cette base de données par R et R Studio, une suite de logiciels libres de traitement statistique.

Sélection

La sélection des JDRT s’est faite sur :

  • La liste de tous les JDRT qui ont une page Wikipédia en anglais et en français. Complétude estimée : environ 95% ;
  • Plus tous les JDRT cités dans des périodiques que je suis depuis les dix dernières années : des podcasts francophones, des blogues francophones et anglophones et des magazines sur le JDRT. Complétude : environ 80% ;
  • Plus tous les JDRT cités par des JDRT issus des listes précédentes.

Cette sélection est modérément biaisée car la notoriété est attribuée de manière externe par des tierces parties (ie. les contributeurs de Wikipédia et les éditeurs des périodiques).

La sélection a été validée par le fait que chaque jeu mentionné comporte une ou plusieurs notices de référence dans la base de données RPGGeek (environ 99.9%).

Dépouillement

Le dépouillement des JDRT a été fait sur plusieurs mois. Chaque page de JDRT mentionnant un autre JDRT a été récolté dans un dossier électronique par numérisation ou par re-numérisation (capture d’écran d’un PDF par exemple) sous la forme de fichiers image PNG nommés nomdujeu-pXX.png (où XX représente la page de la numérisation).

Pour enrichir les données dépouillées, des métadonnées d’édition du JDRT ont aussi été capturées : ours, colophons,  pages de crédit (env. 90%), pages de remerciement, extrait de la page des participants des souscriptions (env. 50%), parfois couverture ou dos de couverture (env. 5%).

D’autres mentions de citation, d’attribution ou de référence ont été récoltées : bibliographies, filmographies, citations d’auteurs ou d’œuvres, etc.

Tout ou une partie des épigraphes ont été récoltés.

Conception de la base de données

J’ai choisi Wikidata pour déposer le cœur de la base de données des pratiques de citation.

  • Cela m’évite d’avoir à créer ma propre base de données ;
  • Cela me permet de partager ma base de données de manière ouverte ;
  • Wikidata est simple à alimenter ;
  • Wikidata exporte dans des formats simples. Aussi, il est très facile de l’interroger directement via R Studio avec le package adéquat ;
  • Il y avait presque toutes les propriétés dont j’ai besoin :
    • propriétés de citation (cites work P2860)
    • publisher P123
    • movement P135
    • author P50
    • publication date P577
    • Inconvénient : il n’y a pas de propriété pour renseigner les informations suivantes : existence d’une bibliographie, présence d’épigraphes.
  • Je peux potentiellement lier les données à d’autres bases de données pour enrichir ce cœur (à explorer : c’est une manipulation à faire dans R Studio, ou bien à faire semi-automatiquement dans Wikidata grâce à des programmes comme QuickStatements).

Pour l’occasion et pour enrichir Wikidata de données liées, j’ai demandé à Wikidata la création d’une propriété d’identifiant (identifier ID P7226) vers RPGGeek pour commencer à lier ces deux bases de données. L’identifiant est désormais présent dans l’outil Mix’n’Match de Magnus Manske.

Avancement

La saisie dans Wikidata a débuté en mai 2019. En décembre 2019, il y avait environ 13 000 éditions faites.

Environ 300 éléments Q ont été créés. La plupart sont des éléments Q d’un JDRT inexistant auparavant. Plus rarement, un élément Q a été créé pour une catégorie taxonomique (ex: tabletop role-playing game supplement, GM-less, death spiral, etc.).

Environ 766 liens ont été créés entre 137 JDRT (voir cette extraction SPARQL).

Beaucoup de données étaient à corriger ou à préciser. Par exemple, de nombreux JDRT n’avaient pas d’instance, ou bien avaient l’instance jeu (game) ou jeu de rôle (role-playing game), alors que l’instance correcte est jeu de rôle sur table (tabletop role-playing game).

D’autres mises en ordre taxonomiques ont été référencées sur la page WikiProject Boardgame.

SPARQL

Le langage SPARQL permet d’extraire les données de Wikidata. La principale requête pour ce projet a été déposée ici. Elle est aussi présente directement dans le code R.

Elle permet d’extraire un tableau simple, ayant les jeux analysés dans une colonne et tous les jeux de rôle cités par celui-ci dans une autre colonne.

Dans une seconde phase, il va être intéressant d’exporter aussi les données de maison d’édition et d’auteur pour pondérer à la baisse la force de certaines citations. En effet, beaucoup de jeux d’une même gamme/ maison d’édition se citent les uns les autres. De la même manière, parfois des jeux du même auteur sont mentionnés en indication purement autobiographique.

Analyse avec le logiciel R

R est une suite de logiciels libres pour traiter de données numériques. C’est la grande mode en ce moment dans la recherche universitaire alors pourquoi pas les utiliser pour mon projet ? Ces logiciels sont gratuit et ouverts, donc il existe beaucoup de partage de codes et d’outils en ligne. Idéal pour moi qui suis un programmeur du dimanche. De plus, la manipulation de R n’est pas très complexe avec l’interface R Studio.

J’ai déposé le code ici https://github.com/pmartinolli/OtSoCG

Cliquer sur l’image pour télécharger une visualisation des données (préliminaires) au format PDF.

Développement futur : comme expliqué précédemment, je souhaite pondérer les liens de citations en réduisant la force des liens vers d’autres JDRT de même publisher ou de même author.

Wikidata : base de données+requêtes pour programmeurs du dimanche

Synchronicité

Dans le billet précédent, j’expliquai les limites techniques de mon projet de chronologie des jeux de rôles, d’arbre des innovations et des citations, par mes limites de compétences en informatique. Il se trouve que je viens tout juste d’assister à une formation sur Wikidata donnée par Simon Villeneuve, véritable wiki-héros Chicoutimien (107 contributions).

Wikidata est une solution simple pour constituer une base de données d’éléments liés (ex: Q1375) et  pour générer des tableaux de données, des chronologies, des graphes, etc. grâce à des requêtes complexes. Même si les déclarations d’éléments peuvent être complexes, Wikidata m’évite d’avoir à apprendre des langages de programmation, de structuration de données et d’installer le tout localement. De plus, le cheminement est progressif et il porte ses fruits dès le début. Il peut être jumelé ou soutenir des projets d’humanités numériques pour lesquels vous manquez de ressources de programmation. Parlez-en à votre bibliothécaire disciplinaire.

Du coup, je réfléchis comment apparier mes données avec celles de Wikidata et comment utiliser cet outil qui a le bénéfice d’être entièrement ouvert (le contenu dans le domaine public CC0).

Bases de Wikidata

  • Un élément Wikidata Q possède des propriétés P qui elles-mêmes sont souvent d’autres éléments Q.
  • Pour plus de précisions, on peut encore préciser ces données avec des éléments P et Q.
  • Chaque élément est multilingue.
  • Il est possible de sourcer tous les éléments avec des références bibliographiques.
  • Il est possible de lier les données à des bases de données externes grâce à des propriétés de type « Identifiers / Identifiants ».
  • Chaque modification est signée et comptabilisée (j’en suis à 12 000 en nov. 2019).
  • On peut interroger Wikidata et récupérer les données sous différents formats grâce à des requêtes SPARQL (exemples).
  • On peut s’amuser à renseigner des éléments :

Bonnes pratiques pour les jeux de rôle sur table

Requêtes SPARQL

Exemples de graphe sur les pratiques de citation dans les jeux de rôle sur table.

Méthode et structure du code dot de l’arbre des innovations des jeux de rôle sur table

Lien vers le dépôt GitHub contenant le code source et le PDF

Mets ta méthode (méta-méthode?)

La meilleure (mais que je n’ai pas suivie)

Idéalement, pour conduire un projet d’arbre phylomémétique des innovations dans les jeux de rôle sur table, la meilleure méthode serait de générer du code à partir d’une base de données dont les éléments seraient les jeux, les innovations et les liens entre eux.

L’intérêt principal de cette méthode est que je pourrais ainsi catégoriser les éléments (leur ajouter des mots clés) et générer facilement un ou plusieurs graphes selon ces catégories. Par exemple, générer un arbre des liens de citation seulement, un arbre autour des mécaniques de randomisation (dés, etc.), un arbre sur les jeux français, etc. Cela permettrait aussi de générer un arbre pour deux langues facilement : un avec des champs en anglais et un un avec des champs en français.

Pour cela, je pourrais utiliser Gephi pour toute la chaîne de production. Ou bien, je pourrais utiliser une base de données, interrogée par Python qui génèrerait du code en langage dot, puis qui serait interprété en ps par Graphviz, puis en pdf par Acrobat Distiller.

La pire (Que j’ai évité)

La pire méthode serait de créer les éléments du graphe et de les relier manuellement directement dans le document final. Exemple : en déroulant une feuille papier de 2 x 3m et rédigeant tout avec un crayon papier. Ou bien en utilisant un logiciel de diagramme visuel WYSIWYG comme Visio, CMaptools, etc.

La voie du milieu (Que j’ai choisi)

En effet, comme je ne sais pas utiliser Gephi ni programmer en Python, j’ai choisi une méthode qui court-circuite la base de données de la «meilleure méthode» ci-dessus pour coder toutes les données directement en langage dot. Cependant :

  1. Cela m’oblige à bricoler des règles de structure car je ne peux pas facilement catégoriser les éléments.
  2. Tout est dans un seul bloc de code. Donc, si je veux couper des éléments pour faire des petits arbres plus simples, il faut que je regroupe ces éléments dans des parties bien séparées (et facilement escamotables).

Chronologie des jeux de rôle sur table (rendu partiel ne tenant pas en compte des innovations, des liens d'auteur, de citation ou de règles)
Chronologie des jeux de rôle sur table (rendu partiel ne tenant pas en compte des innovations, des liens d’auteur, de citation ou de règles)

Le code source code est une adaptation du code créé par Todd Lehman pour son “TeX Family Tree”.

J’ai fait un modèle simple reprenant toute la structure en quelques éléments (aperçu). N’hésitez pas à vous l’approprier pour vos propres projets (et me citer).

Partie 1 : le préambule

  • Métadonnées
  • Conseils de compilation du code
  • Paramètres du graphe

Partie 2 : la ligne du temps

  • de 1969 à maintenant

Partie 3 : la liste des jeux de rôle

{ rank = same; 1977; dndholmes [label="Basic D&D [Holmes]"]} odnd_whitebox -- dndholmes ;
{ rank = same; 1981; dndmoldvay [label="Basic D&D [Moldvay]"]} dndholmes -- dndmoldvay ;
{ rank = same; 1983; dndmentzer [label="Basic D&D [Mentzer]"]} dndmoldvay -- dndmentzer ;
  • Ils sont listés et regroupés par :
    • gamme
      • avec une liste des différentes éditions des règles
      • suivie d’une liste des suppléments/ modules marquants
    • puis ils sont listés et regroupés par genre (fantasy, sf, etc.)
  • Chaque élément est décrit de la manière suivante : 1ère année de publication / identifiant unique / label [nom du jeu et édition] / lien immédiat vers le jeu précédent de la gamme

Partie 4 : la liste des innovations : mécaniques de jeu, intentions ludiques, etc.

Pour le moment, cette partie n’est pas diffusée sur GitHub.

  • Chaque élément est décrit de la manière suivante  : Identifiant unique / label (description synthétique de l’innovation) / lien immédiat avec le jeu dont cette innovation est issue.
    • { identicaldices [label = "Sets of identical-dices values in dice pool"]} godlike -- identicaldices ;
  • Option du label : précédé de «1st» si c’est original (1ère fois que…)
    • label = "1st critical hit\n['lucky hit']"
  • Les innovations sont classées par grandes catégories. Chaque catégorie est colorée différemment.

Liste des catégories des innovations

  • Miscellaneous historical innovations
  • Authority on fiction: gamemaster roles vs players roles
  • Campaign, adventure
  • Design
  • Resolution system
  • Critics & level of success
  • Dramatic modifiers to resolution
  • Saves
  • Use points to influence success (aka Meta-currency)
  • Health
  • Group
  • Sheet
  • Character generation
  • Character advancement
  • Magic
  • Morality, Alignment, Personality, Sanity
  • Literature / Genre Emulation
  • Rolls & Randomizers

Partie 5 : méta-liens entre les éléments

Pour le moment, cette partie n’est pas diffusée sur GitHub.

Les liens de base existent déjà entre les jeux (dans la liste des jeux de la partie 3) et entre les jeux et les innovations (dans la liste des innovations de la partie 4). Dans cette partie, on va tisser d’autres types de liens.

liens de Même auteur

La liste des principaux concepteurs de jeu, avec un historique de leurs principaux jeux édités.

eotpt -- eotpt83 -- eotpt87 -- aot1992 -- tita2002 -- eotpt2005 [headlabel = "M.A.R. Barker"] ;

liens de Citation directe

Quand un jeu est cité par un autre jeu en bibliographie, en dédicace, etc.

{dnd0 -- tnt1} -- runequest1 ;

liens autres

Liens divers mais significatif entre 2 jeux : même maison d’édition, mêmes règles, même univers diégétique, etc. Le trait est alors en pointillé.

  • pathfinder -- starfinder [style=dotted];;
  • { orientaladventures ; l5r2 } -- orientaladventures2 [style=dotted];;
  • agameofthrones -- asongoficenfirerpg [style=dotted];
  • tombofhorror -- returntombofhorror -- tombofannihilation [style=dotted] ;

Comment indiquer les sources des jeux et des innovations ?

  • Les sources sont indiquées dans le code du graphe sous la forme de commentaires (ex: #s075). Les numéros d’identifiants sont uniques, ils sont précédés d’une lettre indiquant le type de source.
    • #p001 : source no. 001, une source primaire
    • #s045 : source no. 045, une source secondaire
    • #t078 : source no. 078, une source tertiaire
  • La liste des sources est rédigée dans un document sources.md à part.
    • Le début du fichier liste les sources générales
    • La fin du fichier recense spécifiquement toutes les sources utilisées.

Role-playing games : Basic bibliometry with PsycNET (draft)

Nombre de publications révisées par les pairs référencées dans PsycNET

Martinolli, Pascal. « Role-Playing Games : Basic Bibliometry with PsycNET (Draft) », février 2018. (accès et réutilisation libre : CC BY)

Une analyse bibliométrique simple sur le sujet des jeux de rôle dans les bases de données en psychologie de PsycNET.

Données complémentaires (csv data, références bibliographiques, code source,…)