dataesr/scientific-paragraphs-categorization huggingface dataset:
DATABASE The database is directly associated with the Django Website. Django CMS integrates a relational database management system named SQLite3, which is adequate for the tele-rehabilitation platform. The database is divided into three parts according to the kind of stored information: (i) personal data; (ii) questionnaire data; and (iii) exercise data. The personal table stores different information about the users, such as: name, email, age, occupation, address… The questionnaire table stores all the qualitative responses provided by the patients and enables the health professionals to follow the evolution of the patient's medical condition. The physical exercise data modeling is more complex. It involves a relationship between five tables. The Main Table synthetizes the data about the exercises completed by the patient: date; kind of exercise; rehabilitation stage; completion time; and outcome.
During the execution of an exercise, fractions of the entire movement are assessed in real-time, in order to evaluate the correctness of the performed movement. Then, a single outcome (perfect, good, or bad) is produced based on the sum of these individual assessments (see next section for more details on the assessment module). The Demo Table is linked to the Main Table through a 1:N relationship, and stores details about each exercise and a demonstration video of the movement that must be performed. The Coordinate Tables are also linked to the Main Table by a 1:N relationship, and store an information regarding the movement performed during an exercise such as the 3D joint coordinates captured by the Kinect. These data can be used to display a replay of the movement carried out by the patients, in order to provide the physiotherapist with a more ecologic visualization of the actual patient's performance.
Finally, the current version of the platform seems to present a quite high usability, since it got a SUS score of 81 out of 100. Nevertheless, some aspects of the design of the user interface must be improved such as the size of certain icons and the interaction with the Web application through the Kinect. Next steps will consist of: (i) adding further functionalities; (ii) performing advanced recording with the Kinect; and (iii) assessing the effect of the use of the platform on the quality and velocity of the recovery process. Gameiro, J. , Cardoso, T. ,  & Rybarczyk, Y. (2014). Kinect-Sign: teaching sign language to listeners through a game. Innovative and Creative Development in Multimodal Interaction Systems. Heidelberg: Springer, pp. 141-159. Heiberg, K. , & Figved, W. (2016). Physical functioning and prediction of physical activity after.
INTRODUCTION Everyday Web applications must dynamically handle various types of contents generated by users or client sensors. Semantic technologies could improve these applications, but are currently under-exploited. One reason is that full-fledged semantic stacks are perceived as costly, unreliable server-sided architectures, in opposition with current (i. e. modular and client-side) Web design practices  [19]. We have addressed this problem in  [18] , by proposing HyLAR, a reasoner that can be both used on the server and client sides. Our goal is to allow using reasoning for tasks currently located on Web application clients, that satisfy several conditions. We focus on datasets of relatively small size (< 50k triples) and target Web applications based on stable data models (TBoxes) and more varying model instances (ABoxes).
e. manipulating typed objects -instances -and inheriting their properties from classes). However, this set of rules can be extended: the reasoner similarly processes entailment and business rules, application developers can add entailment rules among business logics ones, without modifying the reasoner package itself. HyLAR also supports consistency checking in both IR and TB algorithms. Entailment rules involving disjointness, complementness or type checking can be provided as built-in rules using the "false" fact as consequence. HyLAR handles this fact as any other and uses TB maintenance approach to efficiently perform rule-based consistency checking. HyLAR runs on both server (Node. js 9 5. 1. 1) and client (Browserify 10  ) sides, which allows its integration into frameworks designed to optimize reasoning process location, such as  [18].
EVALUATION We evaluate our tag-based algorithm by comparing it to Motik et al. 's incremental reasoning (IR) algorithm based on DRed, described in the Delta-Reasoner  [13]. We chose to compare those algorithms on the same implementation rather than comparing them on different applicative solutions: our goal is not to provide the fastest reasoner, but rather to offer an optimal solution for maintaining datasets incrementally in Web browsers using JavaScript. We evaluate these algorithms for ontology classification and initial insertion, insertion of new triples, deletion, insertion of known triples and selection. The three latter represent Web applications cycles as illustrated in Section 2. We run each algorithm in Google Chrome v. 54. 0. 2840. 99, on a Lenovo Ideapad 700-15ISK (Intel Core i5-6300HQ @2.
Datasets and rules We generated 3 datasets (O1, O2 and O3) using the Lehigh University Benchmark (LUBM)  [5]. They are based on the Univ-Bench Ontology 14  schema, which has ℒℰℋℐ+ expressivity and contains 36 SubClassOf, 6 EquivalentClasses, 5 SubObjectPropertyOf, 1 TransitiveObjectProperty, 21 Ob-jectPropertyDomain, 18 ObjectPropertyRange and 4 Dat-aPropertyDomain axioms, as well as 43 Class Assertions, 25 Object Property Assertions and 7 Data Property Assertions  15. O1, O2 and O3 contain respectively 8824, 7394, and 5759 triples, and correspond to the initial insertion. The evaluation uses the same rule sets as in Section 4.
Practical evaluation We ran 5 evaluation tasks: classification and initial dataset insertion (CLASSIF+INIT), insertion, deletion, re-insertion and selection for both IR and TB algorithms  16. Inserted and deleted data have also been generated with LUBM and contain 500 triples. Each task applies the five rule sets described above. Our results are depicted in Figure  2. Processing times for each task are written in milliseconds. This table also shows the time difference betweeen IR and TB (Diff. ), as well as the performance of TB (Perf. ), i. e. the percentage of time gained if using our solution instead of IR, for a particular task. The "10 CYCLES" column sums the results for (i) classification and initial insertion, (ii) insertion, and ten cycles of (iii) deletion and (iv) re-insertion. Such cycles correspond to applicative scenarios such as the one described in Section 2.
Classification and initial insertion. As expected, TB maintenance does not outperform IR for these tasks, as it adds the cost of tagging facts. Although the number of rules and the size of the schema influence these results (e. g. O1 is more costly on TB as it is more expressive), RL profile reasoners do not target large classification tasks (an OWL-EL reasoner would probably be more suitable). Moreover, in Web applications, the classification and initial dataset insertion usually involve shared data and their results can therefore be computed on a server and cached for all clients. As tagging time is related to the number of triggered rules and their possible recursivity, its overhead is reduced for already closed datasets. First insertion. Again, it takes longer for TB maintenance to perform a first insertion due to the additional tagging step.
Selection. Selections in IR are straightforward and give stable processing times. They are slower on TB maintenance as our algorithm checks the validity of each fact returned by the KB. With respect to IR, TB maintenance could then significantly impact SELECT queries with high numbers of triples or highly interrelated datasets. However, SELECT operations are much faster than the previous ones. Hence, despite its important value in percentage, this overhead sounds acceptable in terms of absolute times (about twenty milliseconds), as it only corresponds to a couple of frame rates of the most performant Web applications. Multiple cycles. Here, we can see all the interest of our approach: the initial tagging cost at classification and first insertion is re-gained along deletions/re-insertion cycles.
Our underlying hypothesis is that our reasoner targets Web applications that can run on small devices such as smartphones. It is not intended for storing application history but to receive facts that will trigger rules at the application level. In our scenario, the phone GPS coordinates are raw numeric values. They are not inserted "as is" in the reasoner but are transformed into facts that fit the application requirements (the phone is located in the house neighborhood). In these conditions, client-side reasoning can save both Web application developers' time while constructing their datasets (by using regular Semantic Web modeling tools), and bandwidth (by leaving saturation and decision processes up to the clients). Using a known set of explicit tags, TB reasoning allows application designers to first-insert and delete these facts at bootstrap or asynchronously, to pre-compute the tagging step and ensure performance at runtime.
Yet, the HyLAR Reasoner is a JavaScript solution that targets Web browsers, which is currently not possible with RDFox. Hence, we did not compare those two reasoners. Nor did we compare BF with TB because the complex data structures used in BF (several rules bodies that would be duplicated into annotated queries) are not efficient in JavaScript (they actually perfom worse than regular IR). The Constraint Handling Rules  [3]  language also allows efficient rule-based reasoning and has been implemented in JavaScript. Unfortunately, it is not able to keep track of inferences, which prevents our fact-tagging approach to be used on this reasoner.
Evaluation results show that the cost of TB maintenance is slightly higher for first insertions and for selections, but outperforms an implementation of IR at deletion and reinsertion. This cost is also re-gained within a few cycles. In order to stimulate the adoption of semantic technologies in the Web community, it is implemented in the HyLAR reasoner, that proposes both IR and TB algorithms and is available as server-side (Node. js) or client-side (Bower) packages. HyLAR ships with a basic set of entailment rules that can be extended or reduced according to applications needs, and can be integrated with other tools, such as popular JavaScript frameworks, as well as our reasoning location adaptation framework  [18]. As future work, we will extend the set of built-in OWL rules and stream reasoning capabilities to deal with larger datasets, and explore pattern mining techniques to discretize frequent sets of causes to reduce the KB size.
Conclusions In this article, we focused on the basics of survival analysis and Cox regression, which are routinely used in thoracic surgery research. We insisted on the Cox model assumptions checks, which is a crucial part of Cox analysis and shouldn't be neglected. We didn't address however the advanced methods of Cox regression. We can cite here the handling of timedependent covariates  (8) , which may be encountered in thoracic surgery research. A covariate is considered as timedependent or time-varying when its values change over time of follow-up. Several methods allow incorporating these variables in a Cox model, including counting process. In these methods, a dataset including multiple rows for each subject is used, with each row corresponding to an interval of time where the time-dependent variable remains constant.
In the past few years, the number of wireless devices connected to the Internet has increased to a number that could reach billions in the next few years. While cloud computing is being seen as the solution to process this data, security challenges could not be addressed solely with this technology. Security problems will continue to increase with such a model, especially for private and sensitive data such as personal data and medical data collected with more and more smarter connected devices constituting the so called Internet of Things. As a consequence, there is an urgent need for a fully decentralized peer-to-peer and secure technology solution to overcome these problems. The blockchain technology is a promising just-in-time solution that brings the required properties to the field. However, there are still challenges to address before using it in the context of IoT.
Introduction IoT is taking over the world; it is estimated that the number of devices connected to the Internet forming the Internet of Things will reach 50 billion by 2020  [1]. One critical application is the eHealth smart homes. In fact, this technology allows monitoring elderly or individuals with diseases and automatically sending the data to a remote server for processing by doctors. This data is recorded in the so-called EMR (Electronic Medical Record). Secure access to this EMR is problematic considering privacy issues, transparency, etc. This is why in order to develop secure and reliable solutions for eHealth smart homes, it requires unprecedented coordination and collaboration between all pieces of the system. All devices must work together and be integrated with all other devices, and all devices must communicate and interact seamlessly with remote systems and infrastructures in a secure way.
Each block references the hash of the block that came before it. This establishes a link between the blocks, thus creating a chain of blocks or blockchain. Any node with access to this ordered, back-linked list of blocks can read it and figure out what is the world state of the data that is being exchanged on the network. To understand how blockchain works, we will first explain how a blockchain network works. This is a set of nodes that operate and interact on the same network using the replicated blockchain copy each node holds. One node might be used as an entry point for multiple users or devices, but let first assume that each node transacts on the network by itself only. First of all, the interaction between users nodes and the blockchain is done via a pair of private and public keys.
The transactions are signed using the private keys, and then addressed by other nodes using the corresponding public keys  [7]. The use of asymmetric cryptography is very important in terms of providing integrity, nonrepudiation, and authentication to the blockchain network. After a transaction is signed, it is broadcasted by the node to all other nodes it is connected to. The nodes, or peers, need to ensure that the transaction is valid, thus they need to trigger a validation process called "mining". A transaction in the blockchain can be defined as any transfer of data that has a value (Bitcoin, IoT data, etc. ). After a transaction is validated via the mining process, it is then added to the blockchain as a new block of transaction and data. Since the blockchain is transparent, these transactions are available for all nodes connected to the network.
Related Works in the Integration of IoT, Blockchain, and eHealth. After an exhaustive investigation of this field, we found out that blockchain is a great candidate for future decentralized IoT architectures and models. For example, authors in  [1]  have defined a complete IoT architecture composed of three layers, where blockchain is used as the storage layer. The authors also defined a data management and a data sharing protocol, along with a study on different mechanisms and their impacts on the system i. e. direct blockchain access, server client access, and publisher/subscriber access. Based on this study, we found that the publisher/subscriber mechanism is very important and the most flexible mechanism. Therefore, we decided to adopt it in our solution. Blockchain technology is also considered in several ehealthcare solution.
In addition, we propose to use in our solution smart contracts to maintain rules, authentication, and communication between the different nodes and parties of our system. Finally, since the transaction of messages with large amount of data highly negatively impact the performance of the blockchain, we propose to use an offchain database to store the data, in our case we have used IPFS  [21]  as peer to peer storage system. The Figure  1  presents a high level diagram of the proposed architecture identifying the different actors, the blockchain and the IoT devices. In the next sections, we will first present the considered scenario then the details of the proposed architecture in terms of components and their interactions.
, authorized doctors) and that it is not altered for any malicious reason by a third party ? The direction that has been followed to solve this problem is actually to protect the location where the collected data is stored. To acheive this objective, we will highlight how the components of our blockchain IoT architecture (blockchain, smart contracts, intermediate servers, and offchain database) could be efficiently glued together for this purpose. The main actors of this scenario are the publishers of data and the subscribers to these data while the endproviders and consumers are the IoT devices and the endusers (data generators and data consumers). Figure  2  presents our solution to be deployed in the smart home that is derived from the more general architecture presented in Figure  1. The main idea of the solution is highlighted in Figure  2  that is to overcome the limitation of connected objects in a smart home not able to directly connect to the blockchain due to their limited processing capacity and energy power.
The Client Contract. The third contract is the client contract. It serves as a mapping contract between normal nodes, or clients connected to the blockchain, and their respective subscriber contracts. It contains the client name, so that it would be simpler for clients to communicate between each other using a frontend application. This name is mapped to the corresponding address in the blockchain. ← (   ) 5:  ← V() 6: if ( = True) then 7:  ← () 8:   ← (ℎ) 9: for (  ∈ (  )) do 10: ℎ. (  ,   ) 11: end for 12: end if 13: end while 14: end function Algorithm 1 (xv) ℎ(  ): function to retrieve data corresponding to hash   After describing the contracts, we specify in this section the behavior of the publisher node after receiving new data generated from the connected IoT devices. The steps that should occur are the following (1) store the data in the offchain database (IPFS in our case), (2) generate the hash pointing to the location in the database, then (3) send that hash to every node on the blockchain that is subscribed to this publisher.
In the subscriber node, the Graphical User Interface (GUI) is the entry point for the end-user. The Ethereum client connects the node to the blockchain and the local database stores the received data (it works as a cache to reduce response time of future accesses). It is also worthy to mention that one important step of the process is not actually visible in the Figure  4  that is the mining. Indeed, for each transaction taking place, the nodes on the blockchain (miners) shall validate the transaction as previousely explained. This increases the time to deliver a message from a publisher to a subscriber and it has also an important impact on the performance of the overall system in terms of response time. Figure  5  shows the sequence diagram of the proposed protocol that depicts the exchanged messages between the different components of the architecture.
HashPointer The main data type transferred between publishers and subscribers, using the Notify function, can be of type base58. data. Unfortunately, this is not always possible. First, it is not always possible to control the CPU computing capacity since it comes with the device hardware and moreover it is not always possible to control the rate and the size of data transmitted by sensors (this also depends on the application logic). For example, monitoring in real time the ECG of an individual can be critical. For that, doctors must be able to interpret the received ECG data. In this case, heart measurements should be sampled and sent at high rate. This is not true for all types of physiological signals. For instance, it is not critical to measure body temperature at high frequency. Thus, changing the sampling rate of the ECG signal without a careful validation from doctors may not be good for an accurate interpretation of the data.
Therefore, we consider in this work the mining time as the main performance metric to evaluate the performance of our proposed system: Let   be the number of devices connected to a publisher. Let   be the rate of IoT device data generation, and consequently the associated rate of generation of new blocks in the blockchain. The total data rate generated by one publisher that has   associated IoT devices, assuming that all the devices have the same data rate   is equal to   ×  sample of data per second. Each new data will generate a new transaction which in turn will trigger the mining of a new block in the blockchain. In this case, the mining rate will depend on the block size   and the time to mine the generated block. The block size depends itself on the number of transactions one block can fit; it varies indeed from one blockchain platform to another.
As previously indicated, Bitcoin uses a fixed size for its block while Ethereum uses a variable size. In this context, the mining rate will correspond to the fraction   /  bps. There are two possible cases; the first one is when the generated data rate from the publisher is lower than the mining rate and the second case is when it is higher. The maximum delay time for each case is formulated is the following: Case 1: Max Delay =   if   ×   ≤   /  Case 2: Max Delay =   ×   where   is the number of necessary blocks to accommodate all transactions if   ×   ≥   /. can be calculated supposing t=1s   = (  ×   )/. In the same way this can be generalized to all the generated data from all publishers. We obtain the following formulation: 𝑁 𝑃 ∑ 𝑛=1 𝑁 𝑃 𝑑 𝑖 × 𝑟 𝑃 𝑑 𝑖 ≥ 𝑁 𝑡 𝑇 𝑏 (1) In this formulation, we did not take into account the work and time taken by the subscriber and the publisher for their own operations.
Implementation of the Solution To implement our solution, we have chosen to use a framework called Embark  [24]. This framework is based on the concept of decentralized applications (DApps) and was fitting our technical requirements. Embark framework implements the Ethereum blockchain, IPFS database, and Whisper protocol used to send messages between multiple DApps. We have chosen to use the GoEthereum (geth) client, along with SolidityC  [25]  language for smart contracts programming. HTML, Javascript and JQuery langages have been used to program the frontend and the GUI. We have successfully implemented our private blockchain as well as the notification smart contracts. We have considered two types of nodes, a laptop and a Raspberry Pi. We have successfully connected both of gateways to the blockchain.
For that, an advertising protocol is used (it is a core function in the proposed pub-submodel). The sensor is modeled in the publisher contract as a record of two variables, the sensor ID and the sensor type. Once the publisher and its sensors are registered to the blockchain, any subscriber connecting to the blockchain can discover the publisher and it sensors. In the general case, when a particular subscriber registers to the system, it is possible for it to discover all the available publishers via this particular subscriber as well as their provided sensing capabilities. It is then possible for a subscriber to subscribe to any of these publishers if it is authorized. If successfull, the address of the subscriber is added to the publisher's contract. Once new data is generated from any of the sensors associated with a publisher, the gateway stores it in the IPFS storage and sends a broadcast message to the blockchain containing a hash pointing to the location where the data is stored.