dataesr/scientific-paragraphs-categorization huggingface dataset:
We talked about the Transmorph framework that articulates computational blocks to conceive HI pipelines, but this is not the only framework that exists which is related to data integration. We can cite MUON  (Bredikhin et al. , 2022) , which facilitates the handling of data consisting of different modalities, Polyphony  (Cheng et al. , 2022) , which carries out transfer learning across datasets by leveraging data integration algorithms, or SinCast  (Deng et al. , 2022)  which is specialized in cell type inference by mapping a query onto an atlas. It is essential to note that there are important pitfalls to data integration that must not be overlooked. The primary issue that can be encountered is named overcorrection and describes an undesirable event where a data integration method incorrectly aligns cells that do not share the same biological type or state.
This typically happens when batch effects are too strong, when a dataset contains specific cell types, when cell type distribution is highly imbalanced, or when there is little anchoring between batches. Overcorrection can be difficult to detect when there is no easy access to cell labels and is a critical issue that hinder every subsequent analysis step. Indeed, it can lead to cells belonging to the same cluster without sharing critical biological properties such as cell type or states. Other issues are worth noting even though they are not exclusive to the data integration task, such as the difficulty in differentiating between true zeros and missing values in RNA-seq datasets or the fact that different modalities are often expressed using different data types (e. g. , binary or integer data) which may be difficult to handle jointly within mathematical frameworks.
Finally, data integration tools based on abstract machine learning paradigms such as deep autoencoders often comes at the cost of a decrease in model interpretability which is an important downside for any healthrelated application. However, many efforts are made to overcome this issue  (Svensson et al. , 2020; Treppner et al. , 2022)  and we expect to see many more in the years to come. There is always an urgent need for large-scale, independent benchmarks like the HI benchmark proposed in  (Luecken et al. , 2022) , or the VI benchmark carried out in  (Cantini et al. , 2021). To the best of our knowledge, there is still a lack of large-scale independent DI and MI benchmarks. Two things are necessary to carry out such benchmarks: high-quality datasets and reliable metrics. A list of potential datasets can be found in  (Argelaguet et al.
We often observe a tradeoff between CBV and RBE, which can lead to different methods choice depending on the application, whether it is preferable to have good dataset mixing or conservation of subtle biological signals. To conclude, years of algorithmic and computational advances made it possible to solve most HI and VI problems with satisfying performance, with only the most complicated instances still being problematic (e. g. , HI of many batches with strong batch effects). Solving DI and MI is the next computational challenge. The most promising approaches that have been developed to tackle it are based on deep learning models, particularly deep autoencoders. It has been shown that purely unsupervised DI may not be a well-posed problem and could suffer fundamental flaws  (Xu and McCord, 2022) , which greatly incentivizes using knowledge-driven tools that allow the user to include external information to enhance models with functional information that link features across modalities.
This leads to our research question: How can Attribute-Based Access Control (ABAC) fulfill connected vehicle requirements of Signal Access Control (SAC), Time-Based Access Control (TBAC), Location-Based Access Control (LBAC), and Frequency-Based Access Control (FBAC)? To address the issue, we propose a data flow model based on Attribute-Based Access Control (ABAC) called eXtensible Access Control Markup Language for Mobility (XACML4M). XACML4M adds additional components to the standard eXtensible Access Control Markup Language (XACML) to satisfy the identified requirements of SAC, TBAC, LBAC, and FBAC in connected vehicles. Specifically, these are: Vehicle Data Environment (VDE) integrated with Policy Enforcement Point (PEP), Time Extensions, GeoLocation Provider, Polling Frequency Provider, and Access Log Service.
Based on our requirements, this paper aims to answer the following research question (RQ): To answer the RQ, we analyze the requirements and related work for access control in vehicles, in which we identify a research gap. We suggest an access control data flow model built on the ABAC-based eXtensible Access Control Markup Language (XACML) to fill this gap. The proposed data flow model is then validated using a functional evaluation based on authorization policies. Note that we consider the following constraints for our work presented in this paper: • We focus on the software residing in the application layer as opposed to the hardware layer inside of a vehicle; • We do not consider physical access control of the vehicle and focus only on softwarebased access control mechanisms. The paper is organized as follows: Section 2 provides a brief overview of terminology and concepts related to connected vehicles to elucidate the context.
Attribute Based Access Control Model A high-level description of ABAC is provided by the National Institute of Standards and Technology (NIST): "[ABAC is] an access control method where subject [access] requests to perform [actions] on [resources] are granted or denied based on assigned attributes of the subject, assigned attributes of the [resource], environment conditions, and a set of policies that are specified in terms of those attributes and conditions. " (  [20] , with adapted terminology) Typical ABAC systems follow a distributed concern-separating approach in that the access control mechanism is split across multiple entities. The NIST guide to ABAC  [20]  highlights four important functional entities as mentioned below: For our work, we use the eXtensible Access Control Markup Language (XACML), which is a standardized policy language schema for ABAC.
Particularly noticeable is the presence of XACML  [21]  which is an ABAC standard and used in two of the ABAC-based proposals (  [8, 26] ) to define policies. XACML is well established with good documentation and it has several open-source implementations to aid development  [29, 30]. We have already established (see Table  1 ) that no ABAC-based access control model satisfies all four requirements; thus, we have to decide on an ABAC model that is extensible and well known in the literature. We have seen in the related work presented that XACML is a common standard used to build on and is also extensible. Abbreviated Language For Authorization (ALFA) is an alternative policy language to XACML. In our use case, where we want to extend the functionality, both are equivalent because ALFA is a domain-specific language for a high-level description of XACML policies, and it is possible to perform a lossless round-trip translation from ALFA to XACML and vice versa  [31].
Furthermore, to the best of our knowledge, no other ABAC-based model enables the required extensibility of our use case at an equivalent or better level than XACML or ALFA. Thus, we use the ABAC-based XACML  [21]  standard as the basis for our data flow model, XACML4M which we present in Section 6. It has to be considered that the policy structure of XACML is complex  [32]. Thus, it makes it challenging to use, especially for stakeholders and other individuals who are knowledgeable about security and privacy issues, but lack advanced technical skills. To aid the understanding of models such as XACML, multiple visual specification languages have been proposed in the literature  [33] [34] [35] [36]. Giordano et al. [34]  propose an editor to visually define policies or security diagrams by retrieving the list of subject, action, and resource entities from the application server, which is then translated into XACML.
Additionally, Nergaard et al. [37] define a policy editor for XACML using Scratch. Heydon et al. [33]  introduce a constraint language to specify security policies using simple boxes and arrows. Basin et al. [35]  and Koch et al. [36]  propose access control models using UML and graphs, respectively, for RBAC systems. In contrast to  [33] [34] [35] [36] , for Layered Privacy Language (LPL), a visual representation is provided to define policies and also help users personalize them  [38]. In this paper, we only focus on modifying the data flow model of XACML and not a visual representation of policy language because our objective is to evaluate the functionality and not the usage of XACML. We intend to evaluate the usage of modified XACML and use a visual specification language as a future step.
XACML for Mobility (XACML4M) As shown in the previous Section 5, we use the XACML data flow model as the basis to propose eXtensible Access Control Markup Language for Mobility (XACML4M) to comply with the SAC, TBAC, LBAC, FBAC requirements. We first provide an overview of the model and then we specify the individual components methodically added to meet each requirement.
XACML4M XACML standard establishes an architecture, a processing model, and a declarative fine-grained, attribute-based access control policy language that describes how to evaluate access requests in accordance with the rules set forth in policies  [21]. When compared to literature work  [5, 6, 8, 19] , they use XACML in its standard form without any modifications. They either use it to define policies and integrate it at the hardware layer within the automotive architecture, or to combine it with other automotive frameworks such as AUTOSAR  [25]. Additionally, they do not consider the combination of our requirementslocation, time, and frequency. The XACML data flow model in its original form is generic and does not satisfy the automotive-specific requirements  [21]. In our modified data flow model called XACML4M based on XACML, we make the following changes:.
2. A custom attribute provider for determining the last time a subject had accessed a resource. We first highlight how access to resources by subjects is stored inside a log database and subsequently expound how this information can be used by the PDP for limiting access request frequency. We use an access log database implemented in the access-log-service component (see Figure  6 ). Two functionalities are provided by the access-log-service: 1. /save 2. /query The first functionality, /save, is used to store successful access requests (after PDP permit) made inside the database, which is stored as triplets subject, resource accessed, and action. They are represented in JSON. An example access log entry is depicted in Listing 6. Listing 6. access-log-service-Log Entry (JSON).
{ " s u b j e c t " : " dashmon " , " a c t i o n " : "GET" , " r e s o u r c e " : "/ v e h i c l e /camera " } Once an access log entry is sent to the logging service, it is assigned the current UNIX time in UTC at the resolution of milliseconds before being stored in the database. The second functionality, /query, can be used to fetch previous access time for a subject by analogously providing it with a combination of subject, action, and resource. As for our current example, the following response, as shown in Listing 7, is returned to /query: Listing 7. access-log-service-Log Query (JSON).
{ " s u b j e c t " : " dashmon " , " a c t i o n " : "GET" , " r e s o u r c e " : "/ v e h i c l e /camera " , " time " : 1649964600000 } In case the resource is accessed for the first time through the subject via some action, i. e. , no log entry is present in the database, the time property is automatically set to 0. For submitting accesses to the log service, XACML obligations as previously introduced in Section 6. 1. 1 are utilized. This implies that accesses are not logged via the PDP, but through the Obligations Service that has been implemented as part of the PEP. The corresponding obligation for logging accesses to access-log-service was named LogObligation. The key advantage of this approach is that logging may be enabled selectively as part of defining XACML policies, resulting in potentially saving disk space and, in some cases, even avoiding privacy issues that arise with logging.
Evaluation For functional evaluation of our XACML4M data flow model, we implement in Java a prototype based on our requirements-Signal Access, Time-Based Access, Location-Based Access, and Frequency-Based Access. Then, to verify the XACML4M data flow model, we perform the functional evaluation based on the authorization policies. In this paper, we focus only on the authorization of an application/service to access vehicle data. We assume that all requesting applications/services are already authenticated into the system.
Experimental Setup An ARM-based Raspberry Pi 4 development board running Ubuntu Linux was chosen as the target platform for all subsequent experiments. A summary of its specifications  [43]  are listed in Table  2. The Raspberry Pi 4 was chosen because its CPU performance is simi-larly constrained to x86-based Intel Atom chips that are used within existing infotainment systems. Concerning the vehicle, a Peugeot 108 compact car serves as the data source. We do not directly access vehicle sensor data from the ECU because it requires low-level access via Controller Area Network (CAN) bus. Physically tapping into the vehicle's bus systems is certainly possible, but this was not taken into further consideration due to legal and, primarily, safety concerns. Instead, we used the OBD-II port of the Peugeot 108 compact car to access diagnostic sensor data.
The data provided by the VDE are actual real-time data and the pre-requisite is that the vehicle engine is running for data to be retrieved via the OBD-II port. Due to the prevailing limitation, only sensor data could be collected. Actuators and ECU-related data were not accessible, although this has no effect on the resulting access control implementation. The values retrieved from the OBD-II port of the vehicle are hexadecimal numbers and SAE J1979/ISO 15031-5 provides a formula for interpreting different sensor data and converting them into decimal values. Different sensor data could be retrieved from the vehicle but for this paper, we only consider location, engineSpeed, vehiclesspeed depending on the use case.
, signal access, time-based access, location-based access, and frequency-based access, and investigate our research question mentioned below: RQ: How can Attribute-Based Access Control (ABAC) fulfill connected vehicle requirements of signal access, time-based access, location-based access, and frequency-based access control? To answer this RQ, this paper proposes XACML4M-an XACML-based data flow model that was methodically developed to satisfy all four requirements. The following components were added to the data flow model of XACML:.
• Access Log Service: To log the last successful access made by a requesting entity, e. g. , an application or a service. To test the developed XACML4M data flow model's functionality against our four main requirements, a proof of concept was implemented based on a real-world use case. Based on a successful functional evaluation using authorization policies created specifically for the use case, it was concluded that XACML4M can meet the identified requirements for connected vehicles. Thus, our RQ 1 is answered. Our proposed XACML4M data flow model provides an access control mechanism that considers time, location, and frequency of access within a single framework for connected vehicles. There is still some scope for future work based on our limitations. First, we plan to extend the evaluation by considering performance metrics such as computation time taken by each component in the data flow model, maximum request load, policy evaluation time based on different policy sizes, and service time for a request.
We plan to add Purpose to the access control system of XACML4M to make it future-proof. Third, to comply with GDPR specifications, the current use case and, thus, the policies, would become complex, requiring GDPR-specific attribute providers, data transformation requirements, and different action restrictions. As a result, a visual specification language is required to represent and translate policies into XACML  [32] [33] [34] [35] 37, 38]. We intend to develop a visual specification language on top of XACML for the creation and maintenance of the policies. Next, an argument can be made that the implemented functionality can also be realized using an alternate policy language such as ALFA  [31]  instead of XACML. Therefore, alternative implementations of our functionality with such policy languages would have to be evaluated and compared to our proposed model.
Discussion To summarize, in this section, we have tested the XACML4M framework for functionality with regard to signal access, location-based access, time-based access, and frequencybased access requirements. The XACML4M data flow model was verified by implementing authorization policies derived from our use case. Table  3  gives an overview of the results of the functional evaluation for XACML4M. Note that the signal access requirement is implicitly tested in the evaluation of each of the above more complex requirements and is considered fulfilled. The results help answer the research question 1 that an ABAC-based XACML can be modified to meet the automotive domain's requirements. In addition, XACML4M is a flexible data flow model based on extensible XACML, implying that future automotive-specific access control requirements such as resource consumption restrictions on an application can also be potentially integrated.
12-VIS) to the exact desired spectroscopic frequencies. The high-speed and large bandwidth of the acousto-optic modulator (AOM) are required to provide a high-fidelity reproduction of the wide range of frequency components in its radio-frequency (RF) drive signal. It is at this point where we apply the fine frequency control in the generation of the multiple frequency modes in the slave laser beam, namely the spectroscopic probe modes, an optical path length monitor mode, and a local oscillator mode to beat the probe/monitor modes down to detectable RF heterodyne frequency. The production of the AOM RF drive signal is realized through the output of the Ettus USRP X300 FPGA-Based Software Defined Radio (SDR). The electrical RF signal containing the desired frequency modes is programmed via the GNU Radio environment in the controlling PC.
The Software Defined Radio Based Platform Agile RF signal generation and treatment are necessary to allow the creation and use of multispectral-hole patterns. An SDR platform is particularly suited for this application as it provides such capability both for emission (TX) and reception (RX) channels, at a moderate cost and with relative ease of programming and reconfiguration, where only knowledge of Python and, in some rare cases, C/C++ programming languages is required. It is important to note that some optimizations, such as the correct synchronization between the RX and TX channels and latency minimization, are needed for the application of an SDR platform to our research; significant instrumentation notes on the subject are added in Appendix A. For our SDR platform, we use commercially available open hardware (Ettus Research X310) with open source software development tools (GNU Radio).
Generation of Multiple Optical Frequency Modes: Multi-channel TX in SDR In TX, the SDR receives a stream of data generated by a GNU Radio-made data flow algorithm from the control computer. This stream rate determines the bandwidth of the desired spectral pattern to be generated (in our use case, typically 20 MSPS). This data stream is sent to the FPGA which makes a Digital Up Conversion (DUC), to a programmable carrier frequency, 𝑓 DUC. In essence, the FPGA is receiving a stream of samples from the computer, processes it through an interpolating filter to reach 200 MSPS, and mixes the result at the modulation frequency, generated by a numerically controlled oscillator (NCO). Note the modulation/demodulation frequency can be set to zero, should no actual up/down conversion be required. In principle, in this implementation the SDR allows us to generate an arbitrary waveform pattern centered around a programmable frequency in the 0-100MHz range, with a bandwidth equal to the Nyquist frequency of the GNU Radio program sample rate.
TX data processing blocks We use two distinct methods, depending on the intended experimental goal, for generating the control RF signals of the experiment. The first method is, in essence, time-based, and produces a single tone signal whose frequency can be swept in a controlled way. This function is not available in the standard libraries of GNU Radio; as such, we wrote a custom data processing block "sweep-frequency" in C++. Ample documentation exists about writing GNU Radio Blocks, a process which is almost entirely automatized thanks to the gr-modtool utility which is part of the GNU Radio standard implementation. The sweep-frequency block is, at its core, a numerically controlled oscillator which generates a constant amplitude complex stream of samples, for which the phase of each sample is equal to that of the previous one plus an increment, and this increment is itself incremented at each sample by a value proportional to the sweep rate of the frequency expressed in Hz/s.
Using such a block, the platform can easily generate frequency ramps of controlled amplitude, sweep rate, and initial frequency and phase. The second method is frequency based. It produces an ensemble of single tone modes of controlled amplitudes and phases. It is implemented by using the GNU Radio built-in inverse Fast Fourier Transform (iFFT) block, which, when fed with the spectral pattern to realize, generates the corresponding complex time-domain signal data stream. Our typical use of such an approach is for realizing the illumination of the rare-earth-doped crystal with multiple optical frequency tones in parallel. In such applications, the waveform to generate is most easily described, in frequency domain, by a discrete Fourier series composed of zero everywhere except at the places where a mode is to be generated.
Reception of Multiple Optical Frequency Modes: Multi-channel RX in SDR In the SDR, the input signal is digitized and then digitally down-converted (DDC) internally by a digitally synthesized demodulation signal of programmable frequency in the 0-100MHz range, 𝑓 DDC , referenced to an external 10 MHz clock. We set the digital down-conversion frequency to frequency separation between the center of the IFFT multi-mode spectrum and the local oscillator mode so that 𝑓 DDC = 𝑓 LO. The resulting baseband signal is streamed to the connected control computer, where a driver (called Universal Hardware Driver "UHD") receives it and sends it to a GUI-designed/python-programmed data flow treatment algorithm realized in the GNU Radio framework. We typically use a 2 MSPS data rate from the FPGA to the computer, which is sufficient for our applications, but have also successfully worked at higher sampling rates.
Conclusion In the context of our SHB laser stabilization experiment, we have demonstrated a scheme for flexible multi-mode heterodyne interferometry. The scheme's agility and ease of implementation derive from the use of open-source hardware (Ettus USRP SDR) and software (GNU Radio) platforms. We have shown an adjustable interrogating setup and detection noise reduction that allows us to work around the power-limit restrictions of spectral hole probing. We have analysed the detection noise performances in the system and the results suggest that the simultaneous probing ability and the noise performance of this novel technique show the potential to meet the requirement of the SHB-based ultra-stable lasers. Additionally, the strategic utilization of additional monitor modes enables the subtraction of technical noise sources, such as parasitic interferometric effects.