Speakers
Description
The package τ-Argus is a widely used EU-funded Open Source tool for disclosure control in tabular data. It is automatable via batch functionality, and as Open Source package it is supposed to be easy to adapt, and transparent. As there is growing demand for specific τ-ARGUS functionalities to be provided “as a service”, the paper will discuss pros and cons of a fundamental revision of the architecture of the package, such as the idea of developing API to allow SDC methods included in τ-ARGUS to be called from “any” language/interface (e.g., Java, Python, R, cloud-based, web-based, …).
The paper will examine this idea and its consequences in some detail. A particular challenge is that API users should be able to run their (exact same) instance also from out of the GUI, for example to get a clue of what went wrong in case of unexpected results. For testing purposes, API users must also be able to check the “correctness” of input data when making calls from other environments in the sense that the GUI would run a particular instance on the exact same input data. “Correctness” in this context refers to the fact that in the original process, parts of the data preparation are implemented in the routines of the τ-ARGUS GUI. With the transition to APIs, this preparation could now be implemented as well in environment systems of individual users, before calling the respective API. We will investigate potential consequences of such requirements on interfaces provided by τ-ARGUS, in the paper.
Another issue the paper will consider is the question of how to better sustain continuous development of the package and its components, ensuring in particular that the package will be able to run with recent/security supported Java versions. Since the most recent Java versions are only available in 64 bit, this means that τ-ARGUS also needs to be upgraded to a 64 bit version. Ideally, there should also be a continually maintained Linux/Unix version, easier to integrate into Linux/Unix production environments. Continuous development should be accompanied by automated testing facilities which would have to be created as well.
Apart from software architecture, other major issues will be discussed as well. For example, the option for a future replacement of the hypercube method for which maintenance has been stopped by its provider by re-implementation of the method. Or to “integrate” another method for secondary cell suppression which, like the hypercube method, is similarly able to deal with extremely large tables (without need of a commercial LP solver), e.g. the package GAUSS [Langsrud, Ø. 2024]. We also briefly report on a current small research cooperation between Destatis and a university, studying options for re-implementation of the algorithm in τ-ARGUS for solving the MILP problems of secondary cell suppression.
