dataesr/scientific-paragraphs-categorization huggingface dataset:
In the Whitehall II Study a sleep log was used to distinguish nocturnal sleep from bouts of sustained inactivity during the day, which could be related to physical inactivity or day time naps. Sustained inactivity bouts were considered to be nocturnal sleep if they overlapped with a sleep window defined by the sleep log. The following variables were derived: sleep onset time, defined as the start of the first nocturnal sustained inactivity bout; waking time, defined as the end of the last nocturnal sustained inactivity bout; time in bed, defined here as the difference in time between the sleep onset and waking time; and total sleep duration, the sum of all nocturnal sleep bouts. Participants who did not have data for at least one weekday and one weekend day were excluded from all analysis that relied on weekly averages of sleep estimates.
Average weekly accelerometer assessed sleep parameters were derived as [(average value for weekdays × 5 + average value for weekend days × 2) / 7]. In the polysomnography study the window of sleep classification was not determined by sleep log, but by the more reliable polysomnography recording of total sleep period, which is defined from lights out till waking up. Processing of sleep log. The (visual) screening of accelerometer (actigraphy) data and sleep log data can be cumbersome in large datasets and it complicates replication  [22]. Therefore, it is important to automate the method as much as possible in order to allow replication and validation of findings  [22, 23]. A one dimensional graph showing the overlap between sleep log entries and accelerometer detected sustained inactivity bouts was generated for all nights where the sleep onset time and/or waking time deviated by more than four hours from the nearest accelerometer detected sustained inactivity bout.
Results Of the 4879 participants to whom the accelerometer was proposed in the Whitehall II Study, 388 did not consent and 210 had contraindications. Of the remaining 4281 participants who wore the accelerometer, 4204 (98. 2%) had valid accelerometer data (a readable data file). Among them, sleep log data were missing for 80 participants and 30 additional participants did not meet criteria for accelerometer wear time (at least one night with >16h of wear time). Therefore, the assessment of discrepancies between the accelerometer and the sleep log was undertaken in 4094 participants (83. 9% of those invited). Owing to missing data in the health survey questionnaire on depression (N = 240) and/or sleep (N = 83), additional 285 cases were excluded for the analysis comparing accelerometer assessed and self-reported sleep duration.
The selection of a 5°angle threshold based on the median value of a moving 5 second window was assumed to capture all static postures and to filter out minor breathing movements and movements of the bed partner. The 5 and 10 minute window of substantial inactivity criterion were assumed to be plausible time intervals after which sleep becomes more likely. Additional parameter configurations were evaluated in the polysomnography study confirming that a 5 and a 10 minute window together with a 5 degree angle threshold provide informative estimates of sleep. Previous findings from the comparison between accelerometer estimates of sleep and a concurrently applied sleep log  [15, 29, 30]  should be interpreted with caution because data from the log was used to time nocturnal sleep initiation and waking time, boosting the agreement between the two methods.
The optimal method configuration to minimize bias in estimated sleep duration depends on the true duration of sleep, which is unknown  [37]. Therefore, a generic configuration for the optimal setting is likely to reflect the data structure of the derivation sample, which may differ from the data structure of the application sample. Our suggestion is to use knowledge (believes) of the effect of sleep on body posture, in terms of parameters such as arm angle and time of sustained inactivity, rather than count data produced by conventional methods for which optimization in particular datasets is the only pathway for interpretation. The lower agreement for time in bed seen in women, depressed participants, those reporting more insomnia symptoms, and on weekend days may be explained by a lower validity of selfreported sleep in these groups or on these days of the week, a lower validity of the accelerometer method, or a combination of the two  [38].
INTRODUCTION The Virtual Brain (TVB; thevirtualbrain. org) is a Python-based neuroinformatics platform for the simulation of realistic largescale networks  (Jirsa et al. , 2010)  of neural population models available for all major operating systems, including Windows, Mac OS, and Linux  (Ritter et al. , 2013; Sanz-Leon et al. , 2013; Roy et al. , 2014; Woodman et al. , 2014). TVB provides a generic framework for computational modeling and tools to extract structural and functional connectomes from multimodal datasets  (Schirner et al. , 2015)  in order to link personalized brain network structure with neural population models. It is an open-source whole-brain simulation platform that integrates empirical data of different modalities and spatial scales to construct comprehensive and biologically plausible models of global brain network dynamics.
Despite the reproduction of several features of empirical neuroimaging data, their biological plausibility is still a matter of ongoing research. Obtained as standalone software, TVB is distributed including all used dependencies, such as the Python interpreter, CherryPy, Genshi, NumPy, and SciPy. Optionally controlled by a convenient graphical user interface (GUI) or a Python programming interface for advanced modeling and postprocessing, TVB appeals to a wide user group. Running in a web browser, 2D and 3D visualizations are implemented with WebGL and scalable vector graphics; data and project management is handled by an SQL database. As a community-driven opensource software, TVB is licensed under GPL 2. 0 and sources may be freely forked from a GitHub repository, modified, and distributed.
Both, GUI and programming interface act as front-ends for TVB. Following a client-server model, both interfaces connect to the Flow Manager that controls those back-end modules and storage components (the GUI via a web-server), enabling multi-user applications on PC or supercomputers. The Web Server generates the HTML interface by receiving data from and passing inputs to the flow-manager. The Flow Manager is in charge of TVB's high-level program control flow and regulates the interaction of all other back-end modules by receiving user actions, feeding back of TVB's responses and all internal processing. The Database, alternatively SQLite or PostgreSQL, organizes project structures by storing references to involved data entities like time series, connectivity matrices, surface triangulations or sensor coordinates.
getItem(key), setItem(key,value), and removeItem(key) within the EduPack Controller edupack_basicController. js. Thereby, information about the currently opened and finished tasks are saved and updated during utilization of TVB-EduPack, such as the combination of the current tutorial, step and sub-step id. This data is needed and used so that users can continue at the point where they last worked with TVB and TVB-EduPack. Furthermore, the values about current progress (key=latestStep, value=stepId) and completed tasks (key=latestTask, value=taskId) are stored and checked by tasks that require certain preconditions to be fulfilled. Upon invocation by burst. js, the TVB-EduPack controller implemented in the script edupack_basicController. js either loads the last used tutorial or the default EduPack startup menu if the localStorage Object does not contain the related preference variable of the activated Helper Elements (keys: helper_description, helper_parameter, helper_misc) or the latest progress (keys: latest_step, latest_task) due to the first use of TVB-EduPack.
Helper Elements Helper Elements are dialogue balloons that appear in the GUI to give the user three types of information about GUI, modeling parameters and miscellaneous TVB features. In addition to the context sensitive Helper Elements implemented in TVB (green buttons with question marks that show information about data types from the TVB-API), Helper Elements provide indepth information in a didactic form. The powerful simulation framework offered by TVB comes at the expense of a complex and, especially in the beginning, potentially overwhelming interface. When the user clicks on a TVB-EduPack Helper element, the main screen of TVB gets darkened and a speech bubble appears that reveals the contextual information (Figures  4, 6 ). Didactic information or instructions come in the form of short video or audio sequences, graphics or text.
, when the user is asked to switch to another interface in TVB. If a <precondition> is not fulfilled, the <sub-step> element is marked as "blocked" and will not open. For this case, the author can specify an error message that pops up in a small overlay. The content of the <precondition> tag defines the error; it can be simple text or images if CDATA tags are used. Within <sub-step> elements graphical overlays can be specified with the <overlay> tag. Overlays are a way to incorporate further audio-visual material like videos or animations that describe the scientific or structural backgrounds of a certain step. Figure  8  shows an example of an overlay object with sliders. An overlay appears in the sub-step content area as a blue "info"-button that opens the overlay upon clicking. Upon clicking the overlay appears and TVB GUI is darkened.
This method reads out the parameters from the simulator page using the function getSubmittableData() from the TVB script genericTVB. js (functions are accessible by their linkage in base_template. html cf. Figure  5 ). Afterwards, the function saves all parameter variable names and value pairs into a hash table data structure. After that, the function createScript() fills the parameter keys and values into a command script template. Finally, the method saveTextAsFile() saves the script as text file and triggers an automatic download of the file within the browser.
OBTAINING TVB-EduPack TVB-EduPack is made available as part of the main TVB distribution, which can be obtained from the TVB website www. thevirtualbrain. org. To get in touch with other users and developers and for questions concerning usage and development the TVB mailing list can be reached at https://groups. google. com/forum/#!forum/tvb-users. For contributing own code, the GitHub code repository can be found at https://github. com/thevirtual-brain. Online documentation and programming interface specification is located at http://docs. thevirtualbrain. org.
Introduction In the pre-www era, dating back to 1987, schools required a communication system for collaboration. A requirements specification was established that focused on user friendliness, flexibility, distributed databases, and the transmission of formatted documents and pictures. During this era Transmission control protocol/Internet protocol TCP/IP communication was used, which is now known as the Internet. Innovative ideas at the time were gradually embedded, and the whole package grew beyond the initial plans, gaining attention outside education as well. The combination of Windows and UNIX led to Winix, a product that was really breaking barriers at the time. The success appeared obvious. However, bureaucracy and politics terminated the adventure. By bringing researchers from Scandinavia together to address educational and technical challenges of mutual interest, a national network and a Scandinavian network of educators and computer scientists were constructed.
Origins of the Project The Minister of Education, Research and Church Affairs (KUF) wanted to build a close collaboration between some upper secondary schools in Northern Norway, comprises the Upper Secondary Schools in Hamarøy, Nordreisa and Honningsvåg. The project was named SPINN (School Project in Northern Norway). The distances between the schools were about one thousand kilometers. Moreover, some of the schools, such as North Cape Maritime College and Upper Secondary school in Honningsvåg (the northernmost town in the world) had several locations along the Coast of Finnmark County, spread over hundreds of kilometers. training in the use of data communications the participants were also trained in database searches.
Several Over the next few years, the simulation system for data communication and database searches was further developed. The plan was for schools to be able to acquire the system and train participants on data communications without the expense of dial-up lines. The Ministry of Education, Research and Church Affairs and The Ministry of Labour and Social Affairs released in 1991 their own textbook "Electronic information resources, information capture and distance learning. " As early as 1990, there were 4615 searchable (like today in WWW) databases available in the world, delivered by 2500 database producers with 654 database hosts. In Scandinavia there were 433 registered databases  [2].
BBN had the primary responsibility for the development, but the project also involved a dozen other development agencies with specific tasks. The original plan for Arpanet was to engage only one center for development to obtain the maximum effect of ARPA's investments on technical equipment. Gradually, however, the dimensions of the project increased, particularly after observing that ARPA could also meet other challenges through Arpanet. ARPA used, for example, grant funds for the development of ALOHA net 1  , which became the origin of packet-switching over microwave networks, and for the development of Packed Radio Net (PRNET) for mobile communication and Satellite Net (SATNET), with a station in Norway, for the transmission of seismic data for defense purposes. Gradually the Internet came into being as we now know it, developed jointly by professionals in Great Britain, France and Norway.
Tisip wrote much of the requirement specifications, and they were also the leader of Winix Support Services (WSS). Winix Support Services were organized in a network and were available to users 24 hours a day. Winix International had organized an educational system consisting of the Winix Main Education Service (WMES) and several local educational services (WES). Numerica Hektor Data AB, Linkøping, was the company which developed the Winix Database file handling system and relational database manager. It was a complete multi-user system that permitted mixed processing of local and remote Windows and UNIX files and included many of the functions found in advanced relational database management systems on mainframes. It could handle fields of variable length, and it could process text, graphical information, lists, and so on, not only binary numerical data and strings.
Hi-Q International Inc. was the company which developed the Winix Terminal Emulator. A Winix LAN could be interconnected to other Winix LANs in a wide network area (WAN). Through the powerful integrated Winix Emulator on a Winix Network, the users could directly access local or remote mainframes, databases and networks. The Winix Terminal Emulator could be used either as a stand-alone product on a MS-DOS host or as an integrated component of a Winix Network. Winix Network. The overall goal for the development of the Winix Network was to gain pedagogical, technological and organizational experiences with tele-education and distributed work situations. We envisaged that a typical installation at the schools in the future would be a LAN connected global network. Therefore, we required seamless integration between LANs composed of workstations.
The development of Winix was to continue unabated. [13]. The Ministry contacted the International Data Corporation (IDC), a leading company in market analysis. They performed a special analysis and concluded that "The enormous potential for growth that occurs for Winix arises from a very lucky combination. One has found the right software solution tailored to the right hardware for computer systems of the 1990-ies. " Further on, it states "And one has come far enough in development of the product to participate in the expansion. The product side is in other words OK, the marketing will now decide if Winix will be part of the expected growth. " Furthermore, IDC stresses how important it is for early success of new products in the market. "Experiences indicate that it is too late to develop a product when the market for this kind of product takes off.
One has to have a reasonably developed product available from the start. We therefore believe that Winix is very well positioned to benefit from being in the particular software market that is likely to have the largest expansion in the 1990-ies. " Special analysis by Marked Share  [14]. A special analysis by Marked Share concluded that "The Winix concept and products are exciting and represent a new and fresh mindset within Norwegian IT. Marked Share is impressed with the strong will and determination that the steering group demonstrates. The work that we have seen up until now is professional and poses a unique opportunity for a Norwegian/Swedish product to achieve wide international sales and distribution. ".
American Business Group The American business group had approved the software product in May 1991, and they placed their first order in the summer of 1991; however, the Ministry was not able to deliver complete packages due to production problems with some plastic ringbinders designed and custom-made by a manufacturer. In a meeting at the Ministry of Education, initiated by the Winix project leader, the Minister approved of contact with the American group to discuss a possible sale of Winix. A direct background for this action was a budgetary authorization by the Ministry of Finance to cover development costs through sales income. This had to be accounted for before the end of the year (1991). The Minister was kept informed. In November 1991, the American Business Group went to Oslo with the intention of buying the Winix family of products for approximately 40 million NOK, offering a royalty of 6% and free Winix-software in the future for the Norwegian school system.
Conclusion The main background for starting Winix in the 1980s was the need for a flexible and user-friendly communication system between Norwegian schools and the fact that no existing system at the time met the defined requirements for educational purposes. Along the road, due to new ideas and desires from the teachers and school authorities, extra modules were added to cover a wider range of services, e. g. , tools for the development of applications and tools for designing and implementing simulation software. As the functionality increased and the total package became more multipurpose and user friendly, complexity and costs naturally also grew. On the other hand, this multi-purpose and flexible software system appeared to be just-in-time for needs and interests far beyond the Norwegian school system.
It caught attention, was evaluated and positively described at large software shows, in magazines and news media around the world, thus inviting unexpected attention and indicating economic potential. The negatives were those in Norway who were against government actions and those who fought for OSI model; the Internet would never be a standard. Winix was now gradually taking on dimensions that were not quite suitable for a government body such as the Ministry of Education. How could this golden egg be taken care of without losing control of the product that should meet the original goals for Winix development? This turned out to be particularly difficult when Winix was ready to go commercial. The question was: Should the Ministry sell out, or should it continue spending public money to develop a product that schools needed and that, at the same time, could be a source of economic benefit? When the decision was finally taken to create an organizational structure that could handle both the development and the marketing of Winix, the Miinstry seemed unable to act.
INTRODUCTION Norine, first released in 2006  (1) , remains the unique platform dedicated to computational biology analysis of nonribosomal peptides (NRPs). Although other databases contain NRPs, they did not have the same scope and did not provide associated analysis tools. For example, the pep-taibiotics database (2) is a comprehensive online resource for peptaibols, while ClusterMine360 (3) is a database of microbial PKS/NRPS Biosynthesis. The NRPs have increased in popularity in recent years because they harbor diverse interesting biological activities. Indeed, they are produced by micro-organisms, bacteria and fungi, to colonize and survive in various environments. Among others, NRPs can act as antibiotics (penicillin -NOR00006-, daptomycin -NOR00001-or vancomycin -NOR00681-), siderophores (pyoverdins -NOR00160 to 206, NOR00903 to 912-or vibriobactin -NOR00250-), surfactants or protease inhibitors.
As it gathers more than 1100 NRPs, Norine enables to explore and better understand the diversity of the NRPs. We already suggested that their diversity of activities comes from the diversity of their structures  (6). The most particular and interesting feature is the diversity of composition. Norine hosts 529 different monomers including proteinogenic amino acids and their derivatives, other amino acids, lipids, carbohydrates, chromophores and polyketides. An-D1114 Nucleic Acids Research, 2016, Vol. 44, Database issue other feature is the diversity of structures. Not all NRPs are linear, they can also contain one or more cycles and branches. Therefore, we provide a specific representation of NRPs monomeric structures that we call the NORINE format. The monomeric structures and their associated homemade bioinformatics tools are major features of Norine.
Norine is freely accessible from the following URL: http: //bioinfo. lifl. fr/norine. It gives access to abundant and valuable annotations on NRPs through a user-friendly interface. The data can be browsed, searched (among annotations and structures), downloaded and accessed by web APIs. Moreover, the peptides and their annotations are manually extracted from scientific literature. So, expert and meticulous work is needed to populate the knowledgebase. The high data quality has contributed to the renown of Norine. Scientists worldwide rely on Norine for studying and discovering new natural products by, for example, combining genomics and metabolomics  (7, 8). Some mass spectra tools integrate Norine data as mMass  (9)  or iSNAP  (10). Moreover, the Worldwide Protein DataBank (wwPBD) organization selected Norine as a reference database  (11).
CROWDSOURCING FOR INCREASING DATA QUAN-TITY AND QUALITY, MYNORINE TOOL MyNorine is a new module that is now part of the Norine platform. With this tool, the main idea is to enhance the first database entirely dedicated to NRPs by allowing scientists all over the world to contribute. From users point of view, MyNorine can be seen as an interface to simplify the submission of new peptides into the Norine database, and to improve quality of information stored by submitting proposals to correct or modify existing peptides. The tool is mainly dedicated to biologists and biochemists who want to contribute to the Norine database. In order to use MyNorine, users firstly register by creating an account. MyNorine distinguishes two main roles: curators and validators. Curators contribute to the Norine database by submitting new peptides or modifications, whereas validators are responsible for validation steps.