Méthodologie

Tri

Montrer toutes les contributions

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


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 est basé est en fin de compte pourtant 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 respectivement 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és4. Sur quel type de support d'information sont conservées les données?ad 1) Plusieurs copies des données du projet devront être archivées chez plusieurs institutions différentes. 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) è prévu pour ce devoir. Ce groupe è lié aux serveurs d'archivage du Leibniz-Rechenzentrum ainsi qu'au BAS Clarin Repository. La mise en dépôt de copies de sûreté supplémentaires chez d'autres institutions qui y sont 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 inclus la respective fonctionnalité) de telle façon qu'il est possible (au moins théoriquement) 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 désigné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ée 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é, la coche sous le u dans le mot tu est rendue par une parenthèse ouvrante: tu(. 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 contenues sont soumis aux licences Creative Commens 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) respectivement




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").

Quelques-uns des fichiers média du module VA_MT que VA ha reçus ou achetés peuvent aussi être soumis au copyright. Les objets dans le module VA_MT sont marqués chaque fois par 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 dé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 dans le tableau KONZEPTE (concepts) de la base de données comme suit : au cas où une dénomination lexicalisée existe pour un concept, cette dénomination vient inscrit dans la case de la base de données 'Name_F' (dénomination française). Quand la lexicalisation manque, la case reste blanche. Indépendamment de l'existence d'une dénomination, le concept est spécifié ou bien défini dans la case 'Beschreibung_F' (description française). Cela se fait en suivant une manière de procéder fixée qui est démontré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, c’est pourquoi on inscrit ÉCRÉMOIR dans 'Name_F'. La description prévoit l'ordre hiérarchique suivant: ustensile, fonction, matériau, forme (éventuellement). Appliqué au concept de l'exemple, il en résulte la description suivante: USTENSILE, POUR ÉCRÉMER, LOUCHE. Si possible respectivement nécessaire on devrait 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 respectivement des modifications 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 consiste 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



Entité-association (Citer)

De principe, des données peuvent être réunies dans des groupes appelés "entités". Il s'agit de classes de données qui présentent une certaine nature et un certain nombre de caractéristiques spécifiques. Comme ça, les villes de Trento, d'Innsbruck et de Lucerne peuvent former une classe "lieux" à laquelle appartiennent les caractéristiques "nom de lieu", "degré de longitude", "degré de latitude", "Etat" e "nombre d'habitants". Les membres individuels d'une classe pareille diffèrent par les valeurs différentes des caractéristiques qui forment cette classe.Dans une base de données relationnelle chaque entité est sauvegardée dans un tableau particulier. Les colonnes de ces tableaux comprennent les valeurs d'une caractéristique spécifique. Les lignes comprennent les membres individuels d'une classe de données (entité), ces membres se distinguent par les valeurs de la caractéristique. Dans presque tous les cas – aussi chez VerbaAlpina – une base de données relationnelle représente une collection d'entités différentes (et par conséquent de tableaux) entres lesquelles il y a des relations logiques. Ainsi, l'entité "informateur" qui est définie par les caractéristiques "âge", "sexe", "lieu de naissance" et "domicile" est liée logiquement à l'entité "lieux" de telle manière que les valeurs des caractéristiques "lieu de naissance" et "domicile" ont des points communs dans l'entité "lieux". Les relations entre les membres de ces deux entités résultent des correspondances des valeurs d'une ou de plusieurs caractéristiques (essentiellement congruentes) de l'entité correspondante. Dans ce cas, il pourrait en résulter théoriquement une affectation entre des valeurs identiques des caractéristiques "lieu de naissance" et "nom de lieu" par laquelle on pourrait affecter indirectement à l'informateur les coordonnées géographiques de son lieu de naissance. Il est évident que dans cet exemple on peut être confronté à des problèmes dus à des homonymes. Pour éviter des problèmes de ce genre, il est habituel d'utiliser des entiers relatifs comme identifiants (abréviation: "ID") qui définissent de façon univoque les membres d'une entité. Le système qui décrit des 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 une explication des dépendances qui y existent. 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). On ajoute à chaque version archivée de VerbaAlpina le modèle entité-association de la version de la base de données qui y forme la base sous la forme d'un diagramme ER, qui est généré avec le programme yEd et enregistré sous GraphML. Les diagrammes créés à l'aide d'outils automatiques ne sont pas ensuite édités graphiquement en raison de la charge de travail considérable qu'ils impliquent. Pour cette raison, et en raison de la grande complexité des structures représentées, elles ne sont généralement pas immédiatement compréhensibles pour des personnes extérieures. Cependant, ils contiennent 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 compris 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 en employant 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. Au cas des données linguistiques des atlas et des dictionnaires, c'est seulement un référencement approximatif conformément à un toponyme qui est possbile en règle générale. Au cas de données archéologiques par contre, des géoréférencements au mètre près sont possibles. On peut sauvegarder des points, des lignes (commes 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 sauvegardé ainsi. La sortie au format WKT se produit par la fonction MySQL astext().
La grille de référence du géoréférencement est le réseau des communes dans 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 du 2014 que VerbaAlpina a reçus de son partenaire "Conférence Alpine" en forment la base. Une actualisation permanente de ces données qui changent tout à fait plus souvent à cause des réformes administratives pas rares est superflue car il s'agit seulement d'un cadre de référence géographique dans la perspective de VerbaAlpina. Une représentation de la grille des communes est déduite de façon algorithmique des frontières de commune et est donc secondaire.



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

Tags: Linguistique Technologie de l'information Contexte extralinguistique



Gestion de versions (Citer)

VerbaAlpina consiste des modules suivants :

-VA_DB: ensemble des données dans 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) qui se trouvent dans la médiathèque de l'interface web

Tous les trois modules forment un ensemble consistant avec des connections et dépendances mutuelles et par conséquent ils ne peuvent pas être séparés l'un de l'autre. Pendant la durée du projet le statut actuel des modules VA_DB et VA_WEB est simultanément "congelé" tous les six mois, le 15 juin et le 15 décembre de chaque année, sous forme de copies électroniques. 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 actuelle et productrice 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 de fichiers média. Pour cette raison, on ne produit pas de copie de ce module au cours du processus de gestion de versions. Des éléments qui y ont été déposés une fois ne peuvent plus être enlevés de la médiathèque VA dès qu'une seule version VA y est associée.

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



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

15/1

15/2

16/1

16/2

17/1

17/2

18/1



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

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



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 ne comprend pas l'emploi simple d'ordinateurs pour le traitement électronique des données, mais essentiellement l'exploitation digitale en profondeur par la *structuration* et la catégorisation systématiques et transparentes.



Dans le projet, on utilise presque esclusivement le modèle relationnel dans lequel les données sont organisées strictement en forme de tableau. Les tableaux se composent de lignes (= enregistrements, tuple) et de colonnes (= attributs, cases, propriétés); chaque tableau peut être élargi dans chaque direction en ajoutant des lignes et des colonnes. Entre les tableaux, il y a des relations logiques qui permettent des associations sensées et des 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 pourtant pas liés à ce système, mais peuvent être exportés à tout moment, par ex. en 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 colonne et la documentation des relations logiques (modèle entité-association). Sur le plan opérationnel de VerbaAlpina, on ne se sert pas de la structure XML qui est actuellement souvent utilisée dans d'autres domaines. Dans le cadre de la conception d'interface, XML est pourtant compris comme format d'exportation.

Au-delà de la structuration logique des données, c'est le codage des caractères qui joue un rôle important dans le contexte du mot-clé "numérisation". Ce domaine est de la plus grande importance juste en vue de l'archivage de longue durée des données et doit être géré de manière prévoyante. Autant que possible, VerbaAlpina s'oriente au tableau de codage et aux prescriptions du Consortium Unicode dans ce contexte. Au cas où la numérisation concerne des caractères qui ne sont pas encore accueillis dans 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 en forme d'un ordre de caractères du bloc Unicode x21 jusqu'à x7E (à l'intérieur du bloc ASCII). Les affectations correspondantes sont témoignées dans des tableaux spéciaux par quoi une future conversion dans des valeurs Unicode qui seront possiblement existantes à ce moment-là sera toujours 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



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 accessible au public actuellement.

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



Technologie (Citer)

Dans la mesure du possible, VerbaAlpina utilise 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 restrictions de la plateforme. L'utilisation des plug-ins est possible grâce à la MIT qui est 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 être téléchargé à partir de là. 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 aussi pour les utilisateurs en dehors de VerbaAlpina, plusieurs fonctionnalités ont été développées, dont la transformation en plug-ins modulaires ne semble pas logique, 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 il est de coutume pour les installation 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).

En conséquence, une distinction est faite entre les données brutes et les données primaires. Les données brutes sont toutes les données sous la forme existante avant le transfert électronique des données 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 définies comme 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, par exemple dans 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 pour satisfaire aux 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 scientiques différentes (philologie romane, allemande et slave) et qui représentent différentes phases historiques de la recherche dialectologique. Quelques 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. Par des raisons techniques, il est pourtant impossible de maintenir certaines conventions intégralement; cela est regarde en particulier les combinaisons verticales de caractère de base ('lettre') et signes diacritiques comme par exemple la superposition typographqiue d'un diacritique pour l'accent, d'un diacritque 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 chosis pour l'encodage beta; ces ressemblances sont mnémoniquement favorables.

(2) Version de sortie en API

Pour satisfaire à la comparabilité et aussi à la convivialité, il est en plus souhaitable de rendre toutes les données également 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: c'est le cas 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