dataesr/scientific-paragraphs-categorization huggingface dataset:
As it can be seen in Fig. 2 , dc and arkpress were the main filters besides the default gallica. The Dublin Core (DC) schema is a small set of vocabulary commonly used to describe a wide range of digital resources (video, images, web pages, etc. ). The schema describes metadata vocabularies that include sets of resource classes, type vocabularies, vocabulary encoding schemes and syntax encoding schemes. Its details are given in the official web site  5. In Gallica settings, arkpress is used to perform queries within a newspapers title and subgallica is used to filter the results page (facets search). Fig. 3  plots more detailed ratios of metadata filtering styles. The advanced queries also include three options (all, any and adj) concerning the text matching way that Gallica enables. The first one indicates the case of matching of all words.
Entities in Text Input. Next, we extract entities from within free text inputs, i. e. , from query keywords issued by users which are not related to any particular metadata field. First, we mapped all queries into DBpedia to extract entities from texts. We then determined their types using DBpedia in order to arrange them into 5 basic types: places, persons, events, groups and others. Fig. 10  shows the distribution of the entity types obtained from the free text inputs. Places is definitely the most popular entity type in the issued queries followed by persons. This is somehow natural as people often recall the past using the names of places where historical events happened as they may be interested in documents/objects related to the histories of locations they live at or are visiting. Tab.
Temporal Analysis Q. What dates are commonly used for filtering results? Q. How long are on average the filtering time spans? Q. How similar are queries issued for different centuries? We next analyze the way in which users filter the results by time. First, to provide background context, we start by showing the temporal span of content stored in Gallica in Tab. 4, from which we can observe that most of the content comes from the 19th and 20th centuries (40% and 46%, respectively). Next, we collect all time constraints from parameters of requests. As it was shown in Tab. 1 there are over 35 million requests in a dataset for which a time filtering was applied. The time filtering of search results is implemented by a parameter gallicapublication_data. We then convert all the collected temporal expressions from the parameter into corresponding durations.
Anyway, in general, the recent past is referred to more than the distant past. This is intuitive and correlates with the previous study conducted on news articles related to different countries  [1]. Finally, we can see that there are two peaks on years 1750 and 1914, the latter being the most common start date in the entire dataset. To understand why users use often these two we collected the top-10 words used with these two filtering choices, and present them in Tab. 5. (1914) (1915) (1916) (1917) (1918) ) is related to a book whose author analyzed the causes, course and impact of the WW1. Furthermore, "cb32693529c" and "cb328131247" are periodicals covering post 1750 periods, while "cb34378481r" is the ID of Journal officiel de la République française. "allcoll" is an internal keyword ("all collections") "fatherhood recognition" is probably a query performed by users in Journal officiel de la République française to find acknowledgement of paternity.
The more the two centuries have common words, the more similar they are. To plot the figure, we first collected queries that have start and end years as the gallicapublication_data filtering. We then determined which centuries are associated with each query. In particular, we counted how many years of each century are included within the interval delimited by the start and the end years. The centuries having the largest overlap were then assigned to the query. The algorithm is based on the following equation: Century(d) = freq({map(y)|y ∈ d}) (2) where freq returns elements that are the most frequent elements in the list of given arguments and map is a function taking a year and returning its century. For example, to a query with the start date of 1690 and the end date of 1950, the 18th and 19th centuries are assigned.
LIMITATIONS Input Words vs. Clicks In this work, we have not investigated how the queries were input. Some of the queries may originate as a result of users clicking on recommended items displayed on the front page of the Gallica portal (this could explain why some queries seem bit 'artificial', e. g. , being too long or having numbers mixed with characters). "ABCdaire1" (cf. Tab. 5) query is such an example of prewired queries in Gallica. Furthermore, Gallica provides various APIs which could be the reasons for some of such queries. We left their determination and analysis as a future work. Data Collection Time Span. We note that the data collection we used is a portion (15 months) of all logs published in Gallica. Subsequent work should investigate portions of data collected over different time frames in order to verify which of the results are specific to the particular time frames of data generation and which are of general character.
Once we can obtain data generated in different durations, we plan to perform such comparative investigation. Different Languages. As Gallica is an online portal, anyone can use it. In this paper, we implicitly made an assumption that all queries are in French and hence we have applied tools dedicated to French language. While the large majority of queries are indeed in French, naturally, there are ones in other languages, too. Further exploration should then involve different languages (e. g. , English, Italian) that Gallica supports as well as the cross-comparison of the obtained results. Also, geographical analysis is another interesting exploration.
CONCLUSIONS & FUTURE WORK Cultural heritage collections are commonly used for storing, preserving as well as finding and learning information related to the past. This wealth of data is then source of interaction and search from many ordinary users. In this paper we have studied how users search content in cultural heritage collections based on data collected from Gallica portal of the French National Library. The data we used is of large scale spanning 15 months. We mainly concentrated on entity analysis looking into the types of entities in queries and on the way in which temporal filters are associated with search queries. We have also analyzed which metadata filters and their combinations are commonly used. Our analysis provides observations that can complement existing investigations of CH collection search thanks to the novel focus on semantic (entity) and temporal angles.
We focus in particular on firmware update mechanisms that can work on constrained IoT devices. Such devices, as specified in RFC 7228  [19] , use microcontrollers -for instance Arm Cortex-M -on which run real-time operating systems, such as RIOT, FreeRTOS, µC/OS, Contiki, mbed OS, among others  [30]. Compared to machines that run full-blown operating systems, such as Linux, constrained IoT devices use a fraction of the power and are equipped with RAM and flash sizes in the kilobyte range. Constrained IoT devices cannot afford the energy drain of Wi-Fi, and thus connect to the network using low-power, wireless, link-layer technologies, such as Bluetooth Low-Energy, IEEE 802. 15. 4, LoRa, 3GPP Cellular IoT (NB-IoT), or through wired buses, such as BACnet. The contributions of this paper are structured as follows: (1) In Sections II-III, we survey available open standards and open source libraries, which provide useful generic building blocks that can be used to enable IoT firmware updates; (2) In Section IV, we design and implement a prototype that leverages the building blocks we surveyed.
The advantage of updating the full firmware is in the simplicity of this approach. Backend framework. The second aspect of IoT firmware updates concerns the backend framework and securing the supply chain of IoT software. The Internet Engineering Task Force (IETF) Software Updates for Internet of Things (SUIT) working group specifies a simple back-end architecture  [43]  for IoT firmware updates. 1 Exception handlers in the Arm architecture can be compared to the interrupt vector table in the x86 architecture. In addition to authentication and integrity protection, even when updates are stored on untrusted repositories, the SUIT specifications enable encrypting the firmware image, to protect against attacks based on reverse engineering. SUIT followed previous work such as  FOSE [? ]  which proposed firmware encryption and signing using JSON and JOSE.
For public key cryptography, Elliptic Curve Cryptography (ECC) is typically used because of the smaller key size (compared to RSA). The National Institute of Standards and Technology (NIST) standardized the Elliptic Curve Digital Signature Algorithm (ECDSA) for use with the P256r1 curve  [48] , which became popular in the industry. With ed25519  [35] , another signature algorithm, based on a different curve, was standardized. New standardization efforts are in progress to evaluate algorithms for the post-quantum crypto area  [47]. Firmware metadata. The IETF SUIT working group is currently standardizing a format for describing firmware updates. The SUIT group defines a so-called manifest, which provides (1) information about the firmware required to update the device, and (2) a security wrapper to protect the metadata end-to-end.
Among the standardized objects is the firmware update object. A more recent design is the CoAP Management Interface (CoMI)  [63] , which is standardized by the IETF. CoMI uses CoAP and a data model based on the YANG modeling language, and aims to reuse existing SNMP-defined objects and resources. CoMI is still in development, and a firmware update mechanism has not yet been defined; we do, however, expect that such an extension will be defined in the future. The Open Connectivity Foundation (OCF  3  ) standardizes an IoT device management protocol operating on top of CoAP and TL-S/DTLS for communication, similarly to LwM2M. The OCF defines a data model with RESTful API Modeling Language (RAML) as the data modeling language. While initially targeting bigger IoT devices in smart home environments, the OCF is now also considering other industry verticals.
Earlier work on device management for IoT devices use remote procedure calls instead of a RESTful design. For instance TR 69  [21] , also known as the CPE WAN Management Protocol (CWMP) developed by the Broadband Forum 4  offers firmware update functionality on higher-end IoT devices, such as Internet-connected printers. The successor of TR 69, called User Services Platform (USP)  [22] , was recently released by the Broadband Forum. De facto standard IoT operating systems. Off-the-shelf open source operating systems, such as Linux, cannot be used on low-end IoT devices, which lack the necessary hardware resources. Unfortunately, the increasing complexity of Internet-connected devices requires a fairly complex protocol stack, which includes IPv6, UDP, DTLS, and CoAP. This situation has led to the development of IoT operating systems, including many open source IoT operating systems  [30] , such as RIOT  [16] , Zephyr  [4] , Mbed OS  [12] , MyNewt or Tock  [40].
Components and Functional Overview Based on our survey of applicable open standards in Section 3, we utilize the following building blocks: The firmware metadata format based on the IETF SUIT manifest. The 6LoWPAN, IPv6, and CoAP transport stack. The LwM2M IoT device management solution. Digital signature algorithms based on ed25519 and ECDSA/P256r1. We selected the RIOT  [16]  operating system for this prototype, but the results can easily be transferred to other real-time operating systems. The remainder of this section provides a functional overview of the prototype. IoT device commissioning. From the embedded software point of view, the prototype we built is based on the design shown in Fig. 2 , articulating: (i) a minimalistic bootloader, (ii) two firmware image slots in flash memory, each prefixed with space for their respective metadata, and (iii) a basic firmware update module, also implemented on top of RIOT, integrated into each firmware image, as detailed below.
Firmware update module. The firmware update module's main tasks are to retrieve the firmware image and manifest from the update server, to parse and verify the manifests, and to store the firmware image on flash memory. The module implements the required buffering between the network packet size and the device flash page size. When a flash page buffer is full, the module writes the buffer to the next flash page in the (non-active) firmware image slot. After the entire firmware image has been written to flash, the module computes a hash and checks that this hash is identical to the hash announced in the transferred firmware's metadata. The received metadata is cryptographically verified with the help of the trust anchor (the public key stored on the device). If the digital signature is verified, and if other security checks pass (for example, the firmware sequence number is confirmed to be newer), the module also writes the metadata to the flash (otherwise, the metadata is blanked) and launches a reboot.
Therefore, this Basic-OTA configuration requires that the IoT device and the update server can communicate directly over the MAC layer (in other words, they have to be on the same local network/bus). The Basic-OTA configuration uses minimalistic firmware metadata (in a proprietary format), namely: A sequence number. The firmware start address and size. A digest of the firmware image. A digital signature of the metadata. IPv6-OTA. This configuration enables the Basic-OTA configuration by using an IPv6-compliant network stack. The IPv6 network layer implementation is provided by the RIOT Generic (GNRC) network stack. CoAP blockwise transfer (block1) is used because UDP limits the size of the firmware image to be transferred to 65,507 bytes and, more importantly, we want to avoid the inefficiency caused by IP fragmentation.
CRYPTOGRAPHIC LIBRARIES Our prototype makes use of cryptographic primitives for verifying digital signatures. Thus, a crucial parameter is the choice of a signature algorithm, and its implementation. In the context of this paper, we considered algorithms that provide a cryptographic strength of roughly 128-bit. Concretely, we considered mainly signatures based on ed25519 and signatures based on the NIST P256r1 curve. Based on the choice of algorithms, a particular implementation must then be chosen. We briefly survey a number of relevant libraries, many of which are highly configurable, and evaluate them in Section 7. 2. subsubsectionLibraries that provide ed25519 signatures HACL*  [66]  is a cryptographic library that is written in the F* programming language and is compiled to C. The goal of HACL* is to have a verified cryptographic library.
In this paper, we evaluate the version from the HACL-C repository  [29]  (commit d65ee4). TweetNaCl  [17]  is a small portable and auditable C library implementing all 25 functions of NaCl. It is simple to use and does not offer configurable options. It provides one combination of cryptographic primitives selected for high security. In this paper, we evaluate version TweetNaCl-2014-04-27. μNaCl  [25]  is a patch on top of TweetNaCl. μNaCl provides assembly code optimized for some microcontroller architectures, and aims to significantly speed up the x25519 key exchange. In this paper, we evaluate version μNaCl-2015-08-13. C25519  [6]  is a library that implements ed25519 for embedded implementations. The memory consumption and code size of C25519 is small. In this paper, we evaluate C25519-2017-10-05.
Monocypher  [62]  is a small auditable library implementing the ed25519 signature scheme among other cryptographic primitives. It aims to keep the code base small while not sacrificing too much speed. In this paper, we evaluate version Monocypher-2. 0. 5. WolfSSL  [9]  is an embedded TLS/DTLS library. The wolfCrypt module is used here to measure raw crypto performance. In this paper, we evaluate a version of WolfSSL adapted for integration in the RIOT operating system (based on commit 412eecd).
Libraries that provide P256r1 signatures. TinyCrypt  [8]  is a cryptographic library that provides signatures based on the NIST P256r1 curve  [41]. The design goals of Tiny-Crypt are to minimize the code size and cryptographic dependencies. In this paper, we evaluate version TinyCrypt-0. 2. 8. Mbed TLS  [13]  is an embedded TLS/DTLS library. In this paper, we evaluate version mbedTLS-2. 12. 0. Note: Although WolfSSL and Mbed TLS are TLS/DTLS stacks, we only use the implementations of the cryptographic algorithms in the prototype; not in the TLS/DTLS protocol itself.
Other digital signature libraries. There are also alternative digital signature schemes that provide the same (128-bit) level of security. For instance, recent work on hyperelliptic curves includes qDSA  [53] , a signature scheme that yields fast signatures and verifications for constrained IoT devices. An implementation of qDSA is available as a RIOT package  [52] , which provides a reference C implementation and assembly code optimizations for both AVR and Arm Cortex M0 microcontrollers. Other work is based on variants with the Gimli permutation  [18]. For instance, libhydrogen  [7]  implements such a signature scheme and enables fast, small cryptographic signatures.
In the following measurements, the code is compiled using GCC 7. 2. 0 for Arm optimized for code size. To retain generality, we focus only on the software necessary to enable secure firmware updates over the network, i. e. we ignore application-specific code and memory such as the driver for the LCD screen shown in Fig. 5. Metrics. To evaluate cost in our comparative evaluation, we use both (i) memory measurements (RAM and flash size) and (ii) CPU performance measurements. These metrics are decisive in terms of hardware costs and in terms of energy costs  [24]. On the one hand, a slower CPU speed and larger RAM size increase energy consumption. On the other hand, a faster CPU with more RAM and flash memory typically increases the price of the MCU 5. In practice, memory sizes available for off-the-shelf microcontrollers are typically of size 2 n (for example, 32 kB RAM and 256 kB flash, or 16 kB RAM and 128 kB flash).
The Cost of OTA. The cost of basic OTA functionality can be measured by comparing the memory requirements of the Baseline configuration with that of the IPv6-OTA configuration. On a per-image basis, the flash overhead comes from the need for additional modules to perform necessary crypto (5 kB) and to handle OTA (2 kB). However, the prototype needs two image slots with metadata and a bootloader. We are, therefore, comparing the Baseline flash footprint against twice the flash footprint of IPv6-OTA added with the bootloader footprint (see Table  4 ). In total, the relative overhead in flash memory footprint is 137% (59 kB more). Note that this overhead means that the flash memory budget crosses over from below 64 kB to below 128 kB. The largest part of the overhead comes from the doubled image slots.
The Cost of Standard-Compliance for OTA. The use of standards-compliant specifications, such as 6LoWPAN, SUIT, and LwM2M, increases the memory footprint due to the extra functionality provided; for example, serialization, metadata processing, and object handling. This is expected. However, we observe that the relative overhead per image, compared to the Baseline scenario, is small. This is because a lot of features are reused in the network module. Furthermore, it is not unlikely that, OTA functionality aside, application code already leverages CBOR, COSE, and other crypto functionality. In such cases, the extra memory overhead per image falls to approximately 10%. This type of software reuse is a clear advantage of using standard building blocks. Compared to the 124 bytes of metadata transferred over the network with the Basic-OTA configuration, 226 bytes of metadata need to be transferred with the SUIT-OTA configuration (counting full COSE data).
Even faster on Cortex M0+, qDSA outperforms all other libraries by an order of magnitude or more. The implementation is optimized with assembly code for use on a Cortex M0+ and for 8-bit AVR but not yet for Cortex M3/M4 where it uses a slower C implementation. This explains why qDSA is slower on Cortex M3/M4. While the qDSA implementation takes a relatively large amount of flash space, a closer look shows that at least 8 kB are required for a SHA-3 digest algorithm, which is required by qDSA. This cost could be amortized when other parts of the system also use the SHA-3 algorithm. The Gimli-permutation-based Libhydrogen performs very well in both size and speed on all platforms. While it is not the fastest crypto library, the flash usage and stack requirements are the lowest among the tested libraries.
Our experiments show that ABATIS can improve traffic fluidity by increasing travel speeds in the range from 16 to 35 km/h, thereby reducing travel times by 8% on average. As an additional advantage, ABATIS works with real maps, meaning that it can directly act as route server for real vehicles without requiring further changes to the software itself. The rest of this paper is organized as follows: Section 2 presents some related works addressing traffic flow improvements using different techniques. Section 3 provides information about the SUMO and DFROUTER tools, along with the iterative heuristic used to mimic real traffic traces, and it also includes details about the route server used. Section 4 describes the methodology used to improve traffic flow using an interface that establishes a communication link between the two simulators and the route server.
Overview of the Simulation Tools Adopted In this section, we provide some details about the mobility simulator used, called SUMO. Then, we will introduce the DFROUTER tool, together with our proposed iterative heuristic to generate the O-D matrix based on induction loop data; such data were retrieved from real traffic traces during the rush hour for a working day in Valencia (8 to 9 a. m. ). Lastly, we will describe the functionality of our route server (ABATIS).
The ABATIS Route Server Presently, vehicular route servers basically rely on static information locally stored, and based on which new routes are calculated. There are several similar systems, including both commercial (TomTom) and free solutions (Google Maps Navigator). The first deficiency of those systems is that they combine historical data with data sent by drivers' smartphones, portable browsers, collaborative social networks, or any reporting application, meaning that users must constantly send reports about where they are, and how long it takes to get from one place to another. Such approaches are not effective if the users do not share this information to protect their privacy, or due to regulatory conditions such as the General Data Protection Regulation (GDPR). Besides, the second deficiency is that both Google Maps and TomTom perform only short-term predictions based on past and current status, but do not act as centralized controllers for all the traffic in a city.
To address this incompatibility, it is necessary to create a translator function that converts the geographical coordinates into codes that are compatible with both the network and the traffic simulator, as well as the inverse conversion to support bidirectional communications. To improve the speed of processing and search in the conversion of geographic coordinates from one format to the other, we store the information relevant to all nodes, such as their ID code and geographic coordinates. Also, we store the "edges", which are representations of streets or roads in the context of SUMO. These edges contain the identification code of the corresponding nodes, edge type information, the edge length, the vehicular speed associated with that edge, and the different street segments that have been unified, as presented in a previous work  [7].