dataesr/scientific-paragraphs-categorization huggingface dataset:
As can be clearly seen, VCS does not capture the notion of transactions. U rbanCo 2 F ab, however captures the changes between two versions (or simply a version transition) through transactions, where every transaction may refer to insertion, deletion or modification of a particular feature value. VCS only tracks the creation time of a commit, whereas, in U rbanCo 2 F ab, we track the real-world existence of a city object as well as the transaction timestamps (when the object was created and completely saved to a database). Commit messages in VCS cannot be modified once a version has been created 5. In U rbanCo 2 F ab, labels can not only be assigned to a version, a version transition and a scenario, but they can also be changed.
DEVELOPMENT Figure  5  shows the basic architecture of U rbanCo 2 F ab. It is built over GIT as shown in Figure  5  and makes use of git-like commands to reduce the learning curve of new users (with slight changes in vocabularly described in Table  1 ). It is developed in Python using the Pygit2 6  library and tracks changes in city objects described using CityGML files. Pygit2 is a python interface over GIT letting developers easily access GIT related metadata. We use pygit2 to access GIT related metadata, especially the information concerning GIT commits. A commit in a GIT is used to give a timestamped snapshot of one or more files and directories. Every commit has an associate metadata: commit author, author signature (email), commit identifier (SHA1), pointers to previous version (or versions in case of a merge), timestamp (or creation date of a commit) etc.
As shown in Figure  7 , UrbanCo2Fab works with two metadata directories:. git directory managed by GIT and. urbanco2fab managed by urbanco2fab. It reads and writes to the. git metadata directory using pygit2 interface whereas it directly interacts with the. urbanco2fab metadata directory, reading, writing and even updating information. In order to limit the changes to CityGML, we make use of two additional attributes (timestamps): validFrom and validTo to demonstrate our idea. Every city object has an identifier (or a gml identifier). We call it the major identifier. This identifier along with the feature name is used to identify any particular feature of a city object and we call it the minor identifier. For example, in cases of a city object like a building having an identifier CO1, CO1 is its major identifier and CO1#function is the minor identifier of feature 'function' of the building.
CONCLUSION CityGML 3. 0 will be released by the end of this year and the use of timestamps in our proof of concept will soon become part of versioning module. We demonstrated in our work, how these changes can be further enhanced to represent concurrent points of view of urban evolution. By developing our proof-of-work on GIT, it is also easy to share the evolution related changes. Our next course of actions is to understand and deal with scalability and performance issues for very large scale CityGML files.
MDE has been successfully adopted in the production of software for several domains. As the models that need to be handled in MDE grow in scale, it becomes necessary to design scalable algorithms for model transformation (MT) as well as suitable frameworks for storing and retrieving models efficiently. One way to cope with scalability is to exploit the wide availability of distributed clusters in the Cloud for the parallel execution of MT. However, because of the dense interconnectivity of models and the complexity of transformation logic, the efficient use of these solutions in distributed model processing and persistence is not trivial. This paper exploits the high level of abstraction of an existing relational MT language, ATL, and the semantics of a distributed programming model, MapReduce, to build an ATL engine with implicitly distributed execution.
Problem statement Foremost, MT operations involve mainly graph matching and traversing techniques. Such operations are CPU-consuming, which raises serious scalability issues as graphs grow in scale and complexity. Consequently, graph processing problems in general, and MTs in particular, can exceed the resources of a single machine (CPU). For example, in our experiments, we show how typical MT tasks in the reverse-engineering of large Java code bases may take several hours to compute in local. One way to overcome these issues is exploiting distributed systems for parallelizing model manipulation (processing) operations over computer clusters. This is made convenient by the recent wide availability of distributed clusters in the Cloud. MDE developers may already build distributed model transformations by using a general-purpose language and one of the well-known distributed programming models such as MapReduce  [11]  or Pregel  [12].
We show that thanks to the properties of the ATL language, interactions among rule applications are reduced. The distribution in our proposed framework is implicit, i. e. the syntax of the MT language is not modified and no primitive for distribution is added. Hence developers are not required to have any acquaintance with distributed programming. The semantics we propose is aligned with the MapReduce computation model, thus, showing that rule-based MT fits in the class of problems that can be efficiently handled by the MapReduce abstraction. Distributed computation models like MapReduce are often associated with persistence layers for accessing distributed data. In our second contribution, we propose a new model-persistence backend, NeoEMF/Column, that provides support for transparently decentralized persistence and access on top of a distributed column store.
Distribution for graph processing languages Among distributed graph transformation proposals, a recent one is Mezei et al. [18]. It is composed of a transformation-level parallelization and a rulelevel parallelization with four different matching algorithms to address different distribution types. In another work  [19] , Izso et al. present a tool called IncQuery-D for incremental query in the Cloud. This approach is based on a distributed model management middleware and a stateful pattern matcher framework using the RETE algorithm. The approach has shown its efficiency, but it addresses only distributed model queries while we focus on declarative transformation rules. Two approaches map a high-level graph transformation language to the Pregel programming model  [20, 21]. Krause et al. [20]  proposed a mapping of a graph transformation language and tool, Henshin, to the "BSP model transformation framework" on top of the BSP model.
The approach is based on a code generator that translates the graph transformation rules and transformation units into a Pregel program. The matching phase is split into a series of local steps. A local step inspects if a local constraint is satisfied and generates, extends, or merges a set of partial matches. A search plan generation algorithm is responsible for the generation of local steps. In a similar approach, Tung et al. [21]  implemented their own DSL for the specification of graph transformations. This DSL is also compiled into a Pregel program and executed over a distributed cluster. The DSL inherits most of its constructs from UnCAL, a query language and algebra for semi-structured data based on structural recursion. The semantics of UnCAL was improved to support the basic Pregel skeletons.
In contrast to the previous approach, this one supports successive applications of queries/transformations. In particular, both approaches implemented their framework on top of Giraph, an open-source implementation of the Pregel model. Besides our work, the only other proposal addressing relational MT distribution is Lintra, by Burgueño et al. [22] , based on the Linda coordination language. Lintra uses the master-slave design pattern, where slaves are in charge of executing in parallel the transformation of sub-models of the input model. The same authors propose a minimal set of primitives to specify distributed model transformations, LintraP  [23]. With respect to our approach, Lintra requires to explicitly use distribution primitives, but it can be used in principle to distribute any transformation language by compilation.
VIATRA 3 offers a family of internal DSLs to specify advanced tool features built on top of existing languages like EMF-IncQuery and Xtend. VIATRA-CEP  [33]  is an engine for streaming model transformations by combining incremental transformation and complex event processing. It includes a DSL for defining atomic event classes and combining them into complex patterns and events. Martínez et al. [34]  introduced a reactive model transformation engine for ATL. This work combines efforts on enabling incrementality and lazy evaluation of ATL transformations. These approaches are well-suited to the model-driven applications involving frequent runtime updates. The transformation engine takes care of re-executing only the necessary computation affected by the update. For efficient execution of one-shot transformation on VLMs, these approaches fail drastically.
High-level languages for distributed data-parallel computing Many high-level languages for data-parallel computing targeting distributed programming models have been proposed. However, these languages are not designed for performing distributed model transformations. Microsoft SCOPE  [35] , Pig Latin  [36] , and HiveQL  [37]  are high-level SQLlike scripting languages targeting massive data analysis on top of MapReduce. Pig Latin and SCOPE are hybrid languages combining both forces of a SQLlike declarative style and a procedural programming style using MapReduce primitives. They provide an extensive support for user-defined functions. Hive is a data warehousing solution built on top of Hadoop. It comes with a SQL-like language, HiveQL, which supports data definition statements to create tables with specific serialization formats, and partitioning and bucketing columns.
DryadLINQ is a language designed to target the Dryad  [38]  engine, a generalpurpose distributed execution engine for coarse-grain data-parallel applications. Unlike PigLatin or SCOPE, which introduce new domain-specific languages, DryadLINQ is embedded as constructs within existing programming languages. A program written in DryadLINQ is a sequential program composed of expressions specified in LINQ, the. NET Language Integrated Query. The expressions perform arbitrary side-effect-free operations on datasets and can be debugged using standard. NET development tools.
Relational-based approaches Connected Data Objects (CDO) model repository  [42]  is the de facto standard solution to handle large models in EMF by storing them in a relational database. It was initially envisioned as a framework to manage large models in a collaborative environment with a low memory footprint. However, different experiences have shown that CDO does not scale well to very large models  [43, 44, 45]. CDO implements a client-server architecture with transactional and notification facilities where model elements are loaded on demand. CDO servers (usually called repositories) are built on top of different data storage solutions. However, in practice, only relational databases are commonly used.
NoSQL-based approaches Barmpis and Kolovos  [46]  suggest that NoSQL databases would provide better scalability and performance than relational databases due to the interconnected nature of models. Morsa  [44]  was one of the first approaches to provide persistence of large-scale EMF models using NoSQL databases. Specifically, Morsa uses MongoDB [47], a document-oriented database, as its persistence backend. Morsa can be used seamlessly to persist large models using the standard EMF mechanisms. As CDO, Morsa is built using a client-server architecture. Morsa provides on-demand loading capabilities together with incremental updates to maintain a low workload. The performance of the storage backend and their own query language (MorsaQL) have been reported in  [44]  and  [45]. Mongo EMF  [48]  is another alternative to storing EMF models in MongoDB.
Moreover, EMF Fragments on top of HBase is not transparent with regard to model distribution. Queries and transformations need to explicitly take into account that they are running on a part of the model and not the whole model. These backends assume to split the model into balanced chunks. This may not be suitable for distributed processing, where the optimization of computation distribution may require uneven data distribution. Finally, existing solutions using a client-server architecture (e. g. CDO over a distributed database) use a single access point. Even when model elements are stored in different nodes, access to model elements is centralized, since elements are requested from and provided by a central server. This constitutes a bottleneck and does not exploit a possible alignment between data distribution and computation distribution.
Method signatures and SimpleStatements (SimpleStmt) are kinds of FlowInstruction. A Parameter is a kind of Variable that is defined in method signatures. The dataflow diagram (Fig. 1b ) has analogous concepts of FlowInstruction, Method and SimpleStatements but a different topology based on the dataflow links among instructions (dfNext). For every flow instruction n, a dfNext link has to be created from all nearest control-flow predecessors m that define a variable which is used by n. Fig. 2  shows an example of models for each metamodel, derived from a small program calculating a number factorial. For readability reasons, and in order not to congest our graphs, containment references are omitted. As it can be seen in the figure, the transformation changes the topology of the model graph, the number of nodes and their content, and therefore can be regarded as a representative example of general transformations.
The proposed mapping is conceptually similar to the original ATL algorithm. As an example, Figure  5  shows how the ATL transformation of our running example could be executed on top of a MapReduce architecture comprising three nodes, two maps and one reduce workers. The input model is equally split according to the number of map workers (in this case each map node takes as input half of the input model elements). In the map phase, each worker runs independently the full transformation code but applies it only to the transformation of the assigned subset of the input model. We call this phase Local match-apply. Afterwards, each map worker communicates the set of model elements it created to the reduce phase, together with trace information. These trace links (grey arrows in Figure  5 ) encode the additional information that will be needed to resolve the binding, i.
In particular, we rely on the on-demand loading mechanism to ensure that only needed elements are loaded, especially when the model is too big to fit in memory. Also, we exploit the different caching mechanisms shipped within NeoEMF reduce accesses to the database and improve the access time of already loaded elements. NeoEMF/Column is built on top of HBase, a decentralized wide-column store. NeoEMF/Column hides the model distribution from client's applications. Model access to remote model elements in NeoEMF/Column is decentralized, which avoids the bottleneck of a single access point, and alleviates the alignment between data distribution and computation distribution. NeoEMF/Column is delivered with two stores, the first one is Direct-write and the second one is Read-only. The first store optimizes memory usage by reflecting model changes directly to the underlying backend.
Guaranteeing ACID properties for distributed MTs with ATL HBase is not a strongly ACID-compliant database, it provides ACID semantics only on a per-row basis. It is up to users to employ this semantics to adapt ACID properties according to the behavior of their applications. Notably, HBase is shipped with the following warranties: • Any Put operation on a given row either entirely succeeds or fails to its previous state. This holds even across multiple column families. Same for the Append operation • The CheckAndPut is atomic and updates are executed only if the condition is met, similar to the CAS mechanism • Any Get or Scan operation returns a complete row existing at the same point in the table's history • Get operations do not require any locks. All reads while a write in progress will be seeing the previous state In this perspective, we adapted ACID properties semantics as provided by HBase, in order to guarantee the set of ACID properties needed by ATL.
Tool Support: ATL on MapReduce (ATL-MR) Figure  7  shows the high-level architecture of our distributed engine on top of the EMF. ATL-MR runs on an Apache Hadoop  [52]  cluster. Hadoop is the leading open-source implementation of MapReduce. The Master node is responsible for distributing the input model, monitoring the ATL-MR Slaves, and finally returning the output results. Each node in the Hadoop cluster transparently communicates with the underlying backend through an EMF model management interface, and hence, making our distributed framework unaware of the persistence backend type. Indeed, besides supporting the de-facto serialization format, XMI  [59] , ATL-MR is also coupled with a multi-database model persistence framework, NeoEMF  [60]. ATL-MR relies on the HDFS to distribute all of its input and output models, together with the transformation specification.
Experiment I: speed-up curve For this experiment, we have used a set of 5 automatically generated Java programs with random structure but similar size and complexity. The source Java files range from 1 442 to 1 533 lines of code and the execution time of their sequential transformation ranges from 620s to 778s. The experiments were run on a set of identical Elastic MapReduce clusters provided by Amazon Web Services. All the clusters were composed of 10 EC2 instances of type m1. large (i. e. 2 vCPU, 7. 5GB of RAM memory and 2 magnetic Hard Drives). Each execution of the transformation was launched in one of those clusters with a fixed number of nodes -from 1 to 8 -depending on the experiment. Each experiment has been executed 10 times for each model and number of nodes. In total 400 experiments have been executed summing up a total of 280 hours of computation (1 120 normalized instance hours  [62] ).
Experiment II: size/speed-up correlation To investigate the correlation between model size and speed-up we execute the transformation over 4 artificially generated Java programs with identical structure but different size (from 13 500 to 105 000 lines of code). Specifically, these Java programs are built by replicating the same imperative code pattern and they produce a balanced execution of the model transformation in the nodes of the cluster. This way, we abstract from possible load unbalance that would hamper the correlation assessment. This time the experiments have been executed in a virtual cluster composed of 12 instances (8 slaves, and 4 additional instances for orchestrating Hadoop and HDFS services) built on top of OpenVZ containers running Hadoop 2. 5. 1. The hardware hosting the virtual cluster is a Dell PowerEdge R710 server, with two Intel Xeon X5570 processors at 2.
In order to solve the issues above, we proposed NeoEMF/Column. Thanks to the lazy-loading mechanism, we were able to load in each node only the model elements that are necessary to compute the transformation of the assigned split. Besides, NeoEMF/Column allows concurrent read/write, enabling the parallelization of the reduce phase. According to existing benchmarks for top NoSQL databases  [63] , HBase is well-suited for read-mostly workloads but not insert-mostly workloads. As a result, when dealing with transformations requiring extensive writes on target models, some performance drops can be noticed. Finally, it is worth to mention that the same models require more space when stored in NeoEMF/Column, compared to XMI. This is because of HBase internals. To deliver high-availability and fault-tolerance, HBase relies on table replication, table snapshots, and rows versions.
Moreover, we do not handle ATL imperative code blocks. We argue that, although imperative blocks simplify the expression of complex transformations, most of the transformation logic can be specified using declarative-only ATL. As for lazy rules and unique lazy rules they are currently not parallelized, but handled in the same way as in EMFTVM, i. e. , they are executed in a final step. Finally, ATL does not support recursive rule applications (i. e. , further transformation of target elements), neither does ATL-MR.
Conclusion and Future Work In this paper, we exploited the recent emergence of systems and programming models for distributed and parallel processing to leverage the distributed transformation and persistence of VLMs. In particular, we relied on a well-known distributed programming model, MapReduce, in order to enable the distributed execution of model transformation in a reliable and fault-tolerant manner. We also adopted NoSQL databases as a new solution for persisting VLMs. We showed that relational model transformation with languages like ATL is a problem that fits in the MapReduce execution model. As a proof of concept, we introduced a semantics for ATL distributed execution on MapReduce. We experimentally showed the good scalability of our solution. Thanks to our publicly available execution engine, users may exploit the availability of MapReduce clusters on the Cloud to run model transformations in a scalable and fault-tolerant way.
Acknowledgments This work is partially supported by the  MONDO  project,  EU Seventh Framework  programme No. ICT-611125 ; and the  MegaM @ Rt2  project, which has received funding from the  Electronic Component Systems for European Leadership Joint Undertaking  under grant agreement No. 737494. This Joint Undertaking receives support from the  European Union 's  Horizon 2020 research and innovation programme and Sweden, France ,  Spain, Italy, Finland , and  Czech Republic.
In Na 2 WO 4 and Na 2 MoO 4 systems which were made by Pistorius  [4] , it has been reported that Na 2 WO 4 exhibits at least one first-order phase transition at around 901 K. It was suggested that the new phase has an orthorhombic symmetry, possibly P nam. It was also suggested that another phase exists, which is stable only between 860. 6 and 861. 8 K  [9]. In this paper, sodium tungstate particles were prepared by a solid-state reaction. We report the electrical properties and mechanism of conduction of Na 2 WO 4 elaborated by a solid-state method at 630 K using impedance spectroscopy. In addition, the results show for the first time, to our knowledge, the optical properties of the Na 2 WO 4 sample using spectroscopic ellipsometry (SE) in the range of 200-2200 nm with a step of 1 nm by means of the DELTA PSI2 software based on a new amorphous dispersion formula at room temperature.
Both the flat faces of pellet samples were electroded with high-purity fine silver particle paste for all the electrical and dielectric measurements. Two platinum electrode configurations were used to perform the electrical measurements. The digital vernier calliper (0-150) mm range is used to measure the thickness of the Na 2 WO 4 sample. We found a thickness of 0. 15 mm close to the ellipsometry results of 0. 154 mm. It can be seen that the standard deviation (σ ) between the exact and measured values of the Na 2 WO 4 particles is 0. 0028. The lower the standard deviation, the closer the data points tend to be to the mean (or expected value).