dataesr/scientific-paragraphs-categorization huggingface dataset:
During the handling of queries, all the nodes execute the queries that are distributed in the network and the results of each query get aggregated as they traverse the routing tree maintained by the system. In the same vein, Cougar  [29]  acts as a database of sensors where the query plans are provided to proxies that take care of activating the relevant sensors and applying the operations on the collected data. MaD-WiSe  [30]  offers a runtime system for queries that is fully distributed, and each sensor may directly execute part of a query plan and then deal with sensor-specific tasks. Borealis  [31] , previously Aurora, uses data stream diagrams, which express the combination of relational operators over the streams received by the system. From a theoretical perspective, various systems propose custom extensions to the relational model as well as custom implementations of the relational operators.
Macroprogramming-based DSMSs enable users to express tasks over the WSAN using a DSL instead of a query language. The resulting tasks, or macroprograms, are compiled into microprograms to be run on the networked nodes, hence easing the developer's work who no longer has to bother with the decomposition and further distribution of the macroprograms. Macroprogrammingbased DSMSs are overall similar to classical macroprogramming approaches aimed at WSAN. However, they feature additional primitives and mechanisms oriented toward stream management. For instance, Regiment  [35]  introduces a functional language that enables programming the WSAN and manipulating the streams that flow in the network. As for Semantic Streams  [36] , it defines a declarative language based on Prolog, which features data structures to handle streams, together with mechanisms to reason about the semantics of sensors.
To this end, the developers should be provided a way to represent WoT applications as abstract programs that are distributed dynamically in the actual network. In addition, sandboxes should be used to increase the overall reliability, as an attacker can benefit from arbitrary binary deployment to deploy malicious code on any open device. Service-oriented DSMSs aim to integrate with classical service-oriented architectures, thereby taking advantages of the existing infrastructure (interaction and discovery protocols, registries, service composition based on orchestration or choreography, etc. ). Similarly to database-oriented relational DSMSs, the simplest serviceoriented DSMSs are centralized with a unique point of data collection  [11, 38, 39] , or semi-distributed based on a set of data collection points  [40, 41].
The mashup graph is equivalent to the query plan that can be found in DSMSs that present sensor networks as databases. However, query plans are strongly coupled to the query language capabilities that are limited w. r. t. the set of operations that can be executed. In contrast, the high-level nature of the Dioptase components makes it possible to easily represent any element of a WoT application as components that produce and consume streams. For example, end-users, GUI and actuators can be abstracted as consumers while sensors, databases, crowd-sensors and any other type of data source (e. g. , a http://www. jisajournal. com/content/5/1/13 Web service that gives information about the weather) can be abstracted as producers. In addition, processors may implement any type of continuous computation, or task.
Data stream According to the literature  [5, 32, 46] , a stream is a sequence of discrete items that are linked by some properties (e. g. , same source, same type, time coupling, etc. ). The size of this sequence is theoretically infinite and it is not possible to know its end a priori. In Dioptase, each stream item is a tuple associated with a timestamp that can be explicit, if generated with the tuple, or implicit, if defined when the tuple is received  [5, 32, 46]. Then, as for relations in relational databases, a Dioptase stream adheres to a schema that defines the attributes of each tuple. In addition, the Dioptase schema is intended to take into account semantic aspects of the sensed data and the characteristics of the data source. In practice, the schema is composed of: • The Semantic concept of the attribute (e.
For example, the unit and semantic type can refer to ontologies of physical concepts and related models (prediction, interpolation or error models)  [47]. The connection between a component's output port to the input port of another component is established through a connector, i. e. , a software component that manages the transport, adaptation and presentation of the data as streams, between two components. We introduce two types of connectors for stream transportation in Dioptase: local connector and remote connector. The former manages connections between two components that are running on the same Thing and optimizes communication accordingly, while the latter acquires data from a component that is running on another Thing. Various specializations of the remote connector may be envisioned, notably for interfacing the Dioptase middleware with other data stream management systems, sensor networks (e.
While the Dioptase DSL, called DiSPL (Dioptase Stream Processing Language), supports generic-purpose structures (control flow statements), specific primitives are provided to manipulate data streams (e. g. , read/write into streams or build new stream items) and atomic components (e. g. , create new storages or migrate a processor). As a benefit, DiSPL enables the developer to describe a wide range of complex tasks and dynamically send them to any known Thing, at any time. Technical details about DiSPL to describe interpreted tasks are provided in the next Section. Compiled tasks are less flexible than interpreted ones, but they are more efficient (native code) and are useful to implement the library of common processing tasks (e. g. , compute an average value, count the number of items) which we refer to as operators.
Dioptase architecture and design Network communication is carried out through Web services that expose the resources of the Thing (access to streams and metadata, manage components, settings, etc. ). For this purpose, the middleware embeds a lightweight all-in-one Web client/server optimized to run with few resources. The services are written in native code and are directly compiled with the middleware. Their implementations are well-decoupled from the Web server and, instead of the costly TCP transport protocol, Web services protocols for resource-constrained devices can be used, such as CoAP or HTTPU (HTTP over UDP)  [52]. Precisely, only a subset of HTTP is useful to implement a Web service  [52]  and, consequently, our small HTTP implementation supports only a limited set of requests (GET/POST only), headers, MIME types, encodings (UTF-8 only), languages and mechanisms.
), Dioptase is highly modular and can be adapted to the resources of the Things. Concretely, the middleware deployment consists of two steps: customization and deployment. Customization of the middleware consists into removing irrelevant modules (e. g. , compression/cryptography plugins or the interpreter component) and adding or implementing new modules based on the specific capabilities of the Thing (e. g. , hardware video decoding). For example, during this phase, the Thing's owner may implement new operators and register them in the standard library, for future usage. Similarly, the DiSPL DSL can be extended by defining additional packages of instructions (e. g. , a wrapper for a library deployed onto the Thing). Ultimately, the customized middleware is deployed onto the Thing and connected to the network.
In fact, customizing the middleware is rather straightforward, as the modules are clearly identified. Nevertheless, even if it has to be done only once, this operation can be time-consuming. Fortunately, a great deal of it can be simplified, by providing pre-packaged and preconfigured versions of Dioptase built for specific classes of Things (depending on their hardware resources). Regarding the development of Thing-specific components (e. g. , http://www. jisajournal. com/content/5/1/13 supporting a video decoding chip), widely used libraries can be shared between developers or, in the future, provided by the vendors.
Middleware services Dioptase is a service-oriented middleware that exposes the Thing's resources (sensors, actuators, components and streams) as services, and more specifically RESTful services because of performance constraints  [52]. The main middleware services are the streaming services that enable access to streams, and the management services which are used to manage and control the Thing and the middleware modules. Streaming Services are implemented using two different techniques supported by the web server's streaming plugin: (i) HTTP streaming, where the connection is never closed and each item is sent as chunks in the HTTP response, and (ii) Web hooks, which establish a callback service in the client in order to enable the server to send new items as HTTP requests. We use both techniques because of their respective advantages and drawbacks.
Once deployed, a processor can be stopped and removed, as well as any other component. As an example of task deployment, Appendix C presents a deployment request over HTTP for an interpreted processor that consumes two streams and executes a given DiSPL program. Deploying a storage component is a similar operation, provided the storage type is supported by the Thing. At present, the Dioptase prototype supports three types of storage: (i) memory storage (fixed or extensible), (ii) file storage, and (iii) database storage (for embedded databases). Unlike producer and processor components, storages have a memory of past states that can be queried a posteriori. A storage component can produce a stream only when it receives a query that expresses some constraints that can be temporal (items between two timestamps, items older than x, etc.
), volumetric (the x last items) or a combination of them. The complying results are presented as a new stream that ends when the last item is sent. Each storage type supports these constraints, but some storages can accept specific parameters (e. g. , the database storage can handle a SQL query directly). Similarly, actuators are presented as Web services and are based on the information provided by the Thing Driver about the physical actions that the Thing is able to perform. Each action can receive specific typed parameters that compose an actuation contract which defines the name and the type of each parameter, and the type of the returned result if any. Other services can be used to access the Thing's metadata about the embedded sensors and actuators, the Thing's capabilities (e. g. , hardware, location, load, energy level, operator library), and the components that are currently deployed (e.
Dioptase stream processing language (DiSPL) As already mentioned, non-blocking operations are executed by processors, which are components dedicated to the execution of (i) compiled tasks that are linked to the middleware during the customization phase, and (ii) http://www. jisajournal. com/content/5/1/13 interpreted tasks that are described using the DiSPL DSL and deployed during the execution. This makes it possible to build logical and physical mashup graphs that use both compiled and interpreted tasks. Using the management services presented in the previous section, the developer is able to ask any known Thing to create a processor that executes either (i) a compiled task by providing its identifier, or (ii) an interpreted task by providing the DiSPL source code of the task. The literature in stream processing already features languages like IBM SPL  [54]  but, in our case, the programs are intended to be interpreted directly onto the Things, as opposed to resource-rich servers.
As an example, the following snippet of DiSPL code shows the implementation of a simple COUNT program that uses instructions for reading the new incoming stream items (getNewItems), build new stream items (item), and write data into the output stream (write). Please note that a larger example is given in Appendix D, which consists in the implementation of a Bloom Filter  [56]  using DiSPL. ;initialization section init: ;creates a global variable for counting (define count 0) ;work section work: ;gets the set of new items (define diff (getNewItems "inStream") ) (if (> (size diff) 0) ;computes the new total ( (set count (+ count (size diff) ) ) ;writes the total into the output stream (write (item (now) "count" count))) ) http://www. jisajournal. com/content/5/1/13 As shown in Figure  4 , interpreted tasks rely on a dedicated parser, which converts the source code into an abstract syntax tree (AST).
Experimental results In order to evaluate our system, we implemented a prototype b of Dioptase in Java and deployed it onto devices with heterogeneous capabilities. The choice of Java is motivated by (i) the advances in porting the Java Virtual Machine to small sensors  [57] , (ii) the existence of all-in-one Java sensors, such as Sun SPOT, and (iii) the huge number of operating systems that supports Java, enabling us to work directly with a wide range of devices (computers, smartphones, embedded systems, etc. ). The experiments presented in this section have two goals. First, we want to show that the customization phase enables the use of the Dioptase middleware on heterogeneous Things in order to serve HTTP streams with suitable performances relative to available resources. Second, we aim to analyze the overhead due to the code interpretation mechanism, by comparing the consumption of resources by compiled and interpreted tasks, respectively.
This language aims to be simple, but flexible enough to describe such advanced operations and, for interoperability concerns, we plan to write converters from state-of-the-art stream processing languages like SPL  [54]  or C-SPARQL  [60]. We demonstrated that the Dioptase middleware can avoid the systematic use of centralized or partially centralized infrastructures, which are commonly used in WSAN-based DSMSs. In addition, we have shown that Dioptase is efficient enough to be deployed on average Things w. r. t. the IoT/WoT needs and use cases, and enables these Things to be integrated in the Web despite the additional complexity of data streaming communication. Dioptase remains a work in progress. Our work can be first improved in a technical way, especially by enhancing the efficiency of the interpreter or integrating other continuous operators.
Endnotes a In web development, a mashup is an application that composes data and services from many sources, using open programming interfaces. Some examples can be seen on http://www. programmableweb. com/mashups (last access: 10-14-2014). b We are finalizing the prototype for release. The current version is made available to reviewers at http:// www. rocq. inria. fr/arles/index. php/component/content/ article/248 (last access: 10-14-2014). The source code is password-protected: dioptase_inria_rev.
Specifically, the parameters are encoded in the multipart/form-data MIME format (line 2), which is the common format for high-length parameters  [62]. The processor name is defined at lines 5-8, the DiSPL code at lines 9-13 and the URIs of the input streams that must be consumed by the processor are defined at lines 14-18. Given these URIs, the operation will specifically consume a local stream, produced by an operation already deployed on the Thing, and a remote stream currently produced by another  Thing (173. 194. 34. 24).
The authors conclude that, even if the results of the image-based approach may be less accurate than the ones delivered by the range-based method, photogrammetry can be considered an interesting solution thanks to its scalability, low cost and onsite swiftness. Koutsoudis et al. 2013  use a similar methodology i. e. laser scanner data is used as a reference for comparison with dense stereo generated 3D data. Remondino et al. , 2012  present a critical insight and a metric evaluation of automated image orientation packages. Different datasets are used in this evaluation. Large and complex scenes with known shapes, precise ground control points (GCP), calibrated cameras and reference scale bars were used in the evaluation of the different software packages. The conclusion is that all the packages evaluated deliver similar results in terms of theoretical precisions of the computed object coordinates and recovered interior camera parameters in the case of a robust image network.
MICMAC and associated tools We use the suite of tools developed by the French mapping agency (IGN -Institut Géographique National) for our tests. This suite includes a number of tools. Among them, we find Apero and MicMac that represent the two main software solutions. The former computes the internal and external orientations of images (Pierrot-Deseilligny and Clery, 2011), whereas the latter performs the surface reconstruction phase by extracting depth maps from oriented images  (Pierrot-Deseilligny and Paparoditis, 2006). From an algorithmic point of view, the IGN's suite of tools implements mathematical formulations derived from both the photogrammetric and the computer vision fields, focusing thereby on the accuracy and metric content of the final results as well as the automation of the image-based pipeline.
Both precalibration and camera self-calibration are available with a choice of lens models. Finally, the dense image matching phase is carried out with the tool MicMac (simplified interface, Malt). The tool implements a multi-stereo formulation of the NCC (Normalized Cross Correlation) coefficient, specifically adapted to deal with large image datasets. The surface reconstruction is based on a multi-scale, multi-resolution image matching approach, which further reduces the required computational efforts and the possibility of having erroneous matching. In order to reconstruct a geometric surface, MicMac uses a regularization algorithm based on an energetic formulation.
Procedural workflow The IGN's suite includes very parametrical tools that provide the user with the possibility of finely controlling each processing phase through a large amount of attributes and parameters. This flexibility, however, forces the user to deal with the lack of clear rules and good best practices in the software manual. Furthermore, the acquisition protocol doesn't usually follow specific rules, especially in terms of convergence angles and employed focal setting. In order to fill these gaps, the present work aims at analysing the influence of different parametrical choices at each step of the IGN's suite. The effect of the image acquisition protocol employed is studied by examining its influence on the orientation and dense matching phases. For each step of the procedural workflow (Figure  2 ), a set of most significant parameters is examined, starting from selected acquisition protocols; adequate reference data are always employed.
It is true that manufacturers of laser scanners or 3D imaging systems provide to their customers a datasheet or a calibration certificate with some numerical values and sometimes a terminology that is much closer to VIM3 and GUM 2008. Nevertheless, it is important to understand that these documents are not generated according to an international standard but instead they are linked to internal company guidelines that may or may not be available to the customer. Fortunately, efforts are being made in international organizations like ASTM (E57), ISO/TC 213 (ISO 10360) and ISO/TC 172/SC 6 (ISO 17123) and by the German national body VDI-VDE (2634). Current methods rely on a comparison between a given measurement dataset from one "instrument" with another measurement dataset from a reference "instrument" which has a smaller uncertainty (at least four times smaller as per ISO 14253).
Methodology Our accuracy tests are performed using 'reference' data acquired with two hemispherical laser scanners (LS1 and LS2), one total station (TS), one laser tracker (LT), and some contrast targets. Only the TS and LT have a clear measurement traceability route; the laser scanners may have one but no information is present in the data sheets. The two experiments are conducted according to the protocols presented in Section 2. Small volumes are measured in order to restrict the study to estimating the accuracy over a limited number of instrument stations and single 3D points clouds. PolyWorks v12. 1. 18 IMAlign™ software package from InnovMetric Software Inc. provides the main image alignment and 3D point cloud comparison techniques. The alignment is based on an iterative algorithm that computes an optimal alignment by minimizing the 3D distances between surface overlaps in a set of 3D images acquired from unknown viewpoints.
Metrological assessment of image orientation Both image correspondences (Tapioca) and measured GCPs are employed in order to compute camera poses and orientations. In particular, the registration of image-based results within the Total Station (TS) reference frame is achieved by using seven well-distributed planar targets. Internal orientation parameters, pre-computed within a calibration procedure performed with an ad-hoc image dataset, are refined in the process by adopting a Fraser-derived formulation  (Fraser, 2001). Once orientations are defined, each pixel visible in at least two images can be backprojected into the 3D absolute space, defining its 3D position as intersecting rays. The 3D coordinates of nine CPs are thereby computed and then compared to the ones measured with TS. This accuracy assessment is performed starting from all available acquisition protocols, after having oriented the corresponding dataset with the procedure mentioned earlier.
Final standard deviations, σ, (Table  1 ) show that results achieved by the 60mm-lens are generally better than the corresponding ones gathered by the 24mm-lens. This is due in part by the better range and lateral accuracy provided by longer focal length, according to triangulation equations. Also, the combined datasets (highlighted in yellow) show the best metric performance. The best accuracy level (highlighted in yellow) is delivered by the dataset including images acquired by both lenses. In this case, an accuracy level below half a centimetre is achieved. The color-coded map associated with this acquisition protocol is shown in Figure  5 , together with a view of the compared 3D scene. The colour scale ranges from -10 mm (blue) to 10 mm (red). The error distribution shows that the areas delivering the largest deviations are mainly the followings ones:.
Metrological assessment of image orientation Once image correspondences and relative orientations are computed (Tapioca and Tapas), the datum ambiguity is solved in this experiment by using four well-distributed ground control points. In particular, GCPs are selected within the NRC-targets measured with the LT: the same data are employed in order to register also the LS2-acquired point clouds in the same LT reference frame. Camera calibration parameters are computed by performing a self-calibration within the bundle adjustment procedure. In order to evaluate the metric accuracy of the photogrammetric orientation results, the remaining 10 targets (contrast and NRC-targets) are then assumed as independent check points and matched in at least three images. Their 3D coordinates, thereby computed as intersections of homologous rays, are finally compared to the ones measured with the LT and LS2, delivering the standard deviations, σ, listed in Results show that the orientation algorithm achieves a considerably good accuracy level: all standard deviations are below 1 mm, with the only exception of one value.