dataesr/scientific-paragraphs-categorization huggingface dataset:
Given the peculiarity of this approach, it can only be performed with BabelNet, a specially designed KB built by automatically linking various lexical databases with Wikipedia. Indeed, fusing different sources of information can greatly improve the richness of the graph, as well as the performance of the algorithm. A way to generalise this approach, at least for NEL, is to exploit equivalence links in the KB, pointing to other sources of information. In the next section, we shall see how our algorithm uses multiple LD sets as KB, by iteratively accessing and crawling the different LD sets available thanks to equivalence predicates (e. g. , sameAs) and by applying the appropriate fusion strategies. Evaluation of NEL should be carried out by analysing the performance of NEL algorithms independently from the NERC phase, which isn't always the case in literature.
NEL: Domain Adaptation for the Digital Humanities While the aforementioned approaches have been mainly developed and evaluated on news texts and web documents, there has not been -to the best of our knowledge -much research on NEL domain adaptation for the humanities and the literary domain in particular. [25]  is one of the first works to highlight the importance of NEL for humanities, with a focus on toponyms. It also contains interesting reflections on the problem of temporal information, and how important it is to exclude some candidates (the correct referent must be a place that exists at the time in question); we shall later see how REDEN also exploits this intuition. Other papers concern the adaptation of Wikification approaches to the domain of cultural heritage, not limiting themselves to the enrichment of texts but also of digital metadata records associated to cultural artifacts.
[26]  adapts a known algorithm (WikiMiner), using Wikipedia to select correct links. Domain adaptation is performed via category pre-selection (culture, arts, humanities). [27]  and  [28]  follow a similar approach. Keeping in mind the aforementioned approaches and the limitations for their use in the DH, we have developed a graph-based NEL approach which is well-suited to handle the semantic annotation of digital literary editions and more broadly other domains in the DH. The algorithm is described in the next section along with our motivations and the user requirements. sources. Finally, they noticed that some candidates could be excluded a priori, since they were not even born at the time when the essay in question was written. To recapitulate, the algorithm must fulfill the user requirements by being: • TEI compliant • LD based, it should access any user selected KBs (domain specific but also generalistic ones) and should also be available via an Sparql end point so as to be always linking to latest versions • independent from NERC and, thus, able to deal with already tagged texts and be used with different NERC tools along with distinct manually corrected data • adaptable to a user-defined domain scope • able to deal with one class or sub class of NEs at a time We, thus, decided that an adapted NEL algorithm should fulfill such requirements, firstly being TEI compliant.
Indeed, REDEN adheres to currently recommended TEI formalism for the annotation of places and people in texts. At the same time, we are aware of current proposals for more complex annotation schemes within the TEI community, see, for instance, the GEOLAT project  [31] , where the relationships between entities are made explicit in text, while at the same time creating more adequate and domain specific data sets. As mentioned beforehand, another requirement is that REDEN should be able to support potentially any LD set with a SPARQL endpoint, capable of gathering and fusing further information from new LD sets when equivalence links are present, and with a customisable index building facility that allows for an ad hoc creation of aliases and for the definition of specific time and space constraints.
g. , BnF). The constitution of the index along with the strategies to search for candidates within it represents the first phase of NEL, that is, candidate retrieval. An excerpt of the resulting candidates for the six NE mentions (along with the number of candidates) from the example is shown below  12. Per mention, REDEN subsequently retrieves the RDF graphs of the resources corresponding to the candidate URIs from the reference LD set (e. g. , BnF). At the same time, REDEN uses existing equivalence links (e. g. , sameAs) in order to retrieve also the RDF graphs of their homologous resources described in other LD sets (e. g. , DBpedia, Wikidata, and any other available ones). Afterwards, graphs are combined into a single enriched graph by fusing the assertions of homologous resources. In other words, assertions about Jules Laforgue in the BnF data set and those from the same entity in the DBpedia data set are fused into one resource.
Another necessary condition for proper retrieval is the existence of interlinking to other LD sets; for what concerns our choice: BnF links to DBpedia, thus, making it very easy to further retrieve and combine more information in one knowledge graph. Besides DBpedia, bibliographic datasets like BnF also strongly rely on domain specific standards such as idref, viaf, or ISNI for interlinking. Sometimes interlinking may follow different strategies, so, for instance, sources such as DBpedia and Yago usually make use of sameAs relationships; but other LD sets like BnF use other relations with the same semantics, such as skos:exactMatch. Moreover, either the reference LD set or at least one of the interlinked ones must exhaustively describe entities in terms of relations with other entities and of alternative labeling properties (e.
In its current implementation, the REDEN algorithm will always choose a link when a non empty candidate set is returned  19. Ideally, thus, the candidate retrieval phase should always return the correct candidate (among other possibilities) and possibly an empty set when no link exists in the KB. This of course is not always the case, due to homonyms and missing aliases. For this reason, it is interesting to evaluate Phase One in isolation, to see whether errors are due to wrong candidate selections, and to assess whether the graph based algorithm makes the correct choice when given the chance. The number of candidates per mention clearly is also an important measure, though not directly an evaluation measure, since it shows what level of ambiguity exists in the dataset. We, thus, calculate a further indicator: -CANDIDATE CARDINALITY MEAN the average number of candidates per mention.
Conclusions and Future Work We presented an algorithm to perform NE disambiguation by referencing author mentions to broad-coverage and domain-specific Linked Data sets, DBpedia and BnF, respectively. We set up a procedure that extracts RDF data of person resources described in these LD sets. This procedure can be generalised to other classes of NE (e. g. , places) only by modifying the corresponding SPARQL query. Furthermore, REDEN crawls RDF graphs from homologous resources described in other LD sets using equivalence links, and our fusion procedure enables for the constitution of a non-redundant graph which is well-suited for centrality calculation during the candidate selection phase. It is noteworthy to mention that REDEN is not completely language dependent; more specifically, the candidate selection phase is language-independent and the index constitution part during the candidate retrieval phase needs only the specification of the appropriate Sparql query to build an index in the desired language.
The work presented in this paper is an important step toward a better understanding of a compact hydraulic robotic actuator, based on the Integrated Electro-Hydraulic Actuator (IEHA) developed by Alfayad and Ouezdou  [1]. The novel advantage of this actuator is being highly compact and autonomous (no need for central hydraulic source), while keeping a good power to weight ratio. In order to present and develop the working dynamics of this actuator, a highly detailed mathematical model for the system is presented. The proposed model is simulated using MATLAB-Simulink software to identify the effect of the internal system parameters on system dynamics and prepare an input-output test-bed model. Such test-bed model is used to obtain the transfer function of the system and its order. Analysis of the effects of the main parameters was carried out and a lower order of the system was identified.
A combination of virtual modeling and mathematical analysis has been used to identify the linear model of the system. Based on the fundamental hydraulic and dynamic equations of the system, a virtual model has been developed. This model is used to provide a test bench for identifying the order of the system. Meanwhile, an analytical study of the equations is carried out to define an enhanced input-output relation of the system. Finally, a system identification technique is used to validate the linearized model. This paper is organized as follows; section 4 briefly describes the architecture of the IEHA electro-hydraulic actuator, IEHA. Section 5 introduces the fundamental hydraulic and mechanical equations used in the development of the virtual model of the actuator. In Section 6, the virtual model of the system under MATLAB-Simulink is developed and the influence of the internal parameters is studied.
IEHA Virtual Model Compactness of IEHA makes it difficult to measure the internal variables of the system, such as the micro pump eccentricity and internal pressure drop. Moreover, it is important to study the effect of configuring the internal variables (e. g. the dimensions of different mechanical parts) on the behavior of the system before modifying the system design in future prototypes. Therefore, development of a virtual model of the IEHA provides deeper understanding of the system and can be considered as an efficient platform for further system optimization. The effectiveness of the developed virtual model allows a quick and accurate evaluation of the internal parameters early in the design and development stage. For this purpose, MATLAB-Simulink was used to model all the dynamic equations of the IEHA actuator, as well as fluid properties such as bulk modulus and internal leakage as shown in Appendix I.
Identification of the Linear System MATLAB system identification toolbox has been used to estimate a linear transfer function that best describes the behavior of the system. This toolbox estimates model parameters using iterative prediction-error minimization method (PEM). PEM is an iterative estimation command, using non-linear least squares algorithm to minimize the cost function. The system input-output linear function has been identified with variable load (can also be interpreted as being in contact with the environment). Unlike simple micro-valves, dynamics of IEHA depends on the load (this is also the property that makes it back-drivable). Increase in the external force, causes increase of the cylinder pressure, which will increase the pressure in the micro-pistons. Consequently, the oil pressure on the carriage goes up and this can displace the carriage, (i.
Overview of the contents of the next sections The DAQ system and the HLT (High Level Trigger), consisting of the L2 trigger and the Event Filter, form the ATLAS DAQ/HLT system, the TDAQ (Trigger and Data AcQuisition) system includes also the L1 trigger. In the next sections the internal organization and the deployment of the DAQ/HLT system are described. An overview of the L1 trigger can be found in ref. [3] , for more details see refs. [4, [21] [22] [23] [24] [25] [26] [27] [28]. Section 2 focuses on hardware and software aspects of the systems. Section 3 contains an overview of results of performance tests and of observations from data taking, while in section 4 design and technology choices are discussed. In section 5 conclusions and an outlook are presented. Appendices contain details on hardware items, a short list of definitions and a list of acronyms.
Control, configuration and monitoring All applications are configured and controlled by a common software framework via a separate control network, which is also used for monitoring purposes. The sequence of steps to start a run is governed by a common state machine that is implemented in all controlled applications  (2. 11). For normal data taking the structure of the system and the settings of all necessary parameters are specified in a set of XML files, which combined form the configuration database  (2. 11. 3)   [30]. The configuration specified is referred to as the "ATLAS partition" and consists of a set of "partitions", which correspond to one or more TTC partitions. A partition contains one or more "segments": independently configurable and controllable parts of the TDAQ system. For testing or calibration individual partitions can be used independently of the rest of the TDAQ system.
Dedicated test setups can be described in the same way as the TDAQ system, the configuration of such a test setup is also referred to as a "partition". In addition to system configuration data trigger configuration data and so-called conditions data are used by several HLT components such as the selection algorithms  (2. 2. 4). Conditions data describe the status of the detector at any given time and are stored in the conditions database. Each entry in this Oracle database has an interval of validity (IOV). The common monitoring framework (2. 12) permits the retrieval of event data in parallel to the normal data flow at various places in the DAQ system. The Information Service (IS)  (2. 2. 2)  and Online Histogram Service (OHS) (2. 12. 1) provide a common base used by all applications for publishing and retrieving real-time status information such as counters and histograms.
These allow additional flexibility as it is possible to move nodes between the L2 and Event Filter farms by adapting the configuration database  (2. 15. 3). Event processing in the HLT starts with the arrival of RoI information in the RoI Builder  (2. 4. 1). For each event RoI information from the various L1 sources is combined and passed to one of a number L2 supervisor (L2SV) applications  (5 in October 2011) , running on dedicated processing nodes. Each L2SV schedules events on a unique subset of the L2 nodes. 2 The event is assigned to an L2 Processing Unit application (L2PU) running on one of the nodes and a message with the combined RoI information is sent to that node. The number of L2PUs per node is either equal to the number of processing cores or since 2012 equal to the number of hardware threads ("hyper-threads").
12. 1) so that they can be inspected and analyzed while running. The execution of the algorithms in the HLT is driven by the trigger menu. This menu determines both which algorithms are to be executed given the decision from the previous trigger level and the exact sequence to be run. In addition prescale values and thresholds are specified in the menu to decide when a given object passes a cut. The HLT Steering part of the HLT software is responsible for coordinating this. It is scheduled by the Steering Controller (2. 9. 1), a common framework for L2 and EF. Configuration data that is not related to the menu but to the geometry, or alignment and calibration of the detector are accessed through the geometry and conditions databases, respectively. For online runs typically the most up-to-date conditions approved by the sub-detector experts are used.
The detector geometry is loaded at the configuration time of the applications, whereas most of the conditions data are refreshed at the start of each run and there can be multiple runs without reconfiguring the applications. Some conditions data requiring more frequent updates can be reloaded during a run. These include the HLT prescales and the online beam position and size (2. 9. 2). The large number (O(10 4 )) of HLT applications that require simultaneous access to the databases require the use of an intermediate proxy and caching mechanism (2. 2. 4).
Information Service The IS provides generic means for sharing user-defined information between distributed TDAQ applications. It implements a client-server communication model, where information is stored in memory by so called IS servers. Any TDAQ application can act as a client to one or several IS servers by using one of the public interfaces provided by the IS, see figure  7 : • an information provider can publish its own information to an IS server using the Publish interface and inform it about changes in the published information via the Update interface, • an information consumer can either access the information of an IS server on request, using the Get Info interface, or it can receive information updates asynchronously via the Subscribe/Notify interface. In 2005 the scalability and the performance of the IS have been tested in the context of the TDAQ software large scale tests, organized at CERN  [35]  with conditions similar to those of real TDAQ running.
11. 8). The Log Service package  [38]  implements archiving of the messages for offline retrieval. The package -15 -  provides the Logger application, an MRS client that collects and archives all of the ERS messages flowing in the system in an Oracle database. It also includes a set of command line utilities to access and manage the database and the Log Manager, and a GUI application that provides an intuitive and user-friendly interface to the database for browsing the archived ERS messages offline (figure  11 ). Tests have shown that the Log Service can sustain a rate of 4,000 messages per second. This has proven to be sufficient. Even during the frenetic testing and commissioning activity in 2009 with first collisions in the LHC, the peak message rate did not exceed 2,000 messages per second.
Relational database infrastructure Detector geometry information, trigger configurations and conditions data, as well as selected data from data-taking runs, are stored in relational databases  [39]. The main back-end is an Oracle Real -16 -Application Cluster  [40]  hosted in the CERN computer centre. The ATLAS online system uses three nodes to serve its needs. Each node has two quad-core CPUs with 16 GB RAM. The total storage capacity is 5 TB spread over 96 disks. To prevent potential bottlenecks, the online database is not directly accessible from the outside but instead is replicated to the ATLAS Tier-0 database on a continuous basis. Similarly, a gateway exists through which conditions updates can be imported that are queued from the offline side. At the programming level, the relational databases are accessed through a common API called CORAL (COmmon Relational Abstraction Layer)  [41, 42] , an interface jointly developed by three of the LHC experiments and the CERN IT department that allows technology-independent and SQLfree access from C++ and Python.
The CORAL interface frees the application code from any particular database technology. Supported back-ends include direct access to Oracle and MySQL  [43]  servers as well as local access to SQLite  [44]  files. This abstraction layer has greatly facilitated the TDAQ commissioning phase during which MySQL servers were used until the final Oracle cluster was deployed, as well as the day-to-day development in which SQLite files are common. One characteristic challenge of the HLT system is the virtually simultaneous request of (identical) configuration and conditions data from its thousands of processes before the start of a data-taking run. With O(100) MB of data needed by each process, such a load cannot be handled by a single server. To achieve scalability of the configuration and conditions access from the growing number of HLT clients, a dedicated database proxy has been developed for the use-case of the ATLAS HLT that caches the client requests and multiplexes the responses.
This so-called CoralProxy uses a custom, technology-independent protocol that essentially implements the CORAL API over the network. On the other side, a multi-threaded server process, the so-called CoralServer, mediates between the proxies and the database back-end  [45]. A hierarchy of proxies mirrors the segmentation of the hardware: each HLT node is served by a node-level proxy, each HLT rack is served by a rack-level proxy and each of the L2 and EF farms is served by a top-level proxy. Thus the database server sees only a single client, while each HLT client talks to a local database server. This has been demonstrated to achieve full scalability. Another advantage of the CoralServer/CoralProxy infrastructure is that it handles the authentication of the database clients by deferring it to the CoralServer.
An RS-232 connection is also available and can be used for communicating with a simple monitor program (U-Boot  [51] ). By means of a dedicated driver an RS-232 interface is emulated that can be accessed via the PCI interface. The emulated interface allows communication with the monitor program without a physical connection between a suitable serial interface (typically the interface of the PC) and that of the ROBIN. Figure  14  illustrates how the event data are handled by the ROBIN. Event data flow from the ROLs into the buffer memories. For test purposes data can alternatively be generated by data generators or input from FIFOs. The latter can be filled with arbitrary data patterns by the processor. For each event fragment received or generated a Cyclic Redundancy Check (CRC) checksum is formed while the fragment is passed to the buffer memory.
Responses to messages other than request messages are written to the DMA descriptor FIFO and are also transferred under DMA control to the memory of the ROS PC. In the current implementation of the ROBIN software event fragments can only be requested per ROB, therefore three separate requests have to be forwarded to the ROBIN if the three fragments of the same event stored in the three buffer memories have to be transferred to the memory of the ROS PC. Delete requests to the ROBIN have also to be provided individually per ROB, but in one request it is possible to specify up to 100 events to be deleted by providing their L1Ids. The processor handles these requests by writing identifiers of pages to be freed to the Free Page FIFO. The program running on the processor of the ROBIN has been written in C and consists of a loop in which data stored in the Used Page FIFOs and the Message Descriptor FIFO is read and handled, and in which identifiers of free pages are written to the appropriate Free Page FIFOs.
JINST 11 P06008 values of the "environment variables" as well as the software for the PowerPC processor are stored in the FLASH memory there is no need to boot the ROBINs from the ROS PC after powering it up. The ReadoutApplication, the program running on the ROS PC for handling requests for event fragments and forwarding the data requested, can also send configuration information to the ROBIN on the basis of information specified in the configuration database. The ROBIN software keeps track of e. g. the number of event fragments received, the number of requests received for which the fragment requested could be provided and the number of requests for which this was not possible, etc. This information, together with the version numbers of the software and of the firmware and configuration information, is passed upon request to the ROS PC.