dataesr/scientific-paragraphs-categorization huggingface dataset:
Additional data needed Our paper has highlighted the need for better data collection on dFADs in the WCPO. While the study provides a useful baseline of the current materials and designs used in this region, the data collected by observers is limited in the level of detail and precision needed to fully document all the features of dFAD materials and designs. Greater efforts to obtain data on mesh size, dFAD design, biodegradability of materials, and their proportion in the overall materials, including on all new dFADs deployed, any retrieved dFADs or those that are found beached, should also be undertaken. Protocols to estimate dFAD submerged appendage depth could also be considered. However, it seems unlikely that all this information can be obtained by observers and alternative sources of information will be required to improve monitoring of dFAD materials Data quantity and information content could be improved by updating the form currently used by fisheries observers to record dFAD related information, and/or in a specific dFAD logsheet filled out by vessel captains  [39].
Literature Review on Binary Formats Serialization is a process widely used in IoT to transmit information between devices. It involves converting data structures or object states into a format that can be transmitted over a network and then reconstructed on the other end. Thus, serialization is important for IoT devices as it allows for efficient and reliable transmission of data, which in turn can enhance the limited capabilities and prolong the lifespan of these devices  [22]. Moreover, serialization formats are widely utilized for the efficient transmission of information between IoT devices  [23]. Binary formats, a subset of serialization formats, represent data through binary encoding and are known for their ability to facilitate efficient transmission and storage, such as CBOR. Other binary formats identified in the literature include: 1.
Binary JSON (BSON) : an open-source, schema-less binary data serialization mechanism that was developed for the storage of key-value pairs (JSON-like maps) in the MongoDB database. It is designed to be lightweight and efficient and is represented as key-value pairs, where keys are strings and values can be any supported data type. Binary JSON (BSON) is suitable for IoT applications, particularly sensor nodes, due to its efficient encoding/decoding and fast traversal  [24]. Its major distinguishing feature is the capability for an in-place update which allows it to maintain a compact representation. It can also be used in other applications through open-source libraries  [16].
The main technological method to integrate numerous heterogeneous devices using different communication technologies is multimode radios. However, security concerns can arise when doing so. A device that uses multiple wireless protocols may provide more attack vectors through which malicious actors could secretly introduce unwanted malware and monitor network data  [9]. For syntactic interoperability, messaging protocols such as Constrained Application Protocol (CoAP), Extensible Messaging and Presence Protocol (XMPP), Advanced Message Queuing Protocol (AMQP), and some platforms have emerged as solutions, each providing essential interoperability capabilities between domains. Although devices are capable of flawless communication, they still cannot understand each other. Therefore, additional techniques are required to express information semantics in a way that can be understood by all IoT devices.
The different devices with different data formats and different APIs are another major problem in IoT interoperability. Due to the lack of data semantics and common standards for interpreting the meaning of the data, as well as the incompatibility of devices at the data layer, the dynamic nature of the data is a significant barrier to communication between IoT devices. In addition, the data must be discoverable, which can be difficult with enormous volumes of remote networks and cloud-based data  [11]. Finally, the majority of IoT data measurements are presented in TS format, nevertheless, this representation depends on the application or the environment in which the system is employed  [12]. Even a single measurement is a degenerated case of a TS representation. Indeed, we have observed that the works from the literature are concentrated on exploiting the data rather than on efficiently representing it.
Big Picture: The Proposed Architecture Figure  2  depicts our proposed architecture for IoT networks that encompasses the implementation of a middleware component between the data transmission process and the information processing process. The implementation of this middleware allows us to concentrate on the production of interoperable datasets. This, in turn, enables the seamless integration of IoT devices into various information systems without requiring any modifications to the actual code of the device. Then, our vision for the IoT architecture is centered on facilitating the integration of IoT devices into different information systems in an efficient and effective manner. In our proposed architecture for IoT networks, the device user application is responsible for generating all the information obtained from the measured values.
To facilitate the efficient management of the data transmission process and enable the seamless integration of IoT devices into various information systems, we propose to implement a middleware, placed between the transmission and information processing stages. Furthermore, the primary function of this part is to compactly group the data generated by a sensor using a common TS representation. This is a key contribution of our research. The middleware is also responsible for selecting the appropriate interface where the data will be transmitted, and for controlling the size and the periodicity of each measurement depending on the interface, band restrictions, and the type of measurement. The transmission of data over wireless networks, such as Wi-Fi and 5G, requires the use of appropriate protocols to ensure efficient and reliable transmission.
In this context, the use of the UDP/IP/CoAP protocol stack is commonly employed for the transmission of data to a proxy. To meet the specific requirements of networks such as LoRaWAN and NB-IoT, which have limited frame sizes, it is beneficial to employ techniques to reduce the size of the data being transmitted. Static Context Header Compression (SCHC)  [37]  is a header compression protocol, to reduce the size of the header information in the data packet. When compression is not enough, it also uses Fragmentation, to divide the data into smaller packets that can be transmitted more efficiently. Re-transmissions of lost packets is also provided to assure reliability. Thus, SCHC  [37]  could be used to compress IP/UDP/CoAP over LoRaWAN and NB-IoT which helps to meet the requirements of L2 word size  [38, 39].
CBOR Templates: An Optimization for TS Data Representation The utilization of CBOR, a binary data format known for its extensibility, presents the opportunity to optimize the transmission process through the definition of new tags. As outlined in  [41] , the proposed use of a CBOR template allows for the handling of variables, thus enabling the transformation of data representation from formats such as JSON to CBOR. As defined by  [41] , a CBOR template is a CBOR data item that contains one or more variables. These variables are represented within the template as a CBOR data item that contains a specific identifier, commonly referred to as CBOR tag 42. This specific identifier allows for the efficient identification and handling of variables within the CBOR template, resulting in a reduction of the overall number of bytes transmitted during the process.
Tree Formatting In this study, we present a novel approach for representing the location of variables in CBOR data items through the use of a tree structure within the TAGN model. This approach allows for a reduction in the amount of data transmitted by IoT devices and opens the possibility for the use of non-static templates in future developments. As an illustration of this approach, we considered the example presented in Listing 16, which features nested arrays across four levels to demonstrate the tree representation. This representation allows for a clear and efficient identification of the location of variables within the CBOR data item. [ [0 , 1 , 2 , 3] ,  [4 , 5 , [ 6 , 7 , 8 , 9]  ] ,  [10 , 11]  ] The tree representation of the array presented in Listing 16 is illustrated in Figure  3.
Delta Between Measurements In this section, we present the incorporation of delta values in CBOR templates as a means of reducing the amount of data transmitted by IoT devices. The utilization of deltas allows for the transmission of only the differences between subsequent measurements, rather than transmitting the entire measurement values. To illustrate this concept, we provide the example presented in Listing 13. The proposed approach of using deltas is shown to effectively reduce the amount of data sent by IoT devices while preserving the integrity of the measurement data. Then, the CBOR data item for the STS template is necessary to reproduce Listing 13 is:  [ 32, 20, 31, 21, 30, 22 ]. This data item requires 10 bytes when encoded using CBOR. By utilizing the delta values between subsequent measurements, the data size can be reduced.
In this case, the difference in temperature is -1 (32 -1 = 31, 31 -1 = 30) and humidity is +1 (20 + 1 = 21, 21 + 1 = 22). Therefore, only the first value is necessary as a reference. As a result, the array using the delta between measurements is: [ 32, 20, -1, 1, -1, 1 ], which requires only 8 bytes rather than 10. The utilization of deltas to represent measurements is particularly beneficial when the measurement values are higher. This is explained by the example of [535,537,539,538] which requires 13 bytes of data when encoded using CBOR. In contrast, the use of delta values [535,2,2,-1] reduces the data size to only 7 bytes. This first approach for delta uses the difference horizontally. However, it is possible to introduce a delta using the difference between the measurements vertically.
Then, consider a CBOR template where the CBOR data item to replace is depicted by Listing 17. Listing 17 requires 53 bytes when encoded using CBOR Then, when we use the horizontal delta, it transforms Listing 17 to Listing 18 using only 29 bytes instead of 53 bytes, reducing around 45% the number of bytes to represent the same information. Listing 18. Example of a CBOR data item with horizontal delta representation. Each array contains the reference value (first position of the array), and then the difference between the subsequent values (i. e. , 535 + 2 = 537, 537 + 2 = 539, 539 -1 = 538). [ [535 , 2 , 2 , -1] , [550 , 1 , 1 , 1] , [572 , 2 , -1 , -3] , [590 , -1 , -1 , -1] ] Moreover, the difference vertically (vertical delta) as depicted in Figure  4  is between each reference value (i.
e. , 535, 550, 572, 590), thus with 535 as the reference value for all the measurements the difference will be (+15, +22, +18) The vertical delta is designed to be used when the data transmitted by the device corresponds to the same measurement when multiple sensor devices are used to collect the same type of information, e. g. , humidity measurements. In this case, as the information does not change abruptly, it is possible to reduce the amount of data sent even more compared to only using the horizontal delta. The utilization of delta values as proposed in this section results in a significant reduction in the amount of data transmitted by IoT devices. This is evidenced by the example presented in Listing 18, which requires only 23 bytes when encoded using CBOR. This represents a reduction of approximately 54% compared to when the delta is unused.
Variable-Based TS (VTS) The utilization of CBOR variables and templates in Section 5. 1 promises to reduce efficiently the amount of data transmitted by IoT devices. However, this approach is limited by the requirement of knowing the exact number of data items or variables to be replaced. This limitation can pose a challenge in certain cases, for example when the number of data items or variables is not known in advance. In this section, we propose the inclusion of a new value to the TAGN specification. The incorporation of this new value addresses the limitation of the previous approach and makes it possible to represent TS data items that have an unknown number of data items. This is achieved by using a template and an array of information depicted in Listing 20. Listing 20. VTS template to represent Listing 13.
[ { 'n ': ' temperature ' , 'u ': 'Cel ' , 'v ': TAGN (0 , true ) } , { 'n ': ' humidity ' , 'u ': '% RH ' , 'v ': TAGN (1 , true ) } ] It is important to note that the identification of the CBOR variables present in the CBOR data item can be achieved through the utilization of the TAGN tag. The remaining value in the TAGN specification indicates the location at which the corresponding value can be found within the data item. Then, the structure of the TAGN is represented in the format from Listing 21. Listing 21. TAGN structure for VTS.
[ [32 , -1 , -1] , [20 , 1 , 1] ]. It is important to note that the understanding of how the template works and how the CBOR data item was constructed is available in Sections 5. 2 and 5. 3, respectively. Thus, the outcome of the template when values are replaced is depicted in Listing 23. The utilization of the template presented in Listing 20 allows for a degree of flexibility in terms of the number of values that can be transmitted. This is due to the presence of the Boolean value 'true' within the TAGN field. As a result, it is possible to transmit multiple values for both humidity and temperature. As an example, the CBOR data item depicted in Listing 24 can be utilized to transmit two values for humidity and two values for temperature. Listing 24. VTS CBOR data item with only two measurements.
[ [32 , -1] , [20 , 1] ] Then, substituting the values from the CBOR data item in Listing 24 into the VTS template, it produces the output shown in Listing 25. [ { 'n ': ' temperature ' , 'u ': 'Cel ' , 'v ': 32 } , { 'n ': ' humidity ' , 'u ': '% RH ' , 'v ': 20 } , { 'n ': ' temperature ' , 'u ': 'Cel ' , 'v ': 31 } , { 'n ': ' humidity ' , 'u ': '% RH ' , 'v ': 21 } ] In the last two examples, it is evident that there are two arrays present. These arrays are utilized to represent two distinct variables-temperature and humidity-independent of the number of measurements that are sent. Thus, this approach is organized by variables, as illustrated in Figure  5. The use of arrays in this manner allows for efficient storage and manipulation of the data, as each variable can be accessed and processed separately.
Metadata Thus far, the examples presented have illustrated the usage of a basic payload. However, it is important to note that the data transmitted within the IoT context is often more complex and multifaceted. In addition to the actual measurement of the variable, certain use cases may require the inclusion of supplementary information, such as: 1. The timestamp of the measurement; 2. The identification of the sensor; 3. The precision of the sensor; 4. The unit of measurement for the sensor; 5. Among others. To address the need for this additional information, we propose the incorporation of a feature referred to as 'metadata'. This feature allows for the differentiation between the metadata and the measurements being transmitted. Then, to facilitate the storage of this metadata, we propose the utilization of a map type in CBOR format.
This map type will be present every time a message is sent, allowing for the clear and organized handling of the data sent by the IoT device. Thus, the metadata representation in the VTS template will be represented as in Listing 26. Furthermore, as mentioned in Section 2. 2, integers are optimized to be represented in CBOR. Thus, we use the integers 0, 1, 2, 3, 4 and 5 to represent the keys in the corresponding map, referring to the context, timestamps, precision, delta, and unit respectively. Finally, Table  2  introduces the metadata values defined in this proposal. Here, you can find a brief meaning, the value defined for each metadata value, the unit used to represent each metadata value, and an example, where the general or specific metadata can be found, and the default value when it is not present in the CBOR data item.
Listing 27 presents an example of a time stamp present in the metadata. Listing 27. Example of a time stamp in the metadata. The number 1 represents the time and the corresponding value is in EPOCH format, while the number 2 represents the difference in seconds between measurements, in this case, corresponding to 30 s. [ { 1: 1654070400 , 2: 30 } ] Listing 27 depicts that the initial measurement in each array of the CBOR data item was recorded on Wednesday, 1 June 2022 at 10:00:00. The subsequent measurements were acquired with an interval of 30 s. This would result in the second measurement being recorded on Wednesday, 1 June 2022 10:00:30, the third measurement on Wednesday, 1 June 2022 10:01:00, and so forth. •.
4: Delta The difference between consecutive values, referred to as delta, is described in section 5. 3 and can be either horizontal or vertical in nature. The presence of delta is indicated by the integer 4. The value within the CBOR metadata object represents the orientation of delta, with 1 indicating a solely horizontal orientation, 2 indicating both horizontal and vertical, and 10 indicating delta being inactive. In the absence of delta being specified in the metadata, a default value of 1 is assumed. In the same direction as other works such as  [45] , delta encoding typically involves only horizontal differences. An example of a delta value as found within the metadata is presented in Listing 29. [ { 4: 10 } ] Thus, Listing 29 shows that the measurements do not have to be managed as the difference of the subsequent values.
Specific Metadata Specific metadata can be found in the measurement array, as shown in Listing 26. This specific metadata have the ability to override the general metadata, but if not present, the general metadata will apply. Furthermore, the values specified in Section 5. 5. 1 can be altered except for the context. Then, consider Listing 32 as an example of specific metadata. In the first array of measurements, it overwrites the time difference  (2). Now, the measurements are not taken every 30 s, instead, the value indicates that each measurement inside the array is taken every 45 s. 2. In the second array of measurements, it overrides the precision (3). Now, the measurements no longer have a precision of 3, instead, the value indicates that each measurement now has a precision of 4. •.
5: Unit The unit, represented by the integer 5, identifies the metric unit used for each variable taken. To ensure validity, all possible values for this key must be listed in  [42]. Thus, when the value does not exist in this list, it will not be accepted by the VTS template. As an example, Listing 32 can be modified to reflect that the first array of measurements is for a temperature sensor measuring in degrees Celsius. The result of this modification is shown in Listing 33. Listing 33. Example of specific metadata with unit specification. In this case, the value 5: 'Cel' in the object where is specified, the measurements are in Celsius degrees.
Performance Evaluation In this section, we present a comprehensive performance evaluation of the proposed time series representation format VTS comparing against JSON, and other binary formats as CBOR, Protocol Buffers (protobuf) and ASN. 1. The evaluation is divided into five parts: Payload Comparison, Fragmentation, Time-on-Air, Battery Lifetime, and Metadata Comparison. In the Payload Comparison, we compared the payload of the proposed representation format against the conventional JSON representation and binary formats as CBOR, Protocol Buffers (protobuf) and ASN. 1. The Fragmentation section evaluated the impact of the proposed representation format on the packet Fragmentation when the payload is sent over a LoRaWAN network. Consequently, in the Time-on-Air section in a LoRaWAN network, we calculated the time required to transmit the data collected by IoT devices using VTS, JSON, Protocol Buffers (protobuf), ASN.
Real World Data To test the template proposal using real world data, we used the dataset 11 from the repository  [46]. This dataset consists of the first 300 observations obtained from a GPS placed on a bicycle to promote cyclist safety in smart cities  [47]. The GPS system includes latitude, longitude, and velocity information, resulting in a total of 900 measurements. Listing 39 presents the JSON format with the SenML structure that must be employed for data transmission. In this instance, it necessitates 42, 843 bytes for successful transmission. Listing 39. The JSON representation of the GPS real world data. [{ 'n ': ' Latitude ' , 'u ': ' Lat ' , 't ':1667135896307 ,'v ': -29. 620745} , { 'n ': ' Longitude ' , 'u ': ' Lon ' , 't ':1 , ' v ': -51. 127167} , { 'n ': ' Velocity ' , 'u ': ' m /s ' , 't ':1 , ' v ':0.
Metadata Comparison In this section, we evaluated the impact of the new metadata proposed in this article against the metadata proposed in  [17]. Consider the metadata defined in Listing 40. This metadata corresponds to a payload of 9294 bytes in the dataset 3 from [46]. Listing 40. Old definition example of Metadata in  [17]. { bt : 1593982800 , dt :10 , bp :3} The first thing to note is that the proposed metadata takes into account that strings are not optimised in CBOR, and therefore, strings such as "bp" are represented as the integer 3. Another aspect is the use of the "context" in the metadata proposed in this article. In comparison, the metadata outlined in  [17]  requires the transmission of all metadata in every packet. In this proposal, once the proxy has gained knowledge of the "context", it is no longer necessary to transmit the full payload, but only the "context" is transmitted.
The concept of a WDP is then introduced to estimate the percentage rate of the erosion for each contact surface. The updating of the geometry is made by shifting the contact nodes with a vertical translation of the wear depth. Finally, an updated mesh is generated by means of the code GMSH  [19]. Thus, after p incremental process, the pth updating of the contact surfaces leads to a new geometry configuation called "profile p". The strategy of the simulation process is illustrated in Fig. 1. Only the implementation of the step 2 is set out in Section 2. 2.
Then, because a CNN2D requires a multi-dimensional format in input, stigmergic track encoding is adopted to build encoded features in a multi-dimensional format. It adopts the directed weighted network (DWN) that takes into account the human spatio-temporal tracks with a requirement of overlapping activities. It represents a matrix that describes an activity segment. Once the DWN for each activity segment is determined, a CNN2D with a DWN in input is adopted to classify activities. The proposed approach is applied to a real case study: the "Aruba" dataset from the CASAS database.
This work proposed an online human activities' recognition schema on streaming data from binary sensors. The methodology integrates three steps: (1) a dynamic segmentation method, (2) encoding, and (3) classification of activities using a deep learning technology (a CNN2D architecture) to test the efficiency of the proposed encoding technique. The dataset Aruba  [13]  is employed to evaluate our proposed methodology. This paper is structured as follows: The related works are summarized in Section 2. The proposed methodology is detailed in Section 3. Section 4 investigates the case study and the experimental results. Finally, concluding remarks are given in Section 5.