Piccola guida per sviluppare strumenti terminologici

Il presente articolo nasce da una serie di riflessioni e considerazioni sorte durante la ristrutturazione del Sistema informativo per la terminologia giuridica – bistro (<http://bistro.eurac.edu>). Si tratta di un applicativo online su cui vengono caricati i dati provenienti da una banca dati terminologica multilingue operante su SDL MultiTerm. Il vecchio sistema, risalente al 2001 e basato su un linguaggio e una tecnologia ormai superati, era diventato con il tempo difficile da gestire in termini di aggiornamento, manutenzione, filtraggio dei dati, fruibilità e visualizzazione delle informazioni. A ciò si aggiungevano un modulo di ricerca abbastanza limitato e una consultazione non intuitiva. Inoltre, risalendo le prime schede terminologiche al 1994 e date le limitazioni dei sistemi di gestione terminologica di quegli anni1, il patrimonio terminologico esistente2 non risultava omogeneo, soprattutto a livello delle picklist e delle categorie, conteneva doppioni ed era presente una certa ridondanza.

Si era perciò reso necessario pensare ad un nuovo sistema che fosse in grado di rispondere alle diverse esigenze degli utenti. Questi comprendono sia i collaboratori dell’Istituto di linguistica applicata di Eurac Research (es. aggiornamento dei dati più agevole) sia gli utenti esterni, siano essi professionisti del mondo del diritto, traduttori, studenti o altre persone che necessitano di un valido supporto alla comprensione e traduzione di testi e documenti giuridici.

La check-list, oggetto del presente contributo, è frutto dell’intenso lavoro svolto durante i tre anni di progettazione e riprogrammazione del nuovo bistro. È pensata come punto di partenza e riflessione per l’ideazione e strutturazione di prodotti terminologici, quali strumenti di «organizzazione e trasmissione di conoscenze specialistiche» (Agrario, Castagnoli 2010, 121). L’obiettivo è fornire un aiuto per individuare il fabbisogno e, al contempo, meglio comprendere le scelte di fondo che è opportuno compiere già in fase di pianificazione.

Che si disponga o meno di dati terminologici, è fondamentale avere piena coscienza dello strumento che si vuole sviluppare. Non sono pochi i casi in cui vengono commessi degli errori già durante la sua concezione, tali da richiedere, in un secondo tempo, delle modifiche importanti, comportando non solo una perdita di tempo, ma spesso anche un aumento dei costi. In questo senso un’analisi ponderata di elementi primari, quali, ad esempio, fabbisogno, destinatari, livelli di qualità, requisiti tecnici, caratteristiche delle singole funzioni, possibili criticità, può agevolare un inserimento corretto e strutturato dei dati e, conseguentemente, favorire un utilizzo efficace ed efficiente del prodotto da parte degli utenti.

Il livello di qualità che si vuole dare all’informazione terminologica e alla sua trasmissione può, infatti, essere valorizzato da una struttura ragionata, funzionale e flessibile. Un lavoro completo e valido può invece essere sminuito da una struttura rigida e vincolante (Agrario, Castagnoli 2010, 138).

Realizzare strumenti terminologici richiede innanzitutto una profonda conoscenza della disciplina e delle pratiche terminologiche. In questo senso le norme ISO ci vengono in soccorso. Ad esempio, la ISO 1087 definisce il vocabolario fondamentale per la teoria e la pratica dell’attività terminologica, mentre la ISO 704 stabilisce principi e metodi del lavoro terminologico.

I prodotti terminologici, nello specifico le banche dati terminologiche, presentano una struttura logica che si compone di più livelli su cui vengono posizionate le categorie terminologiche. Questi livelli sono descritti nelle norme ISO 26162-1 e ISO 30042:

L’informazione terminologica viene dunque trattata all’interno di specifiche categorie. La loro tipologia dipende essenzialmente dal tipo di utenza, dal dominio di indagine e dalle finalità del lavoro. A prescindere dal tipo di categoria, se testuale o attributiva, è fondamentale attenersi ai principi di elementarità e granularità (ISO 26162-1; Pulitano 2010; Drewer, Schmitz 2017, 126; Ralli, Andreatta 2018, 31). In base al primo, le categorie terminologiche possono contenere un solo tipo di informazione. Ad esempio, in una banca dati giuridica, che comprende informazioni su più ordinamenti giuridici, il campo destinato a contenere definizioni pertinenti all’ordinamento giuridico italiano non dovrebbe contenere definizioni relative ad altri ordinamenti contemplati dalla banca dati. In base invece al secondo principio, ogni categoria deve essere definita con il maggior dettaglio possibile. Al riguardo la ISO 26162-1 cita come esempio le informazioni grammaticali, secondo cui i valori relativi al genere e al numero dovrebbero confluire in due categorie separate.

Altro elemento di cui, infine, tenere conto è l’autonomia delle denominazioni: tutti i termini, che si riferiscono allo stesso concetto (quindi sinonimi e varianti), sono considerati sotto-unità e, pertanto, possono essere descritti con lo stesso set di categorie terminologiche utilizzato per la descrizione del termine principale (ISO 26162-1).

La check-list si pone come un insieme di criteri pensati come punto di partenza e riflessione per l’ideazione e strutturazione di strumenti terminologici, siano essi banche dati o applicativi su cui vengono caricati dati provenienti da sistemi di gestione terminologica.

Si compone di cinque parti: la prima è di carattere generale; la seconda è dedicata ai dati, cioè l’informazione terminologica, e alla loro tipologia che riveste un ruolo particolarmente importante; la terza parte è focalizzata sulle lingue di lavoro, mentre la quarta verte sulle fonti bibliografiche; la quinta parte si conclude con delle considerazioni sulla messa online dello strumento e sulla relativa gestione e manutenzione.

La prima parte, di carattere generale, è volta ad individuare importanti punti di base che influiscono sostanzialmente, ad esempio, sullo sviluppo dello strumento, sulla struttura, ecc. In questa fase ci si concentra sulla destinazione della risorsa terminologica, il gruppo di utenza, gli obiettivi, le funzioni e i domini.

In riferimento alla destinazione dello strumento terminologico è fondamentale stabilire se è per uso interno o esterno o entrambi, quindi sia per uso interno che esterno.

Per quanto riguarda il gruppo di utenza, è importante precisare se si tratta, ad esempio, di esperti del settore, traduttori, redattori, studenti o di utenti non esperti. La loro tipologia condiziona profondamente quali informazioni trattare e come presentarle. È pertanto opportuno chiedersi, per esempio, quali categorie terminologiche prevedere in base al tipo di utenza. È inoltre di notevole rilevanza definire se si tratta di un gruppo di utenti rientranti in una stessa categoria o in categorie differenti. È pertanto necessario stabilire se lo strumento si rivolgerà a un pubblico abbastanza omogeneo o, invece, piuttosto eterogeneo. Nel caso in cui il prodotto fosse destinato a un’utenza diversificata, si profilano due possibilità:

In questa prima fase è inoltre fondamentale stabilire gli obiettivi e la funzione dello strumento. Occorre, per esempio, considerare se lo strumento è concepito per agevolare la comunicazione transfrontaliera, la comunicazione entro i confini nazionali, la comunicazione all’interno di una organizzazione o impresa e/o se è ideato per supportare la comunicazione, la traduzione o la redazione in generale. Si tenga presente che si possono avere diversi obiettivi per uno stesso strumento e che tutte queste ipotesi possono far riferimento ad una o più lingue.

In merito alla funzione è opportuno chiedersi se lo strumento è pensato, ad esempio, per favorire la comprensione dei concetti e dei testi e/o fornire un aiuto per la produzione di testi nella madrelingua o nella lingua straniera o la traduzione in una direzione linguistica o nell’altra (Bergenholtz, Tarp 2010, 31).

Importante è, infine, il dominio. Alcuni settori hanno esigenze particolari, come ad esempio il diritto, in cui il linguaggio giuridico è fortemente legato all’ordinamento giuridico che lo ha prodotto, o settori tecnici dove non è da escludere la presenza di formule.

La seconda parte della check-list è dedicata all’informazione terminologica e alla tipologia dei dati. In questo contesto la prima domanda da porsi è senz’altro se lo strumento viene ‘riempito’ ex novo o se è già presente un data set che dovrà essere integrato completamente o solo in parte nel nuovo strumento.

Se non si dispone ancora di una base di dati, si profilano due considerazioni. Da un lato, la situazione può ritenersi semplice, in quanto non si è necessariamente vincolati a decisioni prese in precedenza e si può, quindi, definire tutto sin da principio. Dall’altro, la situazione può palesarsi più delicata. Potrebbe infatti risultare necessario prendere decisioni nuove senza talvolta conoscere tutte le specificità delle informazioni e delle eventuali criticità a cui si dovrebbe far fronte e che, in presenza di un data set esistente, si sono invece già affrontate e di cui, quindi, si può tenere conto in questi ragionamenti iniziali.

La parte della check-list relativa ai dati comprende, ad esempio, delle considerazioni sulla loro gestione ed eventuale scambio, sull’approccio da adottare per la presentazione delle informazioni e sulla loro tipologia.

In merito alla gestione è da ponderare se il nuovo strumento sarà gestito a livello centrale o locale. Pensare a quale metodo adottare ha l’obiettivo di esplorare se sarà seguito un approccio onomasiologico o semasiologico, se sarà orientato alla traduzione o meno o se, invece, sarà necessario applicare più approcci.

Altre domande da porsi riguardano quindi quali informazioni accogliere e quali presentare all’utente: solo termini (eventualmente con sinonimi e varianti) o termini corredati da informazioni aggiuntive come definizioni, contesti, note, ecc. Già in questa fase è opportuno stabilire se il data set includerà anche altri tipi di dati (es. fraseologismi) che potrebbero richiedere un approccio specifico, ovvero diverso da quello adottato per gli altri dati.

Mentre contesti e altre informazioni, come ad esempio la grammatica, sono facili da collocare nella struttura di una banca dati, la definizione richiede qualche riflessione in più. Prima di tutto occorre chiedersi su quale livello collocarla, e cioè se sul livello del concetto, della lingua o del termine principale (Drewer, Schmitz 2017, 134 ss.; ISO 26162-1). In uno strumento che comprende più lingue è inoltre da decidere se definire il concetto solamente nella lingua pivot o se mettere una definizione per ogni lingua indagata. Anche in riferimento a eventuali note sarà da valutare su quale livello o livelli collocarle e stabilire se sono note per l’utente finale esterno o solo per l’uso interno e/o per chi elabora i dati.

Anche per la dicitura delle categorie terminologiche è da considerare se si vuole adottare una lingua pivot per tutte le categorie, a prescindere dal numero di lingue che saranno presenti nello strumento finale, o definire le singole categorie e le eventuali picklist ad esse relative, secondo la lingua a cui esse si riferiscono.

Con riguardo alla struttura e alle categorie da includere, oltre al fabbisogno dell’utente esterno è anche opportuno tenere conto di quello interno, nello specifico del personale che dovrà ‘riempire’ la banca dati: se la struttura è troppo complessa, può diminuire la motivazione di inserire dati nei campi richiesti (Drewer, Schmitz 2017, 128). Se una struttura è troppo libera, possono finire nei campi delle informazioni non adatte alla categoria. Se invece è troppo rigida, ad esempio perché presenti molti campi obbligatori o non predisposta a eventuali aggiunte di nuove voci, chi inserisce può riscontrare delle situazioni in cui è difficile assegnare una specifica informazione ad un valore preimpostato. Per esempio, può succedere che possano mancare dei valori dalle picklist. In questo caso si prospettano due scenari: 1) il campo non è obbligatorio, per cui si può anche scegliere di non selezionare alcuna voce della picklist; 2) il campo è obbligatorio, pertanto è necessario selezionare un valore qualsiasi fra quelli a disposizione, sebbene sbagliato. Ciò potrebbe quindi generare dati incongruenti e informazioni non sempre del tutto corrette.

Inoltre è da riflettere quali categorie devono essere di genere testuale (open data categories), ossia quelle in cui è possibile inserire del testo libero, e quali di genere attributivo in forma di picklist, (closed data categories), dove la persona che inserisce i dati ha a disposizione un elenco chiuso di elementi tra cui scegliere (ISO 26162-1). Quest’ultime sono da preferire poiché favoriscono un inserimento più veloce e ‘pulito’, permettono una maggiore uniformità dei dati e aiutano ad evitare degli errori (per es. che vengano inseriti dei dati nel campo sbagliato) (Drewer, Schmitz 2017, 138). Naturalmente non per tutte le informazioni sono possibili delle closed data categories, tra gli esempi più evidenti definizioni e contesti.

In questa fase è anche da stabilire se è previsto uno scambio di dati, per esempio tra due o più istituzioni o uffici, e con quale modalità i dati saranno scambiati.

In presenza di un patrimonio già esistente, si operano le stesse riflessioni descritte nella sezione precedente (3.2.1.). Tuttavia, la presenza di dati ha senza dubbio un grande impatto sulla concezione del nuovo strumento e richiede pertanto ulteriori considerazioni.

Molto dipende da quali dati sono presenti e in che forma. Bisogna quindi tener conto di fattori come, per esempio, la gestione dei dati in passato: se erano elaborati su iniziativa del singolo e amministrati da differenti postazioni, come singoli uffici, e quindi si tratta di patrimoni separati, o se invece erano gestiti centralmente con possibilità per tutti di accedere allo stesso patrimonio di dati.

A questo si collega la questione sull’approccio adottato per l’elaborazione dei dati: è stato adottato un unico approccio (es. onomasiologico, semasiologico) o è stato impiegato un mix di approcci? Nel primo caso bisognerà considerare se mantenere lo stesso metodo anche per il futuro; nel secondo caso sarà necessario valutare quale tra quelli impiegati in passato sarà opportuno scegliere e, di conseguenza, quali modifiche saranno richieste per adattare il patrimonio o i singoli data set al nuovo approccio che si intende seguire in futuro.

In relazione alla tipologia dei dati, valgono le stesse riflessioni di cui sopra (3.2.1.): se si tratta di soli termini, se con varianti e sinonimi, se i termini sono corredati da informazioni aggiuntive, come definizioni, note, ecc.; come sono organizzate le categorie e quali di queste si vogliono accogliere nel nuovo strumento; se mantenere la struttura o se, invece, ci sono elementi da cambiare.

Un aspetto rilevante è senza dubbio anche il formato in cui sono disponibili i dati (es. formato MS Excel o Word, XML, formati supportati dai sistemi di gestione della terminologia, come il TBX) e se i dati sono presenti in formati diversi. Ne consegue la necessità di valutare quale formato è meglio usare per il nuovo strumento o anche solamente per importarvi i dati e, successivamente, quali misure prendere per uniformarli.

È, infine, da valutare se ci sarà o meno uno scambio di dati e in che modo saranno gestiti, se centralmente o localmente. Anche in questo caso valgono le stesse riflessioni descritte nella sezione precedente (3.2.1).

Con riguardo alle lingue è particolarmente importante sapere se i dati terminologici si riferiscono ad una lingua o più lingue. Inoltre, è interessante sapere se si tratta di lingue con più varietà (es. inglese americano, inglese britannico) e, in tal caso, se si decide di orientarsi su una varietà specifica o se si prevede di includere più varietà. Lavorando con più varietà linguistiche, seguono poi le riflessioni su come strutturare le informazioni per le diverse varietà, ovvero come indicare quali informazioni si riferiscono a quale varietà. Altrettanto importante è verificare se le lingue (ed eventuali varietà) sono supportate dal software.

Infine, un altro aspetto che influisce sulla struttura e le categorie da aggiungere è se si prevede un’armonizzazione terminologica. Per esempio è da considerare quale categoria e relative voci predisporre per indicare lo stato nel workflow di armonizzazione, se si tratta di un termine nuovo aggiunto nella banca dati o approvato dall’organo di armonizzazione o altro.

Essendo la documentazione dell’informazione terminologica un aspetto fondamentale di qualsiasi lavoro terminologico (Arntz et al. 2014, 212 ss.; Drewer, Schmitz 2017, 53 ss.), nella maggior parte dei casi le informazioni saranno corredate da fonti bibliografiche. È quindi importante riflettere su come gestire le fonti e dove catalogarle. La quarta parte della check-list verte pertanto sulle fonti bibliografiche, ad esempio in che forma queste dovranno essere citate e catalogate o, in presenza di un patrimonio terminologico già esistente, in quale forma e modo tali fonti sono già state citate e catalogate.

Se sono già presenti dati terminologici, si deve considerare se questi sono già corredati da fonti bibliografiche. Se sì, va verificato se sono catalogate, dove sono salvate e in quale formato o formati. È inoltre da valutare se mantenere lo stesso metodo di citazione o, in caso fossero presenti più forme di citazione, quale scegliere e, conseguentemente, come uniformarle. Per diverse categorie di fonti può essere anche necessario prevedere diversi tipi di informazioni da aggiungere o modi di citazione da adottare. Si pensi, ad esempio, a manuali e siti internet.

È, infine, da riflettere se o come gli utenti finali potranno accedere alle informazioni complete sulle singole fonti bibliografiche (per esempio, tramite click sulla sigla o indicazione breve della fonte).

La quinta e ultima parte della check-list è dedicata alla pubblicazione online, la relativa gestione e la manutenzione dello strumento.

Innanzitutto è da definire cosa mettere a disposizione dell’utente finale. Nello specifico è da stabilire se tutte le informazioni elaborate saranno visibili anche all’esterno o se certe categorie non saranno visibili, in quanto di rilevanza prettamente interna.

Dai lavori svolti per riprogrammare bistro e, con esso, rivedere la banca dati terminologica operante su SDL MultiTerm, è nata questa check-list. Naturalmente non la si può considerare esaustiva, cerca tuttavia di fornire una guida sugli aspetti ed elementi di cui occorre tenere conto se si decide di sviluppare uno strumento terminologico, sia esso una banca dati terminologica interna o un applicativo online. Ciò per evitare il più possibile degli ‘errori’ ed eventuali modifiche, che potrebbero risultare in seguito necessari a causa delle scarse riflessioni nella fase di concezione dello strumento terminologico, con conseguente perdita in termini di tempo e costi.

Abbiamo visto che sono, infatti, numerosi i fattori di cui dover tenere conto già nelle fasi di concezione e pianificazione dello strumento: dagli obiettivi e i destinatari fino alle condizioni base per lo sviluppo e le possibili criticità. Un’attenta analisi dei dati e del fabbisogno consente di definire detti fattori e, al contempo, di individuare le funzioni a cui dovrebbe assolvere lo strumento, nonché le modalità di ricerca e di visualizzazione delle informazioni. Affinché la qualità dell’informazione possa essere valorizzata al meglio è, quindi, fondamentale che ci sia una certa coerenza fra quelli che sono il gruppo di utenza, le caratteristiche del dominio, le funzioni e gli obiettivi dello strumento con le categorie terminologiche e le informazioni che vengono poi messe a disposizione.

Va tuttavia tenuto bene a mente che uno strumento terminologico non è mai un prodotto finito. Bisogna pertanto sempre pensare a lungo termine e fare in modo che tale strumento presenti una certa flessibilità, cioè che sia aperto a eventuali modifiche e/o aggiunte anche in futuro.

Agrario, C., Castagnoli, S. 2010. “EOHS Term: una knowledge base multilingue in materia di sicurezza sul lavoro”. In Terminologia a colori, a cura di F. Bertaccini, S. Castagnoli e F. La Forgia, 121-61. Bologna: Bononia University Press.

Arntz, R., Picht, H. e K.-D. Schmitz. 2014. Einführung in die Terminologiearbeit, 7. Aufl. Hildesheim: Olms.

Bergenholtz, H., Tarp, S. 2010. “LSP lexikography or terminography? The lexikorapher’s point of view”. In Specialised dicitionaries for learners, edited by P.A. Fuertes-Olivera, 27-37. Berlin: de Gruyter.

Drewer, P., Schmitz, K.-D. 2017. Terminologiemanagement. Grundlagen – Methoden – Werkzeuge. Berlin: Springer.

ISO 1087-1 2000. Terminology Work – Vocabulary – Part 1: Theory and application. Geneva: ISO.

ISO 26162-1 2019. Management of terminology resources – Terminology databases – Part 1: Design. Geneva: ISO.

ISO 30042 2019. Management of terminology resources – TermBase eXchange (TBX). Geneva: ISO.

Pulitano, D. 2010. “Le varianti in una banca dati terminologica: come gestirle”. Publif@rum 2010, volume 12. Atti del Convegno Ass.I.Term 2009, <https://www.publifarum.farum.it/ezine_articles.php?publifarum=du7d64sgdf5dpasuq5dfpg7180&art_id=168> (2019-12-23).

Ralli, N., Andreatta, N. 2018. “bistro – ein Tool für mehrsprachige Rechtsterminologie”. trans-kom – Zeitschrift für Translationswissenschaft und Fachkommunikation 11, 1/2018: 7-44. <http://www.trans-kom.eu/ihv_11_01_2018.html> (2019-12-23).

1 Le prime schede terminologiche furono elaborate con MultiTerm 95. All’epoca questo sistema era innovativo e all’avanguardia, tuttavia presentava delle limitazioni. Ad esempio, la definizione della banca dati poteva contenere fino ad un massimo di 62 campi testuali e 30 campi attributivi, le cui picklist potevano raggiungere un massimo di 1042 caratteri (TRADOS GmbH 1995-1997, 43).

2 Il patrimonio terminologico, in lingua italiana, tedesca e ladina, conta attualmente (2020-01-30) circa 21.600 schede, di cui ca. 13.200 sono pubblicate in bistro.

References Agrario, C., Castagnoli, S. 2010. “EOHS Term: una knowledge base multilingue in materia di sicurezza sul lavoro”. In Terminologia a colori, a cura di F. Bertaccini, S. Castagnoli e F. La Forgia, 121-61. Bologna: Bononia University Press. Arntz, R., Picht, H. e K.-D. Schmitz. 2014. Einführung in die Terminologiearbeit, 7. Aufl. Hildesheim: Olms. Bergenholtz, H., Tarp, S. 2010. “LSP lexikography or terminography? The lexikorapher’s point of view”. In Specialised dicitionaries for learners, edited by P.A. Fuertes-Olivera, 27-37. Berlin: de Gruyter. 10.1515/9783110231335.1.27 Drewer, P., Schmitz, K.-D. 2017. Terminologiemanagement. Grundlagen – Methoden – Werkzeuge. Berlin: Springer. 10.1007/978-3-662-53315-4 ISO 1087-1 2000. Terminology Work – Vocabulary – Part 1: Theory and application. Geneva: ISO. 10.3403/30371123 ISO 26162-1 2019. Management of terminology resources – Terminology databases – Part 1: Design. Geneva: ISO. 10.3403/30374615 ISO 30042 2019. Management of terminology resources – TermBase eXchange (TBX). Geneva: ISO. 10.3403/30338734U ISO 704 2009. Terminology Work – Principles and methods. Geneva: ISO. 10.3403/02211674u Pulitano, D. 2010. “Le varianti in una banca dati terminologica: come gestirle”. Publif@rum 2010, volume 12. Atti del Convegno Ass.I.Term 2009, <https://www.publifarum.farum.it/ezine_articles.php?publifarum=du7d64sgdf5dpasuq5dfpg7180&art_id=168> (2019-12-23). Ralli, N., Andreatta, N. 2018. “bistro – ein Tool für mehrsprachige Rechtsterminologie”. trans-kom – Zeitschrift für Translationswissenschaft und Fachkommunikation 11, 1/2018: 7-44. <http://www.trans-kom.eu/ihv_11_01_2018.html> (2019-12-23). TRADOS GmbH 1995–1997. Trados MultiTerm ‘95 Plus! Benutzerhandbuch.