OpenTMS Specification
From OpenTMSWiki
Open Source Translation Memory System
OpenTMS
[edit] Contributors
[edit] Originator
Michael Schneider, beo Gesellschaft für Sprachen und Technologie mbH
Thomas Wedde, euroscript Deutschland GmbH
[edit] More contributors
Ulrike Baral, beo Gesellschaft für Sprachen und Technologie mbH
Christine Bruckner, Department SMD 1, Bundessprachenamt
Lutz Fischer, University of Mainz
Sascha Hofmann, University of Mainz
Horst Liebscher, euroscript Deutschland GmbH
Marc Mittag, transline GmbH
Andrea Modersohn, oneword GmbH
Michael Neuhäuser, euroscript Deutschland GmbH
Christian Taube, Matrix AG
[edit] Steering Group
Ulrike Baral (Ulrike.Baral@beo-doc.de)
Andrea Modersohn (A.Modersohn@oneword.de)
Michael Schneider (Michael.Schneider@beo-doc.de)
Thomas Wedde (Thomas.Wedde@euroscript.de)
| Organisation | Address | |
|---|---|---|
| Originator
Copyright holder | FOLT
Forum Open Language Tools | Filderbahnstr. 43 A
70567 Stuttgart Germany folt@beo-doc.de www.folt.org Telephone +49 (0) 711 166 46 0 Fax +49 (0) 711 166 46 50 |
| Publisher | Linux Solutions Group (LiSoG) e. V.
Stuttgart Office | Breitscheidstr. 4
70174 Stuttgart Germany info@lisog.org www.lisog.org |
[edit] Wiki Contributors
[edit] Licencing of Wiki content
This content is licensed under a Creative Commons license agreement: Naming – No editing 2.0 Germany. To view the license, visit
http://creativecommons.org/licenses/by-nc-nd/3.0
or write to
Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.
Creative Commons - Commons Deeds
Naming – No commercial use – No editing 3.0
You are permitted to reproduce, distribute and publicly present the content.
Subject to the following conditions:
Naming: You must specify the name of the author / copyright holder.
No commercial use: This information may not be used for commercial purposes.
No editing: The content may not be edited or amended in any other way. If the content is distributed, you must notify other parties of the terms of the license that cover this content. Each of these conditions can be cancelled with the written consent of the copyright holder.
The legal constraints of copyright law are unaffected. The Commons Deed is a summary of the license agreement in generally understandable language.
[edit] Specification
[edit] Foreword
The market for Translation Memory Systems (TMS) is dominated by just a few commercial systems. These are generally incompatible with one another and do not allow data to be exchanged easily. This situation means that the process of creating multilingual documents involves a large number of individual solutions, from DMS to translation tools through to DTP systems, which results in specialist translators frequently being selected based on their use of a specific TMS rather than on their specialist knowledge.
In addition, the costs of the existing commercial and totally proprietary systems are disproportionately high due to their dominant position in the market.
In university education for translators, tuition continually comes up against the same issues. Particularly when it comes to switching study programmes to BA and MA, with the resulting reduction in studying time, it is no longer possible to incorporate all of the existing systems into the curriculum.
Open Source is being widely discussed but to date there have been no serious efforts to actually develop an Open Source TMS. The “Forum Open Language Tools”, FOLT for short, aims to change this and, with this document, is presenting an initial draft for the development of a “Open Source Translation Memory System” (OpenTMS).
FOLT is a syndicate and working group made up of companies, organisations and universities in the translation and documentation sector. The primary aims of FOLT are to support standardised interchange formats, non-proprietary software and testing of new translation technologies and methods FOLT is an open forum and is not run as a registered association or company. Regular workshops are held at 4-6 week intervals, hosted by different members. Any interested parties who want to participate in an open discussion of this issue beyond the Internet forum are invited to these workshops. Registrations can be made on the Forum’s website www.folt.de.
FOLT is a network of experts and aims to represent the interests of independent translation service providers, translators and editors and universities involved in training translators – and to promote a free global translation market.
Linux Solutions Group e.V. (LiSoG) is a co-operation platform that aims to promote the use of Linux-based solutions in business and to increase their market acceptance. As well as major players from the IT industry, the initiative is supported by many small and medium-sized enterprises that are involved with Linux and Open Source solutions.
LiSoG focuses on “collaborative innovation”, which means that it initiates projects on Open Source issues that are currently relevant in the market, in which members and interested parties work together to devise solutions and push them forwards. Its activities currently cover German-speaking Europe. LiSoG also provides a network platform for projects, partners and interested parties.
LiSoG is supporting FOLT in its “Translation Memory Open Source System” project.
[edit] About FOLT
Forum Open Language Tools (FOLT) is a syndicate and working group made up of companies and organisations from the translation and documentation sector.
FOLT is concerned with the entire process of producing foreign language documentation. From creation of the source text to production in foreign languages, we are analysing our processes for weaknesses and a lack of standardisation.
FOLT’s primary objectives are:
- Sharing experiences of processes using standard industry software
- Sharing experiences of the use of Open Source software
- Standardisation of interchange formats
- Testing new Open Source technologies and improving existing technologies in the translation market
- Public support for non-proprietary software and software development
- Supporting universities in integrating an Open Source product for training translators
- Publication of aims and results
FOLT has developed into a mouthpiece for the interests of all parties involved in the translation process, both customers and service providers.
[edit] Purpose of this document
This document outlines the essential requirements for an Open Source Translation Memory System from the perspective of the originator. It is intended to support developers in preparing bids and will form part of any contract awarded. It is also intended as a basis for a system specification to be created by the contractor.
[edit] Initial position and definition of problem
At present, there are various commercial TMSs, which are incompatible with one another and do not allow data to be exchanged easily. Overall, this has led to a lack of standardisation in the translation process as far as TMS is concerned. Translators either have to specialise in using one particular TMS or learn to use a number of different systems. As many customers prefer to use just one of the commercial systems, specialist translators are often selected based on their experience with a particular TMS. Translators are therefore increasingly being forced to perform additional tasks on top of their core competences. Familiarisation with the programs, training and new releases of commercial programs take up an increasing amount of time and bring rising costs that are not offset by additional income. In addition, the purchase and update costs for the standard commercial systems are disproportionately high.
It is correspondingly difficult for training institutions to train future translators and technical editors with the appropriate software during their studies.
The incompatibility of the systems makes it difficult to switch from one system to another. Converting data when changing system is a complex issue.
The aim of an Open Source TMS is to standardise these process in the future and to apply the existing open standards more consistently.
[edit] Introduction to the issue
[edit] Fundamental principle
Translation Memory Systems (TMS), also known as translation memories or sentence databases, store translations that are normally produced by human translators and offer translators the opportunity to reuse existing translations at a later date. They can detect not only identical text but also similar source text segments. TMSs are primarily used to ensure consistency of terminology, content, style and formats in translations. A further key aspect is that they make translation work easier and speed it up, bringing about an associated reduction in costs.
Using a TMS is particularly beneficial when translating texts in which recurring identical or similar phrases come up, such as operating manuals, accounts, balance sheets, advertising texts and catalogues. Essentially, it is true to say that the greater the degree of repetition in the text, the greater the benefits of using a TMS. Using text modules in the editorial process allows the power of TMS to be utilised to the full.
In practice, interactive work using a TMS involves a translator selecting a segment for translation. The system then searches for identical or similar segments in the memory and indicates any existing translations. The translator can use or modify these suggested translations. If no matching segments are found, the translator enters his or her own translation, which is then stored along with the source segment and is available in the memory from then on if identical or similar segments come up again. In addition, depending on the system, the translator is provided with a range of additional information to make the translation process easier. This includes:
- The user who created / modified the translation provided
- The creation date of the translation
- The frequency with which the translation is used
- The context of the translation
- Other classifying information
- Information about subject or user-specific terminology
Alongside this interactive process, most TMSs can perform a fully automatic translation (“pre-translation”) before the text is sent to the translator. The system compares the segments in the document to be translated with those in the translation memory. If there is a full match, the segment is replaced with the saved translation. The user then only has to deal with those sentences / segments that were not found in the translation memory and check the pre-translated segments for correctness in the relevant context.
This method is many times faster than traditional translation. A TMS reproduces target language content and, providing the corresponding interfaces and process definitions are in place, can support authoring of the source language text. This variation is known as an Authoring Memory System (AMS).
TMSs have been developed for commercial use for more than 20 years. Their use is extremely widespread (> 70%). The market is dominated by a small number of commercial suppliers.
[edit] Segment
The individual units in the database are known as segments. They normally correspond to a sentence or paragraph. The TMS is used to access and use the translation memory.
For the purposes of this document, segments are monolingual. Specialist literature often uses the term “translation unit” (TU). A TU refers to the structure represented by tags – alongside various possible meta data items, this contains a source language segment and a corresponding target language segment.
[edit] Document
In a translation context, a document is any completed, coherent collection of translatable texts that are combined into a file. Examples of documents in this sense include:
- Individual Word or Open Document files
- A database export
- All user interface texts for a software module
[edit] Translation job
A translation job consists of one or more documents that are combined with all the other data that is necessary to edit them. For example, this could be all the data a translator requires to translate a document, including the document itself.
[edit] Translation Memory
The Translation Memory is a central database of translation units. The documents to be translated are broken down into segments. For each of these segments, a query is sent to the database to determine whether it already contains a translation in the required target language. The hits found are presented to the translator as suggested translations.
The search finds not only exact matches but also translations of “similar” segments that are also suggested to the translator along with details of how “similar” the segment is.
The use of this kind of “similarity function” is generally referred to as “matching”.
[edit] Match
A match is the result of an inexact search (fuzzy matching) in the TMS for matches or similarity between the source language segment in the TM and the new segment to be translated. The degree of similarity is expressed in percent. To improve clarity and for administration purposes (quotations, invoices and transparency in the process and supplier chain), matches are grouped into match classes. A typical match class distribution would be as follows:
- 100%
- Repetition (first occurrence counted as No match)
- 95% - 99% Fuzzy match
- 85% - 94% Fuzzy match
- 75% - 84% Fuzzy match or no match (depending on settings)
- 50% - 74% Fuzzy match or no match (depending on settings)
- < 50% No match
As well as expressing matches in percent most TMSs also allow the absolute distribution to be indicated by number of segments and number of words.
[edit] Description of a standard translation process
Translations predominantly follow a similar pattern. However, there can be considerable differences in the detail. This is primarily due to the quality of the documents and databases, the experience and knowledge of the translator, the formats involved and the terminology and other information provided. Editorial change processes or correction requests across a large number of target languages while translation is in progress can make the processes very complex. For example, changes to the user interface for a piece of software can result in corresponding changes to dependent texts such as online help, manual, marketing brochure and website.
- The basic process of translation supported by a TMS looks like this:
- Extraction of text from source documents and / or separation of text and structure (“filtering”)
- Segmentation of source documents
- Comparison with TM to identify repetitions and previous translations
- Translation of remaining segments
- Replacement of the source language segments in the source documents with the corresponding translations (resulting in monolingual target language document)
Other important work steps include TM maintenance (importing new segments and their translations into the TM), terminology work and QA measures (checking routines).
[edit] Modular structure of OpenTMS
[edit] Translation Memory
The actual Translation Memory consists of a database of segments. Segments are data objects with the following properties:
- Content (essentially text, normally a sentence)
- Language
- Meta data, e.g. creation or modification date, comments etc.
A segment in a source language can be assigned to one or more segments in a different language (1-n link). This represents translation of the segment into one or more target languages. Restricting the TM to specific language pairs should be avoided.
It must be possible to use more than one TM database (hierarchically graded), These should be central database stored both locally and remotely and used jointly by several translators.
[edit] Segmenter & segment matcher
The segmenter controls the segment delineators. The most common segment delineator is the full stop. Every sentence can be a segment, but not every segment is a sentence. It is necessary to differentiate between general segment delineators, e.g. paragraph marks, and special segment delineators, e.g. a control character from the source code in machine control. For this reason, the segmenter must be configurable – i.e. the segmentation rules must be adjustable. Context-based segmentation is not initially required but should be considered for subsequent development.
The segment matcher is the module that compares the individual segments to be translated with the content of the database and identifies identical or similar segments. It calculates a match quality (normally a percentage) and assigns this to the hits. The hits found and the calculated quality is communicated to the translator interface or the analysis results display using XLIFF.
The context must be taken into account here. Failure to take account of the context frequently results in apparently 100% matches that are not in actual fact matches as the target language segment is only valid in a particular context. A good example would be the word “bank” – depending on the context this could be the bank of a river or a bank for depositing money.
The longer a database has been in use for, the greater the likelihood of such inconsistencies occurring. TMOSS will need to take account of this situation and offer an optional function that takes into account a defined number of segments before and after the active segment to be translated and including these in the matching process.
Another phenomenon is also important in this regard. The match classes mean that the quality of the suggested translations diminishes to the point where revising a poor suggested translation involves more work than translating the entire segment from scratch. However, it is not uncommon for the translator will be presented with individual phrases or partial sentences that are familiar and these can actually be found in the database using a targeted concordance search. A matching process at so-called sub-segment level would be conceivable. If the TMS detects a “no match”, the active segment – where possible and in compliance with the segmentation rules – is broken down into sub-segments that are then queried against the database again. This function would significantly advance working speeds and more efficiently utilise existing translations.
The segment matcher should be interchangeable so that different matching algorithms can be implemented in parallel. Functions that can extend or reduce the segment are required, for example if the semicolon is defined as a segment delineator or if several sentences are stored in a single segment.
This phenomenon can also occur in the normal translation process with the TMS alone. Multi-sentence segments such as this frequency occur when alignment has been performed. This a process in which a tool breaks down a source language document and a target language into TUs segment by segment and stores these in the TM database.
Examples of this would be long sentences, which are changed into several shorter sentences when translated. In this case, the expected 1:1 relationship is cancelled and 1:n relationships are created, which must be reflected in the TUs. Essentially, n:1 and, in rare cases, n:n relationships are also possible.
The segment matcher must be able to deal with all of these phenomena.
[edit] User interface
The OpenTMS user interface will be split into a translation and an administration interface, which will be displayed in a browser. The browser display will not use any functionality of proprietary runtime environments or browser security settings that would normally be filtered out by firewalls (e.g. in government agencies). These include Flash, ActiveX, Cookies and local storage of session IDs (see ZDv 54/100).
The translation interface will display the source and target text, suggestions from the TM and terminology, buttons for calling up various functions and additional information, e.g. context. The administration interface will contain configuration options (e.g. for the interface itself or for segmentation rules), project information, analysis functions and functions for importing and exporting files.
[edit] Filters
No separate document filters will be implemented initially. Instead, existing filters from other Open Source projects can be linked using the XLIFF interface.
[edit] Interfaces
The following interfaces will be used for export / import:
- TTX, TMX, XLIFF
- Terminology (MARTIF in line with ISO 12200, TBX, OLIF, CSV)
- Meta data, such as SRX, GMX and XLIFF
- Integration of external quality assurance tools
[edit] Development process
The development process is planned in 3 phases.
[edit] Phase 1 – Prototype with basic functions
The first step will be to create a core system, which an individual translator can start to use to produce translations.
The following functions must be implemented:
- Pre-processing and post-processing of documents to be translated (filters)
- Segmenter
- Translation Memory database with matching
- Interfaces for translator and simple administration tasks
- Statistical evaluations and analyses
- Spell checking
- Interface to terminology systems
[edit] Phase 2 – Development of convenient handling functions
This includes enhancement of the user interface, terminology recognition and persistent data storage.
[edit] Phase 3 – Development of individual additional functions
Including links to workflow management systems.
[edit] Further information on actual status
Further information about the actual status can be found in the articles about the OpenTMS Roadmap and OpenTMS Version.
[edit] Aim
The main aim of the development of OpenTMS is to provide an alternative to commercial TMSs based on contributions and input from all user groups. This will be guaranteed by developing the solution as an Open Source program. Existing processes in TMS-based translation will be standardised and the open standards will be consistently implemented.
[edit] Mandatory criteria
OpenTMS is completely XML compatible, i.e. it can handle the XML standard and the XML derivatives created for the translation process.
All of the functions required in phase 1 are mandatory criteria.
All internal data formats and processing paths in all modules are completely Unicode based.
[edit] Desirable criteria
To be specified at a later date.
[edit] Boundary criteria
To be specified at a later date.
[edit] Product use
[edit] Area of use and basic architecture
OpenTMS will be realised as a Web application, with a Web browser acting as a thin client. On the client side, no installations except the browser will be needed. For security reasons, the software will not use any of the functionality of proprietary runtime environments or browser security settings that would normally be filtered out by firewalls (e.g. in government agencies). These include Flash, ActiveX, Cookies and local storage of session IDs (see ZDv 54/100).
On the server side, the system will be scaleable, i.e. it must be possible to distribute the functionality across different servers.
[edit] Target groups
OpenTMS will be used by the following user groups:
- Individual translators and translation service providers
- Multiple translators working collaboratively on a project
- Documentation departments in companies, organizations and public bodies with translation requirements
- Universities and other educational institutions
[edit] Software
The design and configuration of OpenTMS is not linked to specific software systems, although the emphasis is on the use of Open Source technologies and this will be actively supported.
[edit] Hardware
On the client side there are no special hardware requirements, as it is only necessary to have installed a Web browser. On the server side, standard hardware will be used.
[edit] Technical interfaces
A link to technical organisational units will be available for later applications and is one of the required criteria. Technical organisational units include workflow management systems and accounting systems. There are no specifications for these at the present time.
[edit] Product interfaces
In Phase 1, data interchange with other products will be realised by importing and exporting using TMX or XLIFF.
[edit] Product functions
[edit] Pre-processing and post-processing
“Pre-processing and post-processing” basically means extracting the text to be translated from standard document formats (filtering) and re-inserting the translated text in the original documents. Initially, this will be done using existing filters, e.g. the Okapi filter framework. This process separates the text from formatting and structural information, which is displayed as tags and maintained during translation. However, it must be possible to pick up this format information to that it can be placed correctly. For example, a superscript copyright symbol at position four in the source language segment is protected as a tag and can be freely placed in the target language segment by the translator. Country-specific automatic replacement of mark-ups is conceivable – for example bold formatting using All-Caps for the US market.
[edit] TM, segmentation and matching
The Translation Memory represents the central repository for segments in the source and target languages.
The segmenter is designed to break down the translatable text into segments. Because the definition of a “segment” can differ greatly depending on the situation, the segmenter must be configurable.
Matching is the process of searching for identical or similar segments in the TM. The similarity of a segment is normally expressed as a percentage. This similarity is also known as the match quality or match class.
[edit] The segment matcher should:
- Take into account figures, punctuation marks and special characters (or ignore them, depending on the settings) and take account of stored lists, e.g. of proper names.
- Use information from the document filter, e.g. to recognise the content of cells in tables as single segments.
- Pass on the match quality to the other modules.
- The match quality in percent can be simply defined, e.g. as the number of identical characters in two segments
[edit] Evaluations, statistics:
- It must be possible to calculate the following values for each document to be translated and for each translation job
- Total number of words
- Total number of segments
- Total number of lines, characters etc. A standard line is defined as 55 characters including spaces. However, the line length must be configurable.
- Number and % of segments and words that are repeated within the document / job (repetitions)
- Number and % of segments and words found in the TM, broken down by match classes
[edit] Filters
Other than XML, no separate document filters will be implemented initially. However, existing external filters from other Open Source projects can be linked using the XLIFF interface.
[edit] Interfaces and interface formats
The following interfaces will be implemented and used for export / import:
- Translation content (in phase 1 XMLIFF and TMX to exchange data between the TM and the translator interface, later TTX)
- Terminology (TBX, CSV in phase 1, later MARTIF in line with ISO 12200, OLIF, HTML)
- Meta data, e.g. creation / modification date, comments etc. Interchange formats for meta data include SRX (= segmentation rules), GMX (= globalisation rules for the word count) and XLIFF (workflow data with information down to segment level).
- Integration of external quality assurance tools (spell checking and other checking routines, validators, parser etc.)
[edit] Product data
To be specified at a later date.
[edit] User interface
[edit] Translator
The user interface for the translator is hugely important for the acceptance of the new solution. Translators prefer certain layouts depending on the processes. Translation of texts into at least one target language must meet at least the following specifications.
- Display of source and target language segments immediately below one another.
- Display of source language segment that is currently being edited.
- Input field for the translated text.
- Display of hits from TM for selection. The match from the TM considered to be the most similar appears first and is directly visible or is shown automatically in the target language segment.
- Context reference by displaying one or more segments before and after the segment to be edited to indicate the specific context.
- QA functions: Spell checker, segment checker, validation of tagged texts.
[edit] Administration
- Analysis of translatable texts in terms of repetitions and TM matches.
- Compilation of all information and settings belonging to a job as a “translation project”.
- Exporting and importing translation projects.
- Creation of statistics based on frequency and match classes
- Adjustment of segmentation rules
- GUI configuration
[edit] Product features
- Comprehensive use of Unicode
- Special requirements of the database model in terms of selecting the source language and changing the language
- Scalability for distribution of tasks and load
- OpenTMS will be client-capable in the final expansion stage.
[edit] Non-functional requirements
[edit] Interfaces
- TTX, TMX, XLIFF
- Terminology (MARTIF in line with ISO 12200, TBX, OLIF, CSV, HTML)
- Meta data, such as SRX, GMX and XLIFF
- Integration of external quality assurance tools
[edit] Platforms
- No particular operating system platform is preferred or stipulated. Instead, we require the TMS to be portable to Windows, MacOSX and Unix or similar systems to Unix (Linux, BSD etc.) and a guarantee of interoperability between the supported platforms.
[edit] Database
- The actual TM database must be an Open Source product such as MySQL, PostgreSQL of a similar widely used, free and openly available database system. As it must be possible for single users to completely install the entire system on one computer, the database system must support all of the intended platforms.
- The database used must support Unicode UTF16.
- The structural requirements for the database model for a multilingual database concept must take into account the following:
- There are no fixed language pairs
- There are no preferred languages (no source – target assignment)
- The language direction can be reversed at any time
| Product quality | Excellent | Good | Normal | None |
|---|---|---|---|---|
| Functionality | X | |||
| Suitability | X | |||
| Accuracy | X | |||
| Interoperability | X | |||
| Compliance with standards | X | |||
| Security | X | |||
| Error tolerance | X | |||
| Recovery | X | |||
| Comprehensibility | X | |||
| Ease of learning | X | |||
| User friendly operation | X | |||
| Speed | X | |||
| Flexibility | X | |||
| Stability | X | |||
| Verifiability | X | |||
| Transferability | ||||
| Adaptability | X | |||
| Installation | X | |||
| Interchangeability | X |
[edit] Scalability
In the long term, the system should be available in different versions in terms of functionality and the TM backend and feature appropriate functional scalability. The following versions must be possible:
- Test version with minimal features
- Single user version with defined functionality
- Fully featured version
- Optional client-capable version
[edit] Quality requirements
[edit] License issues
All new software to be developed is to be licensed based on GPL version 3. Separate licenses for individual modules are conceivable.
[edit] General quotation conditions
[edit] Contact for queries
[edit] PDF Version
[edit] Glossary
| Alignment | Processing of existing translations to create a Translation Memory. This allows the TM to use translations that were created previously without the use of the TM or for which the corresponding data is not available. To do this, the source text is assigned segment by segment (normally sentence by sentence) to the corresponding segments in the translated target text. |
| DMS | Document management system |
| Document filter | A function for separating the structure and content of documents to be translated, which ensures that the translated content and the original structure can be merged later. |
| FOLT | Forum Open Language Tools |
| Fuzzy match | Result of a similarity search (see also Match) |
| GMX | Meta data for word count globalisation rules |
| QA | Quality Assurance |
| LiSoG | Linux Solution Group e. V. |
| Match | Result of an inexact search (fuzzy matching) in the TMS for matches or similarity between the source language segment in the TM and the new segment to be translated. |
| Multi-sentence segment | Source language segment with a 1-n or n-1 relationship to the target text |
| Segment | A segment is the result of a segmentation process. |
| Segmentation | A process in which segments are delineated based on defined rules. |
| Segmentation process | See segmentation |
| SRX | Meta data for segmentation rules |
| OpenTMS | Open Source Translation Memory System |
| TM | Translation Memory is a text archive containing multilingual texts that are segmented, assigned, analysed and classified. It allows multilingual texts to be stored and access using various search queries. |
| TMS | Translation Memory System |
| TU | Translation Unit; a language pair stored in the Translation Memory. |
| XLIFF | XML Localization Interchange File Format. This format maps the different kinds of data to be localised into a standardised format. XLIFF documents can contain not only the data to be translated but also other data that is required for the workflow. As a result XLIFF documents could also be used to manage the translation process. |
| ZDv | Central service regulations for the German armed forces, e.g. ZDv 54/110 VS-NfD “Handling and use of cryptographic methods”; ZDv 54/100 VS-NfD “IT security in the armed forces” |
