dataesr/scientific-paragraphs-categorization huggingface dataset:
COMPARISON AND USAGE Our hypothesis being that we can enable semantic trajectory enrichments with signal values for generic applications, there are many initiatives that solve partially the problem, but not completely as visible in Table  1. The representations of static car data focus on the e-commerce domain and do not describe dynamic data. The trajectory representations tend to be defined for specific applications and domains and neither cover static nor dynamic car data. The contextual representations of cars are an interesting trade-off between static and dynamic car data but have a limited interest in trajectory representation and work only for non-generic use case in ADAS. With respect to our hypothesis, we see that the combination of VSSo, SOSA/SSN and STEP fills different gaps from the existing initiatives and fits the requirements to enable our use cases: it covers the automotive domain and its sensor vocabulary with semantics and trajectory enrichment for generic applications.
SSN to VSSo, we generate RDF triples of observations of vehicle signals and may attach them to a spatiotemporal context using the STEP ontology. 12https://www. w3. org/TR/vocab-ssn/ 13 https://www. w3. org/auto/wg/ 14 https://github. com/GENIVI/vehicle_signal_specification/ 15 https://github. com/klotzbenjamin/VSSontology By linking SOSA/.
Data sharing and collaboration are important success factors for modern biomedical research. As biomedical data contains sensitive information, any mechanism that governs biomedical data sharing should protect subjects' privacy while providing high-utility data in an efficient and prompt manner. The use of biomedical data for research has been studied extensively from the legal aspect. Several regulations control its use and sharing to limit privacy risks. However, current sharing mechanisms can be a barrier to the research community needs. Going through the IRB process is time consuming and will become a bottleneck for the intensive data need of the biomedical research community. Alternatively, creating a universal de-identified research sub-dataset accessible through honest-broker-systems will not satisfy all research use-cases, as stringent de-identification methods can reduce data utility.
Institutional Review Boards (IRBs) or ethical committees are in charge of analysing and evaluating research proposals in terms of their risk and benefit. In general, the approved research projects are the ones that present consequent benefit with minimal risk and that comply with the ethical standards and the local policies. However, going through the IRB process is time consuming and with the intensive data consumption need of modern biomedical research, it is expected that the IRB process will become a bottleneck for the research activity  (He et al. , 2014). A current mechanism to overcome the burden of the IRB process is to share a universal de-identified subdataset with the research community. An IRBapproved honest broker system is in charge of the distribution and the access to the de-identified data.
For example, access to highly sensitive data at the data-holder's location by a trusted user is inherently less risky than providing the same user with a copy of the dataset. Similarly, access to de-identified clinical data from a secure remote system is inherently less risky than access to identifiable data from an unknown location. The authors then define the risk-aware access control as realized on a risk scale divided into multiple risk bands (or classes). These risk bands are determined according to the organization risk tolerance levels and can be dynamically adjusted. Every access request falls into one of these risk bands according to its risk estimate. The access decision is made accordingly and will deny, allow with or without risk mitigation-measures the access (See Figure  1 , which is an adaptation from  (Cheng et al.
RISK-AWARE ADAPTIVE ACCESS CONTROL MODEL We take the definition of the formal model for riskaware access control (RAAC) developed in  (Chen et al. , 2012)  and its subsequent refinement proposed in  (Armando et al. , 2015)  as the basis of our model. We add a new function called IRBapproved to represent the legal risk. This function allows the access in the context of risky situations as long as, the IRB, as a legal entity, has authorized that. We then define the final data sharing decision as a combination of individual risk functions. The components of the formal model are defined as follows: • U: a set of users. • : denotes a dataset and  ⊆  denotes any subset • : is a set of operations that can be applied to a dataset ,  ∈  denotes a particular operation. • : a set of access purposes representing all the possible access purposes in our platform and  ∈  is a particular data access purpose.
Illustration Assume that a biomedical platform holds different data sets of different sensitivity levels ranging fro 0 to 1 (with 1 being the highest sensitivity), such as: - 1 : a public data set with sensitivity level 0 - 2 : a de-identified dataset of flu patients with low sensitivity level 0. 2 - 3 : a de-identified dataset of kids with ADHD with sensitivity level 0. 5 - 4 : a de-identified dataset of HIV patients with high sensitivity level 0. 8 When a researcher requests a permission to access a dataset, Equation 3 is used to calculate the risk associated with her request. The decision is made according to the risk band corresponding to the request risk level. For this example, let us suppose that the researcher is highly trusted and is requesting data for exploratory research purposes.
Therefore, the risks associated with the user trustworthiness and the access purpose are minimal (say both are equal to 0). Assume that the researcher is trying to access dataset  4 which is highly sensitive. If the role associated to the researcher doesn't allow her to access the data set and she has no IRB approval to do so, then the risk to access this data is maximum = 1 and therefore has to be denied. Otherwise, a risk calculation will be performed according to the equation 3: We have two possible cases: -The researcher has IRB approval for this particular dataset. Therefore: (, ) = 1, and  ((, ), ) = {(0. 8,0)) ; (0,0) ;  (0,0));   ((, ), )} It means that the only risk considered here is the security risk to avoid the disclosure of sensitive data in case of high security risk. -The researcher does not have IRB approval for this particular data set.
Our proposed model is based on the formal meta-model developed in  (Chen et al. , 2012)  The instantiation of the meta-model allows the creation of RAAC models with different risk mitigation strategies. The authors focus on system obligations and user obligations as risk mitigation strategies and propose the models to implement these strategies. In  (Armando et al. , 2015) , the authors consider the risk of leaking privacy-critical information when querying a dataset. The risk is calculated according to the query result and using anonymity metrics related to personal-identifiable information. The model includes adaptive anonymization operations as risk mitigation methods to lower the risk associated with a particular data request. In  (Kandala et al. , 2011) , the authors rely on an attribute-based framework to capture the different elements needed to implement an adaptive risk-based access control mechanism.
CONCLUSIONS/FUTURE WORK In this paper we depicted the need for risk-aware access control models that support the regulation, development, and deployment of access control procedures for data sharing in biomedical research platforms. We proposed a method that identifies the essential risk components, necessary for such access control procedures and extended existing models to overcome the limitations of the "manual" biomedical data sharing processes, such as the IRB, and the "automated" ones based on e-HBS. Currently we are working on coming up with efficient equations to calculate the different risk elements. This work is challenging and requires significant efforts on many fronts: • Assigning data sensitivity to datasets is the main challenge. As a start, we are currently working on classifying data into a set of pre-defined sensitivity classes.
In particular, our approach makes it possible to transform formal models of the SoS architecture (expressed in SoSADL) into simulation models (expressed in DEVS). We evaluated our approach by conducting two case studies using a flood monitoring system that is intended to be part of a smart city. Results indicate that ASAS can successfully generate functional simulations for the SoS operation, which in turn can enable to reason and monitor an SoS operation, taking into account its dynamic nature.
Therefore, we pose the following research question: Is it possible to automatically generate simulation models for a SoS to support evaluating its operation? The main contribution of this paper is to present ASAS, an approach that automatically transforms static SoS models (expressed in a language termed SoSADL) into simulation models (expressed in DEVS -Discrete Event System Specification). We applied our approach in two independent case studies that automatically generated simulation models for a Flood Monitoring and Emergency Management SoS (FMSoS). Preliminary results show confidence in our approach, which was able to successfully transform abstract descriptions of this SoS into functional simulation models, leveraging constituents individual capabilities and reinforcing SoS trustworthiness.
II. BACKGROUND SoS are being developed for critical domains in the management of smart cities. Specific means of predicting SoS operation become necessary to offer reliable services for SoS stakeholders  [15]. SoS exhibit dynamic architectures, i. e. , architectures that can assume diverse architectural configurations (i. e. , also known as coalitions) during SoS runtime, due to addition, substitution, and deletion of constituents, or reorganization of the structure of the SoS architecture  [3]. SoSADL is a novel formal language that has been created to support the specification of SoS architectures  [6, 15]. It supports the specification of abstract architectures in which constituents are known at design-time and abstract connectors (also referred to as mediators) that can be dynamically realized for composing concrete architectures of this SoS.
III. FROM SOFTWARE ARCHITECTURES TO SIMULATION MODELS We present a model-based approach termed ASAS, which automatically generates simulation models to evaluate SoS operation. This approach implements an automated transformation from SoS architecture models expressed in SoSADL into dynamic models expressed in DEVS. Moreover, this transformation is accomplished in two parts: one generates atomic models and the other generates coupled models. Our approach encompasses five steps, which are: (i) specification of an SoS software architecture using SoSADL; (ii) transformation of the architecture description into a functional DEVS simulation model (automatically accomplished by an Xtend 7  script); (iii) deployment of the simulation code in the MS4ME 8  environment; (iv) simulation of the SoS software architecture; and (v) analysis of the results.
B. Generating Atomic Models Listing 1 shows a simplified code of a mediator type named Transmitter described in SoSADL. This element can be automatically transformed into an atomic model, which is depicted in Listing 2. Data types are defined on Lines 2-6. These data types are respectively transformed to datatypes in DEVS atomic model (i. e. , lines 1-22 in Listing 2). Duties (which designate gates of mediators) with their respective connections are defined on Lines 8-16. The individual behavior of this mediator is specified in lines 18-23. In short, this behavior defines that after receiving the coordinates of constituents that it mediates (lines  [19] [20] , this mediator will repeatedly receive data from one sensor (line 22) and forward them to the other (line 23). Similarly to gates, duties are transformed into inputs of ports in the atomic model (lines 24-27 in Listing 2).
Finally, the behavior is translated into an automata in the atomic model (lines 29-42 in Listing 2). Listing 3 shows part of the transformation code in Xtend that generates state transitions for the atomic model behavior based on elements specified in SoSADL. If the transformation consists of an input transition, the code in lines 2-7 is executed. If it consists of an output transition, the code in lines 9-15 is executed. The names of connections in SoSADL are preserved by the transformation. The code in lines 4 and 10 in Listing 3 use the connection name to create namesake ports in DEVS, as shown in lines 24-27 of Listing 2. Besides that, the type of data received or sent is used for typifying data that are allowed to be transmitted in a DEVS port (lines 4 and 10 in Listing 3). Furthermore, receive instructions in SoSADL create receive transitions, such as lines 33, 35, and 37 in Listing 2.
C. Generating Coupled Models Listing 4 shows the SoSADL code that specifies a concrete software architecture for the FMSoS. In particular, the architectural configuration of this SoS comprises four sensors, one gateway, and four transmitters (lines 4-12). The bindings (lines 13-23) specify how connections between constituents and mediators are established through gates, which compose the interface of the software architecture of this SoS and define their dynamics for transmitting data among sensors towards a gateway station that is able to process them. A sensor collects the water level through actuators, encapsulating it with the specific location where it was obtained and its corresponding time stamp. After that, sensors can transmit observations to the closest transmitter  9  , which forwards them to a nearby sensor or gateway.
This enables them to receive data for being transmitted and forward them to a gateway (lines 16, 18, 20, and 22). Lines 22 and 23 link the output connection of transmitters to a gateway connection, which is named measure. In this case, a transmitter mediates a sensor and a gateway. The relay statement (line 14) establishes the communication between the FMSoS and external systems, connecting the notification gate of a gateway to one external connection. 1 sos FloodMonitoringSos is { 2 architecture FloodMonitoringSosArchitecture() is { 3 behavior coalition is compose { 4 sensor1 Listing 5 presents transformation rules that translate a software architecture expressed in SoSADL into a coupled model in DEVS. It depicts three transformation rules: one that receives a SoSADL type called ArchitectureDecl as input (lines 1-4), one that receives an ArchBehaviorDecl as input (lines 5-16), and one that compiles Unify statements (lines 17-40).
However, it is also necessary to know data types that are being transferred between two elements in the coalition for creating the simulation code. This data is not available in the architecture specification in SoSADL, but it is available in the specification of the constituents and mediators in SoSADL (hidden here due to lack of space). Still in Listing 5, a portion of code that opens a file in which there is a specification of the connections and their respective data types was hidden for space reasons. The code in lines 31 to 35 compares the name of each pair gate-connection to the gates and connections specified in the coalition, inferring the type of data that they transmit. This data is assigned to the variable data when it is found (Line 34). Line 36 shows the format of the output String, with sender, receiver, and data, and Line 39 prints the result.
The transformation rule for Unify is called once for each unification in the SoSADL specification. Each binding specified in SoSADL is mapped into one coupled model in DEVS. Listing 6 shows the equivalent code derived for the architecture of the FMSoS. Line 1 shows that the FloodMonitoringSoSArchitecture is formed by the same systems specified in the SoSADL code. Lines 2 to 9 show data exchange between the systems and mediators derived from the SoSADL specification. Each line depicts a unification statement of the bindings block in the SoSADL model. Finally, the DEVS tool converts that code into an executable simulation model. Moreover, Listing 6 shows that sensors transmit their data to the closest transmitter (Lines 2, 4, 6, and 8). Then, transmitters forward these data in Lines 3, 5, 7, and 9 to a nearby sensor or gateway.
IV. EVALUATION ASAS was evaluated in a case study on a Flood Monitoring SoS (FMSoS), which is a SoS that is intended to be part of a smart city. FMSoS monitors rivers crossing urban areas, which pose great danger in rainy seasons, potentially damaging property, threatening lives, and spreading disease. FMSoS notifies possible emergency situations to residents, businesses owners, pedestrians, and drivers located near of the flooding area, and also to governmental entities and emergency systems. FMSoS is composed of five different types of constituents, as illustrated in Figure  1:  1) smart sensors, which are fixed embedded systems monitoring flood occurrences in urban areas, located on river edges; 2) gateways, which gather data from constituents and share them with other systems; 3) crowd-sourcing systems, which are mobile applications used by citizens for real-time communication of water level rising; danger level is a pre-defined value (between 1 and 6, 1 being no risk, and 6 being flood effectively occurring) that can be classified by the human user according to what he/she observes; 4) drones, which are UAVs also used to complement sensors observations by monitoring the river water level while they fly over it, sending pictures if some change in the water level occurs; and 5) drone bases, which are fixed basis from where drones departure, and to where they come back for battery recharging, and data transmission.
We evaluated our approach considering two cases, in the context of the FMSoS, that aims: (i) to investigate the accuracy of the transformation to create a valid simulation model that represents functional capabilities of the FMSoS (i. e. , flood monitoring), and (ii) to investigate if the generated simulation model supports modifications in the FMSoS software architecture at runtime, and if with such model it is possible to evaluate different configurations for the FMSoS architecture. Each case is explained in the remaining of this section detailing the research questions that each case must resolve, the rationale for each question, the metrics used to answer such questions, collected data and procedures for data analysis and a discussion of results for each case.
Data used. We chose a dataset collected by the actual FMSoS over four days, from November 23th 2015 to November 27th 2015. This interval was important because during these months a number of floods occurred. This enabled us to establish whether or not our simulation results in a diversity of situations. We established a 4-window strategy implemented at the gateways that receive data from constituents to confirm floods. For each set of four data that subsequently arrives, the gateway checks them. For the period studied, the river had an average rise from 35 to 50 cm, depending on the location. Thus, in this context, the threshold of a flood is defined as a rise of 100 cm or more. If at least one pair of data that arrived have both their depth levels at least 100 cm (the threshold established for that city), a flood alarm is triggered.
We adapted our dataset so to have similar data for stimuli generators for crowd-sourcing systems and drones. For crowd-sourcing systems, the aforementioned scale was used to classify risk between 0 and 6. Zero means that crowd-sourcing systems is not contributing to flood diagnosis. We mapped the height of water in original data to a scale of risk between 1 and 6, 1 being no risk, and 6 being flood effectively occurring. Human users can classify a risk between these values according to what he/she sees. So we could imitate how people would react and behave according to the changes in water level registered before by sensors. Then, we created a dataset corresponding to the data used to feed sensors. For drones, we used 5,000 data per drone. Each drone has an autonomy to fly 2,500 meters and return to the basis.
RQ2. How accurate was the simulation in supporting the monitoring of an SoS operation? The simulation took six hours and 20 minutes to run on an Intel core i5-3230M 2. 60GHz (x64) processor, with 4 GB of RAM Memory, 1TB of HD, and running Ubuntu 16. 04 with 64 bits. The data corresponds to four days of monitoring data from a specific real river. This step was evaluated according to the metrics established in RQ2. 16 true positives occurred, since during the considered period, besides one effective flood (November 23th), in which the level of water reached almost 7 meters. A total of 1,942 true negatives correctly arise. Nor false positives nor false negatives occurred. The river that crosses the city has an average level of 35 to 50 centimeters (cm), depending on the location. For this context, the threshold of a flood is considered about 100 cm.
Data used. Data were provided by a real project that combine crowd-sourcing and sensor data for detecting floods  [9]. We chose a comprehensive data sample collected from November 23th 2015 to November 27th 2015, a period in which there were intense rains and floods. Simulation. We were able to analyze whether our simulation results conform to the expected FMSoS behavior, i. e. , sending a flood alert whenever collected data exceeded a predetermined threshold. We analyzed 50 different architectural configurations, varying the number of sensors, crowd-sourcing systems, and gateways (as well as mediators dynamically appearing between constituents). All 50 architectural configurations were evaluated, starting with a configuration with four sensors, one gateway, and zero crowd-sourcing systems (besides the necessary mediators).
For Case 2, we identified the following threats to our study: (i) data selected to feed the simulation: Data were selected from a real case conducted in a smart sensors network and a crowd-sourcing system deployed in an actual city. We merged these data during SoS operation by feeding the respective constituents to the stimuli generators. The 1000 observations were collected during four days encompassing flooding occurrences. Hence, this threat was mitigated; (ii) scaling: Scale is not a problem since our simulation can handle a larger number of constituents. However, this hampers data visualization and processing, as a large number of constituents is difficult to visualize in a simulation and a more powerful processor would be required to execute simulation of a larger SoS. However, these problems are reduced as the resulting data are saved in spreadsheets to be properly analyzed; (iii) the order in which we performed changes in the architecture and the set of changes that we proposed to perform on the architecture: Different changes could be performed, substituting or eliminating constituents, or even reorganizing SoS configuration.
Simulation models can certainly vary depending on which systems constitutes the SoS. Indeed, our approach is domain-independent. Hence, we claim that ASAS can be adopted to transform static models represented in SoSADL to dynamic simulation models of SoS. Future work might include (i) reproducing the case study in other scenarios, (ii) developing a deeper understanding of the results achieved, especially with different types of constituents; (iii) investigating if the ratio between the number of gateways and the number of constituents influences the data transmission ratio; and (iv) developing artificial intelligence and inference mechanisms (such as neural networks) to trainee the SoS and teach it how to maintain beneficial architectural configurations identified with the ASAS approach. We claim that the ASAS approach can be adopted as a platform to represent different facets of a smart city and other SoS applications, such as coupling distinct models (such as a transportation model and a building energy demand model), establishing new interoperability links to achieve and offer more complex solutions.