Le problème​

La documentation fait partie intégrante de tous les produits logiciels et, pour être utile, elle doit être complète et détaillée. Cependant, cela représente un défi à la fois pour les utilisateurs et les développeurs. Les utilisateurs, en particulier ceux qui découvrent le logiciel, peuvent trouver décourageant de passer au crible de gros blocs de texte, tandis que les développeurs ont souvent du mal à rendre la documentation attrayante et digeste.

Tout au long de mes études universitaires, j'ai fait partie de la première catégorie. En tant qu'utilisateur, j'ai toujours trouvé la documentation difficile à comprendre. Elle me laissait souvent avec plus de questions que de réponses. Le fait que les sites web de documentation que j'utilisais avaient souvent une mauvaise navigation et peu de ressources pour m'aider à comprendre ce que je lisais ne m'a pas aidé, me laissant parcourir différents sites pour trouver des informations qui étaient cachées dans un coin.

En tant qu'étudiant coopératif chez LINCS, j'ai été chargé de migrer le site de documentation du Canadian Writing Research Collaboratory (CWRC). Ce site web fournissait des informations sur les trois ontologies développées par le CWRC et permettait d'y accéder, chacune avec son propre ensemble de documentation. Cela m'a inquiété, car comment développer un site web capable d'afficher efficacement la documentation tout en tenant compte de la navigation, de l'esthétique et de la mise en page ?

Docusaurus​

C'est là que Docusaurus entre en jeu. Docusaurus est un puissant générateur de site statique construit avec React, qui permet aux utilisateurs de créer rapidement et facilement des sites web axés sur la documentation. Comme Docusaurus est conçu spécifiquement pour la documentation, j'ai pu me concentrer sur la présentation du contenu au lieu de me préoccuper du design. Plutôt que de s'appuyer sur des balises HTML pour afficher le contenu, Docusaurus utilise Markdown (MD) et Markdown eXtended (MDX), un langage convivial à la syntaxe simple et facile à assimiler, qui prend également en charge Javascript XML (JSX). Cela m'a permis de combiner la nature simpliste de MD tout en exploitant la flexibilité et la puissance de JSX. Docusaurus combine le tout sous forme de fichiers HTML statiques que je pouvais facilement déployer sur le site web du CWRC, et il permettait même d'intégrer des composants React. Sans sacrifier la fonctionnalité, Docusaurus a rationalisé le processus de création et de publication de la documentation.

Docusaurus m'a permis de créer facilement le type de site web dont la documentation du CCRF avait besoin. L'un des objectifs de la migration du site web des données liées du CCRF était d'améliorer l'accessibilité et la lisibilité des informations du CCRF. Le site original, bien que fonctionnel, manquait de structure et de navigation cohérentes, ce qui le rendait difficile à utiliser.

(Figure : Avant et après)

Ces difficultés se sont également répercutées sur la mise en œuvre, car la structure de codage de la documentation semblait encombrée en raison du nombre de balises HTML nécessaires pour afficher le texte. C'est là que la simplicité de Markdown s'est avérée précieuse, car elle a permis de rationaliser le processus de transition des informations vers le nouveau site web. Bien que je n'aie pas été en mesure d'abandonner complètement les balises HTML, une grande partie de la documentation est maintenant formée avec Markdown, ce qui facilitera le processus de remaniement ou d'édition à l'avenir.

Outils utiles​

Cela ne veut pas dire que Docusaurus n'est utile que pour ses capacités Markdown, car il possède également de nombreux composants et crochets utiles. L'un de ces composants que j'ai souvent utilisé est <Link/>,qui permet de créer des liens à la fois pour les pages internes et externes. Ce qui différencie ce composant des balises HTML de base comme <a/> est sa capacité à précharger les ressources avant de naviguer vers la page de la ressource. En utilisant le “onMouseOver” pour récupérer les ressources demandées sur cette page, Docusaurus précharge ces ressources afin d'assurer des transitions fluides et efficaces entre les pages. L'accès à des informations supplémentaires par le biais de liens internes et externes rend la documentation plus claire et plus facile à parcourir, réduisant ainsi pour les utilisateurs le type de difficultés que j'ai rencontrées en utilisant la documentation d'autres logiciels.

En tandem avec ses divers composants, Docusaurus supporte également les plugins ESLint avec des règles supplémentaires, qui sont compatibles avec ses composants uniques. Ces plugins permettent aux utilisateurs qui ne connaissent pas Docusaurus (moi y compris) de développer du code tout en adhérant aux meilleures pratiques et en utilisant pleinement les capacités de Docusaurus. En d'autres termes, Docusaurus est construit pour faciliter son utilisation. Il ne s'agit pas seulement d'un avantage, mais aussi d'un excellent exemple de documentation et d'outils faciles à naviguer et à utiliser.

N'utilisez pas d'élément `<a>` pour naviguer. Utilisez plutôt le composant `<Link />` de `@docusaurus/Link`. Voir: https://docusaurus.io/docs/docusaurus-core#linkeslint@docusaurus/no-html-links

En résumé​

Alors qu'une documentation dense et riche en texte s'avère toujours difficile à présenter de manière digeste, Docusaurus aide les développeurs à se concentrer sur leur contenu plutôt que sur les détails de la création d'un site. Avec sa communauté grandissante et son code source facilement disponible pour aider les nouveaux venus à apprendre et à collaborer, il n'est pas surprenant que Docusuarus soit un générateur de site de premier plan pour les sites web axés sur la documentation. Tout en continuant à apprendre les tenants et les aboutissants, je suis toujours impressionné par le caractère réfléchi et intuitif de Docusaurus et je continuerai à utiliser ses capacités au maximum.

J'ai passé la majeure partie de mon été à améliorer l'accessibilité du site web du projet LINCS. Au cours de ce processus, j'ai beaucoup appris sur la façon dont les personnes handicapées naviguent sur Internet. Il y a eu beaucoup à faire et cela m'a pris beaucoup de temps, mais ce n'est pas une fatalité ! Si les concepteurs intègrent l'accessibilité dès le départ, un effort supplémentaire minime permet d'améliorer l'expérience de tous les utilisateurs, et pas seulement de ceux qui ont des barrières.

27 % des Canadiens ont un ou plusieurs handicaps qui les empêchent d'accomplir leurs activités quotidiennes, selon l'Enquête canadienne sur le handicap..

En outre, on estime que 1,5 million de Canadiens ont perdu la vue et que 6 millions d'autres souffrent d'une maladie qui pourrait entraîner une perte de la vue. Sans l'utilisation de lecteurs d'écran, ces personnes auraient des difficultés à naviguer sur le web, voire n'auraient aucun moyen de le faire. Pensez à la façon dont vous utilisez votre téléphone ou votre ordinateur pour effectuer des opérations bancaires, contacter des personnes, rechercher des informations, prendre des rendez-vous, trouver un emploi, créer des calendriers - les utilisations sont infinies. Si le web n'était pas accessible, il serait difficile, voire impossible, pour des millions de Canadiens d'effectuer une multitude de tâches quotidiennes.

En effectuant un petit audit d'accessibilité de la page d'accueil du projet LINCS, j'ai découvert que le premier niveau de titre (H1) était utilisé sur toute la page. Bien que cela me paraisse correct, j'ai réalisé à quel point il est important d'avoir une descente logique des niveaux de titres lorsque l'on navigue sur une page web à l'aide d'un lecteur d'écran. J'ai également découvert l'importance du « texte alt » pour ceux qui ne peuvent pas voir les images - et j'ai par la suite passé beaucoup de temps à ajouter un texte alt aux photos du site LINCS.

Si certains problèmes d'accessibilité sont évidents, beaucoup passent inaperçus. Les obstacles sont souvent invisibles pour ceux qui ont une bonne vue, une bonne ouïe ou une bonne dextérité. Heureusement, les outils de test d'accessibilité et les logiciels conçus pour les personnes handicapées permettent aux concepteurs de faire l'expérience de leurs propres sites web du point de vue de leurs utilisateurs. Ma première action lors de l'audit du site web LINCS a été d'activer le lecteur d'écran de Windows et d'essayer de naviguer les yeux fermés ; c'était beaucoup plus difficile qu'on ne le pense ! Une grande partie de cette difficulté était due à la surutilisation des titres H1.

La vidéo suivante montre comment une application de lecture d'écran populaire, JAWS, annonce les informations d'une page web bien structurée. Remarquez que JAWS s'appuie fortement sur les niveaux de titres pour communiquer l'importance et regrouper les informations pertinentes.

Les améliorations en matière d'accessibilité permettent à un plus grand nombre d'utilisateurs d'accéder au contenu ou d'utiliser des outils, tout en améliorant l'expérience de tous les utilisateurs. Prenons l'exemple des fonctions d'accessibilité audio. Plus de 50 % des Américains utilisent le sous-titrage quelquefois ou tout le temps selon CBS, et ce chiffre atteint même 80 % pour les membres de la génération Z. Comme l'explique CBS, des services de streaming populaires tels que Netflix ont initialement mis en place des sous-titres pour l'ensemble de leur contenu à la suite d'un plaidoyer de l'Association nationale des sourds en 2010. Depuis, les sous-titres sont devenus un élément essentiel du streaming, car ils sont utiles à tous : si vous êtes dans un environnement bruyant, si vous n'avez pas d'écouteurs dans une bibliothèque, si vous voulez regarder quelque chose dans une autre langue, etc. Une étude conjointe de Verizon et Publicis Media a fourni les statistiques suivantes après avoir mené une enquête sur les consommateurs américains de vidéos et de publicités :

• 80 % des spectateurs sont plus enclins à terminer la vidéo si elle est sous-titrée
• 69 % regardent des vidéos dont le son est désactivé
• 50 % déclarent que les sous-titres sont importants, citant généralement des raisons telles que le fait d'être dans un endroit calme, de ne pas avoir accès à des écouteurs ou d'être multitâches.
• 37 % des spectateurs sont enclins à activer le son si les sous-titres sont disponibles.

Un autre exemple de l'accessibilité qui profite à tous est celui des capacités mains libres que les gens utilisent souvent dans la voiture ou lorsqu'ils sont occupés à d'autres tâches telles que la cuisine ou le nettoyage. Les livres audio, destinés à l'origine aux personnes souffrant de troubles de la vue, ont connu une popularité croissante ; l'enquête annuelle sur les ventes de la Audio Publishers Association a révélé que les chiffres de vente ont connu une croissance à deux chiffres pendant 11 ans d'affilée.

Tout cela prouve que la conception accessible est tout simplement une bonne conception. C'est précisément pour cette raison que j'ai été si reconnaissant que ma première expérience dans le monde du développement web ait été axée sur l'accessibilité, car il s'agit d'une base essentielle qui m'a sans aucun doute permis de devenir un développeur web inclusif et plus efficace.

Que pouvez-vous faire pour aider ?​

Même si vous n'êtes pas développeur web ou concepteur de produits, vous pouvez contribuer à rendre le web plus accessible en plaidant en faveur de l'accessibilité, en faisant entendre votre voix et en demandant des choses telles que le sous-titrage ou les transcriptions. Si vous constatez que quelque chose n'est pas accessible - par exemple, un texte difficile à lire sur une affiche - donnez votre avis !

Si vous utilisez des médias sociaux tels qu'Instagram, LinkedIn, Facebook ou X, veillez à inclure un texte alt, un texte descriptif expliquant le contenu de la photo postée. Pour obtenir des conseils utiles sur le texte alternatif, consultez le Guide de Tug sur le texte alternatif dans les médias sociaux.

Veillez également à mettre une majuscule à chaque nouveau mot d'un hashtag ! Les lecteurs d'écran ont du mal à lire une phrase trop courte. Par exemple, #ILoveAccessibleWebsites se lira exactement comme vous le souhaitez, mais #Iloveaccessiblewebsites pourrait être lu comme un seul mot bizarre et très long.

Pour en savoir plus sur l'accessibilité du web, consultez cette introduction de W3.org.

Plaider en faveur de l'accessibilité, fournir un retour d'information et utiliser des pratiques inclusives sur les médias sociaux sont des moyens simples mais efficaces pour que chacun puisse apporter sa contribution. Je me réjouis à l'idée de réaliser de bonnes conceptions accessibles au cours de ma carrière. Engageons-nous tous à faire du web un endroit où personne n'est laissé pour compte.

Image: Opératrices de cartes perforées travaillant sur l'Index Thomisticus de Roberto Busa. En arrière à gauche : Rosetta Rossi Bertolli ; en bas à droite : Livia Canestraro. CC-BY-NC. Merci à Melissa Terras, "For Ada Lovelace Day," 2015.

Je suis surpris et ravi que quelqu'un ait jugé utile de me proposer pour le Prix Roberto Busa, et ravi d'avoir été placé par ADHO en si illustre compagnie, tout en étant pleinement conscient qu'il y a tant de superbes travaux dans notre communauté qui méritent cette reconnaissance.

Toute connaissance est relationnelle. Il est fabuleux de voir reconnue une recherche qui émerge d'une perspective intersectionnelle et qui s'inscrit dans un processus : de la fabrication d'objets qui tentent d'exploiter la technologie de manière nouvelle, en essayant et en échouant, mais en continuant à essayer de faire une différence dans notre manière de travailler et de nous permettre de créer et de partager des connaissances ensemble, de manière plus efficace, dans un monde en mutation. Pour un tel travail, la collaboration est essentielle, ce qui revient à dire qu'il s'agit avant tout de personnes.

Mes excellents collègues du LINCS ont formé une équipe phénoménale, même si nous nous sommes réunis à distance, beaucoup d'entre nous pour la première fois, au plus fort de la pandémie, afin de mettre en place une infrastructure permettant de relier les connaissances savantes entre les disciplines. L'équipe principale du LINCS est au cœur d'un réseau croissant de chercheurs, d'étudiants et de professionnels qui, grâce aux efforts combinés de ces personnes brillantes, sont en mesure d'explorer sérieusement la capacité des données liées à améliorer la recherche culturelle et les expériences culturelles. L'environnement de recherche virtuel du CCRF a impliqué plus de 200 personnes formidables (et ce n'est pas fini, car nos crédits doivent être mis à jour avant que nous ne lancions ce printemps une instance du cadre logiciel LEAF). Et ma foi en la magie de la production collaborative de connaissances par de nouveaux moyens numériques est née d'une expérience formatrice en tant que nouveau chercheur dans le projet Orlando, dont les participants remarquables comprennent ~150 étudiants.

Ce ne sont pas les chiffres qui comptent, mais le sentiment d'expansion des réseaux : il y a des chevauchements entre les projets et les rôles, de sorte que le décompte n'est pas exact, voire ne peut jamais l'être, parce qu'il y aura inévitablement des omissions involontaires et parce que les fils d'influence ne cessent de se relier les uns aux autres. Je suis très reconnaissante pour toutes les relations riches qui imprègnent ce travail, étonnée de ce que nous avons créé et appris ensemble, fière de ceux qui l'ont mis en œuvre dans d'autres contextes et d'autres domaines.

Et il y a tant d'autres relations, d'autres personnes à qui il faut rendre hommage. Des mentors qui renforcent ma confiance. Des modèles dont la pensée et les pratiques éclairent et inspirent les miennes. Des co-auteurs et des co-présentateurs qui m'aident à voir les choses différemment alors que nous nous efforçons de nous exprimer ensemble. Les étudiants et les collègues des cours et des ateliers dont les réactions et les questions suscitent une telle perspicacité. Des collègues qui continuent et restent dévoués malgré la précarité déplorable des conditions dans lesquelles ils travaillent. Les collaborateurs de projets dirigés par d'autres, dans lesquels j'ai tant appris, notamment Collective Biographies of Women, INKE, Lesbian and Gay Liberation in Canada, NovelTM, Staging Better Futures/Mise en scène de meilleurs avenirs, The People and the Text, Voyant, The People and the Text et le Women Writers Project. Les créateurs et les activistes dont le travail reflète, réimagine et remodèle le monde dans lequel nous vivons.

Tant d'autres projets qui ont travaillé avec le CWRC et LINCS, et l'incroyable éventail d'initiatives en matière d'humanités numériques dans le monde entier, qui travaillent collectivement pour trouver comment produire et partager le savoir différemment à l'ère des incunables. Les membres de l'administration universitaire - aux universités de Guelph, Alberta et à de nombreuses universités partenaires - ainsi que les organismes de financement - FCI, CANARIE, DRAC, Mellon, CRSH - qui comprennent que ce travail n'entre pas dans les vieux moules, qui s'efforcent d'éliminer les obstacles et qui élaborent de nouveaux modèles. Les collègues qui veillent à ce que les organisations scientifiques telles que CSDH, ACH, ADHO, ACCUTE, ACQL, MLA, BWWA, VSAWC et NAVSA fonctionnent de manière à ce que nous disposions d'espaces collégiaux dans lesquels nous pouvons nous connecter. Des collègues qui siègent dans des groupes et des conseils d'administration et qui m'aident à appréhender la situation dans son ensemble et à comprendre les autres points de vue. Les partenaires du GLAM et de l'écosystème de la connaissance, comme le CRKN, le CHIN et la Bibliothèque et Archives Canada, qui partagent la vision de ce qu'il est possible de faire si nous travaillons ensemble.

Tous ceux qui, dans ce réseau particulier, sont motivés par le sentiment que la complexité et la valeur des cultures et des histoires humaines - en particulier celles des femmes, des BIPOC, des colonisés, des 2SLGBTQI+, des pauvres et des autres personnes marginalisées - pourraient s'inscrire dans l'espace numérique de manière différente, plus vivante, plus nuancée, plus contextualisée, plus respectueuse et plus équitable.

Lors de la conception et de la réalisation d'une application web, il est primordial de veiller à ce qu'elle soit réactive. Une application réactive est belle et fonctionne bien sur toutes les tailles d'écran et tous les appareils. Les applications LINCS sont conçues pour être visualisées de différentes manières : des tablettes aux ordinateurs portables en passant par les écrans interactifs de la taille d'un tableau blanc. Il peut être difficile d'atteindre ce niveau de réactivité, mais avec l'aide d'outils, de techniques et de cadres CSS, la tâche devient beaucoup plus facile...

Il existe des systèmes de mise en page couramment utilisés, intégrés à CSS, appelés Flexbox et Grid. En outre, CSS dispose d'une fonctionnalité appelée media queries, qui permet au contenu de s'afficher différemment en fonction de la taille de la fenêtre de visualisation. Il existe également des cadres CSS tels que Bootstrap CSS, qui sont faciles à utiliser et qui conviennent parfaitement à la conception réactive.

Si vous utilisez le CSS vanille (standard) et souhaitez contrôler entièrement la conception, vous pouvez utiliser CSS Flexbox pour une présentation unidimensionnelle ou CSS Grid pour une présentation bidimensionnelle. Flexbox offre des propriétés personnalisables qui contrôlent la mise en page et l'alignement. Les éléments situés à l'intérieur d'un conteneur Flexbox sont appelés éléments Flex. Les éléments flexibles peuvent être disposés horizontalement ou verticalement en fonction de la propriété flex-direction définie (ligne, colonne, ligne inversée, etc.). En outre, les éléments flex peuvent être centrés verticalement ou horizontalement et peuvent grandir ou rétrécir en fonction de l'augmentation ou de la diminution de leur conteneur parent - des options qui vous permettent de créer une mise en page adaptée à vos besoins. La grille CSS possède également des propriétés qui peuvent être configurées. J'ai souvent recours à CSS Flexbox lors de la conception de l'Espace recherche de LINCS, car il me permet d'aligner horizontalement ou verticalement les nombreux composants que nous devons afficher, en gardant les éléments de la page distincts quelle que soit la taille de l'écran.

Rendre l'information accessible est l'un des principaux objectifs de LINCS et de ResearchSpace, et veiller à ce que les utilisateurs puissent voir clairement l'information affichée à l'écran en fait partie. Les requêtes de média sont une excellente technique CSS pour ce type de tâche. Les requêtes de média vous permettent de créer différentes mises en page en fonction de la taille de la fenêtre de visualisation (la zone visible par l'utilisateur d'une page web), ce qui en fait un outil très puissant. Par exemple, vous pouvez réorganiser les éléments d'un conteneur pour qu'ils s'adaptent à la taille de l'écran. S'il s'agit d'un écran de grande taille, vous pouvez placer les éléments sur une seule ligne. S'il s'agit d'un écran de taille moyenne, les éléments peuvent être disposés sur deux rangées. Le rendu du contenu en fonction de la taille de l'écran est essentiel dans une application web réactive, car il permet à l'utilisateur d'afficher la bonne quantité d'informations pour son écran.

Enfin, il existe des cadres CSS tels que Bootstrap CSS. Avec Bootstrap, vous pouvez rapidement et facilement créer des mises en page réactives qui s'affichent correctement sur toutes les tailles d'écran et tous les appareils, y compris les appareils mobiles. Bootstrap est couramment utilisé pour créer des grilles de présentation réactives. Un conteneur Bootstrap est divisé en douze colonnes, et il vous suffit de spécifier, par exemple, le nombre de colonnes qu'un élément doit occuper. Les fonctionnalités réactives sont déjà intégrées dans la mise en page, de sorte que tout le travail est fait pour vous lorsqu'il s'agit de rendre la mise en page réactive. ResearchSpace utilise Bootstrap CSS. L'un des cas où son application s'est avérée nécessaire s'est présenté lors de la refonte de la page d'agrégation des entités. Dans ce cas, j'ai eu besoin de construire une disposition en grille dans laquelle je me suis appuyé sur Bootstrap CSS. La conception qui en résulte, comme le montrent les captures d'écran suivantes, témoigne de sa réactivité sur différentes tailles d'écran, y compris l'iPad Pro (1024px x 1366px) et le moniteur Full HD standard (1920px x 1280px).

Espace recherche sur un iPad Pro (1024px x 1366px).

L'espace de recherche sur un moniteur full HD standard (1920px x 1280px).

Ces outils et techniques CSS m'ont aidé à redessiner l'apparence de ResearchSpace pour le rendre plus réactif. Ces outils et techniques CSS m'ont aidé à redessiner l'apparence de ResearchSpace pour le rendre plus réactif. Ils sont rapides et faciles à utiliser, et leur documentation en ligne est excellente, de sorte qu'il n'est pas difficile de trouver des informations sur leur utilisation. J'espère qu'en les appliquant à l'Espace Recherche, les utilisateurs trouveront plus facilement des informations en utilisant LINCS.

Lors de ma première réunion cet été en tant qu'assistant de recherche en science des données, nous avons tous suivi nos présentations personnelles en déclarant nos parfums de crème glacée préférés. Le mien était et est toujours la glace Häagen Dazs' Strawberry Cheesecake, et j'ai été agréablement surprise d'apprendre que quelqu'un d'autre dans l'équipe était du même avis. Cependant, la plus grande surprise a été d'apprendre que quelqu'un aimait passer sa glace au micro-ondes pour en modifier la texture. À ce moment-là, est-ce encore de la glace ? Est-ce une soupe ? Ou un milkshake ? Qu'est-ce qui est considéré comme de la crème glacée ? ...

Mettant de côté ces questions, j'ai plongé tête la première dans un monde différent, non laitier, celui des systèmes d'organisation des connaissances. Je nageais dans une mer d'acronymes (RDF, SKOS, OWL, CWRC, et TTL pour n'en citer que quelques-uns) et de structures organisationnelles. J'étais occupé à comprendre comment les humains pouvaient utiliser des systèmes d'organisation et des langages développés dans le seul but de représenter des connaissances pour amener les ordinateurs à voir le monde dans des catégories créées par l'homme.

Alerte au spoiler—c'est compliqué. Mais d'abord, une mini leçon d'étymologie.

Le terme Ontologie vient des mots grecs onto (être) et logia (étude), ce qui signifie en fait l'étude de l'être. Les ontologues s'interrogent sur la manière dont les choses sont regroupées en catégories, sur les catégories qui se situent au niveau le plus élevé et sur la manière dont ces catégories informent la classification de tout. En sciences de l'information et Digital Humanities (DH), une ontologie fait référence à un modèle des catégories les plus larges d'un ensemble de connaissances spécifique. Si les ontologies comportent des concepts génériques, elles n'incluent pas de spécificités - celles-ci sont laissées au vocabulaires. Les vocabulaires développent les concepts génériques des ontologies en leur donnant des contextes et des significations.

Par exemple, une ontologie de desserts peut inclure une classe de desserts laitiers avec une sous-classe pour les crèmes glacées. Cependant, les arômes de crème glacée peuvent être omis de l'ontologie en raison de leur spécificité ; au lieu de cela, ils peuvent apparaître dans un vocabulaire sur les desserts. Le mot clé de cet exemple est "peut". Le créateur de l'ontologie peut décider que la glace au cheesecake et à la fraise est suffisamment importante pour être ajoutée à l'ontologie et que d'autres parfums devraient donc y figurer également.

Le mot peut n'a cessé d'apparaître, non seulement lorsque je pensais à la crème glacée, mais aussi lorsque je naviguais dans les ontologies et les vocabulaires du LINCS. L'un de mes principaux rôles cet été a été de mettre en œuvre les changements apportés aux ontologies dans les vocabulaires également. J'ai notamment corrigé les relations redondantes dans le Vocabulaire du genre, comme la théorie féministe déclarée comme faisant partie du genre philosophique et savant, alors que le genre philosophique est en fait un sous-ensemble du genre savant. En conséquence, j'ai acquis une bonne connaissance des tenants et aboutissants des vocabulaires CWRC, Genre et Illness & Injuries.

Un petit aparté avant de parler du très redouté peut. Les ontologies et les vocabulaires avec lesquels j'ai travaillé n'ont pas été dessinés sur un tableau blanc où je pouvais effacer des concepts et ajouter des connexions entre les classes à ma guise. Au lieu de cela, ils vivaient sur le web où ils étaient codés à l'aide de langages et de structures sémantiques tels que OWL, RDFS et SKOS. Les ordinateurs se nourrissent de binaires où une décision active ou désactive un interrupteur ; l'ambiguïté bloque le système car les machines ne peuvent pas déduire des significations implicites comme le ferait un cerveau humain. Les modèles sémantiques tels que les ontologies et les vocabulaires tentent donc de reproduire les méthodes de saisie et de catégorisation qui semblent être une seconde nature pour les ordinateurs.

Pour résumer, les ordinateurs fonctionnent de manière binaire, ce qui n'est pas le cas pour nous. L'intégralité des données du web est stockée sous forme de uns et de zéros, mais notre cerveau perçoit le monde de manière beaucoup plus complexe et nuancée.

Si les ontologies et les vocabulaires peuvent sembler similaires (ils aident tous deux à catégoriser les choses), les ontologies sont strictes dans la manière dont les concepts peuvent être regroupés puisqu'elles utilisent la logique formelle. En comparaison, un vocabulaire ne prétend pas que la crème glacée est un dessert ; il aide seulement à décrire des concepts, tels que les nombreux parfums de crème glacée décadente. En l'écrivant de cette manière, il semble intuitif que la logique ne s'applique pas aux vocabulaires, ou comme l'écrit W3.org:

[Certains systèmes d'organisation des connaissances] ne sont pas, de par leur conception, destinés à représenter une vue logique de leur domaine. La conversion de ces systèmes d'organisation des connaissances en une représentation formelle basée sur la logique peut, dans la pratique, impliquer des changements qui aboutissent à une représentation qui ne répond plus à l'objectif initialement prévu.

Il est vrai que le recul est de 20/20, car même si cela semble évident aujourd'hui, j'ai passé d'innombrables heures à m'agiter sur des hiérarchies conceptuelles dans les vocabulaires qui n'avaient tout simplement pas de sens logique. Le genre fictionnel peut relever du genre littéraire, mais il peut aussi relever du genre narratif. Si l'on me posait cette question à l'improviste, je demanderais pourquoi pas les deux, mais j'étais tellement habitué à la pensée binaire des ordinateurs que j'ai été pris au dépourvu lorsque j'ai vu que le genre fictionnel était une ramification du genre littéraire et du genre narratif.

Visualisation du vocabulaire du genre basée sur l'ontologie du genre produite à l'aide de WebVOWL.

Il était facile de tomber dans le schéma de pensée selon lequel un concept était soit A, soit B, en particulier lorsque les catégories étaient déjà devant moi. Il était plus difficile de reconnaître que les choses dans la vie réelle sont beaucoup plus compliquées et nuancées qu'un système codé ne peut catégoriser proprement.

J'ai passé une si grande partie de l'été à essayer de comprendre comment le monde pouvait entrer dans des petites boîtes bien rangées que j'ai oublié l'aspect humain de la catégorisation - le désordre et les peut-être qui accompagnent souvent la prise de décision. Alors que le monde raffiné des ontologies et des vocabulaires peut sembler très éloigné de la vie quotidienne, il m'a fallu une bonne partie de l'été pour me rappeler qu'ils sont basés sur des catégories créées par l'homme - des catégories dont les limites peuvent changer au fil du temps et varier selon l'utilisateur.

Tout cela pour dire qu'à la fin de l'été, j'avais une réponse aux questions brûlantes que je me posais depuis le début du mois de mai : tout est subjectif ! Il s'agit peut-être d'une non-réponse dans le sens binaire du oui ou du non, mais tant qu'il existe une sorte de consensus (que ce soit entre deux personnes ou des millions), le destin de la crème glacée fondue, comme les vocabulaires, peut exister dans l'écart entre les absolus.

J'ai toujours trouvé que le contexte changeait tout lorsqu'on apprenait quelque chose de nouveau, en particulier lorsqu'il s'agissait de comprendre pourquoi cette chose était importante. Le premier exemple qui me vient à l'esprit est celui des cours de chimie générale que j'ai suivis et dont les concepts n'ont jamais vraiment fait mouche, pas plus que je n'ai compris pourquoi je devais les apprendre. Quatre de ces cours plus tard, je n'étais pas très enthousiaste à l'idée de suivre un cours de biochimie, mais lorsque je l'ai fait, je n'arrivais pas à croire à quel point cela faisait une différence d'avoir un contexte réel : le corps humain, où les réactions chimiques se produisent pour une raison. Tout d'un coup, l'abstrait est devenu très important - je pouvais voir comment tout cela s'emboîtait, et en retour, ma compréhension de la chimie générale a probablement été multipliée par trois. Rassurez-vous, cet article de blog ne va pas parler de chimie. Il s'agit plutôt de montrer comment le même phénomène s'est produit cet été, lorsque le travail sur le projet Orlando a changé ma façon de penser les données...

Avant d'être assistante de recherche à Orlando, je n'avais connu et compris les données que sous la forme de valeurs numériques. Les données telles que je les connaissais n'étaient qu'un moyen de générer des statistiques ou de tirer une conclusion à la fin d'un article, bien qu'en dehors du contexte d'une étude ou d'une expérience particulière, les données elles-mêmes n'étaient pas très pertinentes. Ainsi, lorsque l'idée de Linked Open Data (LOD) m'a été présentée pour la première fois, je n'arrivais pas exactement à conceptualiser ce que c'était ni pourquoi cela avait un tel impact. Ce n'est qu'après quelques semaines d'utilisation de la base de données d'Orlando que j'ai commencé à apprécier le travail de LOD : chaque fois que j'effectuais une recherche sur une personne ou un lieu, j'en apprenais incidemment sur beaucoup d'autres auteurs qui avaient été leurs proches confidents, comme Iris Murdoch pour Brigid Brophy ; des auteurs qui croyaient en des causes communes, comme Felicia Skene, Christina Rossetti, et Sarah Grand en faveur du mouvement anti-vivisection ; et des auteurs qui avaient une inspiration commune, comme P. D. James, Stella Benson, et Margaret Kennedy pour l'admiration mutuelle de Jane Austen - tout cela parce qu'Orlando avait rassemblé ces listes pour moi. Maintenant, au lieu de considérer les données comme quelque chose d'isolé, je les vois comme un moyen de donner un sens à l'histoire, où les connexions sont une forme de données en soi.

Chacune des tâches sur lesquelles j'ai travaillé pour Orlando cet été, de la construction d'entrées pour les auteurs et les événements historiques à reconciling entities, a impliqué de regarder le passé dans son contexte, plutôt que d'en avoir seulement des aperçus épars. Par exemple, lors du rapprochement - c'est-à-dire de l'établissement d'une correspondance entre une personne de la base de données et son identifiant Web correct -, l'outil le plus utile est constitué par les données qu'Orlando tire d'autres profils et pages à son sujet, ce qui évite de devoir se lancer dans une chasse aux détails. Un peu plus tard au cours de l'été, lorsque j'ai commencé à faire des recherches, à rédiger et à étiqueter un profil d'auteur pour le poète et activiste contemporain Seni Seneviratne, j'ai réalisé que je faisais plus que créer une ressource pour en savoir plus sur sa vie et son œuvre. J'ajoutais plutôt des données à un écosystème, un écosystème qui permettrait à un chercheur essayant d'en savoir plus sur les femmes poètes contemporaines de couleur, ou essayant peut-être de rassembler une liste de poèmes qui traitent du conflit israélo-palestinien, d'atteindre ses objectifs de recherche en quelques recherches.

Grâce aux recherches que j'ai effectuées cet été, j'ai pu constater que le LOD rend l'information plus visible et plus accessible, ce qui m'a permis de faire des découvertes que je n'aurais jamais faites autrement : J'ai appris le nom de suffragettes du passé, comme Emily Davison et les sœurs Pankhurst ; de femmes qui étaient à la fois suffragettes et auteurs, comme Ethel Arnold ; et combien d'auteurs peuvent être liés à Virginia Woolf, soit en tant que contemporains, soit parce qu'elle a inspiré leur travail des décennies plus tard. Maintenant que mon premier semestre à Orlando touche à sa fin, je peux dire que mon été de travail avec le LOD m'a aidé à mieux comprendre le monde, en remplaçant les fragments de connaissances historiques que j'avais par une image plus large et plus complète. À l'instar de mes expériences en biochimie, le LOD m'a montré comment rendre l'information plus percutante : non pas en la retirant de son contexte général, mais en se concentrant sur son potentiel de connexion.

LINCS utilise ResearchSpace comme plateforme pour explorer les relations dans les ensembles de données culturelles interconnectées. Avec ResearchSpace, les chercheurs peuvent parcourir, rechercher et visualiser des données dans le dépôt de données du LINCS. Durant l'été 2022, j'ai fait partie d'une équipe qui développait de nouvelles fonctionnalités pour la version de ResearchSpace du LINCS.

Notre équipe était une collaboration entre des contributeurs ayant une expérience de l'expérience utilisateur (UX) et des contributeurs ayant une expérience du développement de logiciels. Nous avons travaillé en tandem : le groupe UX a recommandé des fonctionnalités pour améliorer l'expérience d'utilisation de l'application web. Ces recommandations ont été transformées en tickets dans GitLab. Les tickets décrivaient le produit final souhaité et il incombait aux développeurs de déterminer comment atteindre cet objectif. Le responsable du développement a réparti les tickets entre les développeurs de logiciels, en les divisant en fonction de ce qui serait nécessaire pour construire les fonctionnalités suggérées...

La plupart des tickets qui m'ont été attribués concernaient des composants nécessitant React.js. Lorsque j'ai commencé à travailler pour LINCS, je n'avais pas beaucoup d'expérience avec React. Même si je connaissais déjà les crochets React, j'avais besoin d'apprendre le React basé sur les classes qui était utilisé dans ResearchSpace. Souvent, je devais en savoir plus que ce que mon billet me demandait de faire. Je devais comprendre l'importante base de code du projet et son fonctionnement tout en élargissant mes compétences. C'est ainsi que j'ai développé une expertise en TypeScript et React et que j'ai appris le fonctionnement de Docker et des conteneurs Docker. Ces choses ont pu être déroutantes au début, mais elles me sont désormais familières. Par exemple, j'ai maintenant une bonne compréhension du fonctionnement des fichiers Docker Compose et j'ai beaucoup d'expérience dans l'utilisation des modèles Handlebar pour les corrections de bogues.

J'ai appris bien plus que des compétences techniques. J'ai beaucoup de gratitude envers les membres de mon équipe. Zach Schoenberger, qui a supervisé mon travail, m'a aidé à développer la compétence cruciale d'expliquer des concepts techniques à des personnes non techniques. Dawson MacPhee, un étudiant développeur senior, m'a appris à aborder mon travail. Il m'a appris à apporter des améliorations progressivement, à effectuer plusieurs tests et à diviser mes objectifs en éléments gérables. Dawson m'a appris à me référer à la documentation chaque fois que nécessaire et m'a encouragé à poser des questions au fur et à mesure.

Apporter des modifications sans bouleverser ce qui avait été établi précédemment était un défi, mais grâce aux compétences acquises auprès de Zach et de Dawson, j'ai été en mesure d'apporter des changements graduels avec succès. ResearchSpace comporte de nombreux composants React interconnectés. Au début, j'ai eu du mal à faire des changements sans casser d'autres choses, mais au fil du temps, j'ai développé mes compétences techniques et non techniques, ce qui m'a permis de transformer les demandes UX en composants fonctionnels.

Si vous avez déjà écouté une conversation technique entre informaticiens, vous les avez peut-être entendus parler de ce qu'on appelle une Application Programming Interface (API). Qu'est-ce qu'une API ? Décortiquons-le...

Une application est un logiciel qui exécute une fonction distincte. Microsoft Excel et Google Sheets sont de bons exemples d'applications courantes que beaucoup de gens utilisent, même ceux qui ne sont pas informaticiens.

Or, chaque application est soumise à des règles spécifiques quant à la manière d'interagir avec elle. Par exemple, la plupart des utilisateurs de Microsoft Excel savent qu'ils peuvent mettre en gras le texte d'une cellule en cliquant sur le bouton B de la barre d'outils du ruban qui apparaît en haut de l'interface d'Excel. Une interface est un contrat qui définit les règles d'interaction entre les logiciels.

Ces deux termes - programme d'application + interface - se rejoignent pour former l'Application Programming Interface ou API. Une API est un moyen pour deux ou plusieurs applications de communiquer entre elles à l'aide de demandes et de réponses. En tant qu'analystes de recherche juniors travaillant pour LINCS, nous avons eu de nombreuses occasions de travailler avec des API en essayant de réunir les applications qui composent LINCS.

L'une des API sur lesquelles nous avons travaillé est le flux de travail Diffbot NLP Vetting. L'objectif de ce workflow est d'évaluer les performances de Diffbot Natural Language Processing (NLP) API sur les ensembles de données du LINCS. L'API Diffbot NLP utilise des algorithmes d'apprentissage automatique et de vision par ordinateur pour rechercher du sens dans le texte. En particulier, il identifie des entités (par exemple, des personnes, des organisations, des produits) et des données les concernant (par exemple, les relations entre elles).

Par exemple, à partir du texte "Le 11 novembre 1741, Abigail Smith (plus tard Abigail Adams) est née à Boston, Massachusetts", Diffbot a créé le graphe de connaissances suivant :

En utilisant les données du web, Diffbot a pu identifier les entités (cercles) du texte ainsi que les relations (flèches) entre eux, qu'il appelle facts. L'algorithme d'IA de Diffbot identifie toujours correctement les entités et les faits dans de nombreuses applications pour lesquelles il est utilisé en dehors du LINCS ; cependant, une identification sans erreur n'est pas toujours possible étant donné la complexité des données avec lesquelles le LINCS travaille. Pour y remédier, nous avons voulu créer un outil qui analyserait l'exactitude de ce que Diffbot nous dit : le Diffbot NLP Vetting Workflow.

Le Diffbot NLP Vetting Workflow est essentiellement constitué de quelques étapes contenues dans un carnet Jupyter ; son utilisation ne nécessite pas d'expérience approfondie en programmation ni de connaissances approfondies sur le fonctionnement de Diffbot. Dans les coulisses, cependant, les quelques lignes du workflow renvoient à un code Python complexe qui gère la communication API et adhère aux nombreux standards de Diffbot.

À partir d'un texte brut, le flux de travail envoie une requête à Diffbot pour qu'il identifie toutes les entités et tous les faits contenus dans le texte. La réponse qui en découle ressemble à ceci :

{
  "entities": [
    {
      "name": "Boston",
      "diffbotUri": "https://diffbot.com/entity/E7vnJ0j-OP4qXP4s9wNDbEQ", 
      "confidence": 0.9994205,
      "salience": 0.4442726,
      "isCustom": false,
      "allUris": [
        "http://www.wikidata.org/entity/Q100"
      ],
      "allTypes": [
        {
          "name": "location",
          "diffbotUri": "https://diffbot.com/entity/BiCyWUm41NziqgLHx47iAIQ", 
          "dbpediaUri": "http://dbpedia.org/ontology/Place"
        },
        {
          "name": "administrative area",
          "diffbotUri": "https://diffbot.com/entity/EcTIultWKPoula6qZtSpc4A", 
          "dbpediaUri": "http://dbpedia.org/ontology/PopulatedPlace"
        },
        {
          "name": "city",
          "diffbotUri": "https://diffbot.com/entity/EzdJrGHiyMWu0XbSn101rFA", 
          "dbpediaUri": "http://dbpedia.org/  ontology/City"
        }
  ],
  "mentions": [
    {
      "text": "Boston",
      "beginoffset": 163,
      "endOffset": 169,
      "confidence": 0.9994205
    }
  ],
  "location": {
    "latitude": 42.36028,
    "longitude": -71.05778, 
    "precision": 15.231546
  }
},

Ce résultat, qui prend la forme d'une réponse JSON, n'est pas facile à évaluer. Pour faciliter l'examen des données, notre programme fait appel à l'API Google Sheets pour générer une feuille de calcul :

Google Sheets, à son tour, applique un formatage par défaut : masquer, redimensionner et figer les colonnes, ainsi qu'appliquer du gras et des couleurs au texte. Chaque fonction est associée à une requête API différente ; de nombreux essais et erreurs ont été nécessaires pour créer quelque chose qui serait facile à examiner par un humain.

La feuille de calcul qui en résulte montre l'entité, la confiance de Diffbot dans sa propre prédiction (un chiffre entre 0 et 1, 0 étant le moins sûr et 1 le plus sûr), et un lien vers une entité correspondante dans Wikidata, et plus encore. Une personne qui examine les données peut utiliser toutes ces informations pour confirmer ou corriger l'exactitude du travail de Diffbot. Pour rendre cette vérification aussi simple que possible, la dernière colonne de la feuille indique où Diffbot a trouvé l'entité dans le texte original, de sorte que l'examinateur puisse facilement se référer à l'original si d'autres vérifications sont nécessaires. À l'aide des informations contenues dans la feuille de calcul, le réviseur peut alors approuver ou rejeter les résultats de Diffbot (en inscrivant oui ou non dans la feuille de calcul ; colonnes L, M et N dans l'image ci-dessus).

Les informations nouvellement vérifiées (ainsi que les scores de précision globaux pour les données examinées) poursuivent ensuite leur chemin, à travers une nouvelle série d'étapes qui impliquent à la fois des applications et des personnes - un processus en plusieurs étapes qu'il est préférable de réserver pour de futurs articles de blog. Au final, ce qui a commencé comme une phrase dans un document peut être découvert sous forme d'entités et de relations dans le triplestore du LINCS. Et, grâce au Diffbot NLP Vetting Workflow, ceux qui utilisent les données du LINCS peuvent être sûrs que le contenu qu'ils explorent est exact !

L'équipe UX a mené des recherches auprès des utilisateurs sur les outils LINCS afin de les préparer à passer du développement à la production. Jusqu'à présent, nous avons effectué des tris de cartes, des tests de convivialité, des enquêtes et des entretiens. Ces recherches nous ont fourni une mine d'informations. Cependant, si nous voulons traduire ce que nous avons appris en changements significatifs et productifs dans la conception des outils, nous devons garder l'actionnabilité au centre de notre pratique de recherche...

Pendant mes études d'UX, j'ai suivi un cours sur les techniques de recherche utilisateur. Je pensais que les méthodes de recherche UX étaient assez simples : parlez à vos utilisateurs, synthétisez les données que vous avez recueillies au cours de ces conversations dans des personas et des cartes de parcours, et voilà - vous avez terminé votre recherche utilisateur. Malheureusement, je me trompais. Dans le cadre de l'un des travaux pratiques du cours, mes camarades de classe et moi-même avons été invités à observer des participants pendant qu'ils effectuaient une tâche d'achat. Lorsque nous avons constaté qu'ils éprouvaient des difficultés, notre professeur a simplement demandé : "D'accord, mais comment ?". Lors de nos premières tentatives de recherche sur les utilisateurs, nous nous sommes contentés de chercher le problème ; nous n'avions pas encore compris que nous devions comprendre exactement comment et pourquoi les participants avaient du mal à accomplir leur tâche. Si nous n'approfondissions pas nos recherches pour comprendre les objectifs et les comportements de nos utilisateurs, nos résultats n'étaient pas exploitables, ce qui signifiait que nous ne pouvions pas tirer de solutions de nos recherches.

Cette leçon m'a appris la différence entre la recherche et une bonne recherche. Les nouveaux concepteurs effectuent souvent des recherches pour les cocher sur une liste de contrôle, afin de montrer que les utilisateurs ont été consultés. Les concepteurs expérimentés mènent des recherches pour comprendre l'utilisateur, et ils transforment cette compréhension en action. Lorsque les besoins des utilisateurs ne sont pas clairs, la recherche ne sert pas la conception, ce qui aboutit à des solutions qui ne sont pas réellement centrées sur l'utilisateur.

Au cours de mon séjour à LINCS, j'ai constaté qu'il était essentiel de réfléchir en profondeur à l'actionnabilité en travaillant sur l'un de ses outils - ResearchSpace - au fur et à mesure qu'il évoluait dans le processus de conception. Les tests d'utilisabilité à l'échelle du site pour ResearchSpace, menés par Robin Bergart (bibliothécaire UX) et Evan Rees (concepteur UX), venaient juste de commencer lorsque j'ai pris mes fonctions. J'ai eu le privilège de faciliter quelques-uns des tests utilisés pour déterminer comment les utilisateurs comprenaient les fonctionnalités de LINCS ResearchSpace. Tout au long des tests et de l'analyse des résultats, j'ai réfléchi à l'actionnabilité à la fois à un niveau bas et à un niveau élevé.

Au niveau le plus bas, j'ai essayé de faire de chaque observation une donnée exploitable. Pendant les tests, j'ai noté des observations détaillées afin de relier les actions des participants à leurs processus de pensée tels qu'ils les décrivaient. Lorsque j'observais les participants accomplir une tâche, je notais leurs actions spécifiques, qu'il s'agisse d'éléments sur lesquels ils cliquaient ou de fonctionnalités qu'ils notaient comme étant les plus remarquables pour eux. Par exemple, nous avons demandé aux participants de rechercher un entité dans l'Espace Recherche. De nombreux participants ont réussi à trouver des entités en accédant au contenu d'un ensemble de données ; ce faisant, ils ont négligé la boîte de recherche dans la barre de navigation, qu'ils auraient également pu utiliser. En observant ce que les utilisateurs faisaient et ne faisaient pas, et en décrivant leurs actions au fur et à mesure qu'ils les accomplissaient, nous avons découvert des données riches qui nous ont permis de synthétiser nos résultats en modèles et thèmes significatifs.

Une fois que nous avons obtenu ces résultats, nous avons dû trouver un moyen d'étendre l'actionnabilité à d'autres personnes en dehors de l'équipe UX. Par exemple, nous devions partager nos résultats avec les développeurs avec lesquels nous collaborions pour apporter des améliorations significatives et réalisables aux outils. En pratique, cela signifiait que nous devions trouver un moyen de convertir notre tableau blanc UX virtuel désordonné, parsemé d'idées sur des notes autocollantes numériques, dans un format que l'équipe LINCS au sens large serait en mesure de lire et de comprendre. Pour ce faire, nous avons rédigé un rapport qui définissait chaque conclusion en mettant en évidence les points de douleur et nos observations clés correspondantes. Ce processus nous a aidés à faire passer nos idées, mais avec le recul, je pense que nous aurions pu être encore plus efficaces si, au lieu de nous contenter de présenter nos résultats à la fin du processus de synthèse, nous avions invité un plus large éventail de parties prenantes à participer au processus de tableau blanc. Cette stratégie aurait permis à l'équipe de mieux comprendre les résultats et aurait invité un plus grand nombre de personnes à réfléchir à des solutions.

Même si le chemin a été semé d'embûches, nos conclusions ont permis de trouver des pistes de solution. Par exemple, j'ai conçu une amélioration de la navigation en permettant aux utilisateurs d'accéder aux fonctions de l'Espace recherche directement à partir de l'écran d'accueil. Les besoins des utilisateurs ont influencé la présentation de mon projet, car l'étude des utilisateurs m'a montré que nous avions besoin d'une conception qui permette aux utilisateurs de trouver et d'utiliser rapidement la myriade de ressources de l'Espace de recherche.

Ainsi, en gardant à l'esprit l'actionnabilité, notre recherche sur les utilisateurs a directement alimenté nos solutions de conception et a contribué à résoudre les problèmes réels des utilisateurs. J'ai trouvé passionnant de mettre en pratique les méthodes de recherche sur l'utilisateur que je n'avais apprises qu'en théorie. J'ai hâte de voir ce que nous réserve la poursuite de nos recherches et de nos conceptions !

Lorsque j'ai commencé mon premier stage coopératif, je n'avais aucune idée de la manière dont le développement de logiciels fonctionnait dans un environnement professionnel. Auparavant, je n'avais fait l'expérience que de la salle de classe, où mes camarades et moi-même développions des logiciels pour des travaux. Lorsque j'ai intégré un contexte professionnel, j'ai découvert de nouvelles méthodes de collaboration, notamment les réunions debout (stand-up meetings) ou les réunions debout (stand-ups)...

Qu'est-ce qu'une réunion debout ? Les réunions stand-up sont des réunions quotidiennes de courte durée au cours desquelles une équipe se réunit pour discuter des différentes tâches d'un projet. De nos jours, les réunions debout sont au cœur de nombreux projets de développement de logiciels, mais elles ont été popularisées à l'origine par le développement agile, qui est une méthodologie bien connue dans l'industrie. Les projets de développement de logiciels peuvent être compliqués, c'est pourquoi le développement agile décompose les problèmes complexes en éléments gérables et réalisables.

Se réunir tous les jours est un excellent moyen de construire un projet de grande envergure. Elle encourage l'équipe à se fixer des objectifs qui peuvent être atteints en un jour, puis à assurer un suivi le lendemain afin d'identifier les problèmes, d'y remédier et de dissiper rapidement les confusions. Les réunions debout favorisent également la communication. Elles aident l'équipe à se sentir à l'aise les uns avec les autres grâce à une communication fréquente. Les réunions debout font en sorte que tout le monde se sente inclus.

Les réunions debout permettent à tous les membres de l'équipe de rester productifs en leur rappelant quotidiennement les objectifs sur lesquels ils doivent travailler et la manière dont ces objectifs s'intègrent dans le projet dans son ensemble. Bien que le développement de logiciels soit souvent un effort individuel, obtenir un retour d'information de la part d'un superviseur ou d'un pair lorsque des problèmes surviennent est un moyen efficace non seulement de réduire les obstacles, mais aussi d'élargir les connaissances de l'équipe. Les réunions debout sont un excellent moyen de parvenir à la transparence, car elles encouragent les gens à partager leurs problèmes et leurs solutions.

Lorsque j'ai commencé à travailler chez LINCS, je ne comprenais pas la valeur des stand-ups. Mais j'ai constaté que plus je participais à des réunions stand-up, plus je pouvais facilement chercher de l'aide et plus je me sentais à l'aise pour poser des questions. À mon tour, j'ai découvert que j'étais capable d'adapter rapidement ma façon de penser et de résoudre les problèmes que je rencontrais. Les stand-ups m'ont aidé à me concentrer sur les tâches à accomplir et m'ont fourni la structure dont j'avais besoin pour travailler de manière efficace et efficiente.

Étant donné que les stand-ups sont fréquents, ils sont également censés être très courts. Grâce au temps limité que nous consacrons aux réunions, j'ai appris à poser mes questions de manière concise et à aller droit au but. Il m'est apparu clairement que je trouvais plus efficace d'organiser des réunions plus petites et plus courtes, car elles me permettent d'aborder les petites questions avant qu'elles ne deviennent de gros problèmes. J'ai toujours été timide, et les réunions debout m'ont souvent aidé à me sentir plus à l'aise pour parler à mes collègues.

Je pensais que mon stage coopératif me permettrait d'en apprendre davantage sur le développement de logiciels. Je ne m'attendais pas à en apprendre autant sur la collaboration, le travail d'équipe et sur moi-même. Les réunions debout m'ont fourni un excellent outil que j'utiliserai tout au long de ma carrière.

En tant qu'étudiante en anglais, on m'a toujours dit de rester concise dans mes écrits. C'était souvent facile, car je pouvais supposer que la personne qui lirait mon travail serait un spécialiste de l'anglais, et que ses attentes à l'égard de mes écrits et des connaissances qu'elle y apporterait se situeraient donc dans une fourchette très précise. De cette manière, je me suis entraînée à adopter par défaut un ton et un niveau de complexité académiques et à produire des écrits comparatifs et analytiques.

Cet été, cependant, en tant que membre de l'équipe de documentation LINCS, j'ai travaillé sur un type d'écriture totalement différent : des guides d'utilisation et des manuels d'instruction pour les nombreux outils logiciels développés ou utilisés par le projet. Pour commencer à rédiger de la documentation, j'ai d'abord dû réapprendre à écrire...

La rédaction d'instructions commence par la simplicité. Je pensais que puisque j'étais un écrivain concis, je serais capable d'écrire simplement et clairement, mais lorsque la première version des instructions étape par étape pour maintenir le site web de documentation LINCS a été éditée, j'ai vu que mon nombre de mots avait été réduit de près de la moitié. En parcourant les pages de mon texte, j'ai constaté que l'intention avait été entièrement inversée - il ne s'agissait pas simplement d'intervertir des synonymes, mais d'un remaniement complet de la voix et du point de vue.

Pour expliquer le processus de création d'une demande de fusion, par exemple, j'ai d'abord écrit ce paragraphe verbeux et personnel :

Pour travailler sur un problème, vous devez créer une demande de fusion. Cela créera une nouvelle "branche" sur notre dépôt GitLab, qui vous permettra d'effectuer et de suivre les modifications sans affecter la branche principale du dépôt (et, par conséquent, le site web lui-même). Plus tard, lorsque vous serez satisfait de vos modifications, elles pourront être ajoutées à la branche principale afin d'être publiées sur le site web de documentation.

En travaillant avec l'équipe de documentation pour réviser ma première tentative, nous avons commencé par remanier mon projet pour lui donner un ton plus actif. Nous avons supprimé les déclarations excessives telles que "faire et suivre" et "à son tour, le site web lui-même", ce qui a permis de raccourcir l'ensemble de la section sans compromettre la qualité de l'information :

Créer une demande de fusion pour travailler sur un problème. Cette demande créera une nouvelle branche dans GitLab, ce qui vous permettra d'apporter des modifications sans affecter le dépôt principal. Lorsque vos modifications sont complètes et vérifiées, elles peuvent être ajoutées à la branche principale pour être publiées sur le site web de la documentation.

Nous avons élaboré un guide de style pour nous aider à orienter nos choix, et bien qu'il m'ait permis de rester dans les clous la plupart du temps, j'ai toujours eu du mal à réprimer l'étudiant anglais auteur d'essais qui avait élu domicile au plus profond de mon cerveau. D'une certaine manière, je trouvais la rédaction d'instructions bien plus difficile que celle d'une dissertation. Je ne pouvais plus dissimuler un manque de vision claire ou des lacunes de compréhension derrière des mots qui sonnaient bien. S'il n'y avait pas de sens clair, mon écriture tombait à l'eau.

Lorsque j'ai commencé à diviser les instructions en sections et les sections en étapes individuelles, j'ai vu qu'il était plus facile d'écrire simplement. Pourtant, mon instinct n'était pas encore tout à fait au point. Je cherchais encore des moyens de rendre l'écriture plus fluide entre les sections. J'imaginais un public qui me suivait d'étape en étape, parcourant les tâches dans le même ordre que moi : en commençant au même endroit et en terminant par le même objectif. Notre guide de style m'a toutefois rappelé qu'il fallait envisager l'écriture du point de vue du public. Comme moi, mon lecteur pouvait être un débutant qui ne connaissait pas l'utilisation d'une plateforme comme GitLab et qui avait besoin de connaître chaque étape de son parcours. Mais il peut également s'agir d'un utilisateur chevronné qui n'a oublié qu'une seule étape et qui a sauté directement à un sous-titre spécifique. Chaque petite section devait donc fonctionner comme un élément de documentation indépendant. Je ne pouvais pas supposer que mon lecteur avait lu toutes les sections précédentes. En adhérant à ce principe, j'ai dû parfois enfreindre l'une de mes règles d'or personnelles en matière d'écriture : éviter les répétitions ! Ce processus - bien qu'il ait donné lieu à des écrits qui répétaient des informations figurant dans les sections précédentes - a contribué à rendre ces outils utilisables par le plus grand nombre possible de personnes.

Cette répétition a également mis en évidence la diversité des lecteurs pour lesquels nous devions écrire. Dès les premiers jours de la planification de notre stratégie de documentation, nous avons cherché à identifier le public imaginaire pour lequel nous adaptions la complexité et la technicité de chaque document. En tant que domaine, Digital Humanities (DH) accueille la participation de personnes ayant un large éventail d'antécédents universitaires et de niveaux d'expertise technique. Nous avons compris qu'il nous faudrait répondre aux besoins de tous, des étudiants en arts de premier cycle aux développeurs de logiciels expérimentés, ce qui signifie que nous supposions un niveau de compétence technique de base, mais pas plus.

En ce qui concerne mon processus d'écriture, essayer de répondre aux besoins d'un éventail aussi diversifié d'utilisateurs signifiait adopter une autre approche circulaire. J'ai découvert les outils que je documentais en tant que débutant et, en me familiarisant avec eux pour apprendre ce qui devait être documenté, je suis devenu un expert. Ensuite, j'ai dû revenir au rôle de débutant (au début du cercle), en écrivant pour quelqu'un qui ne connaissait pas l'outil. J'ai dû apprendre à utiliser des outils que je ne connaissais pas du tout jusqu'à être capable d'en écrire les instructions, puis reprendre immédiatement la position de mon ancien moi, qui ne connaissait pas du tout les outils.

Grâce à mon expérience de la rédaction de documentation, je ne suis plus seulement attaché à la concision et à la simplicité, mais j'ai une approche entièrement différente de l'écriture. Rédiger de la documentation m'a poussé à prendre en compte le point de vue du public et à ne pas avoir peur d'enfreindre certaines de mes propres règles d'écriture. Le fait d'écrire en cercle m'a appris à rédiger des textes plus accessibles pour mes lecteurs.

Pendant mon séjour chez LINCS, l'équipe UX a jeté les bases de la mise en œuvre d'un flux utilisateur intuitif et sans effort pour ResearchSpace. Pour ce faire, nous avons mené de nombreux tests d'utilisation et d'utilisabilité, des entretiens et des tris de cartes.

Travailler sur ResearchSpace a été ma première véritable expérience dans le monde de l'UI/UX. C'était aussi la première fois que je travaillais dans une équipe de conception, et j'ai été époustouflé par le talent de mes pairs... J'ai apprécié le défi d'apprendre de nouveaux concepts UX et d'en apprendre davantage sur la conception et processus de test utilisateur. Evan Rees, pour sa part, avait une habileté incroyable lorsqu'il s'agissait de répondre et de poser des questions pendant un test utilisateur sans pousser aucune sorte de biais ou de leader. Par exemple, au lieu de demander à un utilisateur : "Est-ce que cela vous frustre ?" quand ils étaient clairement frustrés, Evan leur demandait: "Comment cela vous fait-il sentir?" Au lieu. La question soigneusement formulée d'Evan a permis à l'utilisateur de répondre honnêtement sans être poussé dans une certaine direction. Jordan Lum et Nem Brunell m'ont tous deux beaucoup appris sur l'utilisation Figma pour organiser mon travail et créer des composants.

Mon expérience précédente en design m'avait seulement appris à créer quelque chose qui serait visuellement agréable. Travailler en tant que designer UX a radicalement changé ma perspective. J'ai appris à me mettre à la place de l'utilisateur, à essayer de comprendre ce qu'il attendrait d'un design. L'ajout de nouveaux éléments de convivialité et de praticité a considérablement amélioré mes compétences en matière de conception. Par exemple, lorsque je crée des designs maintenant, je détermine l'ambiance que je veux que le spectateur ressente, puis je choisis les couleurs, la typographie, etc. en conséquence. Même si je reviens au travail de conception traditionnel après ce stage, je continuerai à réfléchir à la façon dont la typographie, les choix de couleurs et le placement du texte seront perçus par le spectateur.

L'un des défis auxquels j'ai été confronté lorsque je travaillais au sein d'une équipe de développement UX et plus large a été d'apprendre à accepter que mes idées ne soient pas toujours suffisamment pratiques pour être mises en œuvre. Il y a eu des cas où j'ai pensé que j'avais trouvé un design qui résoudrait les problèmes d'un utilisateur, seulement pour qu'il soit abattu en une seconde. Par exemple, lorsque l'équipe UX essayait de résoudre le problème des icônes dépendantes du survol sur les cartes ResearchSpace pour les utilisateurs de tablettes, j'ai proposé un menu déroulant intégré à la carte d'entité comme solution. Cependant, si un menu déroulant avait été mis en place, toutes les cartes à l'écran auraient dû se déplacer vers le bas de l'écran pour faire de la place, ce qui aurait été difficile à mettre en place. L'équipe UX a fini par ajouter les icônes au bas de la carte sans modifier les dimensions de la carte - une solution qui pourrait être mise en œuvre de manière plus pratique ! Je n'ai jamais pris ces critiques personnellement et je suis heureux de dire que ces expériences m'ont aidé à développer mes compétences créatives en résolution de problèmes.

Travailler au sein de l'équipe UX Design a été une expérience enrichissante qui m'a déjà aidé à décrocher un emploi en design pour le prochain semestre d'automne et d'hiver à l'Université de Guelph. J'ai eu le plaisir de rencontrer tant de personnes talentueuses et je suis plus que reconnaissante d'avoir eu l'opportunité de travailler chez LINCS !

Au cours des deux dernières années, j'ai eu l'occasion de travailler sur de nombreux aspects du projet Orlando, mais le travail que j'ai toujours trouvé le plus intéressant a été la recherche et auteur de l'écriture profils. Les profils d'Orlando sont des histoires savantes rédigées en collaboration, qui sont structurées par un XML, et qui permettent aux chercheurs d'explorer les intersections entre la vie des femmes et leur production créative. Au cours de mon premier été en tant que Digital Humanities (DH) Assistante de recherche, j'ai commencé à travailler sur le profil de Lili Elbe ; l'année dernière, j'ai commencé à écrire un profil sur Gurpreet Kaur Bhatti. En mettant la touche finale à ces profils, j'ai remarqué que les histoires de vie des deux femmes mettent en évidence le chevauchement entre le personnel et le politique, et entre l'identité individuelle et les limites imposées au travail créatif...

En surface, Lili Elbe et Gurpreet Kaur Bhatti diffèrent énormément, à la fois en termes d'expériences et de types de travail qu'ils ont produits. Lili Elbe était une peintre danoise et dans les années 1920, elle a été l'une des premières femmes trans à subir une chirurgie de confirmation de genre. Elle a ensuite écrit et publié From Man Into Woman—un texte qui a été décrit par Lili Elbe Digital Archive comme un récit de vie—sur son expérience. Ce récit est non conventionnel dans son brouillage des faits et de la fiction : il détaille des événements réels, mais ces événements sont narrativisés et intentionnellement obscurcis par le changement de noms et l'omission de détails, tels que certains détails médicaux. En revanche, Gurpreet Kaur Bhatti est un dramaturge anglo-indien contemporain dont le travail explore des thèmes tels que le sexe, la classe, les attentes sociales et culturelles et les expériences des immigrants britanniques d'Asie du Sud. Pourtant, une chose les lie : les œuvres de l'un et de l'autre ont fait l'objet de tentatives de censure.

Peu de temps après que Lili Elbe ait obtenu pour la première fois un contrat de publication pour son récit de vie, un article qualifiant le livre proposé de scandaleux pour sa discussion sur l'évolution des conceptions du genre est paru dans un journal local. La publicité négative générée par cet article a conduit l'éditeur initial d'Elbe à se retirer de son accord. En réponse, Elbe a publié un article défendant son livre; grâce à cet acte de résistance, elle a changé la perception du public et a réussi à conclure un accord avec un nouvel éditeur. Pourtant, la marque de la censure reste une présence subtile dans le récit publié - une présence qui se révèle à travers les omissions et les altérations effectuées afin de préserver l'image de respectabilité d'Elbe (telle qu'elle était définie par les conventions qui réglementaient la performance de genre et la sexualité à l'époque). temps). Dans From Man Into Woman, Elbe parle de l'anxiété intense qu'elle a ressentie en sortant en public après la publication de l'article critique, ainsi que de la pression financière que le scandale lui a imposée, car il lui était presque impossible de vendre ses peintures, qui étaient alors sa seule source de revenus. Ainsi, il n'est pas difficile d'imaginer pourquoi elle se serait sentie obligée d'omettre de son récit tous les détails qui auraient pu la soumettre à de nouvelles attaques publiques.

Dans son récit, Elbe déploie donc de grands efforts pour se présenter comme conforme à la «norme» hétérosexuelle après sa transition, insistant sur le fait que tout sentiment romantique ou sexuel pour sa femme Gerda a pris fin avec sa transition. Pourtant, comme Nerissa Gailey (2017) l'a observé dans un article traitant des constructions historiques des identités trans, des documents historiques tels que l'érotisme lesbien que Gerda a peint en utilisant Elbe comme modèle contredisent de manière flagrante l'hétéronormativité revendiquée dans le récit de la vie d'Elbe. L'explication la plus claire de l'omission d'Elbe de cet aspect de son identité est que, bien qu'elle ait réussi à surmonter les tentatives de censure complète, la menace de scandale associée à son histoire a façonné la mesure dans laquelle elle a permis à son art de dépeindre sa vraie vie et ses expériences. Par exemple, dans From Man Into Woman, Elbe explique qu'après l'opération, elle s'est éloignée de Gerda pour empêcher des connaissances de relier Elbe à son identité d'avant la transition. Elle décrit également comment elle a demandé au roi du Danemark de déclarer invalide son mariage avec Gerda par désir de "libérer" Gerda, ce qui permettrait à Gerda de vivre une vie bien remplie (impliquant ainsi qu'une vie bien remplie est intrinsèquement hétérosexuelle). Pourtant, Elbe écrit également qu'elle a entretenu une amitié amoureuse avec Gerda.

Bien sûr, il est impossible de savoir quelle était la véritable raison pour laquelle Elbe s'est éloignée de Gerda, mais lire entre les lignes donne un aperçu de la raison pour laquelle Elbe aurait pu raconter une version modifiée de son histoire. Dans From Man Into Woman, elle exprime fréquemment sa conviction que son histoire pourrait être une ressource éducative précieuse pour la communauté médicale et pour d'autres personnes ayant des identités similaires à la sienne. Considéré sous cet angle, le désir d'Elbe de se séparer de Gerda, et par extension de son identité passée, prend tout son sens : cette séparation contribuerait à garantir que son identité soit prise au sérieux, permettant à son histoire d'avoir l'impact positif qu'elle souhaite. De plus, l'insistance d'Elbe sur le fait qu'elle voulait que Gerda soit libre de vivre une vie bien remplie - en combinaison avec l'amitié continue des femmes après leur divorce - suggère l'amour profond et désintéressé d'Elbe pour Gerda. Il est tout à fait possible que le choix d'Elbe de dépeindre leur relation comme platonique dans son récit découle de son amour pour Gerda et de son désir de protéger Gerda du genre de persécution à laquelle Elbe savait qu'elle serait confrontée si leur relation apparaissait de quelque manière que ce soit subversive.

Un modèle similaire de censure et de résistance apparaît dans la réaction à la pièce de Gurpreet Kaur Bhatti Behzti (Dishonour) et sa réponse aux critiques qu'elle a reçues. La pièce de Bhatti est centrée sur une agression sexuelle qui se produit dans un Gurdwara (un temple sikh) et est commise par un fonctionnaire de Gurdwara. La décision de Bhatti de placer cet acte de violence dans un Gurdwara a été critiquée par des membres de la communauté sikhe, qui ont organisé des manifestations devant le Birmingham Repertory theatre, où le une pièce de théâtre était mise en scène. Ces manifestations ont commencé pacifiquement mais ont rapidement dégénéré en violence. Suite à une nuit de protestation particulièrement violente au cours de laquelle des manifestants ont fait irruption dans le théâtre et interrompu la pièce, le théâtre a décidé d'annuler les représentations restantes. Tout comme Elbe a publié un article lorsque son contrat de livre a été annulé, Bhatti (2005) a publié un article qui a repoussé la censure à laquelle elle était confrontée. Elle a défendu son droit, en tant que femme sikhe, de parler honnêtement et de manière réfléchie des problèmes de la communauté sikhe. D'autres écrivains (Patel, Bakewell et Adams, 2004) ont répondu en faveur de Bhatti, publiant des déclarations sur l'importance de la liberté d'expression, et Bhatti s'est remis de l'événement. Elle a ensuite écrit de nombreuses autres pièces à succès (dont Behud [Beyond Belief], qui fictionnalise la controverse Behzti), et a ensuite remporté le prix Susan Smith Blackburn pour Behzti. Pourtant, aucun de ces triomphes ne change le fait que la série initiale de performances pour Behzti a été arrêtée prématurément. Au moment de l'arrêt de la pièce, Bhatti ne pouvait rien faire pour lutter contre la censure qui lui était imposée. L'expérience de Bhatti, tout comme celle d'Elbe, démontre la ligne de démarcation entre succomber à la suppression créative et la surmonter.

De toute évidence, Elbe et Bhatti ont testé les limites de ce qu'il était acceptable de discuter à leur époque et dans leur environnement respectifs, et ce faisant, ils ont risqué la suppression de leur travail. Chacun d'eux a répondu en créant quelque chose de nouveau à partir de la censure à laquelle ils étaient confrontés et, ce faisant, ils ont ajouté des couches supplémentaires de sens à leurs messages. Cependant, il est intéressant de noter que la valeur du travail change dans différents contextes. Dans le contexte d'Orlando, c'est la subversivité même du travail d'Elbe et de Bhatti qui rend leur travail si précieux. Une simple recherche Google sur Bhatti révèle que sa pièce la plus connue est de loin Behzti. Essentiellement, tous les résultats qui apparaissent dans une recherche sur son nom mentionnent la controverse Behzti, et avec un peu de lecture, il devient rapidement évident que c'était cette controverse même - et la force et la résistance avec lesquelles elle a réagi - qui a apporté à son travail le niveau de visibilité qu'il a aujourd'hui. Sans le tollé général suscité par son insistance sur la nécessité de repousser les limites, il est possible que Bhatti n'aurait jamais attiré l'attention nécessaire pour être incluse à Orlando. De même, c'est la nature controversée du sujet sur lequel Elbe a écrit qui fait de From Man Into Woman une ressource historique inestimable. Le fait qu'Elbe ait osé tester les limites de ce qui pouvait être écrit de manière acceptable signifie qu'elle nous a donné un aperçu des premières conceptualisations des identités trans, des premières expériences trans avec le système médical et des idées changeantes sur le genre qui ont inspiré le développement du genre. chirurgies de confirmation. C'est cette idée qui fait du profil d'Elbe un élément essentiel d'Orlando. Le compromis entre la sécurité personnelle et la stabilité qu'Elbe et Bhatti ont fait pour écrire un travail significatif et défiant les frontières ne doit pas être pris à la légère, mais il est profondément apprécié et respecté par Orlando.

Travailler sur les profils Elbe et Bhatti m'a fait réfléchir au pouvoir et à l'importance de projets comme Orlando, qui, plutôt que de séparer la vie des écrivains de leur travail créatif comme s'il s'agissait de préoccupations distinctes et sans rapport, attirent l'attention sur la façon dont l'identité et l'expérience sont tissées dans le tissu de la production créative. Les réponses publiques au travail créatif (y compris la violence et les efforts de répression) ne peuvent être pleinement comprises que dans le contexte de la vie et de l'identité d'un écrivain et du climat sociopolitique dans lequel il a vécu. Comprendre cette interdépendance est une poursuite qui, pour moi, semble d'une importance vitale. En attirant l'attention sur les préoccupations du monde réel qui ont un impact sur ce qui est et n'est pas autorisé à être exprimé dans l'art, nous assurons que les aspects des œuvres créatives que la censure a cherché à effacer sont célébrés pour leur subversivité défiant les frontières.

Ouvrages cités​

Bhatti, Gurpreet Kaur. "Ce guerrier continue de se battre." Gardien. 13 janvier 2005. https://www.theguardian.com/stage/2005/jan/13/theatre.religion.

Gailey, Nerissa. "Strange Bedfellows: Anachronismes, politique identitaire et le cas queer des trans." Journal of Homosexuality 64, no. 12 (2017): 1713–1730. https://doi.org/10.1080/00918369.2016.1265355.

Patel, Pragna, Joan Bakewell et John Adams. La violence doit être dénoncée. Gardien. 27 décembre 2004. https://www.theguardian.com/world/2004/dec/27/religion.uk.

Au cours de mes cours d'études supérieures à la Faculté de l'information de l'Université de Toronto, j'ai acquis une compréhension de haut niveau des Linked Open Data (LOD) et CIDOC CRM ontologie, un outil théorique et pratique pour l'intégration de l'information dans le domaine du patrimoine culturel. Parce que je suis un étudiant en Archives & Records Management, je ne m'attendais pas à comprendre LOD et CIDOC CRM à un degré significatif, et certainement pas dans la mesure où mon poste de spécialiste des métadonnées coopérative au LINCS l'exige...

LINCS prend les données des chercheurs canadiens en sciences humaines et les convertit en LOD. Structurellement, nous le convertissons en utilisant l'ontologie CIDOC CRM. Une fois les données des chercheurs nettoyées et les modèles de cartographie approuvés, les données sont converties à l'aide d'un outil open source appelé 3M, le gestionnaire de mémoire de cartographie. Mon rôle principal chez LINCS est de configurer et d'exécuter ces conversions. Pour ce faire, non seulement j'ai dû acquérir une compréhension plus approfondie de LOD, mais j'ai également dû apprendre CIDOC CRM et 3M.

Le processus de formation a duré près d'un mois, deux fois plus longtemps que mes collègues embauchés pour l'été ont passé à se former pour leurs rôles respectifs. J'ai passé la moitié du mois à digérer des lectures et l'autre moitié à lutter contre 3M. Assimiler autant de connaissances en si peu de temps était parfois écrasant, mais même si je terminais ma journée de travail en ayant l'impression que mon crâne avait été ouvert par une bande de singes ivres effectuant une opération du cerveau, j'ai adoré. J'aime apprendre! Toujours avoir. Et maintenant je suis payé pour apprendre ? Je suis payé pour acquérir cet ensemble de compétences extrêmement difficiles sur le plan technique et conceptuel ? Je suis payé pour réfléchir au bourbier théorique de savoir si une action est un ajout à un événement de production précédent, ou s'il s'agit - en fait - d'un événement de production entièrement nouveau, et comment la distinction entre ces deux choses se résume à la l'intention des données elles-mêmes ? Quelle merveille, quel privilège ! Je n'ai pas pris de notes aussi détaillées depuis la première année de premier cycle.

Grâce à une mission de formation, à la fin de la troisième semaine, j'ai suffisamment bien compris le CRM du CIDOC pour expliquer comment entités et propriétés liées les unes aux autres, et je me sentais à l'aise de naviguer dans les notes d'application de la dernière version stable. Lorsqu'on m'a donné un modèle de mappage et des données source, je pouvais écrire manuellement une représentation des données suivant le CRM en utilisant la syntaxe Turtle. Bien sûr, faire cela manuellement pour des milliers et des milliers d'entités serait une entreprise très peu pratique, et c'est là que 3M entre en jeu. Si je pouvais configurer le mappage dans 3M, il appliquerait l'ontologie CRM et écrirait le fichier Turtle pour moi . Le problème, bien sûr, était de le mettre en place. Je me souviens d'avoir été désorienté la première fois que j'ai vu 3M, en partie parce qu'il ressemblait beaucoup aux premiers logiciels Internet et en partie parce que le manuel utilisait un langage extrêmement technique. Je devais comprendre comment la table de correspondance (qui attribuait des classes et des propriétés CRM aux éléments des données source) était liée à un générateur (qui attribuait Uniform Resource Identifiers (URI) et rdfs:labels to entity), comment utiliser le générateur pour créer des URI LINCS temporaires ou pour le diriger vers un URI préexistant, comment écrire un fichier générateur afin que je puisse obtenir les étiquettes personnalisées appropriées, et plus encore. C'était parfois frustrant, mais les frustrations n'ont fait que rendre les succès encore plus satisfaisants. Lorsque j'ai téléchargé correctement les fichiers de schéma d'entrée et cible, lorsque j'ai utilisé une variable pour la première fois, lorsque j'ai appuyé sur "Transformer" et qu'il n'y avait aucune erreur, tous ces succès m'ont fait me sentir comme un assistant technique de niveau 20.

Une vue de haut niveau de CIDOC CRM.

Avec le recul, le premier ensemble de données que j'ai converti pour LINCS, la Map of Early Modern London (MoEML) Personography, était incroyablement simple par rapport aux ensembles de données que je convertis actuellement. Néanmoins, je ressens toujours un immense penchant pour cette première conversion, sans parler de ma profonde gratitude envers Erin Canning (analyste des systèmes d'ontologie) et Natalie Hervieux (analyste informatique principale) pour m'avoir aidé tout au long du processus. En fait, la conversion de données dans 3M est désormais l'une des parties préférées de mon travail. Je peux passer des heures dans 3M à corriger les erreurs, à faire des modifications et à rechercher le frisson d'enfin faire fonctionner les choses. C'est d'autant plus gratifiant de savoir que le travail que je fais profitera aux autres de manière tangible. Je fais ce travail pour que d'autres personnes, qu'il s'agisse de chercheurs ou d'autres membres de l'équipe LINCS, puissent copier mes mappages ou en tirer parti, puissent utiliser ma documentation pour créer leurs propres mappages ou examiner des ensembles de données, puissent effectuer des recherches et trouver de nouvelles connexions dans leur travail grâce aux données que j'ai converties. J'ai appris quelque chose de difficile, pour que ce soit plus facile pour les autres !

3M est une bête et je l'ai vaincue. Sorte de. Le problème avec l'apprentissage, c'est qu'il s'agit d'un processus continu. Un de mes anciens patrons m'a dit cela, et j'ai hoché la tête parce que je voulais désespérément mâcher un des croissants qu'il avait apportés ; écouter à moitié ses conseils de carrière semblait être la condition préalable à l'acquisition des pâtisseries, mais mon adolescent aurait dû écouter sérieusement parce qu'il avait raison. Chaque jour, j'apprends quelque chose de nouveau sur 3M ou CIDOC CRM. Chaque jour, il y a quelque chose d'autre à modifier, une perspective alternative à considérer. Lorsque j'ai assisté à la 2022 LD4 Conference on Linked Data, j'ai eu le plaisir d'écouter des professionnels de LOD discuter des problèmes que j'avais jamais envisagé auparavant, que je ne savais même pas qu'il s'agissait de problèmes nécessitant des solutions. Cela m'a ouvert les yeux et revigoré d'apprendre que, malgré toutes les connaissances que j'ai acquises jusqu'à présent, ce n'est qu'une petite partie de ce qu'il y a à savoir. Il existe des applications innovantes, des organisations et des personnes qui font des choses que je ne peux même pas imaginer. Les données ouvertes liées sont un domaine passionnant et en constante évolution, et j'ai hâte de voir ce que j'apprendrai ensuite.

Le Digital Humanities (DH) n'était pas quelque chose que j'avais beaucoup d'expérience avant de commencer comme assistant de recherche de premier cycle LINCS. Mon travail avec LINCS concerne le projet Early Modern London, en collaboration avec l'équipe Map of Early Modern London (MoEML). Une partie de mon travail est ce que LINCS appelle réconciliation, ou ce que le MoEML appelle désambiguïsation...

On me donne une personne de la [personnographie historique] du MoEML (https://mapoflondon.uvic.ca/historical_personography.htm) - une liste de personnages référencés dans des documents historiques du début de l'Angleterre moderne. Les entrées de persongraphie pour ces personnes sont en grande partie dérivées de références dans A Survey of London de John Stow, en particulier les versions publiées en 1598 et 1633. Je suis chargé de faire correspondre ces personnes aux entrées pour eux dans des endroits sur Internet comme Wikipedia, Wikidata, ou le Oxford Dictionary of National Biography. Ceci est fait pour aider à l'amélioration d'une carte virtuelle de Early Modern London, qui montre comment les espaces de Londres ont été utilisés et réutilisés aux XVIe et XVIIe siècles. Plus qu'une simple cartographie des lieux à Londres, le MoEML trace des personnes, des documents historiques, de la littérature et plus encore sur la topographie du début de la modernité de Londres pour montrer comment ils se rapportent à cet environnement. Mon travail consiste à trouver des liens en ligne pour les personnes mentionnées dans les documents historiques de l'époque, afin que nous puissions avoir une meilleure compréhension de l'époque et du lieu du début de la modernité londonienne.

La difficulté de ce travail est que je travaille à partir de ce que me dit A Survey of London de John Stow, publié pour la première fois en 1598. Cela peut être beaucoup ou très peu selon la personne. Certaines entrées me disent les titres de ces personnes, quand elles sont nées et quand elles sont mortes, quelles fonctions elles ont pu avoir, où elles ont été enterrées, quels parents elles avaient, etc. Certaines entrées ne disent rien de plus que leur nom de famille. Il était assez facile de trouver un match pour St. François d'Assise. Il était impossible de trouver une correspondance pour Mistress Dane, bienfaitrice des pauvres. Les informations sur certaines de ces personnes étant rares, il peut être difficile de trouver une correspondance si je peux en trouver une.

Un autre problème est que parfois le peu d'informations fournies par Stow est carrément trompeuse. En faisant la réconciliation pour un Richard de Cornouailles, il s'est avéré qu'il avait deux entrées de personographie distinctes sur MoEML. Le problème vient du fait que dans A Survey of London, Stow fait référence à Richard différemment. Dans la section "Downgate Ward" de A Survey of London, Stow le cite comme "Richarde Earle de Cornwell, roi d'Almaine". Dans la rubrique « Libertés du duché de Lancastre », il est cependant mentionné comme « Richard roi des Romaines ». Qu'est-ce qui pourrait expliquer cet écart dans Stow ?

Le sceau de Richard de Cornouailles. L'inscription se lit comme suit : RICARDUS DEI GRATIA ROMANORUM REX SEMPER AUGUSTUS ("Richard par la grâce de Dieu Roi des Romains toujours auguste").

Richard Plantagenet, comte de Cornouailles (1209-1272) était le deuxième fils du roi Jean Ier d'Angleterre (1166-1216). Utilisant sa vaste richesse et ses puissantes relations, il a soudoyé et cajolé son chemin pour que quatre des sept princes électeurs du Saint Empire romain germanique en 1257 l'élissent Rex Romanorum, roi des Romains. C'était le titre accordé aux dirigeants du Saint Empire romain germanique qui n'avaient pas encore été couronnés empereur du Saint Empire romain germanique. Seul le pape avait la capacité de couronner le Saint Empereur romain, avant que cette exigence ne soit abolie en 1508. Avant cette époque, il n'était pas rare que le dirigeant élu du Saint Empire romain germanique ne soit pas officiellement investi Saint Empereur romain, et Cornwall était parmi eux, car il mourut en 1272 avant de pouvoir recevoir les insignes impériaux. C'est pourquoi Stow l'a qualifié de "roi des Romaines", mais qu'en est-il de cette affaire de "roi d'Almaine" ?

Ces titres, roi des Romains et empereur romain germanique, sont potentiellement trompeurs pour ceux qui ne sont pas familiers. Le Saint Empire romain germanique gouvernait ce qui est en grande partie aujourd'hui l'Allemagne, et non Rome comme on peut le deviner. Cela avait conduit certains érudits à désigner ces titres comme l'empereur ou le roi d'Allemagne, afin de ne pas le confondre avec l'ancien royaume romain, qui a duré d'environ 753 à 509 avant notre ère. C'est de là que vient le "Roi d'Almaine". Les Alamans étaient un groupe de peuples germaniques qui se sont installés dans ce qui est aujourd'hui l'Allemagne après la chute de l'Empire romain d'Occident. La région où ils se sont installés, et plus tard l'Allemagne dans son ensemble, étaient désignées en latin par Alamannia. Ceci informe le vieux terme français pour l'Allemagne, Alemaigne. Ce mot a été introduit en Angleterre après la conquête normande de 1066, traduit par Allemaine ou Almaine en anglo-normand. Almaine est devenu un moyen populaire de désigner la région de l'Allemagne en moyen anglais. Finalement, Almain est tombé en désuétude en anglais, étant remplacé par le terme Allemagne.

Nous savons donc pourquoi le problème existe et pouvons potentiellement combiner ces deux entrées MoEML en une seule. Mais s'ils sont combinés, comment l'appelle-t-on : Roi des Romains, Roi d'Almaine, ou peut-être Roi d'Allemagne ? Comme je l'ai déjà dit, King of the Romans peut être un terme déroutant, même s'il s'agissait du titre officiel. Le problème avec le roi d'Almaine et le roi d'Allemagne est que le titre n'a jamais été ni l'un ni l'autre. Le roi a peut-être régné sur la zone géographique de l'Allemagne, mais elle n'a jamais été appelée le Royaume d'Allemagne. En outre, ce titre pourrait facilement être confondu avec le Royaume de Francie orientale , d'une durée de 843 à 962, qui était parfois appelé le Royaume d'Allemagne par les érudits ultérieurs; ou avec le dernier Empire allemand, qui a duré de 1871 à 1918.

Lorsque j'ai finalement compris le problème, j'ai transmis ces informations au MoEML, en leur parlant des entrées en double et de la terminologie problématique. Pour les premiers, ils en ont pris note. Pour le dernier? Plutôt que de choisir un nom plutôt qu'un autre pour l'entrée de Cornwall, ou d'essayer de gérer les problèmes liés à l'appeler roi d'Allemagne ou roi d'Almaine ou roi des Romains, ils ont simplement supprimé la référence à la royauté de Cornwall dans son entrée. Vous savez ce qu'ils disent : si vous ne pouvez pas gagner, ne jouez pas !

Si chaque partie d'un navire a été remplacée au fil du temps, quand, si jamais, devient-il un nouveau navire ?

Héraclite, Platon et d'autres ne savaient pas que les problèmes posés par le paradoxe du "Vaisseau de Thésée" continueraient à vexer les humanistes numériques au XXIe siècle...

Au cours de ma coop MLIS au LINCS, j'ai contribué à un vocabulaire qui a aligné les types de lieux de REED London Online (REED), Map of Early Modern London (MoEML ), et L'Arche numérique (Arche). Pour mener à bien cette tâche, nous devions d'abord déterminer comment chaque chercheur représentait la place dans ses données.

Ayant travaillé pour le MoEML pendant et après mon diplôme de premier cycle, je savais que ce processus ne serait pas simple. Les chercheurs en humanités numériques (DH) utilisent des outils et des technologies numériques pour étudier la société et la culture humaines d'un point de vue critique. Les questions de recherche sont nuancées, ce qui crée une tension compliquée, quoique convaincante, entre les ambiguïtés des sciences humaines et les systèmes et règles explicites rendus nécessaires par la technologie. Cette tension entraîne un dilemme : les humanistes numériques doivent naviguer dans les biais et les valeurs intégrés dans les logiciels, les algorithmes et les normes d'encodage pour s'assurer que les nuances et les détails de leurs recherches ne sont pas injustement simplifiés.

Mon exemple préféré de cette tension est le débat entre fonction et structure : dans un jeu de données, un seul emplacement doit-il être représenté comme plusieurs entités si sa fonction ou sa structure change ? Au début de l'époque moderne, le site de la Chartreuse assuma de nombreuses fonctions : il fut à diverses époques un cimetière de pestiférés, une chartreuse, une résidence royale, un hôpital, une école et une maison de retraite. Charterhouse, le monastère, est-il le même lieu que Charterhouse, la maison des retraités ? Qu'en est-il de la structure : le bois du théâtre de 1576 a été utilisé pour construire le Globe de 1599. En 1613, ce Globe a brûlé et un nouveau Globe a été construit. D'autres lieux, comme Somerset House, ont subi d'importantes rénovations au début de la période moderne, sans oublier que des milliers de bâtiments, dont la cathédrale Saint-Paul, ont été partiellement ou entièrement détruits lors du grand incendie de Londres en 1666.

Affirmer qu'un emplacement est le même qu'un autre n'est pas simple. Cela dépend souvent des hypothèses sous-jacentes d'un projet, des questions de recherche et des objectifs scientifiques. Cette tâche devient encore plus compliquée lorsque l'on rassemble plusieurs projets, chacun avec ses propres objectifs, mais tous se référant aux mêmes lieux.

Dans le vocabulaire que nous avons développé avec REED, MoEML et Ark, nous avons décidé de diviser les lieux en quatre grandes catégories : unité administrative, lieu structurel, lieu fonctionnel et élément topographique. Ce faisant, nous avons pu distinguer les lieux que nous pensions être principalement définis par leur structure - par exemple, les ponts, les portes et les routes - de ceux principalement définis par leur fonction - par exemple, les prisons, les églises et les théâtres. Vous trouverez ci-dessous une visualisation du vocabulaire que nous avons développé.

Vocabulaire « Place types in early modern London » développé en collaboration avec REED London Online (REED), [Map of Early Modern London (MoEML)](https://mapoflondon .uvic.ca/), et L'Arche numérique (Arche). Déclaré dans SKOS et visualisé dans SKOS Play.

Néanmoins, certains cas extrêmes défient une simple catégorisation. Par exemple, Newgate est à la fois une porte (Structural Place) et une prison (Functional Place). London Bridge est un pont (Structural Place), mais pourrait aussi être considéré comme un lieu de commerce (Functional Place) car il abritait des centaines de boutiques au début de la période moderne.

L'absence d'une solution unique n'est pas nécessairement une mauvaise chose. Contempler des cas extrêmes avec les chercheurs a conduit à des discussions productives sur la manière de représenter la nuance tout en respectant la structure imposée par le vocabulaire. Plus important encore, la création du vocabulaire a aidé les chercheurs à repenser la façon dont ils catégorisaient et étiquetaient les lieux au sein de leurs ensembles de données.

Bien que notre vocabulaire n'ait pas encore été appliqué aux ensembles de données, il fera partie intégrante de la facilitation de l'interopérabilité et de la spécificité de la catégorisation des données. Plus important encore, son application conduira à plus d'analyses - et si cette analyse ressemble à notre travail précédent, elle sera compliquée, nuancée et passionnante.

Mon premier emploi dans le domaine des musées remonte à 2008, au plus fort de la Grande Récession. L'équipe de numérisation que j'ai rejointe venait de perdre environ un quart de son personnel dans une série de rachats et de licenciements, et l'ambiance était sombre. Nous étions chargés de mettre en ligne une grande collection de photographies historiques, et le plus tôt serait le mieux. Le seul problème était que la collection n'était pas entièrement cataloguée, et le faire correctement prendrait du temps que nous n'avions pas. La pression était forte pour justifier nos travaux, et donc les discussions que nous avons eues sur les métadonnées penchaient vers le provisoire. Si la base de données n'est pas remplie, le numéro d'accession seul suffit-il ? D'accord, qu'en est-il du numéro d'accession et de l'artiste ? Les solutions que nous avons proposées reflétaient les facteurs de stress de ce moment : nous visions quelque chose d'assez bon au lieu de quelque chose d'exemplaire, en équilibrant soigneusement les exigences en matière de données avec la volonté de générer du contenu.

Au cours de la décennie et demie qui a suivi, le parent "assez bon" de Winnicott a été un principe directeur dans mon rôle de gardien des données... J'ai été un "assez bon" catalogueur dans un certain nombre d'institutions différentes, ne fournissant jamais à ma base de données que les choses les plus simples : où elle se trouve, par qui elle est, qui nous l'a donnée, et si elle sera s'adapter à notre monte-charge. J'ai été un conservateur numérique "assez bon" lorsqu'il s'agit de partager du matériel de collections en ligne, en ne donnant que les métadonnées nécessaires pour rendre nos actifs numériques utilisables dans des contextes locaux.

Travailler chez LINCS a été un changement de paradigme majeur pour moi sur le plan professionnel, notamment parce que «assez bon» est une référence différente dans ce nouveau contexte. Je suis actuellement spécialiste des métadonnées, aidant Erin Canning, analyste du système d'ontologie du LINCS, à générer de la documentation pour certains de nos partenaires dans ce projet, en me concentrant sur le Centre canadien d'ethnomusicologie, HistSex.org, la Yellow Nineties Personography, et la University of Saskatchewan Art Gallery. Pour chacun d'entre eux, j'ai été chargé de générer des extraits de code TTL et des diagrammes décrivant comment les données seront mappées dans notre triplestore utilisant CIDOC CRM et FRBRoo, qui étend le CRM pour capturer les sémantique sous-jacente de l'information bibliographique.

Ces diagrammes et extraits font partie de notre profils d'application—un profil parapluie qui capture le projet LINCS dans son ensemble, et un pour chacun des ensembles de données que LINCS comprend. Ceux-ci rassemblent ontologie modèles, nos éléments de métadonnées tirés de plusieurs espaces de noms, les politiques et directives relatives à leur utilisation, les décisions que nous avons prises qui s'écartent des normes communautaires afin de capturer avec précision les nuances de notre ensemble de données, et d'autres décisions concernant à l'objectif de données vers lequel nous travaillons. Le profil d'application est un document vivant qui permet les communications entre les chercheurs, les spécialistes de l'ontologie, les développeurs d'interfaces de données et d'autres, mais il fournit également un fil d'Ariane pour d'autres organisations qui pourraient être intéressées à reproduire la façon dont nous avons cartographié, ingéré, et fédéré tant d'ensembles de données culturelles divergentes dans ResearchSpace. Tout documenter de manière aussi complète nécessite beaucoup de soin et d'attention aux détails, mais c'est le point : alors que dans certains projets, il peut être suffisant pour quelqu'un de déduire des détails non spécifiés à partir d'une documentation peu abondante, ou de téléphoner à une personne et de lui demander ce qu'elle dans ce cas, une documentation suffisamment bonne permet à un projet comme le nôtre d'avoir un impact longtemps après que les fonds de la subvention ont été dépensés et que les rapports finaux ont été déposés. Pour être non seulement durable, mais reproductible, nous devons prendre le temps de documenter les choses maintenant. En ce sens, nous sommes attentifs à la fois aux données et aux contenus : aucun ne prime sur l'autre.

Il y a une sorte de satisfaction à faire quelque chose de très bien. Bien que je sois heureux de participer à toute activité qui facilite la communication au sein d'une grande équipe géographiquement dispersée, j'aime aussi l'idée de jeter du fil d'Ariane derrière nous au fur et à mesure. Les données ouvertes liées n'ont pas encore atteint leur pleine utilité dans le domaine culturel, et j'attends avec impatience le jour où je pourrai interroger une base de données de musée pour déterminer non seulement si une œuvre d'art tient dans un ascenseur, mais aussi des questions plus complexes qui reflètent le type d'inférence possible avec des données sémantiques. C'est excitant de savoir que ce que nous faisons pourrait inspirer d'autres à suivre et que les documents qui s'y trouvent sont assez bons pour guider leur chemin.

La situation est la suivante : on vous a demandé de concevoir un moyen pour un chercheur de se déplacer facilement entre deux outils. Vous vous familiarisez avec les deux outils, découvrez les problèmes connus et lisez ce qui a déjà été essayé. Vous passez quelques jours à décider du meilleur moyen d'aller d'un point A à un point B. Vous passez quelques jours de plus à concevoir à quoi cela ressemblera. Enfin, vous dévoilez votre prototype lors d'une réunion avec l'équipe de développement... pour découvrir que passer d'un outil à l'autre n'est techniquement pas possible. Ou que cela prendrait trop de temps pour construire votre conception. Ou que le déplacement entre les outils ouvre de nouveaux problèmes sur le back-end.

Comment avancez-vous ? ...

L'équipe de l'expérience utilisateur (UX) de LINCS est un ensemble de concepteurs et de développeurs qui travaillent en tandem pour rendre l'utilisation des outils LINCS plus fluide pour les utilisateurs, travaillant sur des sujets variés tels que les structures du système, amélioration de l'accès ou tests d'utilisabilité. L'équipe se réunit deux fois par semaine pour prévenir des situations comme celles ci-dessus. En se connectant souvent, l'équipe est en mesure de se tenir au courant de ce sur quoi chacun travaille et peut ensuite peser sur les points positifs et les défis potentiels des projets de chacun.

Robin Bergart, UX Librarian à l'Université de Guelph, est au LINCS depuis avril 2021. Elle considère les réunions UX essentielles. « Des personnes différentes avec des compétences différentes apporteront des observations différentes. C'est surprenant quand ils voient des choses que vous n'avez pas. Lorsque les développeurs et les concepteurs partagent leurs plans et sont généreux avec leurs compétences, ils sont en mesure de s'assurer que les changements sont possibles (et souhaités !) Avant qu'un membre de l'équipe ne passe des heures sur quelque chose qui ne fonctionnera probablement pas.

Dawson MacPhee, qui travaille comme développeur avec LINCS depuis mai 2021, aime utiliser ses connaissances techniques pour aider l'équipe UX à faire des choix de conception éclairés. Être impliqué dans la conception le maintient également engagé : "Si je construisais une interface et que je n'étais pas autorisé à contribuer à la conception, il serait plus difficile de trouver de l'intérêt et de la motivation."

Les réunions UX ne sont cependant pas sans défis. L'écart entre ce que les concepteurs peuvent vouloir faire et ce que les développeurs sont capables de faire peut être difficile à combler. Justifier pourquoi ils disent non à une conception proposée peut être difficile pour les développeurs : "C'est un défi de convaincre le groupe que quelque chose ne vaudrait pas notre temps", déclare Dawson. "Il peut être difficile de trouver les bons mots pour des choses en termes non techniques."

Un projet de toute envergure profite lorsque ses participants se réunissent pour partager leurs connaissances et leurs ressources. "Nous sommes en mesure d'avoir des interactions plus réfléchies... parce que nous avons un contexte partagé", explique Alliyya Mo, développeur chez LINCS depuis mai 2020. "Pourtant, le contexte manquant conduit parfois à des malentendus. Mais en parvenant à un consensus partagé avec le langage que nous utilisons, nous pouvons mieux communiquer des idées, conduisant à un meilleur produit.

L'équipe UX apporte ses diverses forces pour travailler sur de nombreuses parties d'un ensemble complexe - se réunir en tant que groupe nous permet non seulement de combiner nos compétences pour créer de meilleurs outils pour LINCS, mais cela nous permet également d'apporter ce que nous avons appris notre travail individuel.

En travaillant ensemble, la situation ci-dessus passe d'un échec de conception à une opportunité de collaboration. Présenter le projet à l'équipe à un stade plus précoce ouvre la discussion sur l'apprentissage des limites d'une conception afin que nous puissions en apprendre davantage sur de nouvelles options, sans nous arrêter dans notre élan. Nous sommes en mesure de faire des choix de conception plus solides et plus éclairés en reconnaissant le processus comme quelque chose dont nous faisons tous partie. En ayant un espace pour partager et apprendre les uns des autres, nous sommes en mesure de nous assurer que chacun participe au travail et a la compréhension nécessaire pour développer quelque chose de significatif.

La route vers UX pour moi a été longue et sinueuse, et j'aime beaucoup les utilisateurs de LINCS dans Tube Map in Figma, je me suis retrouvé à différentes stations en cours de route, évaluant où je dois aller ensuite. Étudiant initial en sciences de la vie à l'Université de Toronto, j'ai fait la transition après la première année vers une spécialisation en anthropologie socioculturelle. Après avoir obtenu mon diplôme et ne sachant pas où aller avec ma carrière, j'ai commencé une maîtrise en affaires publiques et internationales à l'Université d'Ottawa. J'ai vite réalisé que j'étais trop passif par nature pour être diplomate, et qu'il me manquait la passion pour la politique que beaucoup de membres de ma cohorte partageaient. Ce que je voulais vraiment, c'était quelque chose lié à ma formation en anthropologie.

Et donc, entrez à la Faculté d'information de l'UofT... Je voulais étudier à nouveau à l'Université de Toronto et j'ai assisté à une séance d'information pour leur concentration en culture et technologie. Comme je pouvais assister à deux sessions le même jour, j'ai également assisté à celle de l'UXD. Au cours des cinq premières minutes, le professeur a mentionné que de nombreux étudiants en anthropologie poursuivent l'UXD en raison du besoin de compétences ethnographiques et des entretiens avec les utilisateurs pour évaluer les besoins en interfaces. J'ai été vendu.

LINCS a été mon deuxième stade en tant que spécialiste UX. Mon intérêt pour l'UX est multiforme, mais je veux en grande partie pouvoir contribuer à quelque chose de significatif en appliquant ma formation en sciences humaines et en utilisant l'empathie pour créer des produits accessibles, proposés et de grande portée. Travailler au LINCS m'a permis de faire tout cela. Créer des interfaces pour travailler avec le Le Web sémantique signifie essayer de comprendre comment les chercheurs pensent et ressentent, et comment ils veulent que leur travail soit utilisé. Issu d'une formation en sciences humaines, LINCS s'est senti comme chez moi, car il m'a permis de me mettre à la place de l'utilisateur plus que je ne l'avais imaginé.

Mon temps au LINCS s'est concentré sur ResearchSpace. J'ai examiné ResearchSpace à travers une lentille analytique et UX, en présentant les points de douleur possibles que les utilisateurs rencontreront lorsqu'ils naviguent dans l'outil et créent les connexions entre les ensembles de données. Pour déterminer ces points faibles, j'ai pris en compte la cohésion de la navigation, la clarté du langage utilisé, le jeu de couleurs en ce qui concerne les normes AODA et si les sections qui effectuent des tâches similaires pourraient être agrégées.

J'ai rejoint le projet LINCS en tant qu'assistant de recherche de premier cycle, principalement pour travailler sur le projet Orlando. Ce poste m'a donné ma première véritable expérience avec Humanités numériques (DH). Avant de commencer le travail, je pouvais à peine trouver une définition même vague de DH (malgré tous mes efforts et pas mal de recherches sur Google). Quand j'ai finalement commencé à avoir une idée de la nature de DH - un domaine qui rassemble la recherche en sciences humaines et les nouvelles technologies, donnant naissance à de nouvelles possibilités et ajoutant de la profondeur à la recherche - il y avait des éléments qui me semblaient très familiers et conformes au genre de travail avec lequel j'ai eu de l'expérience en tant qu'étudiant de premier cycle spécialisé en anglais... après tout, il y avait peu de différence entre patauger dans les sources primaires et fouiller dans les bases de données tout en recherchant un article pour un cours d'anglais, et faire de même pour un projet DH. Il y avait cependant d'autres aspects (principalement du côté numérique) qui semblaient plutôt étrangers.

Une grande partie de mon travail pour le projet Orlando consiste à rechercher, rédiger et baliser des profils d'auteurs. Alors que j'étais d'abord intimidé par la perspective d'apprendre le XML qui est utilisé pour les étiqueter, la recherche et l'écriture étaient suffisamment familières pour me donner l'impression que je ne m'étais pas trop éloigné de ma zone de confort. Lorsque j'ai commencé à lire les profils existants d'Orlando et que j'ai finalement commencé à écrire mon propre profil pour l'auteur Lili Elbe (à paraître), j'ai vite compris que le balisage d'Orlando était intuitif. J'ai également commencé à apprécier la façon dont la réflexion sur le schéma d'Orlando m'a aidé à structurer mes idées. J'ai réalisé que les règles du schéma d'Orlando ne sont pas différentes des règles qui structurent la langue anglaise. Dans les deux cas, la structure est à la fois un cadre et un défi - elle contraint la communication, mais ce sont ces mêmes contraintes qui produisent du sens et de l'ordre. Quand j'ai commencé à comprendre ce parallèle, j'ai plongé un orteil dans le côté numérique de DH et j'ai trouvé que l'eau n'était pas désagréable. En même temps, cependant, j'étais conscient que je n'avais fait qu'effleurer la surface.

A partir du moment où j'ai eu un aperçu du monde de DH, et plus précisément, des nombreux projets interdépendants qui composent le projet LINCS (un projet qui cherche à créer une infrastructure afin de représenter de manière significative l'interdépendance des données culturelles sur le web) , j'étais parfaitement conscient de tout ce que j'ignorais. Au début, je me contentais de comprendre simplement ce que j'avais besoin de savoir pour accomplir les tâches qui m'étaient assignées. Je me suis concentré sur mon travail et j'ai apprécié la beauté de faire partie d'un projet qui rassemble un éventail de personnes ayant des connaissances et des compétences différentes. J'ai écouté les conversations d'autres personnes sur le développement de l'ontologie CWRC, ou sur l'utilisation de requêtes SPARQL pour trouver des images sur Wikipedia pour les auteurs qui ont des entrées dans la base de texte d'Orlando, et j'ai été ravi de découvrir celle-là projet pourrait avoir autant de composants uniques. Après avoir été entouré par ces conversations pendant un certain temps, ce qui était autrefois une appréciation a commencé à se transformer en curiosité.

Plus j'entendais les mêmes mots et acronymes inconnus, moins ils commençaient à me sembler inconnus. Moins ils me semblaient inconnus, plus je voulais les comprendre. Finalement, j'ai commencé à envisager la possibilité que si les parties de mon travail qui semblaient intimidantes s'étaient avérées si intuitives et agréables, alors peut-être qu'il serait plus facile que je ne le pensais d'apprendre d'autres choses qui semblaient initialement bien en dehors du domaine de mes compétences. C'est ainsi que j'ai fini par rejoindre un groupe d'apprentissage SPARQL et que j'ai commencé à élaborer des requêtes aux côtés de collègues qui en savent beaucoup plus sur les ordinateurs que moi.

J'avais l'habitude de trouver l'idée d'apprendre une langue utilisée exclusivement par des ordinateurs totalement déplaisante. J'ai associé le langage des ordinateurs aux nombres et aux mathématiques, des choses qui m'ont constamment fait courir. Pourtant, alors que j'ai commencé à apprendre SPARQL, j'ai découvert que les langages de requête n'ont rien à voir avec les mathématiques et tout à voir avec la structure, la logique et la recherche de la bonne façon de poser les bonnes questions. Ce fut une révélation pour moi, car c'est précisément le genre de choses que j'aime dans le travail d'écriture et de recherche que j'ai l'habitude de faire en tant qu'étudiant en anglais. J'aime le moment au début d'un projet de recherche où vous devez vous asseoir et déterminer quelles questions vous avez sur un sujet, puis décomposer ces questions en leurs parties essentielles pour obtenir l'essence de ce que vous devez savoir sur le sujet. Plus que ça, j'aime le "aha!" moment où vous trouvez le bon langage pour exprimer les questions auxquelles vous cherchez à répondre. La création de requêtes SPARQL a été pleine de ces moments. SPARQL amplifie la nécessité de questions précises et d'un langage précis, car les services de requête ne comprennent que des vocabulaires spécifiques dans certaines structures. Ainsi, apprendre SPARQL a été un exercice pour trouver les bons mots pour poser mes questions et apprendre à adapter ces questions pour qu'elles correspondent à la structure du langage de requête tout en conservant l'essence de la question.

Par exemple, lors de l'élaboration d'une requête pour trouver toutes les femmes qui ont allumé la flamme olympique, j'ai découvert que cette même question peut être posée d'une manière qui centre les jeux olympiques, ou d'une manière qui centre l'acte d'allumer la torche. Ces deux requêtes sont des formes de la même question, et elles ont toutes deux renvoyé des données pertinentes, mais en raison de la façon dont Wikidata étiquettes sont appliquées, les données renvoyées par chaque requête étaient différentes. C'est la partie de la création de requêtes SPARQL qui m'a le plus intrigué. Tout comme c'est le cas au début d'un article de recherche, lors de l'élaboration d'une requête SPARQL, il est utile de trouver différentes façons de poser la même question et de trouver différentes perspectives à travers lesquelles examiner les mêmes problèmes. C'est la nécessité de poser les bonnes questions lorsque l'on travaille avec SPARQL qui me rappelle que les langages « informatiques » sont fondamentalement des langages humains. Chercher obstinément une réponse en posant sans cesse la même question de différentes manières jusqu'à ce qu'elle donne enfin des résultats utiles est une entreprise fondamentalement humaine. En fait, ce besoin persistant de remettre en question les questions mêmes que vous posez, et ce faisant, de produire des opportunités de changements de paradigme, m'a toujours semblé être une partie essentielle des sciences humaines. C'est ce qui m'a attiré vers les sciences humaines.

Je suis peut-être encore au tout début de l'apprentissage de SPARQL, mais je vois déjà que je ne me serais pas rendu service si j'avais supposé que c'était hors du domaine des choses dont je suis capable ou que j'ai le potentiel d'être passionné. , apprentissage. Bien que SPARQL ait d'abord semblé différent du type de travail auquel je suis habitué, en réalité, il nécessite le type de réflexion que j'apprécie le plus. Cela nécessite une réflexion flexible et une attention constante aux petits détails, qui peuvent sembler insignifiants au premier abord, mais peuvent s'avérer vitaux. Tout au long de ma vie intellectuelle, j'ai toujours été attiré par les études littéraires en raison de la façon dont un seul mot ou une seule phrase peut contenir tant de sens. Je suis fasciné par la façon dont quelques phrases ont le potentiel de changer toute mon analyse d'un roman. J'ai trouvé le même genre de joie à travailler sur Orlando, car j'ai réalisé à quel point une rencontre fortuite avec un autre auteur ou un petit changement dans les ressources économiques peut modifier tout le cours de la vie d'une femme écrivain. Maintenant, j'ai découvert à nouveau la joie des petits détails dans SPARQL alors que j'explore la façon dont les étiquettes que j'utilise pour construire ma requête déterminent les données qui me seront renvoyées en réponse à mes questions. Si je n'avais pas fait partie d'un projet DH, je n'aurais probablement jamais entendu parler de SPARQL, encore moins commencé à l'apprendre et à découvrir les parallèles qui peuvent être établis entre celui-ci et mes autres travaux. C'est la beauté de DH - lorsque différentes disciplines sont réunies en un seul endroit, cela crée de nouvelles opportunités pour élargir votre compréhension et repenser et tester les limites de votre zone de confort.