dataesr/scientific-paragraphs-categorization huggingface dataset:
Sample selection procedure and weighting When working with samples (e. g. public opinion polls), it is important to adjust data for population parameters such as gender, age, region, etc. We propose in this work to adjust structure of the two non-OA control groups by calculating weights so that these samples corresponds to that of OA publications (respectively in fully OA and hybrid journals). In other words, we calculated the raking weights for the publications of the control sample in order to ensure that both samples have a comparable distribution with respect to the characteristics identified. In our calculations, we distinguish publications in fully OA journals and those in hybrid journals. There are several ways to do this. One of them is the Raking Ratio method. We used Josh Pasek's package (see: https://cran.
A second interesting observation is the gradual reduction of the citation disadvantage between 2009 and 2016. We could explain that by the fact that OA journals have gained notoriety over time and are attracting high-impact senior researchers. Finally, there is a drop in the OACA from 2016 that we cannot explain with certainty. Nevertheless, we assume that it is related to an increase in the number of newly created OA journals (or newly indexed in the WoS database) from 2016. Another possible hypothesis is that the proliferation of institutional and subject repositories during this period (after 2016) may have played a role. Non-open access articles may now be accessible through green open access road, which could potentially reduce the citation advantage of gold open access. This may be subject to future development.
Another representation of personal knowledge was elaborated by  [14]  in the domain of research. The personal research knowledge graph (PRKG) is designed to acquire the researcher's professional activities, as well as shared laboratory resources and fine-grained knowledge items related to his/her research work. The concepts used are attributes of the usercentric graph and can also be linked to each other. Figure  3  illustrates an example of PRKG of an NLP researcher. The graph shows that the user Sunita is interested in NLP, reviews scienceKG, manages the NLPLab, reads CCINC. To make effective use, PRKG can be populated manually or automatically from information extracted from specialized databases such as ORKG 2 and OpenAlex 3 or from the user conversation with a chatbot. PRKGs can be used to enhance scholarly engines, conversation agents, and recommendation systems in the research field.
Illustration To illustrate the above model of the interpersonal activity knowledge graph, the case of teaching activities within an institution is addressed. As shown in Figure  10  the illustration graph concerns ten teachers for database, Python programming, user interface designing, project management, and software engineering. (02) of these teachers are in charge of the database course and tutorial, (02) for the Python programming course and practicals, (01) for the user interface designing course, (01) for the project management course, and (04) for the software engineering course, tutorial, practicals, and projects. ?activity pko:activityName ?activityname. FILTER ( regex( str(?activity), "Python") || regex( str(?activityname), "Py") ) } These teachers use resources such as hard copies of books, soft copies of books, computers, projectors, and video lessons.
Block 7 :Block 8 : 78 Where do the database activity holds PREFIX pko: <http://www. semanticweb. org/serge/ ontologies/2022/10/pko-onto#> SELECT DISTINCT * WHERE { pko:SoftwareEngTeaching pko:isComposedOf ?activity. OPTIONAL {?activity pko:hasLocation ? location. } } Result of query in Block 7.
While the Jupyter ecosystem  (Kluyver et al. , 2016; Randles et al. , 2017 ) is now widely used for scientific data analysis, it still requires users to have basic knowledge of commands and scripting, and does not allow to launch full GUI applications. Alternatively, a number of commercial solutions exist, such as Amazon WorkSpaces (Amazon Web Services, 2023), FastX (StarNet Com. Santa Clara CA, 2023), and NX/NoMachine (NoMachine, 2023). Other community related software exist, such as the VISA platform  (Caunt Stuart, 2021) , the ISIS Data Analysis as a Service  (Frazer Barnsley, 2016) , and the CoESRA service  (Guru et al. , 2016) , but none of them is fully open-source and easily installable and deployable. The Data Analysis Remote Treatment Service (DARTS) is a lightweight, on-demand, cloud service to instantiate and display ready-to-use complete scientific software environments.
Implementation The conceptual design of the Data Analysis Remote Treatment Service (DARTS) is based on the following sequential steps: 1. Identify a user and computing requirements from a web form (landing page). 2. Launch a copy of a master virtual machine. 3. Display it in a browser. The DARTS service starts from the landing page, in which a user feeds information (credentials, computing requirements), and selects one of the available environments (from the machines. conf file). This information is collected by the main script (qemu-web-desktop. pl), which imports the main configuration config. pl and takes care of the whole service steps (instantiation, monitoring, self-cleaning). A snapshot of the selected master virtual machine environment is created, to hold user-level changes in the instance.
It is then started and attached to the QEMU embedded VNC server. A start-up configuration script can be injected via virt-customize  (Jones, 2011)  to be executed during the boot process. A websocket exposes the internal VNC port as a URL, and displayed with noVNC. The result page is generated with the proper URL for the user to connect. The performance of the virtualization layer reaches native speed for both CPU and GPU, as well as for disk and network. Relying on a steady software stack (Apache2, Perl, QEMU) with limited dependencies, DARTS is easy to deploy and operate. In practice, the only DARTS-related maintenance action consists of adding or updating the virtual machines. The simplicity of DARTS only requires a fraction of a single staff member for its administration.
Research applications DARTS is especially suited for small to medium research laboratories and facilities willing to quickly deploy a remote data analysis infrastructure, with minimal maintenance. At the Synchrotron SOLEIL, the service has been operated continuously since 2020 for our users on two servers equiped with GPUs  (Farhi, 2023). Our current production environments are a default Debian system holding X-ray data treatment software (currently 631 scientific applications and libraries), a reduced system meant to be distributed to the users as they leave the facility, and a Windows 10 system with commercial software. Our Debian images are built automatically via a set of shell scripts  (Picca & Farhi, 2022). This choice is meant to minimize our maintenance. These images mount a persistent user folder (also accessible via a JupyterHub service), as well as the experimental data storage via NFS, CIFS/Samba, and SSHFS.
Acknowledgements We thank the members of the  Data Reduction and Analysis Group at Synchrotron SOLEIL , and particularly  Frédéric-Emmanuel Picca  for his continuous support during the development of this project. We also thank  Roland Mas , from the  GNURANDAL company , for the Debian packaging. This project has received support from the  European Union 's  Horizon 2020 research and innovation programme  under grant agreement No  957189  " BIG -MAP " ( Tejs Vegge, 2020 ).
Software languages have pros and cons, and are usually chosen accordingly. In this context, it is common to involve different languages in the development of complex systems, each one specifically tailored for a given concern. However, these languages create de facto silos, and offer little support for interoperability with other languages, be it statically or at runtime. In this paper, we report on our experiment on extracting a relevant behavioral interface from an existing language, and using it to enable interoperability at runtime. In particular, we present a systematic approach to define the behavioral interface and we discuss the expertise required to define it. We illustrate our work on the case study of Sci-Hook, a C++ library enabling the runtime instrumentation of scientific software in Python.
g. , CORBA  [8] , CCA  [1] , CoLoRS  [13] ). While the former limits to the use of a specific execution platform, the latter requires to define bindings at the program level. This either prevents the use of specific language runtimes (e. g. , specific C++ compilers such as GCC, or mainstream Python interpreters like CPython or Pypy), or imposes the overhead of defining ad-hoc bindings for each new program. In this paper, we introduce an approach to support interoperability between different language runtimes (interpreters and compilers) through specific interfaces defined at the language level. We present our approach to define such language interfaces for NabLab 1  , a Domain-Specific Language (DSL) for scientific computing, and report on our experience using it with SciHook 2  , our C++ library to enable Python-based runtime instrumentation for scientific software.
Using SciHook, computational scientists can write analyses as Python scripts that will run during the simulation, also called in-situ analyses  [12] , with the full power of Python's libraries for scientific computing  [9]. Such analyses can access the data they require in-memory, which allows to turn off expensive input/ouput operations (I/Os) and speeds up the simulation time significantly  [2]. Furthermore, with write access to the execution context of the simulation, instruments can implement complex behaviors varying on a case-by-case basis such as the physical behavior of the environment of a simulation, without needing to recompile the simulator. We experimented the use of SciHook with simulation models implemented in NabLab  [6] , a compiled DSL for numerical analysis. Based on these experiments, we discuss the required effort for the definition of the behavioral interfaces, the resulting performance at runtime, and the suitability of runtime instrumentation coupled with software language interoperability.
We demonstrate the practicality of enabling interoperability between different languages through well-defined and purposefully designed language behavioral interfaces, with a limited overhead. We also show how the combination of interoperability and runtime instrumentation capability opens up new usage scenarios for the instrumented programs. The remainder of this paper is as follows. Section 2 presents the motivation behind this work. Section 3 details the proposed approach. Section 4 discusses how we applied the approach to NabLab, using SciHook to enable the instrumentation of NabLab programs in Python. Section 5 presents our evaluation of the overhead induced by the approach over a selection of use cases. Section 6 discusses related works, and Section 7 provides concluding remarks.
Motivation In this paper, we use the field of scientific computing and the software languages used in that field as our illustrative example. The two main use cases for language interoperability in scientific computing are (𝑖) C++ and Fortran, to call legacy Fortran code from C++ code  [1] , and (𝑖𝑖) Python and C/C++, to pilot efficient C/C++ libraries from Python-based GUIs or with libraries such as SciPy  [1, 11]. In both use cases, interoperability is mainly used to provide program-level bindings for black box software components, and does not allow to interact with the internal state of such components. Yet, specific operations might be more easily or robustly implemented in a different software language, or require scriptability to access the execution state of the component at runtime.
For example, in the context of complex simulation codes, this allows to submit scripts to process data in-situ  [2] , waiving the need to persist complete data sets to disk. Another use case is to expose the execution state at a mathematical level of abstraction, in a language well-suited for mathematical operations (e. g. , Python with NumPy support). This in turn enables debugging and domain-specific property monitoring at an adequate level of abstraction for numerical analysts, while keeping the computation-intensive parts of the simulator efficient. Unfortunately, support for such a gray-box usage of software language interoperability is tedious and error-prone to implement, and does not contribute directly to the business logic of the application. This can be dissuasive for practitioners of scientific computing, who are not software engineers and/or might not have the manpower to spare on these concerns.
SciHook Overview Figure  1  provides an overview of SciHook. On the left is a piece of scientific software, which can be implemented directly in C++, or generated from its specification when written in a language transpiling to C++ (such as NabLab). To leverage SciHook, this piece of scientific software provides an instrumentation interface, as defined in the previous Section. This instrumentation interface can be generated directly for a given program (in C++), or it can be generated from the software specification (using NabLab). At the center of Figure  1  are the SciHook runtime and its registered instruments. Using the SciHook API, applications define their execution events as specified in their instrumentation interface, and trigger those events during the execution. Conversely, SciHook instruments use the Sci-Hook API to register and unregister to the runtime, listing their triggering events from the instrumentation interface.
The SciHook runtime stores the registered events and instruments, and triggers instruments upon the emission of events to which they are registered. Triggered SciHook instruments are provided with the execution context of the application, on which they can perform read and possibly write operations, depending on how the context was exposed, as well as call functions exposed as part of the context. To achieve this, the SciHook runtime depends on the CPython interpreter, as shown on the right of Figure  1 , to which it delegates the execution of SciHook instruments. This means that, when writing instruments, SciHook users have access to the vast ecosystem of libraries for scientific computing such as NumPy, Matplotlib, Numba, and so on  [9]. With access to scientific computing libraries and to the execution state of the application, users can craft analyses that are easily plugged into the application and that can be turned on or off at runtime.
Experimentation with NabLab NabLab is a DSL for scientific computing allowing numerical analysts to define their numerical schemes at a level of abstraction close to discrete mathematics, and then generate the corresponding C++ simulator. The C++ code generation infrastructure handles system-level concerns such as memory and programming paradigm (GPU, CPU, MPI, etc. ). In this experiment, it is extended to derive the instrumentation interface from the NabLab program, and realize it. Identifying Execution Events. The execution events exposing the instrumentation points of a NabLab program include calls to the jobs defined in a NabLab program (i. e. , its callable entities), as well as all variables writes. Job call events are emitted before and after the triggering calls, and write events are emitted before and after the triggering writes.
In the case of job call events, only the global variables and parameters of the call are exposed in the execution context. In the case of global write events, only global variables are considered in the execution context, whereas in the case of local write events, local variables are included as well, as are the parameters provided to the encompassing job. Realizing the Interface. We realize the instrumentation interface during the C++ code generation. First, we insert calls to the SciHook runtime to declare the execution events exposed by the interface. Next, we generate each distinct execution context as a C++ struct holding references to the variables accessible therefrom. We then generate code instantiating these structs at each new execution context, and calls to the SciHook runtime triggering execution events with their execution context.
Finally, we generate Python bindings for these structs, exposing the variables they encapsulate to registered instruments. We also generate a Python-facing interface to expose these execution events to Python-based instruments. Library for Code Generation. To apply the approach, we developed an Xtend library of around 900 lines of code for analyzing NabLab programs and generating C++ instrumentation code, which we added to the code generation infrastructure of NabLab, also written in Xtend. This library provides facilities for computing the set of execution events of a NabLab program, the set of corresponding execution contexts, and the set of concrete types that must be exposed to Python. To mesh well with scientific computing Python libraries, we exposed the array types of NabLab as NumPy arrays, thereby avoiding expensive copy operations.
The code generation library also provides facilities to generate the Python bindings for the execution contexts, and the CMake build files integrating SciHook into the application. This code generation library is disabled by default and, when enabled, places all instrumentation code between #ifdef/#ifndef directives. As a result, C++ code is generated without instrumentation by default, and when generated, the instrumentation must be turned on at compile-time, allowing the instrumented code to be used in production.
Performance Evaluation In this Section we evaluate and discuss the overhead induced by SciHook-based instrumentation of NabLab in various use cases. For each use case, we measured the execution time of 30 runs of the same simulation, and provide the average execution time in Figure  2 , as well as its relative overhead with regard to the baseline execution time. We performed the measurements on a 11th Gen Intel® Core™ i5-1145G7 @ 2. 60GHz × 8, on Ubuntu 20. 04. 4. Baseline. For this evaluation, we consider two baselines (dashed lines in Figure  2 ): the average execution time of the non-instrumented code with, and without I/Os. As we use SciHook instruments instead of post-processing to address the use cases, we disable the built-in I/Os. However, we still compare execution times against the "with I/Os" baseline, as they are mandatory for addressing the use cases with non-instrumented code, through post-processing.
Note that we do not consider the overhead of this post-processing in our comparison. No instrument. This use case shows the overhead induced by the instrumentation alone, without any instrument registered. For the evaluated model, the overhead with regard to the "no I/O" baseline is minimal as it stands at 0. 30%. Legacy I/O. This use case reproduces the original I/Os by calling the original C++ code responsible for I/Os, but through Python bindings, via a SciHook instrument. We estimate that the 27. 31% induced overhead is due to the backand-forth between the Python interpreter and the simulator, and to the absence of link-time optimization. This shows that SciHook is not best used to naively reproduce core functionalities of a C++ simulator such as I/Os. However, the dynamic nature of SciHook allows developers to write adaptive instruments, as discussed next.
Lightweight simulation. This use case exemplifies the use of scientific computing for exploratory purposes, where simulations are run in a fast and iterative process. All input data are provided through SciHook instruments, and a plot of the final state of the simulation is the only produced output, meaning no time is spent on I/Os. The 82. 59% shorter execution time is an important speed-up compared to noninstrumented code, which allows to quickly obtain insights on a simulated physics problem. These results demonstrate the practicality of enabling runtime instrumentation at the language level, and instrumenting scientific software to perform analyses during the execution, reducing the need for highly sequential workflows relying on writing data to disk and reading it back in another tool.
Related Work We identified two categories of related works in the context of enabling software language interoperability. The first category regroups approaches providing interoperability inside a single language runtime, through a unified intermediate representation used by all supported languages. This is the case of Truffle/GraalVM  [14] , LLVM  [5] , or We-bAssembly  [4]. This means that interoperability with specific language runtimes such as Pypy, CPython, GCC, or the Intel compiler must be implemented at the program level. In comparison, our proposed approach aims to support interoperability between language runtimes. The second category regroups approaches like CORBA  [8]  and CCA  [1] , which relies on interfaces defined for each component to allow them to communicate, whether they are defined in the same language or not.
Concluding Remarks and Perspectives In this paper, we presented an approach to support interoperability between different software languages, relying on the definition of language behavioral interfaces, and on the use of an instrumentation runtime to realize those interfaces. We demonstrated the approach on the NabLab DSL, using SciHook as our instrumentation runtime to realize the interface and provide interoperability between C++ (the target language of NabLab), and Python. The ability to instrument scientific software in Python allowed for greater agility when prototyping and debugging, illustrating the benefits of opening language-induced silos to other languages. From here, we envision several threads of future work. A first perspective is to explore the interplay between the instrumentation interface of a language and testing frameworks, with the goal to provide testing support out-of-thebox to languages exposing an instrumentation interface.
JAMA Network Open | Medical Journals and Publishing Protocol Items: Recommendations for Interventional Trials (SPIRIT)  14, 15  items (the SPIRIT for Peer Review [SPIRIT-PR] trial). The CONSORT-PR trial included manuscripts that described RCT primary results. The SPIRIT-PR trial included manuscripts that contained RCT protocols. Both trials received ethical approval from the Medical Sciences Interdivisional Research Ethics Committee of the University of Oxford and were prospectively registered on Open Science Framework. 16, 17 Of note, registration of the 2 trials in a clinical trial registry was denied by trial registries, such as ClinicalTrials. gov or ISRCTN, because our studies did not measure a health outcome in individuals. After a request by the editors who provided personal contact information to ClinicalTrials.
Funding/Support:  Dr Speich  was supported by an  Advanced Postdoc. Mobility grant  ( P300PB_177933 ) and a  Return Postdoc. Mobility  ( P4P4PM_194496 ) grant from the  Swiss National Science Foundation , as well as a research grant from the  Research Foundation of the University of Basel. Dr Lohner  was supported by the  János Bolyai Research Scholarship of the Hungarian Academy of Sciences  ( BO/00498/17/5 ) and a research grant from the  National Research, Development and Innovation Office of Hungary  ( NKFIH_FK_143633 ). Role of the Funder/Sponsor: The funders had no role in the design and conduct of the study; collection, management, analysis, and interpretation of the data; preparation, review, or approval of the manuscript; and decision to submit the manuscript for publication.