dataesr/scientific-paragraphs-categorization huggingface dataset:
L'expérience pédagogique s'est généralisée et transformée progressivement. Le choix initial a été d'employer des films de fiction de distribution commerciale, à l'image de la base de données « Literature, Arts & Medicine Database » de la New York University School of Medicine. 17 Cependant, ce choix bien que légitime et utile en soi, présente des limites pédagogiques. Les descriptions fictionnelles grand public peuvent se révéler éloignées de la « réalité » vécue par les étudiants en parcours professionnel. Dans de tels films, les sciences et la médecine servent souvent de vecteurs narratifs plutôt que de véritable thématique. La mise en scène des épisodes historiques et des thématiques scientifiques et médicales traitées y présente souvent un caractère anecdotique voire anachronique. Ainsi pour élargir et approfondir l'approche initiale, notre intérêt s'est davantage porté vers les films de non-fiction.
Leur publication sur la plate-forme est soumise à une validation par les membres de l'équipe selon une grille d'analyse validée lors du séminaire bimestriel du projet. Par ailleurs, des documents annexes aux différentes fiches incluent des sources originales et des publications secondaires concernant les films. 79 'objectif principal consistant à fournir un accès libre et pratique à ces documents pour une large population de chercheurs, enseignants et étudiants, les choix technologiques de la plate-forme se composent de deux ensembles : un site web classique d'une part, qui accueille les informations générales sur le projet et les annonces et résultats de notre recherche, la base de données d'autre part, qui prend la forme d'un MediaWiki ?  80 MediaWiki est un ensemble wiki à base de logiciels libres open source, développé à l'origine pour wikipédia et aujourd'hui utilisé par plusieurs autres projets.
Les premiers sont : « l'hôpital », « les professions médicales », «portraits de patients », « la fin de vie », ou encore « le médicament ». Les kits sont essentiellement constitués de documents informatifs, accompagnés de références et de trames pédagogiques. Ils comportent en principe un conducteur de cours, des liens vers les fiches descriptives et analytiques des films employés et des documents écrits (articles de journaux, extraits d'ouvrages, textes d'interventions universitaires, etc. ). A noter que dans le cadre des kits, le projet souhaite, à l'instar de la New York « Literature, Arts & Medicine Database », élargir le champ cinématographique à des disciplines culturelles et artistiques. A titre d'exemple, le cours « Cinéma, littérature et médecine » dispensé à la Faculté de médecine de Strasbourg, résulte d'une démarche liée à la construction du kit, qui confronte des documents littéraires, médiatiques, voire musicaux, autour du même sujet sanitaire en faisant percevoir leur complémentarité d'approches.
2010, ANR-10-BLAN-2004. 2  http://medfilm. unistra. fr. Tous les liens internet ont été consultés en date du 06/05/2014. 3 Nous désignons comme « université moderne » les institutions qui après la réorganisation suivant les principes néo-humanistes au début du 19 e siècle, s'appuient sur trois principes fondamentaux : l'unité de la science, l'unité de l'enseignement et de la recherche, et l'idéal de « Bildung » (éducation). Schubring, 1991, pp. 276-326, en particulier p. 278. La mise en place d'un « disciplinary order of sciences » entre 1780 et 1840 forme le point central des études de R. Stichweh sur la « genèse du système scientifique moderne » organisé sous forme de disciplines scientifiques marques par leurs « impératifs de recherche » Stichweh, 1991. Turner, 1986, pp. 495-502. "Science is method not information.
Une des premières initiatives en ce sens est la « Literature, Arts & Medicine Database » de la New York University School of Medicine. Elle se définit comme une liste annotée de ressources multimédia de littérature, poésie, film, vidéo et art, développée pour constituer une ressource dynamique, accessible exhaustive pour l'enseignement et la recherche en « medical humanities ». La base ne contient pas les films décrits mais seulement leur description et analyse, puisque ce sont des films de fiction commerciales, donc couverts par des droits d'exploitation et accessibles par la vente. En revanche la base établit des liens très intéressants entre les trois domaines de la littérature, le film et les arts plastiques et leurs rapports avec la santé et la médecine. http://litmed. med. nyu. edu consulté en date du 06/05/2014.
GRETA 3   [8]  sont deux systèmes interactifs dédiés à la conception d'agents conversationnels animés. VHT propose une collection de composants pour la majorité des tâches nécessaires aux systèmes interactifs, telles que la reconnaissance et la synthèse vocale, la gestion du dialogue et des comportements non verbaux. GRETA propose une architecture développée en Java permettant d'interagir avec un personnage virtuel du même nom. [8]. D'une part, VHT est la plateforme la plus aboutie, mais son code fermé rend son utilisation contraignante et ne permet pas de modifier ses composants. D'autre part, GRETA est plus orientée sur l'étude des agents virtuels, en particulier dans leur composante d'animation. AgentSlang propose ainsi une alternative open-source et indépendante de l'incarnation à ces deux plateformes.
Une liste nonexhaustive de ses fonctionnalités est présentée ci-après :-Afin de traiter les entrées utilisateurs, plusieurs modules sont disponibles : (1) un module de transcription vocale automatique via l'API Google Speech ; (2) des composants permettant le traitement du langage naturel via Senna [2] , un système versatile permettant notamment l'annotation grammaticale du discours et la reconnaissance d'entités nommées. -Pour la gestion du dialogue, la plateforme propose des composants réalisés à l'aide de Syn!bad [9] , un langage d'expressions rationnelles basé sur des synonymes. Le modèle de dialogue proposé suit une approche déterministe : une correspondance est faite entre l'entrée utilisateur et un modèle réalisé via Syn!bad ; une réponse est ensuite générée en fonction du motif identifié.
le logiciel Cereproc Voice 4  , et (2) qui génèrent et transmettent un fichier BML (Behaviour Markup Language) vers un outil de représentation du comportement compatible avec ce format tel que MARC [3]  ou GRETA [8]. 3 NOUVEAUX COMPOSANTSDe nouveaux composants ont été intégrés à la plateforme de façon à (1) intégrer une nouvelle approche concernant les mécanismes de dialogue, (2) assurer l'interfaçage avec des agents robotiques. 2 https://vhtoolkit. ict. usc. edu/ 3 https://github. com/isir/greta 4 https://www. cereproc. com/fr/products/voices.
This method is supported by Lepton  [3] , a freely available software tool developped in house for this specific purpose. It is well suited for doing research but also for adding documentation to existing methods. This tool has been described previously in  [4]  from the point of view of reproducible research and in  [5]  for its use in teaching mathematics (random exercises with solutions and project reports). Here we start from a rather large piece of image analysis code without a manual and illustrate how Lepton can be used to understand how the source code works and how to use the corresponding program.
Investing in documentation In our opinion, one major rationale for writing documentation is to convey knowledge to our future self. This is what turns random bits of digital information into usable and meaningful media. Proper documentation should be written for the future so that the work remains live and usable long after its production. In that sense, documenting is a long-term investment, and we have its returns when we want to reuse and modify it. For instance, it is very common to redraw figures or rerun analyses of datasets to answer reviewers' comments or match the editing policy of a journal. Sometimes the figures must simply be redrawn without color, sometimes larger simulations or benchmarks are called for. When presenting your work at a conference or comparing with newer work, figures may need to be adapted for the presentation slides or for the conference proceedings.
Proposed method Our proposed documentation framework hinges on three compoments: • a package format that holds all the elements in the research project, • a software tool for extracting the elements from the package, • a documentation format that is compatible with existing practices and automatically provides information on the contents of the package. Lepton uses a file format inspired by literate programming  [1]. In this approach, authors are encouraged to focus on writing documentation in the format of their choice. This manuscript is in fact a Lepton file written with L A T E X as the documentation format. All other elements such as source code, scripts, input data and results are embedded inside the documentation in blocks (called code chunks) of the form : Code chunk 1: lepton <<name options>>= contents @ The Lepton software is responsible for extracting the contents of code chunks, and producing a bona fide documentation file that can be processed by L A T E X.
During this process, several operations can be applied to the contents of code chunks, depending on the options specified by the author: • -write writes the contents of the code chunk to disk (chunk name is used for the filename) • -exec interpreter sends the contents to an external process for execution (Unix shell, Matlab, Scilab, etc. ) • -chunk format -output format controls how the chunk contents and outputs are embedded in the resulting documentation • <<chunk_ref>> is an abbreviation for the contents of another code chunk. In the literate programming paradigm, authors can use the above features to manipulate source code, regardless of the constraints of the programming language. For instance: • source code can be divided into meaningful chunks • code chunks can appear anywhere, and especially below the corresponding algorithmic description or a specification to complement the documentation, • test cases can be defined and executed next to the code • benchmarks defined inside the documentation will have their results automatically embedded inside the documentation and updated upon source code modification.
Note that providing the source code that corresponds to an algorithmic description does not require additional work, but allows the reader to check if the two are coherent. We propose to use literate programming with Lepton in incremental stages. First, we package all the necessary elements into a single document and set up extraction properly. Second, we make sure that source code compiles. Then, we make sure that the binaries can be executed and set up some tests. Finally, we analyse and document the functions in the source code and the methods. The documentation process may be interrupted at any stage, Each stage provides a given level of usability and reproducibility.
First stage : make a documented package Start with a working installation of Lepton. Lepton is distributed as a standalone executable for Linux, and downloading the binary file from http://www. math. univ-paris13. fr/ ~lithiao/ResearchLepton/Lepton. html should be sufficient. On 64bit systems, the executable runs as a 32bit program and thus requires the basic 32bit libraries. The usage manual and several examples are also available on the website. For this example, we open a new file named readme. nw in a text editor like Emacs or Vim. This file will act both as a L A T E X documentation, and a package that will contain our comments as well as the source code. At this stage readme. nw is pure documentation. Running Lepton on this file produces a readme. tex file that is identical, and we verify that it can be processed by L A T E X.
Then we package each file in the project by inserting its contents in a code chunk, and describe it in the L A T E X documentation. This code chunk should have option -write and the chunk name should be the name of the file Lepton will create. In our example, there is only one C source file : Code chunk 2: readme. nw % LaTeX documentation This project implements all five methods in a single C source file below. <<bigfile. c -write>>= C source code @ Input files and other files can be added to readme. nw in the same way. Again, we run Lepton, and check that bigfile. c is correctly re-created by Lepton. At this stage, you should have a package containing all the necessary files and their description in a single Lepton file. Lepton is able to extract those elements from the source, and documentation can be compiled.
If you decide to stop working at this stage, readme. nw is a package containing all the files related to the project and their description. Note that when sending readme. nw, collaborators do not require Lepton for accessing the contents of the package. The file readme. nw can be opened and modified in any text editor, and the files can be extracted by copy-and-paste. We suggest that only files of moderate size be included in readme. nw in order to preserve the readability of both the documentation and the L A T E X source. Authors should only include large files as a temporary measure before decomposition into meaningful elements. Lepton provides the \Linput directive for assembling large projects.
Second stage : compile Before attempting to compile the source code, we suggest including the machine configuration in the readme. nw file, either by capturing the output of a configure script, or by running system information commands. This provides information that can be used for debugging when compilation fails or used to indicate a working configuration upon success. To do this, we use a code chunk containing the following commands. With the option -exec shell, Lepton starts a Unix shell, executes the commands, and outputs the results.
Code chunk 3: configuration uname -a COLUMNS=115 dpkg -l gcc libc6 | tail -n 3 Interpret with shell Linux lepton 3. 12-1-686-pae #1 SMP Debian 3. 12. 6-1 (2013-12-21) i686 GNU/Linux +++-======================-================-================-================================================== ii gcc 4:4. 8. 1-1 i386 GNU C compiler ii libc6:i386 2. 17-97 i386 Embedded GNU C Library: Shared libraries To compile the source code, we use the same mechanism. We write the compilation commands in a code chunk with the option -exec shell. As the program uses the math library, we need to add the -lm flag. When gcc reports no error, it produces no output. Code chunk 4: shell gcc -lm bigfile. c -o program. bin.
Interpret with shell For larger programs or more complex scenarii, it is often recommended to use a makefile. This makefile can be embedded into readme. nw in its own code chunk, and executed by a shell command. The Unix shell can also be used to run documentation tools such as dependency graph generators, static analysis code tools, etc. An advantage of using Lepton, is that the outputs are automatically collected and that the produced documentation is always in a coherent state. At this stage, you should have a self-compiling program. If you send this, the recipient can extract the files, compile the program, but there is still no documentation about how the method works.
Similarly, the logic for reading the input image and writing the results to disk is shared between the five programs. At this point, we discovered that the methods could only be applied to square images of size power of two. This was corrected by copying the image contents into the smallest square image. By using a chunk reference, we ensure that this modification applies to all five programs correctly. At this stage, readme. nw contains implementation details with embedded source code. Code is divided in small meaningful chunks that are organized according to their meaning rather than in the order dictated by the compiler. Shared code is re-used by using chunk references. The program can now be applied on multiple images with a (hidden) shell script, output is set for direct inclusion into the L A T E X documentation in Figure  2.
Next steps and conclusion We have progressively modified and documented a fairly large C source file containing several image analysis programs. With the help of Lepton, we have first packaged and documented the project files, then added instructions for compilation and usage. Finally, we modify the source code in order to run a benchmark of the program. Each stage provides increasing levels of reproducibility and re-usability of the program itself and also of our documentation work. Packaging makes the whole project available for sharing with collaborators. Compiling and execution instructions provide the means to use the method. Implementation details provide information for modifying the method, and often improves the quality, modularity and correctness of source code.
Observational data and numerical simulations a. Data and methods This paper will focus on a subset of the extensive suite of COPS instruments. Meteosat Second Generation (MSG) 1-km visible satellite images were obtained every 15 min on 6 August 2007. The illustration of the cloud field development is a critical component for nowcasting CI (e. g. ,  Wilson and Mueller 1993; Kingsmill 1995; Hane et al. 1987; May 1999). Composite radar displays were created every 10 min using the low-level scans from the German Weather Service (DWD) operational C-band radars. These composites were useful for illustrating the evolution of the storms once they formed, but they did not detect clear-air boundaries or early storms due to low-level radar blockage and elevated radar beams at large distances. One of the DWD radars, Feldberg, observed the convection highlighted in this case study and will be shown.
For the purpose of this current study the precalibration was performed prior to operations on 6 August based on an extensive comparison of the water vapor mixing ratio profiles from BASIL with. 100 simultaneous radiosonde profiles. The radiosondes were a combination of Vaisala RS80 and RS92 radiosondes. The moisture dry bias correction was applied to all RS80 radiosondes using the technique of  Wang et al. (2002). The lidar calibration constant was determined by using BASIL and radiosonde profiles in the altitude region between 1 and 2 km. The consideration of more than 100 radiosonde profiles for the determination of the calibration constant prevents the dependence of a single lidar vertical profile upon the simultaneous radiosonde profile. The BASIL data used in this study were integrated over 15 min and have a vertical resolution of 150 m, starting at 150 m AGL.
5-min periods. Volumetric scanning sequences covered much of the southern Rhine Valley as well as the eastern slopes of the Vosges Mountains, whose ridgeline is oriented roughly along a northeast-southwest direction and whose maximum heights are ;1. 5 km. The mobile radar data were corrected for any pointing errors and carefully edited to remove noise, ground clutter, and second-trip echoes using the National Center for Atmospheric Research (NCAR) SOLO II software package  (Oye et al. 1995). Edited data at spherical locations were mapped with the NCAR Reorder software onto a regular Cartesian grid with 500-m horizontal and 250-m vertical grid spacings. The lowest level of the grid was 0. 25 km (;50 m above the floor of the Rhine Valley) and the highest level was 5 km. Cressman (1959)  distance-weighted averages of all data points within nearby 0.
, 1990 ). An examination of successive volumetric scans revealed that overall flow patterns changed only slowly and exhibited little or no advection. Therefore no time adjustments were made during the wind synthesis, a procedure first suggested by  Gal-Chen (1982). Little or no intrinsic fall speeds of the air motion tracers or vertical air motions were likely to contaminate the radial velocity measurements because of the low elevation angles scanned by the radars. This dual-Doppler (or two-equation) solution was deemed to adequately represent the horizontal wind field. Before the winds were synthesized, each of the radial velocity datasets were edited in CEDRIC to remove some obvious outliers and to fill in some small holes using linear-least squares methods. Once radial data were cleaned up and filled, a two-dimensional Hanning filter was applied over 5 3 5 horizontal regions.
Further two-dimensional Hanning filtering over horizontal 3 3 3 regions of convergence was used prior to vertical integration to eliminate noise amplification at twice the horizontal grid spacing that is inherent in centered finite-differencing schemes. Estimated errors in retrieved horizontal and vertical motions are no more than 0. 1-0. 2 m s 21. Surface station gridded analyses were derived using a mesoscale data analysis and downscaling method, named the Vienna Enhanced Resolution Analysis (VERA; e. g. ,  Steinacker et al. 2000 Steinacker et al. , 2006;; Gorgas et al. 2009). VERA utilizes more than 12 000 Global Telecommunication System (GTS) and non-GTS surface station datasets to provide an 8-km gridded field every hour. The VERA technique calculates gridded fields of potential temperature, equivalent potential temperature, water vapor mixing ratio, mean sea level pressure, horizontal winds, and precipitation.
Acknowledgments. The  COPS PIs  are gratefully acknowledged for bringing together this rich and diverse dataset. The DOW dataset was collected by the  staff of Center for Severe Weather Research (CSWR)  through the support of the  Deutsche Forschungsgemeinschaft (DFG) and Ministry of Science of Baden-W€ urttemberg, Germany. The VERA analyses were provided by  Theresa Gorgas (U. Vienna). The U. K. Facility for Ground-based Atmospheric Measurement (FGAM)  wind profiler data were provided by  Emily Norton  and the Salford lidar data by  Fay Davies. Fruitful discussions with  Jim Wilson  are much appreciated. Constructive reviews by  Wen-Chau Lee  and  Jim Wilson  greatly improved an earlier version of this manuscript. Two anonymous reviewers and  Dan Kirshbaum  are gratefully acknowledged for their insightful, thorough, and helpful comments.
The second (LJB) and sixth authors (AMB) acknowledge support from the  Natural Environment Research Council  Grant  NE/E018483/1. The fourth author's (JVB) participation in the COPS campaign was financially supported by the  ANR  (Grant  ANR-06-BLAN-0018-04 :  648 COPS/France ) and  CNRS/INSU (LEFE/IDAO program ) in France. Support of the last author (TJH) through the  NCAR Short-Term Explicit Prediction (STEP) program  is greatly appreciated.
La base de données présente des lacunes de quelques mois pour seulement deux appareils vandalisés puis réinstallés un peu plus tard et un appareil qu'il n'a pas été possible d'atteindre en avril 2012 en raison de l'enneigement. Enfin, trois mois consécutifs (février à avril 2012) manquent suite à un problème technique ayant touché tous les appareils (mémoire saturée dès le début du mois de février). Au total, nous disposons de 25 mois complets représentant 825 jours d'observation. Certains mois sont lacunaires (1 mois pour février et mars) tandis que d'autres sont complets (3 mois pour juin à septembre). Un premier filtre a permis d'extraire le minimum et le maximum journalier des données SCF. Ensuite, un appariement entre les Tn et Tx journalières issues des stations de Météo-France et celles des stations sous forêt a été effectué pour que la comparaison porte exactement sur la même chronique.
Résultats Compte tenu des lacunes dans la base de données, certains mois, janvier à mars par exemple, comportent un nombre réduit de mesures. Aussi, n'a-t-il pas été possible de présenter des résultats systématiques portant sur l'année entière. Ces derniers concernent surtout deux mois caractéristiques de l'été et de l'hiver : juillet, mois le plus chaud de l'année, et décembre (janvier, le mois le plus froid, comportait un nombre trop réduit d'observations).