140mm(0.1mm,-2cm)

This is the authors’ preprint version. The article is accepted for publication
in the Special Issue on Data Transparency in the ACM Journal of Data and
Information Quality (JDIQ). ©2021

# Knowledge-driven Data Ecosystems Towards Data Transparency

Sandra Geisler<EMAIL_ADDRESS>Fraunhofer FIT and RWTH
Aachen University, GermanySchloss BirlinghovenSankt Augustin53757 ,  Maria-
Esther Vidal<EMAIL_ADDRESS>TIB-Leibniz Information Centre for Science
and Technology, GerrmanyWelfengarten 1BHannover30167 ,  Cinzia Cappiello
<EMAIL_ADDRESS>Politecnico di Milano, Italypiazza Leonardo da
Vinci 32Milano20133 ,  Bernadette Farias Lóscio<EMAIL_ADDRESS>Federal
University of Pernambuco, BrazilCidade UniversitariaRecife/PE50740-560 ,
Avigdor Gal<EMAIL_ADDRESS>Technion Israel Institute of Technology,
IsraelTechnion CityHaifa32000 ,  Matthias Jarke<EMAIL_ADDRESS>RWTH Aachen University and Fraunhofer FIT, GermanyAhornstrasse 55Aachen52056 ,
Maurizio Lenzerini<EMAIL_ADDRESS>Sapienza Università di Roma,
Italyvia Ariosto 25RomaI-00185 ,  Paolo Missier<EMAIL_ADDRESS>Newcastle University, United KingdomFirebrick AvenueNewcastle upon TyneNE4 5TG
,  Boris Otto<EMAIL_ADDRESS>TU Dortmund University,
GermanyOtto-Hahn-Str. 12Dortmund44227 Fraunhofer ISST, GermanyEmil-Figge-
Straße 91Dortmund44227 ,  Elda Paja<EMAIL_ADDRESS>IT University of Copenhagen,
DenmarkRued Langgaards Vej 7Copenhagen SDK-2300 ,  Barbara Pernici
<EMAIL_ADDRESS>Politecnico di Milano, Italypiazza Leonardo da Vinci
32Milano20133 and  Jakob Rehof<EMAIL_ADDRESS>TU Dortmund
University, GermanyOtto-Hahn-Str. 12Dortmund44227 Fraunhofer ISST,
GermanyEmil-Figge-Straße 91Dortmund44227

(2021)

###### Abstract.

A _Data Ecosystem_ offers a keystone-player or alliance-driven infrastructure
that enables the interaction of different stakeholders and the resolution of
interoperability issues among shared data. However, despite years of research
in data governance and management, trustability is still affected by the
absence of transparent and traceable data-driven pipelines. In this work, we
focus on requirements and challenges that data ecosystems face when ensuring
data transparency. Requirements are derived from the data and organizational
management, as well as from broader legal and ethical considerations. We
propose a novel knowledge-driven data ecosystem architecture, providing the
pillars for satisfying the analyzed requirements. We illustrate the potential
of our proposal in a real-world scenario. Lastly, we discuss and rate the
potential of the proposed architecture in the fulfillment of these
requirements.

Data transparency, data ecosystems, data quality, trustability

††copyright: acmcopyright††journalyear: 2021††doi:
10.1145/1122445.1122456††journal: JDIQ††journalvolume: 37††journalnumber:
4††article: 111††publicationmonth: 8

##  1\. Introduction

Industrial digitalization and the use of information technologies in public
and private sectors provide evidence of the pivotal role of data. However,
despite the paramount relevance of data-driven technologies, organizations
demand alliance-driven infrastructures capable of supporting controlled data
exchange across diverse stakeholders and transparent data management.

_Data Ecosystems (DEs)_ are distributed, open, and adaptive information
systems with the characteristics of being self-organizing, scalable, and
sustainable (Oliveira and Lóscio, 2018). While centered on data, the main
concern with DEs is about knowledge generation and sharing. Thus, they aim to
solve issues like learning from unstructured and heterogeneous data, and
construct new abstractions and mappings. They may also offer various data-
centric services, including query processing and data analytics.

DEs are equipped with computational methods to exchange and integrate data
while preserving personal data privacy, data security, and organizational data
sovereignty. The report of the Dagstuhl Seminar 19391 (September 22-27,
2019)111http://www.dagstuhl.de/19391 on Data Ecosystems: Sovereign Data
Exchange among Organizations (Capiello et al., 2020) contains summaries of
discussions and abstracts of talks from the seminar on various topics,
including requirements, use cases, and architectures. Diverse reference
architectures rely on DE foundations (Bader et al., 2019; Lopez de Vallejo et
al., 2020). Keystone player-driven data ecosystems and B2C platforms like
Google, Alibaba, or Facebook are hugely successful. In contrast, the adoption
of alliance-driven platforms which aim at more equitable control and data
sharing (Otto and Jarke, 2019) is still lagging, even in crucial domains such
as data-driven B2B engineering collaboration (Jarke, 2020) or biomedicine.
This paper focuses on the alliance-driven setting, even though many addressed
issues occur also in the other category.

A few works address general data quality (DQ) aspects of DEs (e.g., (Batini
and Scannapieco, 2016; Kitsios et al., 2017; Donker and van Loenen, 2017;
Zhang et al., 2019)). In (Donker and van Loenen, 2017), the authors focus on
open DEs and claim that data availability and DQ need to be guaranteed, so as
to prevent users to be hesitant to use data. Kitsios et al. (Kitsios et al.,
2017) depict DQ assessment as one of the fundamental components for building
and maintaining a DE. DQ assessment requires the definition of a DQ model
composed of DQ dimensions and metrics. Several DQ dimensions have been defined
in the literature, as discussed in (Batini and Scannapieco, 2016). Many
dimensions have a possible impact on data fairness and trustability, in
particular completeness, accuracy, and consistency, which have a significant
impact both, on transparently processing data for analysis and on data
pipelines. The lack of accountability for data transparency is one of the
severe limitations of existing interoperable methods and represents a critical
aspect of data quality. This paper starts from the hypothesis that these
limitations could be a significant reason for the slow adoption of DEs.

To account for data transparency, the rest of this paper offers the following
contributions: (1) an analysis of the specific requirements arising for DEs
and from DEs regarding data governance and transparency aspects; (2) a new
form of _networks of knowledge-driven DEs_ towards trustworthiness and wider
adoption; (3) challenges that stem from the identified requirements; and (4)
an assessment of how the various DE types address these requirements.

##  2\. Requirements of Transparent Data Ecosystems Motivated by an Example

We motivate the need for expressive data ecosystems with an example from the
health domain. Subsequently, we grasp the requirements demanded for data
transparency in similar scenarios.

###  2.1. Motivating Example

Consider a use case of multi-site clinical studies as an example to illustrate
the impact that managing multiple stakeholders have on interoperability and
transparency requirements. In these studies, several parties are involved;
they include clinics, resident doctors, data scientists, patients, study
nurses, quality assurance, researchers, and care services. A stakeholder may
have multiple sources generating data. For example, clinicians conduct
examinations and collect, amongst others, sensor readings, medical images,
test results, and diagnostic reports. These data collections are processed
(e.g., transformed, curated, and integrated); for transparency reasons, they
are potentially annotated with meta-data, domain vocabularies, and data
quality values.

Data is analyzed to uncover insights that can support clinicians to conduct
thoughtful diagnostics and effective treatments. Data management tasks are
also influenced by the organization’s regulations or higher instances, such as
regulations for data protection or rules defined by the hospital, and
strategic decisions. Patients may require transparency about both, their
treatment and the privacy protection of their data in cross-clinical studies.
Each of these data management tasks brings up already multiple challenges for
data transparency and data quality management. Additionally, data is exchanged
between stakeholders to fulfill the goals of the studies; data collected from
the various sites has to be pseudonymized and integrated to be audited by
quality assurance. But transparency of these processes must be maintained to
protect against scientific fraud. Further integration with data from
additional parties, such as health insurance companies, may be needed to be
finally analyzed by study researchers.

The study setting corresponds to a _network of knowledge-driven DEs_. This
network aligns the stakeholder DEs and their data; it also uses meta-data to
describe the network and its constituents. Furthermore, the network is
influenced by regulations, contracts, or agreements specific to the study at
hand. They may include participation agreements created by insurance companies
and patients consent forms authorizing data usage for specific studies.
Heterogeneity issues across the different network DEs impose challenges for DQ
management. Moreover, documenting computational methods performed to assess
and curate data quality issues is crucial to guarantee data transparency.

###  2.2. Requirements Analysis

The motivating example highlights the multiple issues that a DE needs to cover
in order to enhance trustability of the involved stakeholders. These issues
are not only present in biomedical applications, but rather exist in any
application where crucial decisions are driven by data (Barbero et al., 2020).
Based on literature and reports from current European data sharing and data
space projects (Barbero et al., 2020; Otto et al., 2019; Curry and Sheth,
2018), requirements can be categorized along data management, organizational
aspects, and legal and ethical issues. In terms of _data management_ ,
tackling the challenges outlined in the motivating example, demands (meta)data
sharing among different stakeholders in a secured and traceable manner. At an
_organization level_ , trustable data exchange requires complex ecosystems
that underlie organizational-specific business models, processes, and
strategies to enforce sovereignty, privacy, and protection of both, data and
analytical outcomes. Furthermore, sharing sensitive and personal data, e.g.,
clinical records, should comply with data protection regulations and legal
compliance at national and international levels. More importantly, accounting
for ethical decisions made by stakeholders and algorithms is crucial and the
ability to provide reliable and verifiable explanations of these decisions.
Meeting these requirements at a _legal and ethical level_ empowers DEs to
safeguard data privacy and mitigate unfairness in data-driven pipelines.
Moreover, the satisfaction of these requirements provides the foundations for
ensuring that clinical data is only used according to consents given by these
data owners, i.e., the patients. Next, each of these three requirement
categories is described in more detail.

#### Data management requirements

DEs, as described in the motivating example, demand sharing of data with a
high variety (e.g., in terms of type, structure, size, or frequency). The
requirements listed in this category concern both, data and metadata. Data
quality management has to be able to (DMR1) _handle all kinds of data and
offer common DQ tools_ to describe, query, and assess quality values for the
data. In the medical domain for example, this comprises unstructured data,
such as images and texts, but also highly structured data from databases, csv
files, and data streams. Additionally, (DMR2) _the data has to be fit for
sharing_. Data has to exhibit quality values, which fulfill a certain quality
standard, suitable for sharing it in a defined context. Data consumers,
especially in data markets, have thereby the possibility to query data based
on its quality. Hence, data can be rejected, if it does not satisfy the
negotiated standards. In the motivating example, this could mean that the
reading center rejects the data, because important values are missing, i.e.,
the completeness of the data set is too low. Furthermore, data transparency
plays a crucial role for enhancing trust for all stakeholders. (DMR3) _Data
transparency has to be enabled from the origin of the data until its usage._
At any time in a data-driven pipeline, the current meaning of the data has to
be available, as well as metadata describing data transformations made by the
different components of the pipeline. This explicitly includes traceability
and transparency of algorithms and their results (e.g., for data curation and
integration, or for prediction). Consider for example the use of data from
cancer registries by researchers and other registries. Both need to know
explicitly how the data has been acquired and modified to estimate its value
for the research at hand. Potential conflicts between data transparency and
company secrets or privacy may exist. Thus, transparency must be offered to
all the stakeholders according to their role in the DE, and in terms of
consent management and usage control. Hence, (DMR4) data quality management
needs to _take trade-offs into account and provide dimensions and assessment
metrics_ that enable stakeholders to rate the possible impact of, e.g., data
curation. Anonymized medical data for example may loose its value for further
research if important attributes are eliminated from a data set. Lastly, data
integration and querying over multiple data sources and across organizations
are required in a multitude of scenarios. For this, mappings among data
sources are defined either manually or (semi-)automatically by schema
matching. For data quality management this implies several aspects, but
basically (DMR5) _stakeholders should be part of the loop of data quality
assessment_. They should be able to rate the quality of every step in a data-
driven pipeline, e.g., schema and entity mappings or query answers. The
automatic matching between huge medical taxonomies, e.g., for decision support
systems, may be very error-prone as the taxonomies per se have quality
problems. (DMR6) _The impact of adding a new component to a DE should be
measurable._ The DEs and their stakeholders should be able to rate the impact
of, e.g., the information gain of adding a new data set. This is a crucial
aspect especially when considering to pay for a costly data set or when the
integration of the data set requires a lot of upfront effort in terms of data
cleaning, transformation, or data integration.

#### Organizational-centric requirements

In cases of sensitive data exchange and processing, data must be transparently
used according to organizations’ policies, as well as its business models and
strategies. (OCR1) _Enabling data governance_ is crucial for the appropriate
data exchange and sharing according to the organizations’ strategies and
business models. (OCR2) _Ensuring traceability of data sovereignty_ is
essential to increase trust among stakeholders. Again this has to be ensured
throughout the whole data processing pipeline including data quality
assessment and curation. For example, the willingness of patients to use
applications or participate in studies may be increased by giving them the
opportunity to enforce access and usage policies. Furthermore, (OCR3)
_business, certification, and utility models need to be established_ to
certify, based on data quality values and other characteristics, the monetary
value of exchanged and transformed data. The monetary value of medical data is
manifold, e.g., data from clinical studies may be of interest to other
parties, such as pharmaceutical or insurance companies, to create or improve
products. (OCR4) _Adherence to data and data processing standards_ is required
to enhance DQ and interoperability across stakeholders, which is specifically
important in the medical domain. Standards such as
FHIR222http://www.hl7.org/fhir/index.html have made an important step forward
reaching these goals in the clinical domain. (OCR5) _Flexible DQ management_
for different coordination and negotiation models among stakeholders (e.g.,
clinics, data scientists, and insurance companies), and considering the
evolution of these models over time.

#### Legal and ethical requirements

As shown in the motivating example, respecting personal data privacy and
security during data management, exchange, and analytics impairs requirements
at both, legal and ethical levels. Both categories of requirements are aligned
with the European Union guidelines for Trustworthy AI (EU, 2018). (L&ER1)
_Providing expressive legal frameworks for exchanged data_ , including legal
references, responsibilities, licenses, and ethical guidelines is essential.
(L&ER2) _Accounting and mitigating bias and fairness_ ensure that the outcomes
of the execution of the system components are independent of sensitive
attributes (e.g., gender, age, ethnicity, or health conditions) and augment
confidence in the impartiality of the system behavior. (L&ER3) _Endeavouring
safeness and robustness_ of the decisions made by each component that
exchanges, processes, or analyzes data. Thus, the deployment of data-driven
pipelines and their outcomes will guarantee the compliance with ethical
guidelines (e.g., the respect of the patient consents), and the misuse
reduction that could conduce to data quality issues, data privacy violation,
and unfairness. (L&ER4) _Enforcing data protection and ownership_ safeguards
privacy, sovereignty, and legal compliance with licenses and regulations for
data sharing, exchange, and processing. Thus, the satisfaction of this
requirement will ensure that clinical data is used by the distinct parties as
indicated in the patient’s consents. (L&ER5) _Pursuing diversity and non-
discrimination_ in data collections shared, exchanged, and processed by data-
driven pipelines. As a result, the risk of excluding specific entities (e.g.,
patients with a given health condition) is mitigated, and the chances of
covering all the representative entities of the population increase. (L&ER6)
_Trackability of regulations compliance_ in the way that each data-driven
decision can be documented and validated in terms of legal regulations,
business models, and ethical guidelines. Lastly, (L&ER7) _Trustworthiness and
Reliability_ of data-driven pipelines demand the accurate measurement,
validation, and interpretation of each of the decisions taken by the system
components in compliance with legal and ethical guidelines of the
stakeholders. Thus, data owners (e.g., patients, insurance companies, and
researchers) will be able to trace management and analysis methods performed
over their data.

As illustrated in the next section, this paper positions _networks of
knowledge-driven DEs_ as alliance-driven decentralized infrastructures
empowered with components to satisfy the requirements listed above. Lastly,
section 4.1 presents the challenges to be achieved to meet these requirements.

##  3\. Knowledge-driven Data Ecosystems: Overview & Architecture

The literature defines DEs in different ways. For instance, Oliveira and
Farias Lóscio (Oliveira and Lóscio, 2018) define Data Ecosystems as a “set of
networks composed of autonomous actors, which consume, produce, or provide
data or other related resources.” Other definitions add that the results
created by the consumption and processing of the data should return to the
ecosystem (Pollock, 2011). In (Barbero et al., 2020; Otto et al., 2019), the
emergence of the concept of DEs is traced and taxonomically situated among
related concepts such as Business Ecosystems, Digital Ecosystems, and Platform
Ecosystems (Guggenberger et al., 2020).

Cappiello et al. (Capiello et al., 2020) synthesized the following
comprehensive definition of a data ecosystem DE as a 4-tuple DE=$\langle$Data
Sets, Data Operators, Meta-Data, Mappings$\rangle$ where:

  * •

Data sets can be structured or unstructured, can have different formats, e.g.,
CSV, JSON or tabular relations, and can be managed using different management
systems.

  * •

Data Operators are functions used for accessing or managing data in the data
sets.

  * •

Meta-Data provides means for describing the DE context domain, can be used to
specify the meaning of data and associated data operations. It comprises  i)
Domain ontology, providing a coherent and unified view of concepts,
relationships, and constraints of the domain of knowledge, associating formal
semantics with the elements of the domain. If appropriate, several ontologies
for different portions of the domain can be devised.  ii) Propertiesthat
enable the definition of qualitative aspects for the elements of the
ecosystem, such as quality and provenance requirements for data sets and
operations.  iii) Descriptionsto associate annotations to the elements of the
system for explaining relevant characteristics of data sets and operations. No
specific formal language or vocabulary is required in descriptions.

  * •

Mappings express correspondences among the different components of the data
ecosystem. The mappings are as follows:  i) Mappings among ontologiesto
represent associations among concepts in different ontologies constituting the
domain ontology of the ecosystem.  ii) Mappings between data sets and
ontologyto represent relations among the data in the DE data sets and the
domain ontology, to allow for their interpretation in terms of the ontology.

Data ecosystems can be further empowered with services that exploit the
knowledge encoded in the meta-data and operators to satisfy business
requirements, such as data transparency and traceability. We nam these
_knowledge-driven data ecosystems_. Services include query processing, data
transformation, anonymization, data quality assessment, or mapping generation.
The following correspond to examples of notable services:

  * •

Concept or mapping discovery: identify a new concept or a new mapping using
inductive reasoning and techniques from schema matching, taking into account
aspects of uncertainty (Gal, 2011). Based on the result, the domain ontology
and the mappings can be augmented.

  * •

Data set curation: identify the best way to keep humans in the loop in order
to create a curated version of a data set in a DE (see (Ackerman et al., 2019)
for limitations of humans in matching). Services can also update the
properties of a DE to indicate the provenance of the new curated data sets and
manage new generated data from data transformation, analysis, and learning.

  * •

Procedure synthesis: construct new procedures out of data operators and other
building blocks by composing existing services towards new goals. In complex
and evolving systems, it is infeasible to program procedures and even queries
without automatic support. Also, exploring repositories and libraries of
existing procedures should be possible.

In our running example, stakeholders like clinics, insurance companies, and
researchers can create their own knowledge-driven DE. Each DE comprises data
sets and programs for accessing, managing, and analyzing their data.
Interoperability issues across data sets of a DE are solved in a unified view
represented in the DE ontology. Mappings between the data sets and the DE
ontology describe the meaning of the data sets. Moreover, the description of
the data operators enhances data transparency and provides the basis for
tracking down the computational methods executed against a DE.

Figure 1. A Network of Data Ecosystems Empowered with Strategy and Business
Models and Regulations.

To enable collaboration across various knowledge-driven DEs and cope with
complex scenarios, a set of DEs can be connected in a network. For this, we
envision an ecosystem-wide meta-data layer where the entire ecosystem is
described. Figure 1 depicts a network where nodes and edges correspond to
knowledge-driven DEs and mappings among them, respectively. In this
configuration, the meta-data layer describes each of the nodes (i.e., DE) in
terms of descriptions, properties, and domain ontologies. The following
mappings can be defined among a network DEs:

  * •

Mappings between domain ontologies: state correspondences among the domain
ontologies of two nodes or between one node and the global meta-data layer.

  * •

Mappings between properties: describe relationships among properties in two
nodes. For example, the provenance of two curated versions of a data set could
be the same.

  * •

Data set Mappings: represent correspondences among data sets of different
nodes.

Finally, knowledge-driven DEs can be enhanced with additional meta-data layers
to enable the description of business strategies and the access regulations.
Figure 1 depicts the main components of a network of knowledge-driven DEs
empowered with these layers. As can be observed, this enriched version of a
network of DEs comprises:  (1) Ontological formalisms or causality models that
enable the description of the relationships between the data sets received as
input and produced as output for the services or operators of a DE.  (2) Meta-
data describing business strategies that enable the definition of the
stakeholders of the network and their roles.  (3) Objectives to be met and the
dependencies among the tasks that need to be performed to achieve these
objectives.  (4) Agreements for data exchange and criteria for
trustworthiness.  (5) Regulations and licenses for data access and for data
privacy preservation.  (6) Services composing services of the nodes of the
network.  (7) Services able to monitor and explore decisions taken by services
and operators.

A network of knowledge-driven DEs will facilitate controlled data exchange
across stakeholders in the running example. This network can be hosted and
maintained by the consortium of stakeholders. The meta-data layer specifies
alignments among the data sets in each DE. It enables the definition of
business models and access regulations to be satisfied when the data from one
DE (e.g., the clinics DE) is transferred to other DEs (e.g., the DE of the
insurance companies or the researchers). Moreover, the formal descriptions of
the data sets and operators enhance transparency not only at an individual DE
level (e.g., clinics or insurance companies), but also in the network. Lastly,
services to monitor how exchanged data is processed in the various multi-site
clinical studies empower the network to verify if legal and ethical
regulations are fulfilled.

##  4\. Enabling Data Transparency in Data Ecosystems

In this section, we discuss what are the challenges implementing the three
groups of requirements introduced in Section 2.2 in the network of knowledge-
driven DEs. In Section 4.2 we evaluate and rate how hard it is to meet the
requirements for the different types of DEs we defined in this section.

###  4.1. Challenges of Enabling Data Transparency in Data Ecosystems

Data Management Requirements. Sharing heterogeneous data requires guarantees
in terms of data quality and transparency. As regards data quality, all the
collaborative entities should assess data quality using a common set of DQ
services.

In fact, in order to get the maximum benefits from the participation to a DE,
actors should be able to identify, evaluate, and get the most suitable data
for the intended usage. Starting from facilitating the access to available DE
data, some existing solutions propose that query processing over heterogeneous
data sets rely on a unified interface for overcoming interoperability issues,
usually based on meta-models (Jeusfeld et al., 2010). A few DEs have been
proposed, mainly focusing on data ingestion and meta-data extraction and
management. Exemplary approaches include Constance (Hai et al., 2016) and
Ontario (Endris et al., 2019). Data integration enables the transformation of
heterogeneous data sources or views under a unified access schema (Lenzerini,
2002). Data integration systems comprise data collection and curation steps
and resort to record linkage, schema matching, mapping, and data fusion to
integrate data from a collection of data sets (Croce et al., 2020). At the
heart of the data integration realm lies the matching task (Bellahsene et al.,
2011), in charge of aligning attributes of data sources both at a schema and
data level, in order to enable formal mappings. Numerous algorithmic attempts
(matchers) were suggested over the years for efficient and effective
integration (e.g., (Chen et al., 2018; Do and Rahm, 2002; Kenig and Gal, 2013;
Konda et al., 2016)). Both practitioners and researchers also discussed data
spaces as an appropriate data integration concept for DEs. Data spaces do not
require a common schema and achieve data integration on a semantic level.

Moreover, only a small percentage of data integration systems provide causal
explanations to support traceability (Wang et al., 2018), as well as query
processing methods to navigate these explanations (Rekatsinas et al., 2019)
efficiently. Existing rule-based approaches that allow for a declarative
specification of data transformation, integrity, and integration represent
building-blocks for tracking the validity of the domain constraints in all the
data-driven pipeline steps in a knowledge-driven DE. These approaches include
rule-based entity linking (e.g., (Sakor et al., 2020)), mapping-based tools to
perform the process of data integration (e.g., (Jozashoori et al., 2020)), and
declarative languages like SHACL (Corman et al., 2019), to describe integrity
constraints. Knowledge-driven DEs represent a new paradigm for data
integration able to trace and annotate provenance and causal relations
existing during data ingestion, curation, and integration (Heyvaert et al.,
2019).

DQ challenges are also related to the data variety, and to the fact that the
description and measurement of data quality is highly subjective (Redman,
2001), especially if data are used for completely different purposes from the
ones they were originally collected for (re-purposing). Algorithms able to
describe and assess the quality of very heterogeneous sources and very
different stakeholder views are required, together with an agreement about DQ
assessment standards in the DE. These standards must include general DQ
dimensions but also be derived from the domain at hand to be accepted by the
parties sharing the data. The DQ assessment phase requires to provide meta-
data and rules to support the selection and reuse of data. DQ should be also
assessed on derived data. Challenges here are related to the evaluation of the
quality of the outputs of any transformation (e.g., aggregation, formulas,
integration) and to the fact that in some cases quality evaluation could be
performed in a semi-automatic way. Different stakeholders may have different
views on them (e.g., different levels of granularity) and, as a consequence,
their integration needs may vary. The input offered by stakeholders regarding
the quality of the integration is therefore needed to tailor it to their
needs. Data transparency is enabled by a combination of accurate meta-data,
including provenance. The facilities to add these to a single, isolated DE are
described in Section 3.

Networks of DEs introduce further complications: i) meta-data descriptions
provided for similar entities by each DE may differ, and may require semantic
re-conciliation; ii) levels of transparency provided through provenance may
differ across the nodes. A general challenge is therefore to achieve full
transparency, or at least formally characterize the boundaries of what is
visible, in the presence of “black spots” in the global information flow
across all nodes in the network. Specific transparency challenges are also
related to the difficulties in tracking all the operations performed on data.
These new tasks call also for novel reasoning services, based on a sort of
reverse engineering process, which rewrites data source queries in terms of
global schema (or, ontology) expressions. Future technical support for
transparency, traceability, and usage policy enforcement could be developed
from distributed ledger technology (e.g., blockchains) and secure multi-party
computation (MPC) services.

Organization-centric Requirements. The enabling of data governance by several
collaborating entities requires the management of different governance models,
different levels of data governance maturity, and a clear attribution of
responsibilities. The traceability of data sovereignty requires process or
dependency models which define how data sovereignty has been executed, e.g.,
by usage control. The challenge is here to define the content and granularity
of information a data owner needs to know based on her role according to
regulations valid for the domain. A further challenge is to consider data
quality assessment and curation, that can add bias to the data and may also
lead to unwanted usage of the data. We need to find business models and
regulations which respect the interests of involved stakeholders, adequately
react to unwanted data usage, and increase the trust between them. A big
challenge is how a data ecosystem can ensure that stakeholders comply to data
and data processing standards. Usually, all stakeholders implement their own
processes in multiple ways. Enforcing certain standards in a data ecosystem or
network of data ecosystems to ensure data quality and data transparency across
heterogeneous processes and their interactions is challenging. It requires to
negotiate common standards and developing a model feasible for SMEs and big
stakeholders to implement. Stakeholders could get a certification which
testifies that they adhere to the standards. This makes the quality grade of
data sources more transparent to data consumers. As described by Curry and
Sheth (2018) data ecosystems may vary according to the degree of interaction
between stakeholders, coordination of data exchange, and control over data
sources. This variety heavily influences also data quality management as it
may substantially change the way to assess, monitor, and improve data quality
depending on the model.

Legal & Ethical Requirements. The satisfaction of laws, fundamental rights, or
ethical guidelines demands traceability and certification of data-driven
pipelines in a DE. The big challenge is to devise services capable of
certifying robustness in data ecosystems according to the national and
international legal norms for data protection and fundamental rights, while
safeguarding data sovereignty. Furthermore, formalisms, models, and
computational algorithms able to interoperate across various stakeholders
represents grand challenges to ensure data transparency.

###  4.2. How can Data Ecosystems Fulfil Data Transparency Requirements?

Concluding our analysis, we analyze the three DE architectures presented in
Section 3 with respect to their potential in satisfying the requirements and
overcoming the challenges towards data transparency. Each requirement is
graded following a three-stars scheme:  i) $\star$means that the requirement
is unsatisfied;  ii) $\star$$\star$indicates that the data ecosystem has the
potential to satisfy the requirement, but it is challenging;  iii)
$\star$$\star$$\star$states that the data ecosystem has the potential to fully
satisfy the requirement.  Each requirement is also evaluated in terms of three
levels of satisfaction:  I) Complete:The requirement is fully achieved.  II)
Traceable:The results of the requirement implementation can be traced down.
III) Verifiable:The inspection, demonstration, test, and analysis of the
requirement implementation can be verified.

Table 1. Three-stars Model for Requirement Satisfaction.

Data Management Requirements Data Ecosystem Knowledge-Driven Data Ecosystem
Network of Knowledge-Driven Data Ecosystems Complete Traceable Verifiable
Complete Traceable Verifiable Complete Traceable Verifiable DMR1 $\star$
$\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$
$\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ DMR2
$\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$
$\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$
$\star$ DMR3 $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$
$\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$
$\star$ $\star$ DMR4 $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$
$\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$
$\star$ $\star$ $\star$ DMR5 $\star$ $\star$ $\star$ $\star$ $\star$ $\star$
$\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$
$\star$ $\star$ $\star$ DMR6 $\star$ $\star$ $\star$ $\star$ $\star$ $\star$
$\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$
$\star$ $\star$ $\star$ Organizational Challenges Data Ecosystem Knowledge-
Driven Data Ecosystem Network of Knowledge-Driven Data Ecosystems Complete
Traceable Verifiable Complete Traceable Verifiable Complete Traceable
Verifiable OCR1 $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$
$\star$ $\star$ $\star$ $\star$ $\star$ $\star$ OCR2 $\star$ $\star$ $\star$
$\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$
$\star$ OCR3 $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$
$\star$ $\star$ $\star$ $\star$ $\star$ OCR4 $\star$ $\star$ $\star$ $\star$
$\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$
$\star$ $\star$ $\star$ $\star$ $\star$ $\star$ OCR5 $\star$ $\star$ $\star$
$\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$
$\star$ Legal & Ethical Challenges Data Ecosystem Knowledge-Driven Data
Ecosystem Network of Knowledge-Driven Data Ecosystems Complete Traceable
Verifiable Complete Traceable Verifiable Complete Traceable Verifiable L&ER1
$\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$
$\star$ $\star$ $\star$ $\star$ L&ER2 $\star$ $\star$ $\star$ $\star$ $\star$
$\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$
$\star$ $\star$ L&ER3 $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$
$\star$ $\star$ $\star$ $\star$ $\star$ L&ER4 $\star$ $\star$ $\star$ $\star$
$\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ L&ER5 $\star$
$\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$
$\star$ $\star$ $\star$ $\star$ $\star$ $\star$ L&ER6 $\star$ $\star$ $\star$
$\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ L&ER7
$\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$ $\star$
$\star$ $\star$ $\star$

Table 1 summarizes the analysis of the types of DEs in Section 3. We can
observe that the baseline architecture of DEs has the potential to fulfill
several requirements (i.e., DMR1-DMR6, OCR4, L&ECR2, and L&ECR5). However,
since these DEs are only equipped with data sets, operators, and meta-data, it
is challenging for them to keep the stakeholders in the loop during the data
quality rating or for assessing the impact of adding new components. For the
same reason, these DEs cannot trace or validate the satisfaction of none of
the requirements. In contrast, the other two types of DEs are able to fully
satisfy the data management requirements (i.e., DMR1-DMR6). Nevertheless,
requirement traceability and verifiability still remain a challenge because of
the multiple problems of interoperability, data access, and legal regulations
imposed by the stakeholders of a knowledge-driven DE or each individual node
in a network of DEs. Moreover, a single knowledge-driven DE cannot interact
with other DE or circulate their business, regulations, or strategies. As a
result, most organization-centric and legal and ethical requirements cannot be
satisfied, or if so, it is very challenging. Lastly, networks of knowledge-
driven DEs are equipped with meta-data, services, and strategic and business
models that facilitate the description of each node and the documentation of
the negotiations required to exchange across the network. Thus, despite
traceability and verifiability are challenging, these DEs are the only ones
furnished with components to enable data transparency.

We hope that this analysis contributes to the understanding of data
transparency challenges. We also aim to encourage the research community to
develop trustable networks of knowledge-driven DEs, enabling, thus, DQ
management, data governance, and sovereignty, as well as mechanisms to trace
and verify the requirement fulfillment.

##  5\. Conclusion

In this work, we have tackled the challenges that DEs face on their way to
become “smarter,” equipped with a knowledge layer. In particular, we focused
on data quality and data transparency challenges. Using the motivating example
of multi-site clinical studies, we have outlined six data management
requirements, five organizational-centric requirements, and seven legal and
ethical requirements. We then presented a specific architecture from which
data quality challenges were derived and discussed. Table 1 summarizes the
discussion by presenting for each of three types of DEs to what extent each of
the requirements can be completed, traced, and verified.

With the increasing need for integrated data sets and infrastructures to
support DEs, we expect their impact on organizations to increase. As data
quality in general and data transparency in particular, become a significant
issue in data management, we hope this work offers a guideline for researchers
and practitioners when investigating developments of knowledge-driven DEs.

## Acknowledgements

The authors are grateful to the Dagstuhl team for hosting us in September 2019
(Dagstuhl Seminar 19391). Initial ideas that serve as a basis for this paper
were originated and discussed there. Gal also acknowledges the support of the
Benjamin and Florence Free Chair. Lenzerini acknowledges the support of MUR-
PRIN project “HOPE”, grant n. 2017MMJJRE, and of EU under the H2020-EU.2.1.1
project TAILOR, grant id. 952215. Vidal acknowledges the support of the EU
H2020 project iASiS, grant id. 727658 and CLARIFY grant id. 875160. Geisler
acknowledges the support of the German Innovation Fund project SALUS, grant
id. 01NVF18002. This work has also been supported by the German Federal
Ministry of Education and Research (BMBF) in the context of the InDaSpacePlus
project (grant id. 01IS17031), Fraunhofer Cluster of Excellence ”Cognitive
Internet Technologies” (CCIT) and by the Deutsche Forschungsgemeinschaft (DFG)
under Germany’s Excellence Strategy - EXC-2023 Internet of Production -
390621612. Pernici acknowledges the support of the EU H2020 Crowd4SDG project,
grant id 872944.

## References

  * Ackerman et al. [2019] Rakefet Ackerman, Avigdor Gal, and Roee Sagi, Tomerand Shraga.  A cognitive model of human bias in matching.  In Abhaya C. Nayak and Alok Sharma, editors, _PRICAI 2019: Trends in Artificial Intelligence_ , pages 632–646, Cham, 2019. Springer International Publishing.  ISBN 978-3-030-29908-8.
  * Bader et al. [2019] Sebastian R. Bader, Maria Maleshkova, and Steffen Lohmann.  Structuring reference architectures for the industrial Internet of Things.  _Future Internet_ , 11(7):151, 2019.
  * Barbero et al. [2020] Martina Barbero, Arne Berre, Davide dalle Carbonare, …, and Walter Weigel.  Towards a European-governed data sharing space.  https://www.bdva.eu/sites/default/files/BDVADataSharingSpacesPositionPaperV2_2020_Final.pdf, November 2020.
  * Batini and Scannapieco [2016] Carlo Batini and Monica Scannapieco.  _Data and Information Quality - Dimensions, Principles and Techniques_.  Data-Centric Systems and Applications. Springer, Cham, 2016.  ISBN 978-3-319-24104-3.  doi: 10.1007/978-3-319-24106-7.  URL https://doi.org/10.1007/978-3-319-24106-7.
  * Bellahsene et al. [2011] Zohra Bellahsene, Angela Bonifati, and Erhard Rahm, editors.  _Schema Matching and Mapping_.  Data-Centric Systems and Applications. Springer, Berlin Heidelberg, 2011\.  ISBN 978-3-642-16517-7.  doi: 10.1007/978-3-642-16518-4.  URL http://dx.doi.org/10.1007/978-3-642-16518-4.
  * Capiello et al. [2020] Cinzia Capiello, Avigdor Gal, Matthias Jarke, and Jakob Rehof.  Data Ecosystems: Sovereign Data Exchange among Organizations (Dagstuhl Seminar 19391).  _Dagstuhl Reports_ , 9(9):66–134, 2020.  ISSN 2192-5283.  doi: 10.4230/DagRep.9.9.66.  URL https://drops.dagstuhl.de/opus/volltexte/2020/11845.
  * Chen et al. [2018] Chen Chen, Behzad Golshan, Alon Y Halevy, Wang-Chiew Tan, and AnHai Doan.  BigGorilla: An Open-Source Ecosystem for Data Preparation and Integration.  _IEEE Data Eng. Bull._ , 41(2):10–22, 2018.
  * Corman et al. [2019] Julien Corman, Fernando Florenzano, Juan L Reutter, and Ognjen Savković.  Validating SHACL constraints over a SPARQL endpoint.  In _International Semantic Web Conference_ , pages 145–163, Cham, 2019. Springer.
  * Croce et al. [2020] Federico Croce, Gianluca Cima, Maurizio Lenzerini, and Tiziana Catarci.  Ontology-based explanation of classifiers.  In _Proceedings of the Workshops of the EDBT/ICDT 2020 Joint Conference_ , pages 1–5. CEUR-WS, 2020.
  * Curry and Sheth [2018] E. Curry and A. Sheth.  Next-generation smart environments: From system of systems to data ecosystems.  _IEEE Intelligent Systems_ , 33(3):69–76, 2018\.  doi: 10.1109/MIS.2018.033001418.
  * Do and Rahm [2002] H. H. Do and E. Rahm.  COMA: a system for flexible combination of schema matching approaches.  In _Proceedings of VLDB_ , pages 610–621. VLDB Endowment, 2002.
  * Donker and van Loenen [2017] Frederika Welle Donker and Bastiaan van Loenen.  How to assess the success of the open data ecosystem?  _International Journal of Digital Earth_ , 10(3):284–306, 2017.  doi: 10.1080/17538947.2016.1224938.
  * Endris et al. [2019] Kemele M. Endris, Philipp D. Rohde, Maria-Esther Vidal, and Sören Auer.  Ontario: Federated query processing against a semantic data lake.  In _Database and Expert Systems Applications - 30th International Conference, DEXA 2019, Linz, Austria, August 26-29, 2019, Proceedings, Part I_ , pages 379–395. Springer, 2019.
  * EU [2018] EU2018.  Ethics guidelines for trustworthy AI.  https://ec.europa.eu/digital-single-market/en/news/ethics-guidelines-trustworthy-ai, 2018\.
  * Gal [2011] Avigdor Gal.  Uncertain schema matching.  _Synthesis Lectures on Data Management_ , 3(1):1–97, 2011.
  * Guggenberger et al. [2020] Tobias Moritz Guggenberger, Frederik Möller, Tim Haarhaus, Inan Gür, and Boris Otto.  Ecosystem types in information systems.  In _Twenty-Eigth European Conference on Information Systems (ECIS2020)_ , pages 1–21. Association for Information Systems, 2020.
  * Hai et al. [2016] Rihan Hai, Sandra Geisler, and Christoph Quix.  Constance: An intelligent data lake system.  In _Proc. of the 2016 International Conference on Management of Data, SIGMOD, San Francisco, USA_ , pages 2097–2100. ACM, 2016.  doi: 10.1145/2882903.2899389.
  * Heyvaert et al. [2019] Pieter Heyvaert, Ben De Meester, Anastasia Dimou, and Ruben Verborgh.  Rule-driven inconsistency resolution for knowledge graph generation rules.  _Semantic Web_ , 10(6):1071–1086, 2019.
  * Jarke [2020] Matthias Jarke.  Data sovereignty and the Internet of Production.  In _Advanced Information Systems Engineering, 32nd International Conference; Grenoble_ , pages 549–558, Cham, 2020. Springer.
  * Jeusfeld et al. [2010] Manfred A. Jeusfeld, Matthias Jarke, and John Mylopouos.  _Metamodeling for Method Engineering_.  MIT Press, 2010.
  * Jozashoori et al. [2020] Samaneh Jozashoori, David Chaves-Fraga, Enrique Iglesias, Maria-Esther Vidal, and Óscar Corcho.  Funmap: Efficient execution of functional mappings for knowledge graph creation.  In _The International Semantic Web Conference_ , pages 276–293, Cham, 2020.
  * Kenig and Gal [2013] B. Kenig and A. Gal.  Mfiblocks: An effective blocking algorithm for entity resolution.  _Information Systems_ , 38(6):908–926, September 2013.
  * Kitsios et al. [2017] F. Kitsios, N. Papachristos, and M. Kamariotou.  Business models for open data ecosystem: Challenges and motivations for entrepreneurship and innovation.  In _2017 IEEE 19th Conference on Business Informatics (CBI)_ , pages 398–407. IEEE, 2017.  doi: 10.1109/CBI.2017.51.
  * Konda et al. [2016] Pradap Konda, Sanjib Das, Paul Suganthan GC, AnHai Doan, Adel Ardalan, Jeffrey R Ballard, Han Li, Fatemah Panahi, Haojun Zhang, Jeff Naughton, et al.  Magellan: Toward building entity matching management systems.  _Proceedings of the VLDB Endowment_ , 9(12):1197–1208, 2016.
  * Lenzerini [2002] Maurizio Lenzerini.  Data integration: A theoretical perspective.  In _Proceedings of the Twenty-first ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems_ , pages 233–246. ACM, 2002.
  * Lopez de Vallejo et al. [2020] I. Lopez de Vallejo, S. Scerri, and T. Tuikka.  Towards a european-governed data sharing space.  Technical report, Brussels. BDVA, 2020.
  * Oliveira and Lóscio [2018] Marcelo Iury S. Oliveira and Bernadette Farias Lóscio.  What is a data ecosystem?  In _Proceedings of the 19th Annual International Conference on Digital Government Research: Governance in the Data Age, DG.O 2018, Delft, The Netherlands, May 30 - June 01, 2018_ , pages 74:1–74:9. ACM, 2018.
  * Otto and Jarke [2019] Boris Otto and Matthias Jarke.  Designing a multi-sided data platform: findings from the international data spaces case.  _Electronic Markets_ , 29(4):561–580, October 2019.  URL https://doi.org/10.1007/s12525-019-00362-x.
  * Otto et al. [2019] Boris Otto, Dominik Lis, Jan Jürjens, Jan Cirullies, Sebastian Opriel, Falk Howar, Sven Meister, Markus Spiekermann, Heinrich Pettenpohl, and Frederik Möller.  Data ecosystems - conceptual foundations, constituents and recommendations for action.  Technical report, Fraunhofer ISST, 2019.
  * Pollock [2011] Rufus Pollock.  Building the (open) data ecosystem.  https://blog.okfn.org/2011/03/31/building-the-open-data-ecosystem/, 2011\.
  * Redman [2001] Thomas C. Redman.  _Data Quality: The Field Guide_.  Digital Press, USA, 2001.  ISBN 1555582516.
  * Rekatsinas et al. [2019] Theodoros Rekatsinas, Sudeepa Roy, Manasi Vartak, Ce Zhang, and Neoklis Polyzotis.  Opportunities for data management research in the era of horizontal AI/ML.  _Proc. VLDB Endow._ , 12(12):2323–2324, 2019\.
  * Sakor et al. [2020] Ahmad Sakor, Kuldeep Singh, Anery Patel, and Maria-Esther Vidal.  Falcon 2.0: An entity and relation linking tool over wikidata.  In _CIKM ’20: The 29th ACM International Conference on Information and Knowledge Management_ , pages 3141–3148. ACM, 2020.
  * Wang et al. [2018] Xiaolan Wang, Laura M. Haas, and Alexandra Meliou.  Explaining data integration.  _IEEE Data Eng. Bull._ , 41(2):47–58, 2018\.
  * Zhang et al. [2019] Ruojing Zhang, Marta Indulska, and Shazia W. Sadiq.  Discovering data quality problems - the case of repurposed data.  _Bus. Inf. Syst. Eng._ , 61(5):575–593, 2019\.  doi: 10.1007/s12599-019-00608-0.  URL https://doi.org/10.1007/s12599-019-00608-0.


# Ionization profile monitors for the IOTA proton beam ††thanks: This
manuscript has been authored by Fermi Research Alliance, LLC under Contract
No. DE-AC02-07CH11359 with the U.S. Department of Energy, Office of Science,
Office of High Energy Physics.

H. Piekarz<EMAIL_ADDRESS>A. Romanov  R. Thurman-Keup  Fermilab  Batavia
IL 60510  USA
V. Shiltsev  Northern Illinois University  DeKalb  IL 60115  USA

###### Abstract

Ionization profile monitors (IPMs) are widely used in accelerators for non-
destructive and fast diagnostics of high energy particle beams. Two such
monitors - one vertical and one horizontal - are being developed for
installation in the IOTA storage ring at Fermilab. They will be used for turn-
by-turn (microseconds scale) measurements of the 70 MeV/c IOTA proton beam
sizes. In this paper we present the IPMs design (largely following the FNAL
Booster IPMs which employ no external guiding magnetic fields), their
mechanical, vacuum, and electric subsystems and DAQ, and discuss anticipated
effects on the beams circulating in IOTA.

##  1 Introduction

Particle accelerators heavily rely on precise diagnostics and control of
critical beam parameters such as intensity, pulse structure, position,
transverse and longitudinal beam sizes, halo, etc [1]. IOTA (Integrable Optics
Test Accelerator) at Fermilab is a 40-m circumference ring dedicated to
accelerator R&D [2]. It is capable of operation with 100-150 MeV/c electrons
and 70 MeV/c protons and requires flexible and precise beam diagnostics for a
variety of beam experiments. Ionization profile monitors (IPMs) are considered
as a primary tool for fast and accurate measurements of the IOTA proton beam
profiles.

IPMs [3, 4, 5, 6, 7, 8] are fast and non-destructive diagnostic tools used in
proton and ion linacs, colliders and rapid cycling synchrotrons (RCS) [9, 10,
11, 12]. They operate by collecting ions or electrons created after the
ionization of residual vacuum molecules by high energy charged particle beams
[1, 13], which are then guided to a detector by a uniform external electric
field $E_{\rm ext}$. The detector is usually made of many thin parallel
strips, whose individual signals are registered to make the beam profile
signal ready for processing – see Fig.1.

Figure 1: Close-up view of the IOTA IPMs. Anode strips at the bottom are
parallel to the proton beam (not shown).

Space-charge forces of the primary beams make the measured IPM profiles
different from those of the beams and must be correctly accounted. Theory of
the IPM without a guiding magnetic field [14] allows reconstruction of the
actual beam sizes from measured IPM profiles given the key parameters, such as
high-energy beam intensity $N$ and IPM extracting field $E_{\rm ext}=V_{0}/D$
which is the electric field due to the voltage gradient $V_{0}$ across the IPM
gap $D$. It was shown that the space-charge expansion in IPM results in
proportional magnification of the profile of the distribution of the secondary
particles, and the rms transverse size of the IPM profile at the time when the
secondary particle reaches the IPM detector is :

$\sigma_{m}=\sigma_{0}\cdot
h\approx\sigma_{0}\cdot\Big{[}1+\frac{2U_{SC}}{E_{\rm
ext}\sigma_{0}}\Big{(}\frac{\Gamma({1\over
4})}{3}\sqrt{d\over\sigma_{0}}-{\sqrt{\pi}\over 2}\Big{)}\Big{]}\,.$ (1)

Here, the gamma-function $\Gamma({1\over 4})\approx 3.625$. The space-charge
expansion factor $h$ is determined only by the space-charge potential of the
primary proton beam $U_{SC}=30[V]J_{b}/\beta_{p}$, its rms size $\sigma_{0}$,
the IPM extracting field $E_{\rm ext}=V_{0}/D$, and the beam-to-MCP distance
$d$ but it does not depend on the type of secondary species (their mass and
charge, etc). Equation (1) can be easily solved, and the original $\sigma_{0}$
can be found from $\sigma_{m}$ [14].

For the IOTA proton ring parameters - see Table 1 \- Eq.1 predicts very modest
space-charge expansion of the beam profile in the IPMs $h-1\approx 0.01-0.1$
and, therefore, the monitors can operate only with guiding electric field. No
need for the guiding magnetic fields significantly simplifies the IPM design.

Figure 2: Conceptual view of IOTA IPM electric scheme.

##  2 IPM SUBSYSTEMS

###  2.1 HV cage

In the IOTA ring, the several mm wide proton beam with an average current of
up to 8 mA will pass through the IPM HV cage - see Fig.1. The cage dimensions
are 60 mm(height)$\times$60 mm(width)$\times$100 mm(length). The voltage on
the upper plate is +16 kV (can vary upto 30 kV), the electric field uniformity
is arranged by a four-stage voltage divider attached to copper bars (in
brown). The positive ions of the residual gas ionized in the IPMs high
electric field are pulled away from the positively charged electrode toward
the grounded RF screen - see at the bottom of Figs. 1 and 2, in gold. The
negative potential (e.g., 1 kV) of the micro-channel plate (MCP) pulls the
ions towards the MCP plate where they generate electrons. The latter, after
amplification in the MCP, exit and proceed for another 7.5 mm to an array of
thin, parallel anode strips spaced 0.5 mm apart at +100 V above the exit of
the MCP, where the electrons are collected for further processing. The anode
detector readout strip plate dimensions are 40 mm(width)$\times$80 mm(length)
with 60-80 strips in each H and V monitor.

###  2.2 Electronics and DAQ

The 1.8 $\mu$s revolution period of IOTA is close to that of the Booster (2.2
$\mu$s) and the bandwidth of the existing Booster IPM electronics should be
sufficient for turn-by-turn profile measurements in IOTA. The IOTA IPMs
readout system will be based on that for the FNAL Booster IPMs [15]. Both
horizontal and vertical IPMs will each need: a) NIM crate with pre-amps and
low-pass filters; b) VME readout system, similar to the fast ($\mu$s)
digitizers built for the Booster IPMs; c) LabView control system (similar to
the one for Booster IPMs), connected to the IOTA ACNET (later, EPICS) control
system.

Figure 3: Projected IOTA proton beam size 3$\sigma_{x,y}$ at the IPMs location
$S=2120-2210$ cm (red- horizontal, blue - vertical).

###  2.3 Location and geometry

Both IPMs will be set side-by-side at the IOTA ring straight $\sim$0.8 m long
section between quadrupole magnets $qe1r$ and $qe2r$ where the proton beam
size is projected to be about 6-8 mm (three times the rms size - see Fig. 3).
Fig. 4 presents a schematic layout of the of the IOTA IPM insert.

Table 1: Main Parameters of IOTA IPMs  Parameter | Units | Design | Range
---|---|---|---
IOTA beam |  |  |
Proton pc | MeV | 68.5 |
Number of bunches |  | 4 | 1-4
Rev. period $T_{r}$ |  $\mu$s | 1.83 |
RF frequency $f_{RF}$ | MHz | 2.19 |
Avg. current $I_{b}$ | mA | 2 | 0.5-8
Tr. emitt. geom. $\varepsilon_{x,y}$ |  $\mu$m rms | 3 | 1-4
Rms size at IPM $\sigma_{x,y}$ | mm | 2.5 | 1-5
SC potential $U_{SC}$ | V | 0.9 | 0.2-3.5
Mom.spread $\Delta p/p$ | rms | 2$\cdot 10^{-3}$ | (1-2)$\cdot 10^{-3}$
Rms bunch length $\sigma_{l}$ | m | 1.7 | 1-2
SC tuneshift $-\Delta Q_{SC}$ | 0.5 | 0.05-1 |
Avg. vacuum $P_{IOTA}$ | Torr | 6$\cdot 10^{-10}$ | $10^{-10...-8}$
Nucl. lifetime $\tau_{vac}$ | s | 300 | 20-103
SC lifetime $\tau_{SC}$ | s | <1 | 10-3-2
IOTA IPMs |  |  |
Number of IPMs |  | 2 |
Total length | m | 0.808 |
Min aperture | mm | 30 |
HV gap $D$ | mm | 60 |
HV cage length | mm | 100 |
Strips/IPM |  | 60 |
Strip alignment | mrad |  $\pm$1 |
Pitch $\Delta$ | mm | 0.5 |
IPM Voltage $V_{0}$ | kV | 16 | 4-30
Vacuum $P_{IPM}$ | Torr | 6$\cdot 10^{-9}$ | $10^{-9...-7}$
Eff.vac.length | m | 0.48 |
Integr. time | turns | 1 | 1-10
Ions/turn | 103 | 1.8 | 0.3-30
SC expansion $h-1$ |  | 0.03 | 0.01-0.1
Figure 4: Schematic of vacuum system arrangement for IOTA IPMs insert.

###  2.4 Vacuum system

The IOTA vacuum beam pipe (1-7/8" or 47.6 mm inner diameter) maintains up to
$\sim$10-10 Torr vacuum pressure (that’s the minimum expected average value,
with the design specification of $6\cdot 10^{-10}$ Torr). With such a pressure
and the circumference of 40 m, the IOTA ring integrated vacuum load is
$40\cdot 10^{-10}$ Torr-m. The IPMs insert adds less than 10% to that value.
This means that for the 2 m long IPMs insert the injected gas pressure should
not exceed $2\cdot 10^{-10}$ Torr. The total length of the IPMs and associated
vacuum equipment is 2.2 m (between the nearest two ion pumps). As the proper
IPMs chambers occupy 0.404 m of space they use all allowable integral vacuum
load with $\sim 10^{-9}$ Torr pressure of the injected gas. This situation
requires that the pressure rise in the IPMs insert sections outside the IPMs
vacuum chamber is strongly suppressed. For that, not only strong vacuum
pumping outside the IPMs chambers is needed but reduction of the IPMs gas flow
toward IPE3 and IPE1R ion pumps as well. Such a reduction is arranged by
installation of aperture-restricting inserts ("collimators") inside the IPM
vacuum system as shown in Fig.4.

There are 4 new ion pumps to be installed right next to the left and to the
right of the H and V IPMs, and 2 existing ion pumps at the IPE3 and IP1R
locations will be replaced with much more powerful pumps to increase the
pumping speeds of nitrogen and argon by a factor of 2.6 and 7, respectively.
The flow from the IPMs space into the IOTA beam pipe is constrained with the
series of “collimators”, C1, C2, C3. The total length of these collimators is
350 mm. Based on the projected proton beam sizes, the collimator orifice of 30
mm (diameter) was chosen. The pressures and the integrated pressures for the
selected locations relevant to the IPMs insert were estimated using
conductance formulae for the molecular gas flow regime. We calculate that a
$10^{-9}$ Torr pressure inside the IPM cage - arranged by a controlled leak -
will result in a quite acceptable integrated pressure load of less than
$5\cdot 10^{-10}$ Torr-m - a small fraction of the total IOTA ring integral.
The IPM vacuum pressure will be controlled by the variable leak valve (VAT,
Series 59.0).

There are indications that use of noble gases such as Ar, Kr, or Xe can be
beneficial for IPM operation as they allow a smaller profile smearing [16,
17]. Our analysis of the IOTA IPMs vacuum systems shows no significant
difference in the resulting pressures between, e.g., Nitrogen and Argon. This
is because as the pumping speed for argon gets lower its conductance through
the pipes also gets lower leading to a pressure rise at the pipe ends in a
similar range to that for nitrogen. We therefore, conclude other gases, such
as Ne and Xe, can be successfully explored though their pumping speeds are
likely lower than that for Argon.

At the $10^{-9}$ Torr pressure of the gas injected into the IPM HV cage, the
estimated number of generated ions by the IOTA beam of $9\cdot 10^{10}$
protons at 70 MeV/c is $\sim$1200 per 1.83 $\mu$s turn, that is expected to be
sufficient to provide statistically significant turn-by-turn proton beam
profile measurement.

##  3 Effects on IOTA beams

General: IOTA IPMs should be compatible with other IOTA experiments and plans
(including the plan to make IOTA optics periodic with period $P$=2). The IPMs
can not be fully transparent to the IOTA operations: they generate transverse
kicks in both H and V planes, they contribute about 10% to the total vacuum
load, the IPM vacuum system reduces the transverse aperture to 30 mm diameter
(15 mm radius), and, in the end, the system of two monitors will take about
0.8 m (flange-to-flange) of the ring circumference.

Effects on the 70 MeV/c proton beam orbit can be estimated as: with voltage of
15 kV (the nominal operating voltage) over the 60mm IPM cage gap and 100 mm
length, will result in about 5.1 mrad of angular kick (in both planes) and
unacceptably large IOTA beam and orbit distortions. Compensation of these
deflections will require $Bl\approx$ 12 Gauss-meter magnetics (the IOTA proton
ring rigidity is $B\rho$=0.23 Tm=2300 Gauss-meter). There are two
opportunities for this. The IOTA orbit correction system could be used to
control/correct such distortions. The ring has 20 combined H/V/skew-quad
correctors, with maximum dipole strength of 25 Gauss-meter (built with
270-turn air-cooled coils: 2A/5V). The most impactful could be the nearby (to
the IPM) local correctors $(x,y)$SQE1R and $(x,y)$SQE2R. The second option
involves installing new magnetic correctors along approximately 100mm-long C2
sections of the beam pipe, adjacent to the vacuum pump four-way ports
IPIPMV1-4 and IPIPMH1-4, both upstream and downstream of the IPMs – see Fig.4.

##  4 CONCLUSION AND OUTLOOK

We have designed the ionization profile monitors (IPMs) for the IOTA ring
turn-by-turn proton beam profile measurements, and have started construction
of the monitors. The IPMS are expected to be fully compatible with the IOTA 70
MeV/c proton operation. The IPMs are anticipated to be ready for installation
in the ring early 2025, to be followed by a reasonable time for commissioning
and initial tests. Of note, testing the IPMs with a pencil-like narrow
electron beam - easily available at IOTA - will allow precise determination of
the instrument point spread function (PSF) and its dependence on beam current
and size – that information will be very helpful for the monitors operation
with protons.

## References

  * [1] P. Strehl, Beam Instrumentation and Diagnostics, vol. 120, Berlin, Germany: Springer, 2006.
  * [2] S. Antipov et al, “IOTA (Integrable Optics Test Accelerator): facility and experimental beam physics program“, _JINST_ 12 T03002, 2017. doi:10.1088/1748-0221/12/03/T03002.
  * [3] F. Hornstra, W. H. DeLuca, “Nondestructive beam profile detection systems for the Zero Gradient Synchrotron", in Proc. VI Conference on High Energy Acceleration, Cambridge, MA, 1967, pp. 374–377.
  * [4] H. Weisberg et al., “An Ionization Profile Monitor for the Brookhaven AGS", _IEEE Trans.Nucl.Sci._ , vol. 30, p. 2179, 1983. doi:10.1109/TNS.1983.4332753
  * [5] B. Hochadel et al., “A residual-gas ionization beam profile monitor for the Heidelberg Test Storage Ring TSR", _Nucl.Instr.Meth. A_ , vol. 343, p. 401, 1994. doi:10.1016/0168-9002(94)90217-8
  * [6] R. Anne et al., “A Noninterceptive heavy ion beam profile monitor based on residual gas ionization", _Nucl.Instr.Meth. A_ , vol. 329, p. 21, 1993. doi:10.1016/0168-9002(93)90918-8
  * [7] R. Connolly et al., “Beam profile measurements and transverse phase-space reconstruction on the Relativistic Heavy-Ion Collider", _Nucl.Instr.Meth. A_ , vol. 443, p. 2015, 2000. doi:10.1016/S0168-9002(99)01162-6
  * [8] A. Jansson et al., “The Tevatron Ionization Profile Monitors", _AIP Conf. Proc._ , vol. 868, p. 159, 2006. doi:10.1063/1.2401401
  * [9] F. Benedetti et al., “Design and development of Ionization Profile Monitor for the Cryogenic sections of the ESS Linac", _EPJ Web of Conf._ , vol. 225, p. 01009, 2020. doi:10.1051/epjconf/202022501009
  * [10] R. S. Moore, A. Jansson, and V. Shiltsev, “Beam instrumentation for the Tevatron collider", _J. Instrumentation_ , vol. 4, no. 12, p. 12018, 2009. doi:10.1088/1748-0221/4/12/P12018
  * [11] S. Levasseur et al., “Development of a rest gas ionisation profile monitor for the CERN Proton Synchrotron based on a Timepix3 pixel detector", _J. Instrumentation_ , vol. 12, no. 02, p. C02050, 2017. doi:10.1088/1748-0221/12/02/C02050
  * [12] J.Eldred et al., “Beam intensity effects in Fermilab Booster synchrotron", _Phys.Rev.Accel.Beams_ , vol. 24, p. 044001, 2021. doi:10.1103/PhysRevAccelBeams.24.044001
  * [13] K. Wittenburg, “Specific instrumentation and diagnostics for high-intensity hadron beams", in CAS - CERN Accelerator School: High Power Hadron Machines, Mar. 2013, pp. 251–308. doi:10.5170/CERN-2013-001.251
  * [14] V. Shiltsev, “Space-charge effects in ionization beam profile monitors", _Nucl.Instr.Meth. A_ , vol. 986, p. 164744, 2021. doi:10.1016/j.nima.2020.164744
  * [15] R. Thurman-Keup, Internal Note FNAL-BEAMS-DOC-9775-v4 (unpublished, 2023).
  * [16] J. Egberts et al., ”Detailed Experimental Characterization of an Ionization Profile Monitor, Proc. 10th European Workshop on Beam Diagnostics and Instrumentation for Particle Accelerators (DIPAC’11), Hamburg, Germany (May 2011).
  * [17] J. Egberts, “IFMIF-LIPAc Beam Diagnostics. Profiling and Loss Monitoring Systems", Ph.D. thesis, Universite Paris Sud, Orsay, France, 2012.