Méthodologie

Tri

Montrer toutes les contributions

(no Tag)   Contexte extralinguistique   Domaines de fonction   Technologie de l'information   Linguistique   Page Web  


API  (Citer)

L'abréviation API signifie en anglais "application programming interface", en français 'interface de programmation'. VerbaAlpina fournit une telle interface à l'adresse https://www.verba-alpina.gwi.uni-muenchen.de/?api=1. Une documentation détaillée de la syntaxe à utiliser se trouve dans l'article suivant: Documentation API. L'API permet de repérer des contenus spécifiques de la base de données VA (VA_DB) dans des formats définis à travers un navigateur web. La sélection des données et le format de sortie sont contrôlés par des paramètres URL.

(auct. Stephan Lücke – trad. Beatrice Colcuc)

Tags: Technologie de l'information



Archivage de longue durée  (Citer)

Toutes les données du projet VerbaAlpina sont gérées de telle sorte qu'elles restent lisibles et utilisables pendant une période la plus longue possible. La perspective temporale envisagée du projet comprend au moins plusieurs décennies, le concept sur lequel le projet se base est lui orienté sur une conservation sans limitation de durée. Les aspects suivants sont pris en considération :
1. A quelle institution/à quelles institutions est confiée la conservation des données et des des supports d'information en question ?
2. Documentation de la structuration des données ainsi que des relations logiques entre données et catégories de données (entité-association)
3. Documentation des codages de caractère utilisés
4. Sur quel type de support d'information sont conservées les données

Plusieurs copies des données du projet devront être archivées chez différentes institutions . Actuellement, l'IT-Gruppe Geisteswissenschaften de la LMU (c'est-à-dire le groupe de technologie de l'information des sciences humaines de l'Université de Munich, ITG) lié aux serveurs d'archivage du Leibniz-Rechenzentrum et le BAS Clarin Repository s'en chargent. La mise en dépôt de copies de sûreté supplémentaires chez d'autres institutions y étant aptes est prévue. L'archivage a lieu au rythme de la gestion de versions. Chaque fois, la base de données est archivée avec toutes les données du projet ainsi que le framework d'application web qui est responsable pour la présentation des données au web (y compris la fonctionnalité respective), de telle façon qu'il est possible (au moins en théorie) de "réveiller de nouveau" chaque version isolément dans les correspondants environnements de système d'exploitation respectivement de logiciel émulés.

(auct. Stephan Lücke – trad. Susanne Oberholzer)

Tags: Technologie de l'information



Beta code  (Citer)

En référence à la terminologie du Thesaurus Linguae Graecae (TLG) (qui a développé au début des années soixante-dix, avec les moyens de technique informatique d'alors, un concept similaire pour la saisie électronique de textes en grec ancien), la transcription de systèmes d'écriture complexes à l'aide exclusif de caractères ASCII est appelée "Beta code" dans le cadre de VerbaAlpina.
Le graphique suivant illustre le procédé à l'aide d'un exemple de l'Atlante italo-svizzero (AIS):





Pour permettre la retranscription en caractères ASCII des transcriptions phonétiques selon Böhmer-Ascoli utilisées dans les atlas, il faut tout d'abord distinguer caractères de base et diacritiques. Si un caractère de base est présent dans le code ASCII, ce caractère est représenté tel quel lors de la transmission (ce cas se retrouve dans l'exemple). Tous les diacritiques liés au caractère de base le suivent immédiatement après. Chaque diacritique est remplacé par un caractère ASCII dédié. L'attribution des diacritiques à des caractères ASCII est sans équivoque au sein de VerbaAlpina et des tableaux dédiés de la base de données VerbaAlpina consignent le processus. Autant que possible, le choix de l'attribution est guidé par le principe de la ressemblance optique. Ainsi dans l'exemple mentionné, le point sous le e dans le mot tega est rendue par un point d`interrogation: te?. Les diacritiques sont retranscrits en partant de leur position par rapport au caractère de base dans l'ordre suivant : de bas en haut et de gauche à droite, après le caractère de base. En raison du principe de la ressemblance optique, l'affectation des diacritiques se fait indépendamment de leur sémantique dans la source spécifique, c.-à-d. que même si une coche sous un caractère de base a un sens phonétique complètement différent dans une source que dans une autre, la coche sera rendue dans les deux cas par une parenthèse fermante. Les différences sémantiques sont documentées dans des tableaux de transcription spécifiques à chaque source: ceux-ci règlent la conversion du beta code à la transcription d'output selon API, c.-à-d. que le même beta codage peut conduire à des codages API entièrement différents suivant la source.
Le procédé décrit a nombre d'avantages:
- la saisie des données peut être faite sur des claviers standard traditionnels, à relativement grande vitesse, et elle est complètement indépendante du système d'exploitation;
- les transcripteurs n'ont bas besoin de connaissance des systèmes de transcription phonétique;
- n'importe quel caractère ou diacritique peut être saisi, qu'ils soit codés dans Unicode ou pas;
- la saisie des données électronique se fait sans perte d'information.
Le beta code peut être converti en presque tout autre système de transcription par des routines de remplacement. Dans le cadre de telles conversions, des pertes d'information peuvent éventuellement se passer; mais c'est là le caractère même des systèmes de transcription. Ainsi, la transcription phonétique selon Böhmer-Ascoli fait une distinction des différents degrés d'ouverture d'une manière très détaillée, qui n'est pas prévue dans le système API.



(auct. Thomas Krefeld | Stephan Lücke – trad. Susanne Oberholzer)

Tags: Linguistique Technologie de l'information



Concession d'une licence  (Citer)

Les modules de VerbaAlpina (VA_DB, VA_WEB et VA_MT) et les données y étant contenues sont soumis aux licences Creative Commons suivantes:




CC BY-SA 3.0 DE (http://creativecommons.org/licenses/by-sa/3.0/fr/; "Attribution, Partage dans les Mêmes Conditions") (dépendant de l'objet)




CC BY-NC-SA 3.0 DE (http://creativecommons.org/licenses/by-nc-sa/3.0/fr/; "Attribution, Pas d'Utilisation Commerciale, Partage dans les Mêmes Conditions").

Certains des fichiers média du module VA_MT que VA a reçus ou achetés peuvent aussi être soumis au copyright. Les objets dans le module VA_MT sont chaque fois marqués des signes correspondants.

Le système de concession d'une licence ainsi que les droits d'accès des groupes d'utilisateurs de VA différents sont montrés dans le graphique suivant:





(auct. Stephan Lücke – trad. Susanne Oberholzer)

Tags: Technologie de l'information Page Web



Description de concept  (Citer)

Les concepts sont saisis comme suit dans le tableau KONZEPTE (concepts) de la base de données : existe une dénomination lexicalisée pour un concept, alors cette dénomination s'inscrit dans la case 'Name_F' (dénomination française) de la base de données. Si la lexicalisation manque, la case reste blanche. Indépendamment de l'existence ou non d'une dénomination, le concept sera décrit dans la case 'Beschreibung_F' (description française) en suivant une procédure fixe. La voici présentée à l'aide de l'exemple du concept 'ÉCRÉMOIR' (ID_Konzept 142; identifiant du concept dans la base de données): le concept mentionné est désigné par un lexème spécifique, on inscrit donc ÉCRÉMOIR dans 'Name_F'. La description prévoit l'ordre hiérarchique suivant: ustensile, fonction, matériau, (éventuellement) forme. Appliqué au concept de l'exemple, il en résulte la description suivante: USTENSILE, POUR ÉCRÉMER, LOUCHE.
Si possible ou si c'est nécessaire, il faut suivre ces règles supplémentaires: les nombres 1-10 sont écrits en toutes lettres; dans la description d'un processus, d'une activité etc. on peut ou utiliser "pour+infinitif" ou "pour+article+substantif". L'observation de ces modèles permet des traductions analogues, la formation de catégories indépendantes de langues particulières à des niveaux différents d'abstraction (->RÉCIPIENTS ->RÉCIPIENTS POUR LE TRANSPORT ->RÉCIPIENTS DE BOIS etc.), des corrections automatisées et une recherche transparente. Tous les concepts sont saisis de cette manière dans les langues allemande, italienne, française, slovène et romanche.

(auct. Giorgia Grimaldi | Thomas Krefeld – trad. Susanne Oberholzer)

Tags: Technologie de l'information



Digital Object Identifier (DOI)  (Citer)

Le Digital Object Identifier (DOI) est une adresse mondiale unique et inchangeable, grâce à laquelle les ressources électroniques, comme par exemple les sites web, sont accessibles. L’accessibilité reste garantie même lorsque l'"Uniform Resource Locator" (URL) d’une ressource change. L'avantage principal du système DOI est donc de pouvoir citer pérennement les ressources électroniques. On peut y accéder par un simple mapping : la fondation DOI tient un registre dans lequel l’actuelle URL d’une ressource est systématiquement associée à un DOI. Lors de la modification d’une URL s’ensuit la modification correspondante dans le registre de la fondation DOI. Les modifications doivent être communiquées à la fondation DOI par l’intermédiaire des organisations associées (par exemple les bibliothèques) qui ont fait enregistrer les DOI en question. La saisie dans le registre DOI par VerbaAlpina se fait en passant par le "Referat Elektronisches Publizieren" de la bibliothèque universitaire de la LMU qui effectue quant à elle l’enregistrement non pas directement auprès de la fondation DOI, mais auprès de DataCite, lui-même une composante de la fondation DOI.

Le DOI de VerbaAlpina est le suivant : 10.5282/verba-alpina. Le préfixe, les chiffres (10.5282), se rapporte à l’organisation enregistreuse, dans ce cas la bibliothèque universitaire de la LMU. Pour qu’une citation, par exemple dans une dissertation scientifique, renvoie directement au portail de VerbaAlpina, il faut que le DOI soit intégré dans l’URL de la fondation DOI : http://dx.dopai.org/10.5282/verba-alpina.
La convocation immédiate de données spécifiques partielles sur le portail VerbaAlpina (par exemple de données singulières dans le module médiathèque de VerbaAlpina [VA_MT]) par l’intermédiaire du DOI n’est pas possible. Il faudrait un DOI supplémentaire pour chaque donnée partielle de VerbaAlpina.

Le Uniform Resource Name (URN) a presque le même objectif que le DOI, et son mode de fonctionnement est à peu près le même. A la différence du DOI, on peut cependant enregistrer de multiples URL pour une ressource. Cela peut être intéressant si les ressources, afin de garantir pérennité ou cas de défaillance, sont déposées dans différents serveurs avec des URL différents leur correspondant. Un certain inconvénient des URN par rapport aux DOI réside dans le fait que le registre URN n’est pas administré par une institution unique, mais par différentes organisations nationales décentralisées. Pour l’Allemagne, c’est la Bibliothèque Nationale Allemande (Deutsche Nationalbibliothek) qui prend en charge cette mission, c’est pourquoi le serveur régissant les URN (le Resolver) doit être convoqué pour les ressources qui sont enregistrées sur la DNB. L’URN de VerbaAlpina est la suivante : urn:nbn:de:bvb:19-verba-alpina-8, l’URL correspondante au resolver DNB menant au portail de VerbaAlpina est http://nbn-resolving.de/urn:nbn:de:bvb:19-verba-alpina-8.
De même que dans le cas des DOI, la convocation immédiate de données spécifiques partielles sur le portail de VerbaAlpina par l’intermédiaire de l’URN n’est pas possible.



(auct. Stephan Lücke | Julian Schulz [ITG])

Tags: Technologie de l'information



Données d'autorité  (Citer)

L'origine de la notion des données d'autorité se trouve dans le système de bibliotèques. En catalogisant des publications, par exemple, l'identificaton sans équivoque des auteurs est indispensable pour assurer l'attribution correcte des œuvres, indépendemment de variantes graphiques ou de changements de noms. Cette exigence porte également sur l'indexage des titres de publications où il s'agit par exemple d'identifier sans équivoque et de relier des termes géographiques pouvant faire l'objet d'ouvrages diverses. Ces contraintes on mené au développement de listes onomasiologiques, individuelles dans un premier temps selon les différentes bibliothèques.

Avec les nouvelles techniques d'interconnexion d'ensembles de données, nées dans les années 1970, il fallut bientôt concorder les indexes jusqu'alors individuels des différentes bibliothèques. Par conséquent, les bibliothèques commencèrent au cours des années 1980, au plus tard – les premières conceptions eurent lieu vers la fin des années 1970 – à harmoniser les indexes individuels pour obtenir une consistence englobant toutes les bibliothèques. Au début, des registres séparés pour les personnes (allem. Personennamendatei, PND) et les collectivités publiques (allem. Körperschaftsdatei, GKD) ainsi qu'une nomenclature de mots-clés (allem. Schlagwortnormdatei, SWD) furent établis. Après un moment, la séparation thématique résultante s'avéra inappropriée, d'autant que les personnes et les collectivités peuvent figurer non seulement commes des auteurs ou des éditeurs mais à aussi comme l'objet de publications à leur tour, devant également se considérer lors des indexations sur la base du fichier d'autorité des mots-clés. C'est pour cette raison qu'entre 2008 et 2012, les trois fichiers d'autorité individuels (y compris le fichier d'autorité des titres uniformes des archives de musique allemandes) s'unifièrent dans un effort commun de la Bibliothèque nationale allemande et des associations de bibliothèques germanophones pour former un type d'autorité s'appelant GND (allem. Gemeinsame Normdatei, GND). Ce dernier est à disposition du public depuis 2012 dans des formats divers (MARC 21 Authority, MARC21-xml et RDFxml) et s'utilise de plus en plus pour des buts d'indexage en dehors du système de bibliothèques. Les projets en humanités numériques BMLO (Bayerisches Musiker-Lexikon online) et Kaiserhof réalisés par l'ITG (allem. IT-Gruppe Geisteswissenschaften), notamment, s'en servent pour assurer l'identification sans équivoque des personnes.

Sous l'adresse http://ognd.bsz-bw.de/ (centre de service bibliothécaire de Bade-Wurtemberg) on a accès à un outil de recherche compfortable pour consulter le GND. Dans le monde, il existe des types d'autorité comparables au GND, gérés dans la plupart des cas par des bibliothèques. Depuis 2003, le projet VIAF (Virtual International Authority File), mis sur pied dans une collaboration entre la Bibliothèque nationale allemande et la Bibliothèque du Congrès, poursuit le but de réunir et rendre accessibles ces ensembles de données au sein d'un seul système.
Cependant, si en théorie le système des tyes d'autorité permet l'identification sans équivoque des personnes et des concepts, l'exploitation pratique dépend largement de l'implémentation technique dans les systémes électroniques des catalogues de bibliothèques. Dans les catalogues de la Bibliothèque nationale allemande et de la Bayerische Staatsbibliothek (BSB), la recherche du mot-clé "Homère" donne aussi des résultats que le système bibliothécaire a saisi sous "Homer". Inversément, en cliquant sur un nom d'auteur hyperlié dans le catalogue en ligne de la BSB on obtient actuellement (oct. 2018) non seulement les titres de l'individu en question mais aussi ceux d'autres auteurs du même nom.

Le concept des données d'autorité s'étant originé dans le contexte du système de bibliothèques son utilisation s'est cependant généralisé entretemps dans d'autres domaines. À titre exemplaire on peut citer les projets suivants: Geonames (entité geographica), Pleiades (entité geographica antiques) ou encore Glottolog (entité langues internationales).

Les données d'autorité sont particulièrement importants en vue des exigences d'interopérabilité, postulées entre autres par l'initiative FAIR. Chaque donnée d'autorité définie et dotée d'un identifiant (alpha)numérique permet non seulement l'intégration dans l'exploitation sémantique des catalogues de bibliothèques mais aussi l'interconnexion logique et technique d'entités correspondantes faisant partie d'ensembles de données indépendants.

Du point de vue de VerbaAlpina, la création des catégories de données d'autorité «type morpho-lexical» (⇒ Réduction à types et «concept» serait méthodologiquement rigoureux et, de là, souhaitable. Ainsi, on aurait la possibilité d'attribuer des identifiants aux types morpho-lexicaux et aux concepts, ce qui permettrait le référencement de données lexicales à l'échelle mondiale, même indépendemment, dans le cas des concepts, des langues individuelles. Quelques efforts dans cette direction se font remarquer: dans les ensembles de données stucturés du projet Wikidata, par exemple, on attribue des «identifiants Q» pour identifier sans équivoque des concepts extralinguistiques, fournissant ainsi une référence commune et identique pour tous les articles Wikipédia et leurs versions multilingues traitant le même sujet. Le concept du nom allemand ALMHÜTTE (chalet d'alpage), par exemple, est identifié sans équivoque sur Wikidata avec l'ID Q2649726. Dans la fiche Wikidata correspondante, on trouve des liens vers tous les articles Wikipédia, actuellement (octobre 2018) représentés en sept langues, qui sont réliés à cet identifiant. Du total des concepts saisies par VerbaAlpina se montant à 2629, 400 ont pu être reliés à un identifiant Q jusqu'à présent. D'une manière générale, les identifiants Q sont enregistrés, dans la mesure où ils existent, dans l'ensemble de données de VerbaAlpina. En revanche, ni Wikipédia ni Wikidata, respectivement, semblent disposer d'un système d'identification comparable au niveau des types morpho-lexicaux. Les identifiants L déjá en existence sont attribués à des formes langagières, mais il est peu clair s'il s'agit de types précisément définis.

A l'instar du modèle des données d'autorité, VerbaAlpina attribue leur propres identificateurs aux catégories de données (entités) «concept», «type morpho-lexical» (cf. Réduction à types) et «communauté», les identificateurs pouvant être référencés grâce au data mapping à des systèmes de données d'autorités plus établis comme p.ex. les identifiants Q de Wikidata. En outre, VerbaAlpina s'emploie à faire entrer la catégorie de données «type morpho-lexical» dans la systématique du Gemeinsame Normdatei (GND). Cet objectif prend appui sur la prémisse que le GND doit s'élargir structurellemnt mais aussi au niveau du contenu en fonction des exigences de la science et des institutions et personnes du domaine culturel. Un échange à propos de ce sujet est prévu en décembre 2018 dans le cadre de la conférence GNDCon 2018.

Le GND distingue actuellement les entités suivants: collectivité publique (sigle: b), conférence (f), donnée géographique (g), personne (non individualisée) (n), personne (individualisée) (p), objet référentiel (s), œuvre (u) (http://www.dnb.de/SharedDocs/Downloads/DE/DNB/standardisierung/inhaltserschliessung/entitaetenSatztypen.pdf?__blob=publicationFile). Par ailleurs, dans une fiche du GND appartenant à la catégorie «Arbeitshilfen zur gemeinsamen Normdatei (GND)» on trouve l'information que le code d'entité «slz», représentant une sous-catégorie de l'entité «objets référentiels», a été réservé pour les données de la catégorie «lettres, morphèmes, mots comme objet de recherches linguistiques». Dans cette logique il serait évident de relier les données d'autorité de VerbaAlpina avec celles de cette catégorie.

Référence:
Capellaro 2003

(auct. Stephan Lücke – trad. Sonja Schwedler-Stängl)

Tags: Technologie de l'information



Entité-association  (Citer)

Par principe, les données peuvent être regroupées en "entités". Il s'agit de classes de données, chaque classe possédant des caractéristiques spécifiques variant en nombre et en nature. Ainsi, les villes de Trente, d'Innsbruck et de Lucerne peuvent former une classe "lieux", classe à laquelle appartiendraient les caractéristiques "nom de lieu", "longitude", "latitude", "pays" et "nombre d'habitants". Les constituants individuels d'une telle classe diffèrent les uns des autres selon les données fournies par ces caractéristiques. Dans une base de données relationnelle, idéalement, chaque entité est sauvegardée dans un tableau particulier. Les colonnes de ces tableaux indiquent les valeurs d'une caractéristique spécifique. Les lignes indiquent les membres individuels d'une classe de données (entité), ces membres se distinguent par les valeurs de la caractéristique. Presque toujours – et c'est le cas chez VerbaAlpina – une base de données relationnelle représentera une collection de différentes entités (et par conséquent de tableaux) liées par des relations logiques. Ainsi, l'entité "informateur", définie par les caractéristiques "âge", "sexe", "lieu de naissance" et "domicile", sera liée logiquement à l'entité "lieux" de telle manière que les valeurs des caractéristiques "lieu de naissance" et "domicile" aient des correspondances dans l'entité "lieux". Les relations entre les membres de ces deux entités résultent des correspondances de valeurs d'une ou de plusieurs caractéristiques coïncidentes des entités respectives. Ainsi, théoriquement, si les valeurs fournies par les caractéristiques "lieu de naissance" et "nom de lieu" coïncident, une affectation pourrait se faire, par laquelle les coordonnées géographiques du lieu de naissance d’un informateur apparaîtraient automatiquement. Cet exemple démontre que l'on peut être confronté à des problèmes d'homonymes. Pour éviter cela, on utilisera généralement des entiers relatifs comme identifiants (abréviation: "ID") qui définissent de façon univoque les membres d'une entité. Le système décrivant les entités et leurs relations logiques s'appelle "entité-association".
Les données recueillies dans une base de données relationnelle sont difficilement intelligibles et utilisables sans que le système de dépendance utilisé soit expliqué. L'entité-association est représentée normalement sous la forme d'un schéma graphique. L'entité-association est soumise à des adaptations continues et par conséquent à des modifications pendant les phases de développement cycliques de VerbaAlpina (cf. gestion de versions). Chaque fois qu’une version de VerbaAlpina est archivée, est ajouté le modèle entité-association correspondant à cette version. Il se présente sous forme d’un diagramme ER, généré avec le programme yEd et enregistré sous GraphML. Les diagrammes créés à l'aide d'outils automatiques ne sont ensuite pas édités graphiquement, en raison de la charge de travail considérable que cela implique. Pour cette raison, et à cause de la grande complexité des structures représentées, ils ne sont généralement pas immédiatement compréhensibles pour des personnes extérieures. Ils contiennent néanmoins toutes les informations nécessaires pour comprendre la structure de VA_DB et représentent donc une condition préalable importante pour utiliser la base de données, même après la fin du financement du projet. Le graphique suivant est basé sur les entités et les liens de la base de données VA_XXX dans son état actuel (30.11.2017), mais il ne les représente pas complètement et doit seulement être vu comme un exemple illustratif :





(auct. Stephan Lücke – trad. Susanne Oberholzer)

Tags: Technologie de l'information



Format des données  (Citer)

voir Modélisation des données

Tags: Technologie de l'information



Géoréférencement  (Citer)

Le géoréférencement selon les degrés de latitude et de longitude est un critère de classement essentiel pour la gestion des données de VerbaAlpina. La précision de ce référencement varie selon le type de données; on aspire un référencement le plus exact possible, au mètre près. Dans le cas des données linguistiques issues des atlas et des dictionnaires, c'est seulement un référencement approximatif conformément à un toponyme qui est en règle générale possible. Dans le cas de données archéologiques par contre, un géoréférencement au mètre près est possible. On peut sauvegarder des points, des lignes (comme des rues, des rivières) et des surfaces. Sous l'angle technique, le format WKT (https://en.wikipedia.org/wiki/Well-known_text) est principalement utilisé, celui-ci est transféré à un format MySQL spécifique dans la base de données VA par la fonction geomfromtext() (https://dev.mysql.com/doc/refman/5.7/en/gis-wkt-functions.html et est ainsi sauvegardé. La sortie au format WKT se produit par la fonction MySQL astext().
La grille de référence du géoréférencement est établie selon le réseau des communes de la région alpine, qui peuvent être sorties ou comme surfaces ou comme points, suivant les besoins. Les tracés des frontières de commune de 2014 que VerbaAlpina a reçus de son partenaire "Conférence Alpine" en forment la base. Une actualisation permanente de ces données est superflue, même si elles changent selon les réformes administratives, car il s'agit dans la perspective de VerbaAlpina seulement d'un cadre de référence géographique. La représentation en point des communes est calculée selon les frontières communales de façon algorithmique, elle est donc secondaire, ne marquant pas nécessairement le centre bourg.



(auct. Thomas Krefeld | Stephan Lücke – trad. Susanne Oberholzer)

Tags: Linguistique Technologie de l'information Contexte extralinguistique



Gestion de versions  (Citer)

VerbaAlpina se compose des modules suivants :

-VA_DB: ensemble des données de la base de données du projet (MySQL) (va_xxx)
-VA_WEB: code de programme de l'interface web du portail www.verba-alpina.gwi.uni-muenchen.de avec la base de données Wordpress (va_wp) correspondante
-VA_MT: fichiers média (photos, films, textes et documents audio) se trouvant dans la médiathèque de l'interface web

Ces trois modules forment un ensemble consistant, avec des connections et dépendances mutuelles ne pouvant par conséquent pas être séparés les uns des autres. Au cours de la durée du projet, les statuts actuels des modules VA_DB et VA_WEB sont "congelés" simultanément sous forme de copies électroniques tous les six mois, le 15 juin et le 15 décembre de chaque année. Ces copies congelées reçoivent un numéro de version selon le schéma [année civile]/[numéro de série] (par ex. 15/1). La version VA actuellement productive reçoit la désignation XXX (voir manière de citer).

La production de copies de la médiathèque VA (VA_MT) est exclue à cause de la dimension énorme des fichiers média. Pour cette raison, on ne produit pas de copie de ce module au cours du processus de gestion de versions. Les éléments une fois déposés ne peuvent plus être enlevés de la médiathèque VA, et ce dès que ne serait-ce qu'une seule version VA leur est associée.

Le portail du projet offre la possibilité d'alterner entre les versions différentes, c'est-à-dire entre la version VA "productrice" qui est soumise à des changements permanents et les versions archivées, "congelées". L'utilisateur peut reconnaître s'il se trouve dans la version productrice ou dans une des versions archivées de VA selon la couleur du fond ou de certains éléments de commande. *Seules* les versions archivées doivent être citées.



Photos de couverture des versions précédentes de VerbaAlpina:

Grange en proximité de Fex Platta, dans la Val Fex à côté de Sils Maria, Haute Engadine (Image: Thomas Krefeld)

Chalet d'alpage sur la Roßsteinalm, au-dessus de Lenggries (Image: Thomas Krefeld)

15/1

Automne dans le Tyrol du Sud en proximité de la val Passiria (Image: Susanne Oberholzer)

15/2

Élaboration du fromage Mascherpa, Lombardie (Image: Formaggio Bitto )

16/1

Alpsee, Immenstadt dans le Allgäu (Image: Christina Mutter)

16/2

Récolte du foin dans le Chiemgau (Image: collection Groth-Schmachtenberger, Freilichtmuseum Glentleiten)

17/1

Récolte du foin (Image: collection Groth-Schmachtenberger, Freilichtmuseum Glentleiten)

17/2

Récolte du foin (Image: collection Groth-Schmachtenberger, Freilichtmuseum Glentleiten)

18/1

Paysage d'hiver sur la Plose au-dessus de Brixen (I)(Image: Stephan Lücke)

18/2

Vue sur les Odle à travers le Seiseralm dans le Tyrol du Sud (Image: Stephan Lücke)

19/1

Alpes de Zillertal (Image: Thomas Krefeld)

19/2



(auct. Stephan Lücke – trad. Susanne Oberholzer)

Tags: Technologie de l'information



Gestion des données de recherche  (Citer)

Depuis l'essor des méthodes numériques, la question du traitement de ce qu'on appelle des «données de recherche» s'impose de plus en plus. Il semble que les idées courantes à ce sujet se sont fondées en fonction des pratiques en sciences naturelles où l'on a souvent affaire à de gros volumes de données de mesure qui, après être soulevées, s'évaluent par le biais de textes interprétatifs. Cette démarche implique une bipartition apparemment nette, ne considèrant comme «données de recherche» que les résultats de mesure bruts. Quoique dans le passé, et sans doute aussi dans le présent, le fait de considérer les donnés brutes comme éphémères et peu dignes d'une conservation durable est assez courant, la gestion des données de recherche s'est fixé comme objectif la représentation ainsi que le stockage et la mise à disposition durables non seulement des textes interprétatifs, mais aussi des données dits «de recherche» formant la base de ces interprétations.

En Allemagne, le domaine de la «gestion des données de recherche» (allem. Forschungsdatenmanagement (FDM)) se voit actuellemnt doter des moyens importants au niveau national ainsi qu'au niveau des länder, quelques projets étant déjà en cours. Les activités en question se poursuivent dans le souci de créer un nuage informatique à l'échelle européenne (European Open Science , EOSC). Des contributions allemandes à citer dans ce contexte au niveau suprarégional et national sont les recommandations relatives à la mise en place d'une infrastructure nationale pour les données de recherche (allem. "Nationale Forschungsdateninfrastruktur" (NFDI)), formulées par le Conseil pour les infrastructures informatiques (allem. "Rat für Informationsinfrastrukturen" http://www.rfii.de (RfII)), le groupe de recherche de l'Union des académies des sciences allemandes NFDI-Arbeitsgruppe der Akademienunion s'y référant (représentant surtout les sciences humaines) ainsi que le projet interdisciplinaire "Generic Research Data Infrastructure" (GeRDI) pris en charge par la Fondation allemande pour la recherche depuis 2016.

Dans le champ des sciences humaines, la séparation nette en apparence entre données de recherche d'un côté et données – ou textes respectivement – interprétatifs de l'autre à l'instar des sciences naturelles (qui en gardent sans doute une certaine utilité) s'avère problématique voire intenable. Pour sa part, VerbaAlpina renonce par principe à une telle distinction, favorisant plutôt la notion d'un ensemble indivisible formé par toutes les données répertoriées au sein du projet dont les unités sont entrelacées pour former un tissage aux relations multiples. En suivant ces principes relatifs au concept de la «gestion des données de recherche», VerbaAlpina déclare l'intégralité des ses données numériques (c'est-à-dire données linguistiques, commentaires, entrées de glossaire, codes numériques, données médiatiques etc.), réparties sur les modules VA_DB, VA_WEB et VA_MT, comme une donnée de recherche à conserver conformément aux principes FAIR et en observant les conseils pertinents du RfII (RfII 2016, annexe A, p. A-13). VerbaAlpina est associé à titre pilote aux projets GeRDI et «eHumanities – interdisziplinär», cités ci-dessus.

L'un des aspects principaux de la gestion des données de recherche constiste à assurer leur interopérabilité par le biais de liens persistants entre les sous-ensembles de données appartenant à des projets ou ensembles de données divers. À cet égard, les DOI («Digital Object Identifier») sont un prérequis technique indispensable assurant que les «objets numériques» soient adressables durablement et indépendamment des URL. On peut générer des DOI pour tout contenu électronique tant qu'il est accesible par URL. Dans les systèmes de gestion des bibliothèques, on s'est servi des DOI dans un premier temps pour créer des identifiants persisants de publications électroniques (p.ex.https://doi.org/10.5282/ubm/epub.25627) ou bien de sites web entiers (p.ex. http://dx.doi.org.emedien.ub.uni-muenchen.de/10.5282/asica). Contrairement à cette pratique, l'interopérabilité d'ensembles de données établis et gérés individuellement exige une granulation beaucoup plus fine. À cet effet, VA génère une série de documents accessibles sur Internet par URL contenant le matériel linguistique collectionné et regroupé selon les catégories suivantes: type morpho-lexical, concept, commune d'origine et attestation. Chacun de ces documents est nommé selon l'ID attribué par VA à la catégorie de données correspondante: les documents appartenant à la catégorie «communauté» portent un «A» comme lettre initiale, «C» marquant les concepts et «L» les types morpho-lexicaux; le chiffre qui suit cette initiale correspond à l'ID attribué par VA. Ces données sont accessibles par l'adresse https://www.verba-alpina.gwi.uni-muenchen.de/fr/export. Les DOI sont d'abord attribués par la bibliothèque universitaire de la LMU dans le cadre du projet «eHumanities – interdisziplinär» et ensuite intégrés dans sa propre structure de stockage où leur contenu sera exploité en profondeur grâce à des procédés encore à développer utilisant des schémas de métadonnées. Outre la mise à disposition des données de recherche dans ce dépôt, il s'agit d'assurer l'intégration et la repérabilité des données finement granulées de VA dans les catalogues de bibliothèques. De plus, les données de VA sont extraites de l'entrepôt de l'UB de la LMU par le projet GeRDI, pris en charge par le DFG, qui les inclut dans son index pour permettre l'exploitation postérieure dans une visée interdisciplinaire.

v. aussi Données d'autorité

(auct. Sonja Kümmet [UB der LMU] | Stephan Lücke | Julian Schulz [ITG] | Florian Zacherl – trad. Sonja Schwedler-Stängl)

Tags: Technologie de l'information



Humanités numériques  (Citer)

Le projet VerbaAlpina a d'emblée été conçu avec la perspective d'un usage web, devant contribuer de manière décisive à faire passer les traditions établies des sciences humaines, plus précisément de la géolinguistique, aux humanités numériques, ang. digital humanities. Ce terme est maintenant établi, cependant ses deux constituants ne sont en aucune façon explicites et méritent chacun un commentaire méthodologique.

(1) numérique possède une multitude d'implications complexes:

  • La base empirique de la recherche se trouve dans les données (cf. Schöch 2013), c.-à-d. des unités digitalement codifiées et structurées ou au moins structurables ; ici il s'agit pour une part de données déjà publiées puis numérisées (comme par ex. les matériaux des atlas les plus anciens), mais en partie aussi de données originales encore à relever. Dans les domaines conceptuels pertinents, on aspire à entrer dans la base une quantité constistante de données. La méthode est donc quantitative et dans une large mesure inductive.
  • La communication scientifique utilise les ressorts médiatiques d'internet. Cela permet tout d'abord de relier par hypertexte différents médias (écriture, image, vidéo, audio) ; de plus, les chercheurs, les partenaires de coopération et/ou les informateurs peuvent communiquer et coopérer les uns avec les autres de façon continue.
  • En procédant de cette façon, cette plate-forme scientifique et collaborative offre aux chercheurs la possibilité de participer activement à son développement. Cette perspective est utile et productive à au moins deux égards : elle permet d'inclure différents lieux de travail et surtout, de combiner constructivement technologie de l'information et géographie linguistique avec ressources publiques, ce sans devoir recourir aux services de sociétés informatiques privées (services d'assistance juridiquement et économiquement problématiques).
  • Le savoir pertinent pour le projet pourra être accumulé et modifié de façon continue sur une longue durée, bien qu'une disponibilité permanente ne puisse pas encore être techniquement garantie (cf. sur ce point l'infrastructure scientifique CLARIN-D , page Web disponible seulement en allemand et en anglais). Sous cet angle, publier les résultats du projet en support matériel (livres, CD, DVD) n'est plus une préoccupation principale. Néanmoins une option, secondaire, d'impression sera installée, option qui est parfois aussi offerte par la lexicographie en ligne, de façon exemplaire par le Tesoro della Lingua Italiana delle Origini.
(2) Derrière le terme humanités se cache une conception bien spécifique de ce domaine de recherche, que le terme désuet de philologie ne peut décrire entièrement. Les domaines de la linguistique étudiant la langue parlée ont déjà dépassé cette tradition basée sur le texte. Ainsi, au regard de VerbaAlpina, le terme de linguistique numérique serait trop étroit car bien que l'accent soit mis sur les données linguistiques, on intègre délibérément des données extra-linguistiques, indispensables à une compréhension historique des rapports géolinguistiques.

(auct. Thomas Krefeld – trad. Julie Defert | Susanne Oberholzer)

Tags: Technologie de l'information



Métadonnées  (Citer)

Le traitement de données oblige à une distinction entre les données primaires et les métadonnées. Les métadonnées sont toutes les données décrivant les données primaires. Au lieu de "métadonnées", on peut utiliser également les deux termes "attributs" ou "caractéristiques", sémantiquement identiques. Au cours de la modélisation des données, on détermine quelles données primaires doivent ou peuvent être décrites par quelles métadonnées. Les métadonnées se décomposent en catégories de métadonnées individuelles. Pour chaque catégorie de métadonnées, on définie les valeurs autorisées.

Ce système peut être décrit à travers un exemple. Les données primaires sont des personnes. Chaque personne est décrite par son nom, prénom, lieu de naissance, date de naissance et couleur des yeux. Les valeurs autorisées peuvent être décrites de la manière suivante:

Nom: séquence de caractères composée de lettres
Prénom: séquence de caractères composée de lettres
Lieu de naissance: séquence de caractères composée de lettres
Couleur des yeux: une valeur de la liste "marron, vert, bleu".

Chaque individu doit être clairement décrit par la somme de toutes les valeurs des différentes catégories de métadonnées. Dans le cas d'une duplicité dans l'ensemble des données (c'est-à-dire deux individus ayant des valeurs complètement identiques dans toutes les catégories de métadonnées), le système de métadonnées doit être considéré comme inadéquat et, par conséquence, modifié.

(auct. Stephan Lücke – trad. Beatrice Colcuc)

Tags: Technologie de l'information



Mise à jour des données pour la visualisation  (Citer)

Afin d'assurer le bon fonctionnement du plan interactif, les tables de la couche d'accès aux données et les tables auxiliaires sont actualisées seulement une fois par jour. Ainsi, toute modification des données langagières et des données supplémentaires ne sera rendue visible sur le plan interactif que le lendemain. Pour une mise à jour immédiate, il est possible d'afficher les routines correspondantes directement dans la base de données à l'aide de requêtes SQL:

données langagières:
CALL zling();

données supplémentaires:
CALL zgeo();

(auct. Florian Zacherl – trad. Julie Defert)

Tags: Technologie de l'information



Modélisation des données  (Citer)

voir Modèle relationnel.

(auct. Stephan Lücke)

Tags: Technologie de l'information



Modules  (Citer)

voir gestion de versions

Tags: Technologie de l'information



Numérisation  (Citer)

Dans le contexte de VerbaAlpina, par numérisation on n'entend pas simplement l'utilisation d'ordinateurs pour le traitement électronique des données, mais surtout et essentiellement l'exploitation numérique en profondeur par la *structuration* et la catégorisation systématiques et transparentes du matériel.



Au sein du projet, c'est presque exclusivement le modèle relationnel qui est utilisé, dans lequel les données sont organisées en forme de tableau. Les tableaux se composent de lignes (= enregistrements, tuples) et de colonnes (= attributs, cases, propriétés); chaque tableau peut être agrandi dans chaque direction en ajoutant des lignes et des colonnes. Entre les tableaux existent des relations logiques, qui permettent des associations cohérentes et les représentations synoptiques correspondantes (dites "joins") de deux ou plusieurs tableaux. Pour la gestion des tableaux, VerbaAlpina utilise actuellement le système de gestion de base de données MySQL. Les tableaux ne sont pas figés par ce système, ils peuvent être exportés à tout moment, par ex. sous forme de texte avec des délimiteurs univoquement définissables pour les limites de case et d'enregistrement (dits séparateurs) avec les noms de colonnes et la documentation des relations logiques (modèle entité-association). La structure XML, souvent employée actuellement, n'est pas utilisée au niveau du plan opérationnel de VerbaAlpin,. Dans le cadre de la conception d'interface pourtant, XML est utilisé comme format d'exportation.

Aux côtés de la structuration logique des données, c'est le codage des caractères qui tient le second rôle principal dans le contexte du mot-clé "numérisation". Ce domaine est de la plus grande importance, en particulier en vue de l'archivage longue durée des données et il doit être géré de manière prévoyante. Autant que possible, VerbaAlpina s'oriente au tableau de codage et selon les prescriptions du Consortium Unicode. Au cas où la numérisation concerne des caractères qui ne sont pas encore intégrés par le tableau Unicode, la saisie digitale de données d'un caractère isolé se fait de préférence en sérialisant le caractère sous forme d'un ordre de caractères du bloc Unicode x21 jusqu'à x7E (à l'intérieur du bloc ASCII). Les affectations correspondantes sont renseignées dans des tableaux spéciaux, une conversion future en valeurs Unicode, lorsqu'elles seront disponibles, reste alors possible.

(auct. Stephan Lücke – trad. Susanne Oberholzer)

Tags: Linguistique Technologie de l'information



Page de code  (Citer)

VerbaAlpina réunit des données issues de différents types de sources : des données d'atlas linguistiques et de dictionnaires imprimés, qui doivent tout d'abord être numérisées, ainsi que des données déjà numérisées, issues de projets partenaires. Chaque source utilise des systèmes de transcription plus ou moins individuels. Pour réaliser l'uniformisation nécessaire, des listes sont établies dans lesquelles il est fixé quel caractère du système de transcription d'une source X correspond à quel autre dans le système de transcription d'une source Y. Il s'agit surtout de retranscrire les différents systèmes de transcription en Alphabet phonétique international (API), qui fait office de transcription de référence dans VerbaAlpina. Pour convertir le système de transcription spécifique à une source en système API, on doit créer une liste complète sous forme de tableau indiquant les correspondances de caractère. Un tel tableau est nommé "page de code". Ci-dessous un extrait de la page de code fondamentale pour la conversion du système de transcription de l'AIS en API. Cette page de code comprend environ 4500 lignes/affectations en tout :


La colonne `BETA` comprend les caractères utilisés dans l'AIS en forme transcrite selon le principe du beta code; la colonne `IPA` le caractère API correspondant, et la colonne `HEX` la valeur ou les valeurs du tableau Unicode qui correspond(ent) au caractère API.

Un aperçu complet des pages de code de toutes les sources de VerbaAlpina se trouve ici.

(auct. Stephan Lücke – trad. Susanne Oberholzer)

Tags: Linguistique Technologie de l'information



Principes FAIR  (Citer)


En 2016, un article rédigé par de nombreux chercheurs de diverses nationalités parut dans la revue scientifique Nature dans le souci de formuler des recommandations pour la gestion des données de recherche (Wilkinson, M. D. et al. The FAIR Guiding Principles for scientific data management and stewardship. Sci. Data 3:160018 doi: 10.1038/sdata.2016.18 (2016). 🔗), Les idées avancées dans cette publication remontent, en effet, à un workshop tenu au Centre Lorentz de l'université de Leyde aux Pays Bas en janvier 2014 ayant comme sujet Jointly designing a data FAIRPORT.

Entretemps, ces idées, condensées dans l'acronyme FAIR, se sont établies comme point de repère dans le débat actuel concernant la gestion des données de recherche (ce qui s'est affirmé p.ex. lors de la rencontre réseaux du projet GeRDI en octobre 2018; cf. aussi FAIRGROUP der FORCE11-Community).

Voici les postulats clés, partiellement corrélatifs, qui se cachent derrière l'acronyme FAIR:

  • F — Findable
  • A — Accessible
  • I — Interoperable
  • R — Reusable

Ces derniers impliquent toute une série de conséquences quand il s'agit de gérer des données de recherche numériques.

Pour assurer la repérabilité des données il faut, en principe, au moins un portail central capable de traiter des demandes de recherche. Pour référencier les données de recherche – avant tout leur contenu ainsi que leur lieu de conservation – il est indiqué d'adopter le système des catalogues de bibliothèques, établies depuis longtemps. A éviter serait toute démarche impliquant des recherches réparties sur plusieurs sites.

Bien évidemment, les données doivent exister physiquement pour être trouvées. Dans ce contexte, c'est moins la question des solutions techniques qui pose problème, grâce p. ex. à la généralisation des centres de calcul en disposant, mais plutôt celle des responsablilités institutionnelles. Ici encore, les bibliothèques s'imposent en fait vu leur histoire, leur mission fondamentale de conserver le savoir et leur perspective de longévité; ce sont elles, il faut le dire, qui devraient, a priori, prendre en charge la conservation durable des données numériques. Dans la réalisation concrète, le choix du lieu d'emmagasinage ne joue qu'un rôle secondaire: soit les bibliothèques mettent en place et gèrent leurs propres bases de données, soit elles ont recours au service des centres de calcul.

L'un des points cruciaux concerne la conception et l'attribution des métadonnées assurant la repérabilité des données de recherche en question. Il semble incontournable d'employer au moins un schéma de métadonnées contraignant et hiérarchisé permettant la catégorisation des données de recherche selon leurs contenus en intégrant des vocabulaires également contraignants et contrôlés. VerbaAlpina a opté, pour l'instant, pour le schéma de Datacite-Schema, largement pratiqué, y compris par la bibliothèque universitaire de la LMU. L'emploi de plusieurs schémas de métadonnées serait possible mais seulement judicieux en les appliquant de façon conséquente à la totalité des données de recherche saisies. Des schémas de métadonnées subordonnés concernant des champs de recherche spécifiques peuvent s'avérer utiles en tant que compléments des schémas supérieurs.

Le terme (anglais) «accessible» se réfère avant tout à la libre accessiblilité des données, notamment sans restrictions légales comme p.ex. par le droit d'auteur. L'accessibilité constitue le facteur le moins contrôlable par ceux qui produisent et rassemblent des données. Dans beaucoup de cas les recueils de données ne sont pas seulement sujets au droit d'auteur mais à ceux de la personnalité. Pour cette raison, l'exigence d'accessibilité vise surtout à une pratique du côté des producteurs de données évitant la mise en place de restricitions individuelles quand il s'agit de données autrement libres de droits. Concrètement, il s'agit surtout de renoncer au copyright et d'appliquer un modèle de licence qui répond aux conditions du libre accès (open acccess). Dans le contexte scientifique on utilise souvent des licences Creative Commons (CC), cependant, toutes ne sont pas conformes aux critères de libre accès, l'interdiction d'exploitation commerciale notamment pouvant faire partie d'une licence CC contrevient au concept du libre accès. Cela s'explique par le fait qu'en principe, presque toute utilisation de données peut être interprètée comme und «exploitation commerciale», d'autant plus qu'il est quasiment impossible d'un point de vue juridique de tracer des délimitatons nettes (v. aussi l'article de méthodologie «Concession d'une licence»).

Tout comme la repérabilité des données, leur intéropérabilité se présente sous deux aspects différents, l'un technique et l'autre théorique et organisationnel. Pour réussir des connexions relationnelles entre données satisfaisantes, il est le plus souvent nécessaire de choisir une granulation logique, suffisamment fine et conforme à des règles, normalement définies au sein d'un champ de recherche donné. Dans ce contexte, les «données normalisés» jouent un rôle primordial: il s'agit de catégories conceptuelles prédéfinies et, idéalement, standardisées dont les instances (objets numériques) se distinguent grâce à des critères qualitativement et quantitativement bien définies, comme quoi elles sont singulières ou (angl.) «distinct». Dotées d'identifiants («IDs») numériques ou alphanumériques, les différentes instances d'une catégorie conceptuelle sont référencées sans ambiguïté. Le fait de granuler des ensembles de données en suivant les délimitations de certaines catégories et de leurs instances en combinaison avec l'application d'identifiants spécifiques permet finalement d'interconnecter ensembles de données isolés et contenus concordants. En revanche, pour obtenir une véritable plus-value il faut qu'il soit techniquement possible de faire référence à des objets de façon directe, afin de permettre de bouger entre des objets de deux ensembles de données différents avec un seul clic, ce qui ne semble réalisable qu'en attribuant son propre URL à tout et chacun de ces objets (cf. «granum»). De plus, pour satisfaire au postulat de durablilité, l'attribution d'un DOI pour chaque URL est indispensable.

La réutilisabilité d'ensembles de données, enfin, résulte du respect et de la mise en œuvre des postulats cités ci-dessus.

Chez VerbaAlpina on cherche à modeler tous les procédés et conventions relatifs au traitement de données en accord avec les principes FAIR. Thomas Krefeld voit dans cette démarche le fondement principal d'une éthique de recherche en humanités numériques (Thomas Krefeld [2018]: Linguistische Theorien im Rahmen der
digital humanities. Korpus im Text. Version 2 (05.11.2018, 11:35). Absatz 4. url: http://www.kit.gwi.uni-muenchen.de/?p=28010&v=2#p:4.). La repérabilité des données est assurée grâce aux collaborations engagées dans le cadre du projet e-humanities – interdisziplinär avec la bibliothèque universitaire de la LMU et le projet GeRDI qui est pris en charge par la Fondation allemande pour la recherche (DFG). De façon prioritaire, on attribue des métadonnées propres à chaque version de l'ensemble de données central du module VA_DB pour les transmettre sous diverses formes à la BU de la LMU qui assure a minima l'archivage dans la base de données Open Data. Par la suite, les métadonnées, tout au moins, sont incorporées dans l'index qui est actuellement mis en place dans le cadre du projet GeRDI. Le but est d'assurer la repérabilité centralisée des données rassemblées et traitées par VerbaAlpina par le biais du catalogue de la bibliothèque de la BU ainsi que du portail de recherche du projet GeRDI, encore en cours de développement. L'intégralité des données gérées par VerbaAlpina sont placées, dans la mesure du possible, sous une licence Creative Commons comprenant le libre accès (jusqu'à la version 18/1 CC BY SA 3.0 de, ab 18/2 CC BY SA 4.0). Quant à l'interopérabilité des données, on y parvient en choisissant un degré de granulation suffisamment fin et conforme au concept des données normalisées grâce au fait que des données normalisées existantes sont reliées aux données fournies par VerbaAlpina, ce qui se réalise par exemple dans le cas des données geógraphiques, se référant, entre autres, aux communes, ces dernières constituant le système de référence central du travail de VerbaAlpina. Dans le cas des catégories de données «type morpho-lexical» ainsi que «concept», primordiales pour VerbaAlpina, il n'existe pas encore de données normalisées auxquelles les données de VerbaAlpina pourraient se référer. VerbaAlpina essaie de créer des (catégories de) données normalisées en collaboration avec des institutions appropriées comme p.ex. la Bibliothèque nationale allemande (DNB). Pour maîtriser les exigences techniques d'une interopérabilité efficace, l'ensemble des données lexicales, d'importance primordiale, est archivé sous forme de paquets de données dans de nombreux fichiers de petite taille pouvant être ciblés par DOI sur Open Data LMU. En plus, chacun de ces fichiers est accompagné d'un fichier contenant des métadonnées en format Datacite ce qui permet de trouver les fichiers individuelles par le biais du catalogue de la bibliothèque.

(auct. Stephan Lücke – trad. Sonja Schwedler-Stängl)

Tags: Technologie de l'information



Représentation quantifiée  (Citer)

[Remarque préliminaire: l’article suivant est lié en partie aux fonctionnalités de VA_WEB qui sont encore actuellement en travaux et qui ne sont pas encore accessibles au public]

La carte interactive de VerbaAlpina permet, à côté d’une cartographie qualitative, également une visualisation de données agrégées dans le sens d’une représentation quantifiable des données dans l’espace. L’agrégation s’oriente toujours à cet égard sur des régions géographiques. L’utilisateur a le choix entre une agrégation sur la base d’une surface communale (petit espace), les soit- disant régions NUTS-3 (espace moyen) et enfin les régions de diffusion des trois grandes familles linguistiques germano-roman-slave (grand espace). En outre, il y a la possibilité de définir à volonté les surfaces communales comme des régions individuelles qui ensuite fonctionnent inversement comme des valeurs de référence de l’agrégation. Une toute dernière option peut agir contre des effets déformants qui résultent dans la perspective d’une agrégation au-delà des surfaces administratives et ainsi dans la perspective de la linguistique des régions communales ou bien des régions NUTS-3. Dans des cas particuliers, cette procédure correspondante peut bien entendu n’être qu’heuristique, l’utilisateur a cependant la possibilité de sauvegarder les cohérences régionales qu’il aura découvertes comme étant éloquentes, de les commenter, de les réutiliser et de les mettre à disposition de la communauté.
En relation avec les régions choisies, respectivement avec les surfaces, l’ensemble des données qualitatives choisies jusqu’à l’activation de la représentation quantitative sont agrégées. Grandeur et rendu des couleurs de chaque symbole cartographique sont corrélés à cet égard avec le nombre des données qualitatives singulières focalisées sur un symbole à chaque fois. La valeur maximale fondée de manière arithmétique, par l’accès duquel un symbole contient toujours une grandeur maximale et un rendu des couleurs, correspond à cet égard de manière standard la quantité la plus grande en matière de données agrégées, qui apparaît dans l’une des surfaces, respectivement des régions choisies. Cette valeur de référence maximale peut être appliquée à souhait sur l’ensemble des données agrégées prise une par une, ce qui conduit à une modification de la représentation cartographique.
Lorsque la fonction quantification est activée, on peut extraire des données quantitatives, par désactivation de chaque entrée dans une liste dans la légende de la carte, les données qualitatives correspondantes ou bien ajouter d’autres données par un autre choix.
A côté de la quantification d’une carte géo-référencée qui reproduit les tracés frontaliers en temps réel, VerbaAlpina permet également la représentation de données quantifiées sur une carte dénommée « en alvéoles ». Son modèle est un dessin Wikipedia qui visualise les résultats des élections britanniques à la Chambre des Communes de 2015. Sur celle-ci, on a d’abord restitué fidèlement la carte en ses points, distances et angles (celle-ci désigne la « carte géographique ») avec les résultats des élections dans chaque circonscription. Au final, on y représente une carte en alvéoles sur laquelle chaque circonscription est figurée par un hexagone de grandeur identique.




Source : https://upload.wikimedia.org/wikipedia/commons/3/3e/2015UKElectionMap.svg (abgerufen am 03.11.2016)




Source : https://upload.wikimedia.org/wikipedia/commons/c/cd/2015_UK_general_election_constituency_map.svg (demandées le 03.11.2016)
La confrontation des deux types de cartes montre leurs avantages et inconvénients respectifs. La carte en alvéoles renvoie à des imprécisions géographiques, respectivement même à des informations erronées. On reconnaît ainsi par exemple dans le district Greater London une alvéole rouge isolée qui se trouve entourée d’alvéoles bleues imposantes – un fait anodin mais qui ne trouve pas de preuve sur la carte géographique. D’un autre côté, la carte en alvéoles possède l’avantage de mieux visualiser les relations réelles entre les chiffres, par chaque couleur, étant donné que, sur la carte géographique, une multitude de toute petites circonscriptions du point de vue de la surface sont perçues par l’observateur comme inférieurs, bien que leur importance politique est mise sur le même plan que celle des grands districts d’un point de vue de la surface. C’est ainsi que les deux types de cartes se complètent et leur véritable plus-value réside dans la possibilité de pouvoir consulter les deux cartes et de confronter leur visualisation.
La carte alvéolaire de VerbaAlpina se distingue du fait qu’elle représente l’ensemble des communes politiques de l’espace alpin par de grands hexagones de taille identique à chaque fois. A cet égard, on cherche, à peu près, à conserver au moins la logique géographique. Le calcul du rendu des couleurs des hexagones pris un par un s’ensuit de la même manière que sur la carte à points. L’avantage d’une telle carte alvéolaire consistant, contrairement à une simple coloration des surfaces communales, en une carte géo-référencée, est que les effets suggestifs sont mis au second plan par rapport aux grandeurs variables des surfaces communales.


(auct. Stephan Lücke – trad. Pierre Herrmann)

Tags: Technologie de l'information Page Web



Structuration des données  (Citer)

voir Modélisation des données

Tags: Technologie de l'information



Technologie  (Citer)

VerbaAlpina utilise autant que possible la technologie en ligne. Le noyau du projet est une installation Wordpress (Modul VA_WEB) à laquelle sont reliées plusieurs base de données MySQL (Modul VA_DB). Wordpress est un framework PHP disponible gratuitement, open source et extensible individuellement, dont les fonctionnalités sont complétées par l'utilisation de bibliothèques Javascript. Cela s'applique surtout au plan interactif en ligne qui, dans les premières versions de VerbaAlpina, utilisait la Javascript-Bibliothek von Google Maps. La conversion vers le framework open source Javascript-Framework "Leaflet", devrait avoir lieu avec la version 19_1, qui sera accompagnée par l'implémentation d'un layer WebGL pour la visualisation de grandes quantités de données.

Toutes les fonctionnalités développées par VerbaAlpina sont implémentées sous forme de plug-ins. Les plug-ins sont ensuite stockés sur "Github", une plateforme bien connue et fermement établie dans la communauté des développeurs (https://github.com/VerbaAlpina/). Ils peuvent être téléchargés et réutilisés librement et sans restriction. L'utilisation des plug-ins est possible grâce à la MIT, largement utilisée dans le domaine du développement de logiciels. La distinction entre les plug-ins PHP et Javascript affichée sur Github est artificielle et a été automatiquement saisie par la même plateforme. La plupart des plugins développés par VerbaAlpina contiennent toujours certaines parties de code Javascript en plus du code PHP. Actuellement (novembre 2018) les plugins "TranscriptionTool-Plugin", "Interactive-Map_Plugin", "Verba-Alpina-Plugin" sont disponibles sur la page Github de VerbaAlpina. De plus, le "Thème Verba-Alpina", design utilisé pour le frontal, peut y être téléchargé. VerbaAlpina a prévu de proposer d'autres extensions fonctionnelles sous forme de plug-ins à télécharger sur Github.

Liste des principales extensions fonctionnelles développées par VerbaAlpina jusqu'à présent:
  • Plan interactif en ligne (visualisation multicouche des analyse de données)
  • Outil de transcription (surtout pour la transcription des atlas linguistiques)
  • Outil de typisation (catégorisation du matériel relevé et affectation aux types)
  • Arbre conceptuel (gestion de la structure hiérarchique du monde conceptuel extra-linguistique)
  • CS-Tool ("Crowdsourcing"-Tool; collecte de matériel linguistique via Internet pour compléter les données)
  • SQLtoHTML (intégration directe des résultats des requêtes SQL dans les contributions Wordpress)

A côté de ces outils complexes, qui peuvent être utiles pour les utilisateurs aussi en dehors de VerbaAlpina, plusieurs fonctionnalités ont été développées, dont la transformation en plug-ins modulaires ne semble pas pertinente, car elles apparaissent soit trop petites soit trop spécifiquement adaptées aux besoins de VerbaAlpina. Cependant, cette catégorie de développements est également accessible, d'autant plus que le code complet du logiciel de VerbaAlpina est stocké sur Github en plus des plug-ins ci-dessus.

Le back-end connecté à Wordpress est constitué de plusieurs bases de données MySQL. La base de données va_wp est basée sur le modèle standard d'une base de données MySQL, couramment utilisée comme back-end pour les installations Wordpress. A travers cette base de données, on gère principalement les fonctionnalités "génériques" d'une installation Wordpress comme par exemple la gestion des utilisateurs. La base de données scientifique centrale de VerbaAlpina telle que les transcriptions (tableau 'tokens'), typisations au sens large (tableau 'morph_typen', 'basistypen', 'etyma' et 'lemmata'), concepts ('konzepte'), contributions méthodologiques ('glossar') et du Lexikon Alpinum ('im_comments') ou la bibliographie ('bibliographie') se trouve dans la base de données va_xxx. Le suffixe "xxx" indique les différentes versions de VerbaAlpina, dont la base de données est soumise à des modifications constantes en cours de fonctionnement. Lors de la création d'une version de VerbaAlpina, une copie stable de cette base de données est créée. Le nom de cette copie stable sera composé par "va_" et le suffixe contiendra le numéro de version (par exemple: va_181). De plus, il existe une base de données MySQL pour différents partenaires de VerbaAlpina. Les noms de ces bases de données portent le préfixe "pva_" (=Partenaires de VerbaAlpina) suivi d'une abréviation du projet partenaire (par exemple: pva_ald-i).

Les fichiers multimédia (images, vidéos, enregistrement sonores) collectés par VerbaAlpina dans la médiathèque (Modul VA_MT) de l'installation Wordpress sont stockés dans le système de fichiers du serveur web, comme de coutume pour les installations Wordpress.

Toutes les instances technologiques de VerbaAlpina, à savoir l'installation Wordpress ainsi que les bases de données, utilisent l'infrastructure informatique du groupe de la technologie de l'information des sciences humaines de la LMU. Cette institution dispose d'un système de gestion informatique professionnel avec des serveurs web et de bases de données à haute disponibilité et utilise également les services du centre informatique de l'académie bavaroise. Avec un total de sept postes permanents, le stock actuel du groupe est assuré à long terme. Une partie du personnel se consacre exclusivement à l'exploitation, à la maintenance et à l'entretien du matériel et des logiciels du serveur.

Tous les développements de logiciels ont été réalisés par les informaticiens David Englmeier (collaborateur scientifique; depuis octobre 2016), Filip Hristov (assistant; depuis septembre 2016) et Florian Zacherl (collaborateur scientifique; depuis octobre 2014).

(auct. Stephan Lücke – trad. Beatrice Colcuc)

Tags: Technologie de l'information



Terminologie  (Citer)

On fait souvent une distinction entre les données brutes, les données primaires et les métadonnées. Il n'existe pas encore de définition contraignante de ces catégories.

Données brutes: données après l'adoption à partir de la "source" (par exemple à partir des données des partenaires, par OCR à partir de dictionnaires, par transcription...)

VA est basé sur le modèle Stuart Card (infovis-reference-model; modèle de référence pour la visualisation).

Une distinction est faite entre les données brutes et les données primaires. Les données brutes sont toutes les données sous leur forme d'avant leur transfert électronique dans la structure de VA. Ceci s'applique également dans le cas où les données à transférer sont déjà disponibles dans la structure de VA, puisque l'interaction humaine est également nécessaire pour le transfert de données dans ce cas (par exemple, pour déterminer *que* la structure est identique).

Les données primaires sont toutes les données qui peuvent être récupérées via l'API avec le paramètre "getRecord" (exemple: https://www.verba-alpina.gwi.uni-muenchen.de/?api=1&action=getRecord&id=C1&version=182&format=xml&empty=0; pas encore complètement implémenté). Une distinction est faite entre les données primaires de base (= données linguistiques) et les données primaires périphériques (périphérie linguistique comme par exemple les données archéologiques).

Les métadonnées sont l'ensemble des données décrivant les données primaires (par exemple, les données administratives décrivant l'ensemble du projet, tous les textes explicatifs, commedans la méthodologie [qui met en évidence différents aspects du projet global] ou le Lexikon Alpinum).

Les données secondaires sont toutes les données utilisées pour traiter toutes les autres données (code, requêtes, etc....).

(auct. David Englmeier | Filip Hristov | Thomas Krefeld | Stephan Lücke | Christina Mutter | Florian Zacherl – trad. Beatrice Colcuc)

Tags: Technologie de l'information



Transcription  (Citer)

Les matériaux linguistiques sont rendus graphiquement de manière double afin de satisfaire les deux principes contraires de la fidélité à la source et de la comparabilité facile:

(1) Version d'entrée dans la transcription originale

Le portail de VerbaAlpina réunit des sources qui proviennent de traditions scientifiques différentes (philologie romane, allemande et slave) et qui représentent différentes phases historiques de la recherche dialectologique. Certains données lexicographiques ont été relevées au début du siècle dernier (GPSR) et d'autres il y a peu d'années (ALD) seulement. Pour cette raison, il est nécessaire du point de vue historique et épistémologique de respecter la transcription originale à quelques détails près. Pour des raisons techniques, il est pourtant impossible de maintenir intégralement certaines conventions; cela concerne en particulier les combinaisons verticales de caractère de base ('lettre') et signes diacritiques comme par exemple la superposition typographique d'un diacritique pour l'accent, d'un diacritique pour la durée, d'une voyelle et d'un diacritique pour la fermeture. Ces conventions sont transférées dans des séries linéaires de signes selon des transcriptions techniques définies pour chaque convention en utilisant exclusivement des caractères ASCII ("Beta code"). Jusqu'à un certain point, on peut profiter des ressemblances graphiques intuitivement compréhensibles entre les diacritiques originaux et les pendants ASCII choisis pour l'encodage beta; ces ressemblances sont mnémoniquement favorables.

(2) Version de sortie en API

Pour satisfaire la comparabilité et aussi le confort, il est souhaitable de rendre toutes les données dans une transcription uniforme. C'est pourquoi tous les beta codes seront transférés dans des caractères API au moyen de routines de remplacement spécifiques. On n'est confronté qu'à peu de problèmes, qui pourtant sont inévitables : par exemple si un caractère de base spécifié par des diacritiques dans la transcription d'entrée correspond à deux caractères de base différentes en API. Cela concerne surtout les degrés d'aperture des voyelles où par ex. deux caractères de base <i> e <e> combinés avec un point de fermeture et un ou deux crochets d'aperture permettent de représenter six degrés d'aperture dans la série palatale; dans l'encodage beta ce sont les suivants: i – i( – i((– e?-- e – e(– e((. Pour représenter cela, API n'offre que quatre caractères de base: i – ɪ – e – ɛ.

(auct. Thomas Krefeld – trad. Susanne Oberholzer)

Tags: Linguistique Technologie de l'information



Uniform Resource Name (URN)  (Citer)

voir Digital Object Identifier

Tags: Technologie de l'information



Wikidata  (Citer)

Wikidata est une base de connaissances libre servant à gérer et mettre à disposition les données d'autres projets Wikimédia (Wikipédia, Wikivoyage, Wikisource) dans une sorte de mémoire centrale. Grâce à leur mise à disposition sous une licence libre (Creative Commons Public Domain Dedication 1.0), les données Wikidata peuvent être rédigées, utilisées et consultées dans jusqu'à 111 langues. À la différence de Wikipédia on n'y trouve pas des articles entiers, mais une nomenclature de concepts dont chacun correspond à un identifiant Q unique (Q-ID). Le concept LACTOSÉRUM, par exemple, est lié à l'identifiant Q 185009 (cf. Wikidata). Même si la pérennité du catalogue Wikidata n'est garantie dans le sens strict, dans une visée linguistique ce dernier constitue en effet la base pour un référentiel onomasiologique particulièrement utile.

VerbaAlpina attribue à ses concepts les identifiants correspondants enregistrés par Wikidata, ces derniers jouant un rôle clé notamment pour la collaboration avec le projet GeRDI. GeRDI peut alors recourir à Wikidata comme base de connaissances (knowledge base) dans le but de faciliter des recherches multilingues et interdisciplinaires; la recherche d'un mot clé italien, par exemple, fournira donc aussi des résultats disponibles en d'autres langues.

Des concepts encore inexistants sur Wikidata y sont ajoutés par VerbaAlpina au fur et à mesure. À ce titre, un compte d'utilisateur Wikidata lié au projet VerbaAlpina a été créé. La langue standard étant l'anglais on peut cependant saisir l'équivalent d'un concept donné dans toutes les langues disponibles sur Wikidata.

(auct. Christina Mutter – trad. Sonja Schwedler-Stängl)

Tags: Technologie de l'information