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é le concept correspondant au début des années soixante-dix pour la saisie électronique de textes en grec ancien avec des moyens de technique informatique d'alors, la transcription de systèmes d'écriture complexes à l'aide exclusif de caractères ASCII est désigné "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):





Tout d'abord, on distingue les caractères de bases des diacritiques lors de la transmission de la transcription phonétique utilisée dans l'atlas linguistique selon Böhmer-Ascoli dans des séquences composées par des caractères ASCII. Si un caractère de base est présent dans le code ASCII, ce caractère est représenté par lui-même lors de la transmission (ce qui est entièrement le cas dans l'exemple présenté). 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 spécial. L'affectation des diacritiques à des caractères ASCII est claire dans VerbaAlpina et elle est documentée dans des tableaux de la base de données VerbaAlpina. Le choix de l'affectation est guidé par le principe de la ressemblance optique autant que possible. Ainsi dans l'exemple mentionné, la coche sous l'u dans la parole tu est rendue par une parenthèse ouvrante: tu(. Les diacritiques sont écrits en partant des leur disposition près le caractère de base dans l'ordre 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.: 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 est rendue malgré tout en les deux cas par une parenthèse fermante. Les différences sémantiques sont documentées dans des tableaux de transcription spécifiques pour chaque source: ceux-ci règlent la conversion du beta code à la transcription d'output selon API, c.-à-d.: le même beta codage peut conduire à des codages API entièrement différents suivant la source.
Le procédé décrit a un nombre d'avantages:
- la saisie des données peut être fait 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 connaissances de systèmes de transcription phonétique;
- n'importe quel caractère respectivement diacritique peut être saisi, indépendamment s'il est codé dans Unicode ou pas;
- la saisie des données électronique se fait sans perte d'information.
Le beta code peut être converti en presque n'importe quel autre système de transcription par des routines de remplacement. Dans le cadre de telles conversions, des pertes d'information peuvent se passer éventuellement; celles-ci sont pourtant crées par l'essence 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



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



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 spécifique caractéristique. 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. Comme ça, 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 en pourrait 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 à 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 décrit des entités et de leur 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 en 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 en forme de graphique en format JPG.

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

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.



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

Tags: Technologie de l'information



Humanités numériques  (Citer)

Le projet VerbaAlpina était destiné d'emblée à être implémenté par les navigateurs web car il veut contribuer de manière décisive au transfert des traditions établies des sciences humaines, plus précisément de la géolinguistique, aux humanités numériques, eng. digital humanities. Bien que ce terme soit maintenant établi, 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 consiste en données (cf. Schöch 2013), c.-à-d. en unités digitalement codifiées et structurées ou au moins structurables ; il s'agit de données en partie déjà publiées et numérisées beaucoup plus tard, dans le cadre de ce projet même (comme par ex. les matériaux des atlas plus vieux), mais en partie aussi de données originales à relever encore. Dans les domaines conceptuels pertinents on aspire à bancariser une quantité de donnée consistante. La méthode est donc quantitative et largement inductive.
  • La communication scientifique se sert des conditions médiatiques de l'internet. Cela offre tout d'abord la possibilité de tresser hypertextuellement des média différents (é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'engager des sièges différentes et surtout de promouvoir la combinaison constructive de technologie de l'information et géographie linguistique avec des ressources publiques sans devoir recourir au service d'assistance de sociétés d'informatique privées (service d'assistance qui peut créer des problèmes juridiques et économiques).
  • Le savoir qui est pertinent pour le projet pourra être accumulé et modifié de façon continue pendant longtemps bien que la garantie d'une disponibilité permanente ne puisse pas encore être offerte du point de vue technique (cf. sur ce point l'infrastructure scientifique CLARIN-D , page Web disponible seulement en allemand et en anglais). Sous cet angle, ce n'est plus une requête principale de publier les résultats du projet en forme de support d'information matériel (livres, CD, DVD). Néanmoins une option secondaire d'imprimer sera installée, une option qui est offerte parfois aussi par la lexicographie en ligne, comme le fait le Tesoro della Lingua Italiana delle Origini de façon exemplaire.
(2) Derrière le terme humanités se cache une conception bien spécifique de ce domaine de recherche qu'on ne peut entièrement décrire avec le terme désuet de la philologie. Les domaines de la linguistique qui étudient la langue parlée ont déjà dépassé cette tradition basée sur le texte. Ainsi, au regard de VerbaAlpina, le terme d'humanités numériques est 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 qui sont 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.

Tags: Linguistique Technologie de l'information



Modules  (Citer)

voir gestion de versions

Tags: Technologie de l'information



Page de code  (Citer)

VerbaAlpina réunit des données de différents genres de sources: des données d'atlas linguistiques et de dictionnaires imprimés qui doivent tout d'abord être numérisés aussi que des données qui existent déjà en forme électronique d'un nombre de projets partenaire. Chaque de ces sources différentes utilise des systèmes plus ou moins individuelles pour la transcription. Pour réaliser l'uniformisation nécessaire on a besoin de listes dans lesquelles est fixé quel caractère dans le système de transcription d'une source a quelle correspondance dans le système de transcription d'une autre source. Il s'agit surtout de représenter les systèmes de transcription différents sur l'Alphabet phonétique international (API) qui fait office de transcription de référence dans VerbaAlpina. Pour transférer le système de transcription spécifique à une source au système API on doit créer une liste complète en forme de tableau avec les correspondances de caractère. Un tableau pareil est nommé "page de code". Ci-après un extrait de la page de code qui est fondamental pour la conversion du système de transcription de l'AIS à l'API. En tout, cette page de code comprend en gros 4500 lignes/affectations:


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.

(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



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