dataesr/scientific-paragraphs-categorization huggingface dataset:
The segmentations of the liver are superimposed on the original volumes. The visual inspection of the 3D views of registered liver volumes in Fig. 9  and Fig. 10  highlight that VoxelMorph and ANTs(SyN) lead to similar registration results, even when considering images from the 3D-IRCADb-01 dataset, which was not considered in the training set of VoxelMorph. This conclusion is also supported by the Dice scores and the Hausdorff distances. Throughout the experiments, while visually inspecting the registration results on the test images, rare cases of poor registration were observed (samples are shown in Fig. 11  and Fig. 12 ). Although the training dataset of abdominal images (both 2D and 3D) was chosen and augmented carefully, it is clearly not possible to cover all anatomical configurations and variabilities on such a learning limited dataset.
While it is not always feasible, it has been shown that providing anatomical segmentations along with the dataset for training can help to learn a model that better generalizes. In this study we have assessed the quality of the registration using the standard Dice score, computed from the registration of segmented anatomical regions. If Dice is able to evaluate the global correspondence of the organs, it does not provide information on the quality of the local matching. This limitation has been partly overcome by computing Dice scores on narrow structures such as the portal vein, whose Dice scores are sensitive to misregistrations. We have also provided Hausdorff distances which gives supplementary information. However, considering landmark-based evaluation metrics, such as "target registration errors" would definitely strengthen the evaluation.
Conclusion This paper has shown that unsupervised learning-based approaches for 3D deformable registration become more and more competitive with conventional approaches. VoxelMorph has made a striking difference by substituting a time-consuming optimization problem for every test image pair with a learningbased registration algorithm, where a registration function is optimized over a training dataset. Precisely, after training, the model is able to perform deformable registration with state-of-the-art accuracy on abdominal images, while reducing the computation CPU time from minutes to seconds in comparison to SyN (ANTs). This paves the way for the routine use of deformable registration in the clinical workflow and will facilitate the development of high throughput image processing services.
Experimental Setup Experiments are conducted with the implementation of VoxelMorph (https://github. com/voxelmorph/voxelmorph) using Keras and Tensorflow as a backend. The ADAM optimizer is used with a learning rate of 10 8L. A mini batch stochastic gradient descent technique is employed for every experiment with a batch size of 4. Training steps are executed on an NVIDIA GeForce Elsevier © 2020. This manuscript version is made available under the CC-BY-NC-ND 4. 0 license http://creativecommons. org/licenses/by-nc-nd/4. 0/ GTX 1080 GPU (8 GB), while all the testing steps are computed using an Intel Core-i7 3770 CPU (3. 40 Hz).
summarize the Dice scores and the Hausdorff distances calculated for Affine, ANTs (SyN) and VoxelMorph based on MSE and CC similarity metrices. The values listed are computed from all possible combinations of pairwise registering the 11 test images of the LiTS dataset (110 test registrations in total). Similarly, Fig. 5 and Fig. 6 shows the mean Dice scores and the Hausdorff distance values  "  !  ! ○  ( " - ! ) ( " - ! ○ ) Fig. Example of 3D Pairwise Registration (using MSE); Dice Score (affine registration) 0. 7093; Dice Score (VoxelMorph) 0. 7955 Hausdorff Distance (affine registration) 27. 9464; Hausdorff Distance (VoxelMorph) 21. 7715 respectively, obtained on the 3D-IRCADb-01 dataset for six anatomical regions of the abdomen, namely, bone, left kidney, liver, portal vein, right kidney, and skin.
3. 1 1 Experimental Setup Experiments are conducted with the implementation of VoxelMorph (https://github. com/voxelmorph/voxelmorph) using Keras and Tensorflow as a backend. The ADAM optimizer is used with a learning rate of 10 8L. A mini batch stochastic gradient descent technique is employed for every experiment with a batch size of 4. Training steps are executed on an NVIDIA GeForce Elsevier © 2020. This manuscript version is made available under the CC-BY-NC-ND 4. 0 license http://creativecommons. org/licenses/by-nc-nd/4. 0/ GTX 1080 GPU (8 GB), while all the testing steps are computed using an Intel Core-i7 3770 CPU (3. 40 Hz).
7. 7 summarize the Dice scores and the Hausdorff distances calculated for Affine, ANTs (SyN) and VoxelMorph based on MSE and CC similarity metrices. The values listed are computed from all possible combinations of pairwise registering the 11 test images of the LiTS dataset (110 test registrations in total). Similarly, Fig. 5 and Fig. 6 shows the mean Dice scores and the Hausdorff distance values  "  !  ! ○  ( " - ! ) ( " - ! ○ ) Fig. Example of 3D Pairwise Registration (using MSE); Dice Score (affine registration) 0. 7093; Dice Score (VoxelMorph) 0. 7955 Hausdorff Distance (affine registration) 27. 9464; Hausdorff Distance (VoxelMorph) 21. 7715 respectively, obtained on the 3D-IRCADb-01 dataset for six anatomical regions of the abdomen, namely, bone, left kidney, liver, portal vein, right kidney, and skin.
In this paper, we propose a return to roots by defining a Model-Driven Engineering (MDE) methodology that supports automation of BDA based on model specification. Our approach lets customers declare requirements to be achieved by an abstract Big Data platform and smart engines deploy the Big Data pipeline carrying out the analytics on a specific instance of such platform. Driven by customers' requirements, our methodology is based on an OWL-S ontology of Big Data services and on a compiler transforming OWL-S service compositions in workflows that can be directly executed on the selected platform. The proposal is experimentally evaluated in a real-world scenario focusing on the threat detection system of SAP.
INTRODUCTION Big Data has become a major IT trend that involves academia, research institutions, and industries. According to IDC  [1] , "revenues for Big Data and business analytics will grow from $150. 8 billion in 2017 to more than $210 billion in 2020, at a CAGR of 11. 9%". Big Data does not only mean huge amount of data, but points to scenarios where data are diverse, come at high rates and must be proven to be trustworthy, as clarified by the 5V storyline  [2]. The paradigm shift from traditional data mining approaches to Big Data techniques has already been acknowledged by the research community, which has introduced the concept of Big Data often provided as a service. Many works on Big Data techniques have focused on distilling the competences of Big Data technologists offering Platform-as-a-service solutions that support the automatic deployment of Big Data services  [3] , while others are focusing on supporting semiautomatic execution of analytics  [4].
Declarative requirements are then used to select a platform-independent procedural model (Section 4) specifying how analytics should be carried out and composed in terms of abstract services. Procedural models are finally compiled in a ready-to-be-executed deployment model (Section 5) specifying Big Data platform-dependent configurations and supporting automatic provisioning of computational components and resources. Such transformations are implemented in a methodology specifying a semi-automatic process for MBDAaaS (Sections 4 and 5). We practically evaluated our methodology in a real-world scenario that considers the threat detection system of SAP (Section 6), one of the largest Software and Information Technology services groups worldwide. The contribution of this paper is threefold. First, we define a declarative approach to the specification of BDA requirements.
In the fourth step (MBDAaaS Compiler), MBDAaaS compiler uses the Deployment Configurations to transform the procedural model in a platform-dependent workflow called deployment model. This step is crucial to build a semiautomatic MBDAaaS and puts some strong constraints on the generality of the compiler, which needs to adapt to and configure the target Big Data platform. Finally, in the fifth step (Deployment Model Execution), the target platform executes the designed analytics. All data sets, models, and specifications used to develop our solution are available for interested readers at https:// tinyurl. com/ycvh9u39. For the sake of readability, in the rest of this paper, we illustrate our work using code excerpts that highlight relevant aspects of our methodology.
Again, an excerpt of this mapping is provided in Figure  4. Figure  5  presents the OWL-S process model of the anonymization service, where a data set (Dataset) and the parameter(s) target of the anonymization algorithm (field) are taken as input (elements process : hasInput), and the anonymized data set (AnonymizedDataset) is returned as output (element process : hasOutput). Figure  6  presents an example of grounding, where the function of the anonymization process is specified. In our example, a reference to the WSDL file of the service (HashingAnonymizationService. wsdl) is used as a placeholder that points to the functionality/library provided by the target Big Data platform and implementing the service itself. This reference is fundamental to map the abstract OWL-S service to the real service in the target platform, linking a central repository of information needed to execute the real service (see Section 5).
EXECUTABLE WORKFLOWS The last step of our MBDAaaS methodology is based on a compiler that automatically transforms a procedural model (OWL-S service composition) in a deployment model (executable workflow) that is ready to be executed on the target Big Data platform. We note that OWL-S service composition is a technology-independent representation of  the executable workflow, which models what the Big Data campaign should achieve and how to achieve its objectives; the executable workflow is the implementation of an OWL-S service composition on a specific technology/platform.
2) Alternative ⊗ implementing a conditional statement where either s i or s j is executed (s i ⊗s j ). 3) Parallel ⊕ implementing a parallel statement where both s i and s j are executed at the same time (s i ⊕s j ). 4) Loop µ implementing a loop statement, which can be either implemented as a separate statement (µs i ) or as a degeneration of the sequence. Upon identifying the operators, the compiler loads the driver of the language used for deployment model specification and generates an empty skeleton of the Big Data pipeline to be executed, which corresponds to the structure of the procedural model. The structure, in addition to operators, contains an empty service for each service in the procedural model. It is important to remark that our approach has been designed to be generic, meaning that our compiler is independent of the selected workflow language.
The compiler, in fact, can translate an OWL-S service composition in a workflow that is modeled both using a workflow language specifically defined for Big Data, such as Apache Oozie, 2 and a workflow language originally defined for web service composition, such as WS-BPEL. Table  1  presents the mapping between OWL-S operators and corresponding operators in Apache Oozie and WS-BPEL workflow languages. In the following, for simplicity but with no lack of generality, we focus on Oozie workflows. Service configuration. After generating the workflow structure, for each empty service s i , i) the corresponding service s i in the procedural model is identified, ii) service s i is instantiated using the OWL-S service description, information on the Big Data execution platform, and the language selected for specifying the deployment model.
The workflow in Figure  8  is composed of three activities (elements action) in a sequence that execute i) data cleaning, ii) anonymization, and iii) clustering. As indicated by the element start, the workflow begins by executing DataCleaningProcess, which receives as input two parameters (elements arg), the first with the type of normalization to be executed (${normalization}) and the second with the target data set (${datasetURI}). Upon a successful execution of Data-CleaningProcess, AnonymizationProcess is executed (second element action). It receives as input the output of DataClean-ingProcess (${normalizedDatasetURI}), the anonymization operation (${hashing}) and the field(s) over which the anonymization must be performed (${IPAddress}). Upon a successful execution of AnonymizationProcess, ClusteringProcess is finally executed (third element action).
It receives as input the results of AnonymizationProcess (${anonDataset}), and parameter(s) for clustering (${K}, ${maxIterations}). There is, however, a subtlety to consider: the workflow in Figure  8  is not completely specified. In fact, the activities in the workflow refers to templates that need to be instantiated with parameters in the OWL-S workflow. 3 For instance, let us consider the reference to AnonymizationProcess in Figure  8. The corresponding activity is completely specified unless the variables associated with the parameters anonymization operation ($hashing) and target ($IPAddress). When $hashing and $IPAddress are filled in with real values, the workflow is completely specified and ready to be executed. 4.
In case a parameter value is missing, it is prompted to the user that can provide it. 4. In case no workflow engine is available on the target platform, these parameters are directly added in the call to the corresponding library (through a command line interface). given as input to the Service Selection Component, and used to configure traditional Big Data platform components: Analytics Engines, Data Warehouse, Visualization Tools. Upon receiving the declarative specifications, Service Selection Component automatically retrieves the compatible services, which are manually composed by the users to build an OWL-S service composition using the Service Composition Engine. The OWL-S service composition is given as input to the Workflow Compiler, which automatically transforms it into a workflow that can be managed by the selected Workflow Engine.
The workflow is used to finalize the configuration of traditional Big Data components and is executed by the Workflow Engine on the selected platform. Retrieved results can be used to tune the declarative model specification and restart the process from scratch. In our experimental evaluation, we adopted the Hadoop stack that is based on the YARN programming model and the Hadoop Distributed File System (HDFS). We then used Apache HBase as our Data Warehouse, a database engine built using Hadoop and modeled after Google's Big Table. We further integrated Apache Spark as our Analytics Engine, a general purpose, fast, and reliable cluster computing engine. We then used Zeppelin as the visualization tool for data sets and results. We finally adopted Oozie as our workflow engine and integrated it with the rest of the Hadoop stack.
Experimental Evaluation We extended the preliminary evaluation conducted in  [18]  by executing a complete process from declarative model specification to deployment model generation and execution. Our starting point was devising an anomaly detection functionality through clustering detected anomalies. In particular, we aimed to detect usage of certain types of programs (called transactions) outside of a user's peer group (possibly a case of privilege escalation) and to cluster anomalies pertaining to a planned abnormal activity in a single stage (instead of assessing them one by one, for example anomalies due to a system upgrade or due to an internal reorganization). We used a log data set containing around six weeks of activity collected from SAP systems deployed in a test environment. We considered three features, namely Executed Transaction, Data Sent, and Data Received, extracted from the log files and aggregated per user.
In this case, since anonymity is not preserved anymore, the final user is prompted and a new specification for goal Anonymization Technique is provided: φ 1 =(Anonymization, Anonimization_Technique, hashing), {Algorithm: SHA-256, Target: UserID}, -}. Service selection. Declarative model specification is used to select the set of compatible services that can be composed to build the Big Data campaign. According to the three requirements above, our MBDAaaS methodology selects all SHA-256 services, different instances of clustering services, and all visualization services, including the ones provided by Zeppelin, for scatter-plot visualization, available in the target platform. The specification of declarative constraints can further affect the list of selected services. In our example, the definition of constraint k m , that is, the number of clusters, affects service selection results.
When k m is not defined or is defined as a range (Figure  2 ), the list of compatible services also includes optimization services such as elbow method and silhouette score. This means that either the final user can select a value for k m when specifying the procedural model or an optimization algorithm can be used to infer it. Service composition. Upon service selection, the final user manually composes a subset of the selected services to build her Big Data campaign. In our scenario, the user selects a SHA-256 anonymization service, a k-means clustering service, and a scatter-plot visualization service. There is, however, a subtlety to consider when services are composed: selections made at declarative level could also pose restrictions on the way in which services can be composed. Let us consider the case for the selection of constraint k m (i.
This is because the declarative model provided as input (as an extension of the excerpt in Figure  2 ) does not specify the number of clusters k m , meaning that the user does not know the optimal parameter and optimization services, such as elbow method, are beneficial. Workflow execution. The composition in Figure  10(b ) is finally given as input to our compiler that automatically generates the Oozie workflow. The workflow is then stored in our platform, following the appropriate path and instantiated according to the information available in the files job. xml and properties. xml. These files are associated with each service component, so that the Oozie engine can refer to them when executing. Initial analysis. Figure  11  presents the results retrieved through our MBDAaaS using the Big Data platform in this section.
This second experiment returned 5 clusters presented in Figure  12. GMM clustering permitted to group regular transactions in a limited number of clusters and highlighted new small clusters, corresponding to a transaction seldom used by one of our users, which was not visible via k-means clustering. This cluster corresponds to a second type of anomaly: a transaction run by a user but by no other users having a similar role. We then considered the segmentation produced by GMM more significant. Performance evaluation. We evaluated the overhead introduced by our solution with respect to standard Big Data architectures, that is, the overhead introduced by the service composition engine and the workflow compiler. The performance of the service composition engine and compiler have been measured in the three scenarios in Figure  10 , using a laptop with a CPU Intel i7 and 8GB of RAM, retrieving the following results.
The details about the process, data management, and orchestration of the specific procedural implementation permit to compare different alternative solutions before their deployment (see Figure  10 ), paving the way to the a priori assessment of the impact that alternative specifications have on performance or quality of analytics. Also, such details provide all information needed to define privacyby-design Big Data campaigns, by verifying OWL-S service compositions against existing standards (e. g. , General Data Protection Regulation -GDPR). In conclusion, our methodology supports users in the management of Big Data campaigns that require tuning, adaptation, and continuous analytics. More specifically, It contributes to fill in the gaps identified in Section 1. Our MBDAaaS methodology has some room for improvement mainly in terms of flexibility and validation capability, which we leave for our future work.
First, while our proposal provides a highly-usable approach for users with low competences, it falls short to satisfy requirements of skilled users that need also to control the low-level parameters of the computation before moving to production. Second, our approach does not permit to select services at infrastructure layer hosting the computation on the basis of declarative specifications. Our approach should then include execution-side use of declarative model information for generating deployment recipes supporting service distribution across virtualized containers like Dockers. This perspective, fully compatible with our methodology, will introduce a degree of automation in execution. Finally, a throughout benchmarking of our methodology will be targeted to evaluate the quality of the retrieved results on the basis of the selected technologies, the level of details in the declarative model, and the type of data and analytics selected.
resource="#HashingAnonymizedDataset"/> <grounding:wsdlMessagePart rdf:datatype="http://. #anyURI"> file <process:AtomicProcess rdf:about="#AnonymizationService:Process"> <process:hasOutput> <process:Output rdf:ID="Dataset"> <process:parameterType rdf:datatype="http://www. w3. org/2001/ XMLSchema#anyURI"> &tdm;#AnonimyzedDataset </process:parameterType> </process:Output> </process:hasOutput> <service:describes rdf:resource="#AnonymizationService"/> <process:hasInput> <process:Input rdf:ID="Dataset"> <process:parameterType rdf:datatype="http://www. w3. org/2001/ XMLSchema#anyURI"> &tdm;#Dataset </process:parameterType> </process:Input> </process:hasInput> <process:hasInput> <process:Input rdf:ID="Field"> <process:parameterType rdf:datatype="http://www. w3. org/2001/ XMLSchema#anyURI"> &tdm;#Field </process:parameterType> </process:Input> </process:hasInput> <rdfs:label>Process</rdfs:label> </process:AtomicProcess> Fig.
5. Anonymization Service: OWL-S process model <grounding:WsdlGrounding rdf:about="#Grounding"> <service:supportedBy rdf:resource="#Service"/> <grounding:hasAtomicProcessGrounding> <grounding:WsdlAtomicProcessGrounding rdf:ID="AtomicProcessGrounding"/> </grounding:hasAtomicProcessGrounding> </grounding:WsdlGrounding> <grounding:WsdlAtomicProcessGrounding rdf:about="#AtomicProcessGrounding"> <grounding:wsdlInput> <grounding:WsdlInputMessageMap> <grounding:owlsParameter rdf:resource="#Dataset"/> <grounding:wsdlMessagePart rdf:datatype="http://. #anyURI"> file:HashingAnonymizationService. wsdl#Dataset </grounding:wsdlMessagePart> </grounding:WsdlInputMessageMap> </grounding:wsdlInput> <grounding:wsdlOutput> <grounding:WsdlOutputMessageMap> <grounding:owlsParameter rdf::HashingAnonymizationService.