dataesr/scientific-paragraphs-categorization huggingface dataset:
OSM therefore creates, orchestrates and deletes VMs that will host the Kubernetes clusters (network resources), whereas Kubernetes is the application orchestrator. The PaaS Network Application has an interface with the OSM through a REST API for creating and launching clusters as NSSIs. It also interfaces with the Kubernetes cluster through the RESTful API (Kubespray and Kubernetes Federation API v2 as PaaS controller). Security Network Application: This Network Application leverages an open-source Software Defined Perimeter (SDP) stack  [13] , which will be deployed and integrated with the 5GMediaHUB experimentation facility. The Security Network Application protects the Network Applications, which could serve as entry points for attackers via their Northbound APIs. Protection is accomplished via a Next-Generation Firewall (NGFW), which is part of the SDP stack.
Network Applications Repository: This is a portal for application developers to design, build and deploy their Network Applications. The repository is a standalone application with several functionalities that can be intertwined with other 5GMediaHUB components. This repository follows a CI/CD approach, providing complete automation and lifecycle development. CI is automatically triggered to 1) build the application, 2) create a new container for hosting the newly built application, and 3) store the container in the Gitlab container registry. CD deploys the newly built container to the target environment, which is a Kubernetes cluster in the CTTC testbed. The deployment consists of executing scripts that instruct the master node of the Kubernetes cluster to "pull" the container image from the source GitLab registry, create an instance of that container within its own pod, configure the services surrounding that pod and expose the interfaces/ports of that service to the cluster.
The Network Applications repository has four main components: 1) frontend portal, 2) portal backend service, 3) backend repository (GitLab instance) and 4) service catalogue. Each of these components have their own Kubernetes configuration file (in YAML format). The components are deployed to the same namespace within the Kubernetes cluster in order to maintain the appropriate level of abstraction between the various platform tools. The Kubernetes cluster also provides a means of storing application data across the lifecycles of the pods, including the sources of VNFs and Network Applications that have been configured using the Network Applications Repository.
Geochronology 40 Ar/ 39 Ar dating A summary of the 40 Ar/ 39 Ar data is presented in Table  1  and the full dataset in provided in SOM Table  S3. The first batch of 40 Ar/ 39 Ar measurements (VU110) was done on andesite hornblende from the BGL-5 (S14-82; VU110-T3), detrital hornblende from the interface between the BGL-5 and the BBC-1 (s) below the BBC-2 (S14-83; VU110-T4). All single grain measurements on these samples have large analytical uncertainties. Multigrain measurements (three and six grains per fusion) on the same samples have lower uncertainties, revealing age distributions spanning more than 1 Myr (SOM Table  S3 ). The andesite clast from the BGL-5 yielded an inverse isochron age of 0. 71 ± 0. 12 Ma (2s, VU110-T3; SOM Fig. S5 ). The inverse 40 Ar/ 36 Ar isochron intercept of 399.
Acknowledgments This study was carried out with the permission of the  Indonesian Ministry of Research, Technology and Higher Education  (RIS-TEK research permits:  263/SIP/FRP/ES/Dit. KI/VII/2016 ,  33/SIP/FRP/ E5/Dit. KI/II/2018  and  12/E5/E5. 4/SIP. EXT/2019  of  Josephine Joordens ;  8 B/TKPIPA/E5/Dit. KI/VIII/2018  and  2/TKPIPA/E5/Dit. KI/II/ 2019  of  Sander Hilgen ) under the project ' Studying Human Origin in East Java'. We thank Arkenas (Pusat Penelitian Arkeologi Nasional ) and in particular  Dr. I Made Geria ,  Priyatno Hadi Sulistyarto , and  Marlon Ririmasse  for facilitating and supporting our collaborative research. We would also like to thank  BPCB Jawa Timur  and the  Government Regency of Ngawi  for giving us support and permission to do research in Trinil. We are grateful to the people of  Trinil, Kawu and Ngancar  and the staff of the  Trinil Museum  for their hospitality and support.
I. INTRODUCTION Learning thrives on data. The recent renewed popularity of Machine Learning (ML) largely owes to the availability of vast training datasets. However, datasets with the required quality are often not available from a single source, and need to be assembled from subsets owned by different organizations that have a variety of access policies and that often grant no access at all to external entities, thus implementing policies that are far more stringent than required by the GDPR (General Data Protection Regulation). In recent years, Federated Learning (FL) has emerged as a revolutionary privacy-enhancing technology  [3] , apparently able to address the problem of collaborative training. Popularized by Google for privacy-preserving prediction of user keystrokes on smartphones  [4] , FL has quickly expanded to other applications  [5] ,  [6] ,  [7].
A. The TRUMPET project: An Armored FL Framework The TRUMPET project  [1] ,  [2]  aims at building a multisided, privacy-enhanced, Federated Learning-based platform for the development of dedicated AI applications that will assist (in the use cases selected for the project and described in Section VI) healthcare professionals. Our platform for Armored FL (AFL) will enable AI-powered studies of siloed, multi-site, cross-domain, cross-border European datasets with privacy guarantees that follow the requirements of GDPR. The key end users are researchers/solution developers (on the demand side), data owners (on the supply side) and healthcare professionals (indirect users of TRUMPET on the application side), as shown in Figure  1.
B. TRUMPET's Main Objectives The goal of the TRUMPET project is to deliver a highly scalable Federated AI service platform for researchers (see Section II), which will enable AI-powered studies of siloed, multi-site, cross-domain, cross-border European datasets with privacy guarantees that follow the requirements of GDPR. To this aim, the project will focus on two complementary technical aspects: (1) to research and develop novel privacy enhancement methods tailored for FL (see Section III), and (2) to research, develop and promote with EU data protection authorities a set of novel privacy metrics and a tool for the privacy evaluation of FL implementations (see Section IV). During the project, we will identify and perform a legal study of the implications of GDPR in FL implementations, which may be applied with further restrictions by different European countries.
II. THE TRUMPET PLATFORM High-Level Description: Data Owners (hospitals) keep their datasets private and do not share them directly. Instead, after being given trustworthy privacy guarantees by the TRUMPET platform operator, they install a TRUMPET learning node on their premises and allow it to access the data, so it can be trained and processed on the Data Owner's premises, by a locally executed AI model. The training of the local model can be performed either continuously or in batches, depending on the application. During training, only the parameters of the resulting model are exchanged with a central node called Federated Model Management (FMM), which is located outside the hospital's premises. The FMM aggregates the local model updates into a global one, and shares it with the TRUMPET nodes, so as to replace the local model updates and continue training if required.
This FL process converges to a global model that is constructed from the private datasets of individual Data Owners, but without the data being moved across the boundaries of each Data Owner's premises. Figure  2  illustrates the flow chain of the TRUMPET platform acting as a privacy-enforcing intermediator. Hospitals keep their data private and do not share them directly. Instead, they install a TRUMPET learning node on their premises and allow it to access the data, so it can be trained and processed on the hospital's premises, by a locally executed AI model. We refer the reader to Section VI for more details on the clinical use cases.
1) Data Owner Dashboard: The data processing and transformation (ETL; Extract, Transform, Load) service is located at the data owner node. It exposes REST APIs which are used by the hospital's IT team to upload patient datasets privately to the data owner node. Then, each data owner can describe its dataset, define the required privacy level, and also advertise it to external researchers by making use of its data owner control panel. Different versions of the ETL service are envisioned to support several ETL strategies suitable for different healthcare systems. The control panel also provides a dashboard to monitor the different advertised datasets for GDPR transparency, review the model training requests, etc. Each data owner node will have isolated its user administration and be fully managed by the data owner's IT team.
Three user groups are envisioned in the data owner node: (a) Administrator: performs user management, (b) Privacy manager: sets the privacy level of datasets, defines descriptive metadata of datasets, advertises datasets, approves data requests made by external researchers, mainly focusing on aspects related to ethical and data protection, monitors the advertised datasets, and monitors data owner node health, (c) Observer: monitors advertised datasets and monitors data owner node health. 2) Researcher Dashboard: The researcher dashboard will facilitate that researchers can browse advertised datasets, add/remove a dataset to/from favorites, define cohort, get descriptive statistics, train AI models, etc. For example, the model training management service will coordinate model training at data owner nodes, which is done via the agent services acting on behalf of a researcher.
First, the researcher will define the code to be executed at the training agent of a data owner node. Afterwards, the code will be reviewed by the data owner and executed on the private dataset. Finally, if the code is approved by the data owner, results of the execution will be returned to the researcher. We envision to develop a library of pre-approved code that can be executed by the training agent without data owners' intervention. This library of pre-approved code will differ from data owner to data owner, hence reflecting both the data owner's comfort level and dataset requirements. PET methods and privacy budget will be transparently applied to all code execution to prevent data leakage. Finally, the case of descriptive analytics will follow a similar behavior, but without requiring the explicit intervention of the data owner.
B. Data Collection We will harmonize clinical datasets into a common format and inject them into the TRUMPET private repositories. With the support of technical partners, hospital partners (IRST IRCCS and CHU de Liège) will align their data with a common data model. They will also extract information from databases, data warehouses or other types of data sources that can be shared with the TRUMPET platform to support the three use cases. This data collection will be performed in batch mode (see Figure  4 ). There will be no data continuously streamed from the clinical databases to the TRUMPET data owner node. It shall also be understood that only data for those patients matching the inclusion and exclusion criteria of the TRUMPET use cases will be extracted. Moreover, the complete patient record will not be extracted.
2) Independent Penetration Testing: With the aim of fostering trust of data owners in the TRUMPET platform, the project will (1) engage external penetration test experts to validate the privacy protection, and (2) provide a PPT (Privacy Penetration Test) facility for data owners to carry out independent privacypentesting via the TRUMPET platform against their own datasets. The external independent expert will launch attacks against a test dataset in one of the hospitals through the TRUMPET platform. To do this, the expert will be given freedom to use the TRUMPET PPT utility and the Researcher dashboard, having the role of a malicious user of TRUMPET. 3) Characterization of Robustness: Privacy is undoubtedly a critical aspect of the TRUMPET platform, as should always be the case when dealing with sensitive information.
However, the robustness of ML-based systems is equally important to establish trust and credibility. To this end, several empirical and formal methods and tools can be used for the test and verification of the desired robustness properties. Some federative platforms  [15]  can serve as a unique entry point for such an effort, seamlessly handling the inner encoding to a set of state-of-the-art tools, as well as the aggregation of their results and the generation into summarizing tables and graphs. This allows to have a characterization of the ML-based system through pre-defined metrics  [16]  (e. g. , the models are robust within a distance of X around the dataset D) which can support an argumentation of safety to stakeholders and certification bodies. Ultimately, a TRUMPET platform that is both privacy-aware and robust is crucial for building trust, which is essential for its success.
A. PET methods in TRUMPET As it has been already discussed, FL was originally presented as a privacy-preserving technique enabling the training of models on decentralized data sources without needing to transfer the data to a central server. Unfortunately, it has been proven that FL is vulnerable to several inference attacks related to the exposition of the model updates exchanged during training. To ensure resilience to membership inference and attribute leakage attacks, the TRUMPET platform will deploy the most appropriate combination of PETs depending on a number of factors, such as the selected AI model, FL aggregation algorithm, training dataset and the dataset under analysis, as well as scalability and accuracy/performance requirements of the use cases (see Section VI). The following provides a short description of the most relevant PETs in the context of the TRUMPET project: 1) Homomorphic Encryption (HE): It allows for computation directly on encrypted data  [19].
Frameworks such as the one of Pufferfish privacy  [27]  offer more opportunity for fine grained modeling, but task the user with deriving all privacy guarantees by himself. In the TRUMPET project, we will develop statistical privacy metrics: (1) making more fine-grained assumptions, and not only (2) consistent with the other TRUMPET platform components, but also (3) appropriate for our setting in which a limited number of larger, known entities, that can be kept liable for deviation from the protocol, collaborate to train a statistical model on federated data. In the learning scenario, the proposed privacy metrics will rely on statistically modeling the prior knowledge (or, rather, the uncertainty) that the adversary has regarding the target training datasets. In particular, these metrics will quantify how much knowledge the adversary may gain upon observing the exchanged data in each interaction.
This Bayesian approach deviates from the worst-case adversary considered in DP, and is conceptually more aligned with concepts like distributional privacy  [28]  and Pufferfish privacy  [27]. One advantage of these metrics, besides providing higher utility, is the availability of many information-theoretic results that can be almost directly imported. Another advantage is that its formulation is closer to practical attacks that account for the adversary's uncertainty through sampling a dataset that is assumed to be statistically similar to (i. e. partially overlaps) the target dataset  [29] ,  [30].
B. A Tool to Measure TRUMPET Privacy Having a definition of a privacy metric does not lead easily to being able to actually measure privacy according to that metric. For example, there is a vast literature considering specific algorithms in isolation and studying their privacy guarantees, but far less attention has been paid to the setting where a researcher interacts with a federated data set and decides on the next query after having seen the answer to the previous one. In order to address this issue, TRUMPET will develop a tool that keeps track of the privacy budget a researcher has used so far. By doing so, we aim at not only using the classic composition rules, which have been studied for differential privacy, but also to let the tool look more intelligently at the queries, searching for tighter upper bounds of the actual privacy budget consumed.
In the FL scenario, it is often the case that the Data Owners also interact with the Aggregator through the exchange of updates of the model that is being learned. Each of these updates potentially leaks information regarding the contents of the training dataset available at each Data Owner. The availability of a privacy budget and, more importantly, a practical way of measuring how much information has been leaked becomes crucial in such an interactive scenario: on the one hand, it may serve to establish to which extent the exchanged data must be protected/obfuscated by PET methods; on the other hand, it may lead to hard rules on the federation, for example, by preventing a Data Owner from submitting further updates whenever the budget limit has been reached.
V. GDPR COMPLIANCE OF AFL Regulation (EU) 2016/679 (General Data Protection Regulation, GDPR) applies to any processing of personal data, including the training of machine learning (ML) algorithms on data relating to identifiable individuals. Federated learning (FL) has gained recent popularity as a privacy-preserving technology that can help ML solutions achieve GDPR compliance due to its capability to train algorithms on various datasets without the transfer of any personal data. As data never leaves its source and is not collected in a central location, FL solutions can be used to ensure better security for personal data. This was recently highlighted by ENISA, which confirmed that FL can help preserve the privacy of data and protect against the unauthorized disclosure of sensitive data  [31].
The AFL methods TRUMPET will develop combining FL with other PETs are therefore crucial for reducing the risk of reidentification of data subjects (see Sections III and IV). Second, while AFL methods are essential for ensuring data privacy and security, data controllers using the TRUMPET AFL platform remain responsible for ensuring compliance with all GDPR principles. In particular, they should implement measures to prevent any unfair or arbitrary treatment of data subjects, including by performing Data Protection Impact Assessments (DPIAs) to assess any risks for the data subjects. Data owners should ensure that in cases where previously collected personal data are re-used for training ML models, the new purpose for which they are processing those data is compatible with the original one.
VI. RESEARCH WITH DISTRIBUTED CLINICAL DATA The AFL-based TRUMPET platform will give the possibility for researchers to develop statistical AI models from distributed clinical datasets, while providing strong privacy guarantees and without transferring data out of each hospital's infrastructure. We will consider three different clinical use cases to demonstrate the capability of the TRUMPET platform in the field of cancer treatment and diagnosis. A. Use Cases' Description 1) Non-small Cell Lung Cancer (NSCLC) Use Case: It is the primary cause of cancer-related death worldwide. Patients with advanced non-oncogene addicted disease usually benefit from treatment with immune checkpoint inhibitors (ICIs), which are able to reactivate the repressed immune response against tumor cells. However, only a portion of patients achieves durable clinical benefit from these treatment approaches  [34].
C. Ethical Aspects of the Clinical Use Cases The main ethical aspects of the TRUMPET project relate to the use of retrospective patient health data for the three TRUMPET platform use cases. The required ethical approval actions for the use of patient health data are being prepared and performed by IRST IRCCS and CHU de Liège before starting work on any of the above described use cases. In order to address and mitigate potential risks for data subjects stemming from the secondary use of data within TRUMPET, a Data Protection Impact Assessment (DPIA) will be performed, and the necessary technical and organisational measures (such as de-identification and encryption of personal data) will be implemented throughout the project to ensure the security of patient data and compliance with data protection requirements.
VII. SOME CONCLUSIONS AND EXPECTED RESULTS This work has given an overview of the scope and main technical aspects of the EU-funded project TRUMPET: • The main objective is to provide a highly scalable FLbased service platform for researchers. • The TRUMPET platform will allow to perform collaborative studies with cross-border European datasets and with privacy guarantees that follow GDPR requirements. • Two concrete technical objectives: (1) research and development of FL-tailored PET methods, and (2) research and development of a set of novel privacy metrics and a tool for the privacy evaluation of FL implementations. • Identify and perform a legal study of the implications of GDPR in FL implementations. Moreover, even if the GDPR is an European regulation, different European countries may apply further restrictions.
TRUMPET will necessarily take this into account in the legal study. • The project will engage external penetration test experts to validate the privacy protection, and provide a facility for data owners to do independent privacy-pentesting. • The use cases cover major unmet clinical needs in treatment and diagnosis of cancer. They emphasize different points of view over the cohorts, either from a disease perspective or from a treatment modality perspective. Thanks to the federated nature of the platform and its privacy metric, the pilots will demonstrate the benefits of Armored FL to streamlining clinical and epidemiological research processes across the EU, while ensuring compliance to the GDPR and national data privacy laws.
In this systematic review, we assess the literature while focusing on three main characteristics of the studies (i) the navigation advice that the devices provide, (ii) the technology on which the devices rely and (iii) the experimental methodology used to test the devices. Doing so, we aim at answering the following questions: (i) Which devices providing navigation assistance for people with dementia have been developed and tested? (ii) Do they improve navigation abilities and daily living? (iii) Which characteristics are the most beneficial? (iv) How were the devices assessed? In the remainder of this article we present in Section 2 the methodology we used to search, select and extract data from the literature. Then, in Section 3 we present the results obtained from our analysis of the literature focusing on three main points: the navigation advice provided, the technology that provided the advice and the experimental methodology used to assess the device.
Study selection To summarize the state of the art regarding navigation assistance systems tested with persons with dementia, a systematic literature search has been conducted in the Scopus and PUBMED databases as described in Figure  2. PRISMA and ENTREQ guidelines were followed for this comprehensive search that aimed at seeking all available studies, i. e. , preplanned search (see Supplementary material Table  named  Adequacy to ENTREQ statement). The following field-related terms connected by Boolean operators were used: (wayfinding OR guiding OR navigation OR indoor traveling OR outdoor traveling) AND (alzheimer OR dementia OR mild cognitive impairment) AND (device OR tool OR system OR instrument OR glasses OR smartphone OR gps OR virtual reality OR augmented reality OR mixed reality OR windshield).