dataesr/scientific-paragraphs-categorization huggingface dataset:
As an illustration, in their state-of-the-art paper about end-user software engineering, Ko et. al  [15]  address the challenge of enabling the end user to produce reliable programs that actually achieve his requirements, by supporting the programming task with visualization and simulation tools. However, they do not mention the need for a formal definition of an end-user language so that the supporting tools be provably consistent with the language definition. A first step towards addressing this issue is to bridge the gap between the domain analysis, taking the requirements into account, and the design of a language, providing the constructs to achieve these requirements. In this paper, we present the formal definition of a domain-specific language, named Pantagruel  [10, 11] , following the methodology proposed by David Schmidt for language development  [20].
This language is dedicated to programming applications that orchestrate networked entities. It targets end users that are professionals, in areas such as building management and assisted living, and leverages networked entities to support daily tasks. For example, security guards are assisted by an anti-intrusion system that coordinates motion detectors and surveillance cameras to signal the presence of an intruder on monitoring screens. For another example, a range of assistive devices, like time trackers, task prompters, and motion sensors, are available to support caregivers in assisting people with disabilities in their daily life. Pantagruel offers a number of features that address the requirements of the domain of networked entity orchestration, while making it accessible to users that do not necessarily have programming skills.
Specifically, Pantagruel provides two language layers, one for specifying interfaces from which entities are manipulated, and another for orchestrating entities. The orchestration layer offers high-level operators taking advantage of the information defined in the specification layer to discover, select concrete entities, and interact with them via their interfaces. This paper gives a definition of Pantagruel in the form of a denotational semantics, exhibiting the domain-specific features of this language. In particular, this formal definition makes the key concepts of the orchestration of networked entities (i. e. , entity discovery and interactions) explicit. It also brings out some traditional programming language concepts (e. g. , the notion of memory and loop, or variable assignment), which have been abstracted away from the developer.
Outline The rest of this paper is organized as follows. Section 2 presents the specificities and the key concepts of the domain of the orchestration of networked entities. Section 3 gives a tour of our DSL, Pantagruel, illustrated by a working example of a building-automation application. Section 4 motivates the use of the denotational style for our language. Sections 5 and 6 describe the syntax and the denotational semantics of the specification layer and of the orchestration layer of Pantagruel, respectively. Conclusion and future work are given in Section 7.
We refer to such an abstraction as an interface. An interface groups together a set of sensing and actuating capabilities and attributes to which entity implementations must conform. Interfaces may be organized hierarchically, enabling them to inherit capabilities and attributes. We have built a domain-specific language, named Pantagruel  [10, 11] , for developing orchestration applications using the methodology for language development proposed by Schmidt  [20]. Pantagruel consists of two language layers: a specification layer for describing the entity interfaces, and an orchestration layer for describing the orchestration logic. The syntax and denotational semantics of both layers are presented in the following sections. Notably, Pantagruel relies on a pervasive computing platform, named DiaSuite  [3] , for dealing with the variety of underlying, low-level technologies.
Tour of Pantagruel The Pantagruel language is introduced using a working example: a building-automation application. This application is responsible for switching on/off lights of a room when a motion is detected in a room. It also helps regulating the temperature of rooms using fans. Although rather simplistic, this working example is sufficient to illustrate the salient features of the Pantagruel language. More elaborate examples can be found elsewhere  [8]. A key feature of Pantagruel is the tight coupling of the specification layer with the orchestration layer. It allows users to easily and safely develop their own orchestration applications. Figure  1  gives a specification for our working example. This specification consists of four entity interfaces and eight entity instances. For example, the MotionDetector interface declares a sensing capability, named detected, enabling to signal the presence or the absence of a motion.
This event has the same name as the action and its type consists of the types of the action parameters. These three rules show how the language constructs enable to interact either with a particular entity (e. g. , the thermo entity in Rule (3)), or with a set of entities via their interfaces. Moreover, the dependencies between the entities within an orchestration rule are made explicit by the with clause. To illustrate the behavior of a Pantagruel program, Figure  3  shows an excerpt of an execution trace for the orchestration rules given in Figure  2. This trace illustrates the behavior of our working example when a person enters the room 101 which was empty until then. It is represented as a sequence of states, where each state consists of both the values of data collected by entities and the implicit events.
Pantagruel in the denotational style Defining the semantics of a language usually relies on one of the following three methodologies: operational, axiomatic, or denotational  [19]. Denotational semantics focuses on the mathematical relation between input data and output data, and makes explicit the domain definition of these data. In our approach, the structure and characteristics of the data related to the entities are central to the dynamic semantics of our language. Furthermore, because the denotational semantics uses a functional style, a definition can easily be mapped into an implementation. In fact, we have implemented in the OCaml language an interpreter based on the semantics of Pantagruel. Additionally, the functional style of the denotational semantics enables us to generalize the definition of orchestration rules, from an entity to a class of entities.
Some notations This section presents the notations used to define the specification layer and the orchestration layer of Pantagruel. We use the following conventions, inspired by Schmidt's methodology  [20] : a, b a tuple of two elements a and b [x → v]ρ x maps to v in ρ x↓ i , i ∈ N * projection on i th element of tuple x, where i is a non-null integer X denotation of a syntactic fragment T ω = {t i ∈ T } i∈N T ω is the set of infinite sequences of elements of set T T = [ τ 0 , τ 1 ,. ] T is an infinite sequence The last notation is borrowed from  [1, 2, 14]. Following Schmidt's methodology, we define the semantics of the specification layer of Pantagruel in three steps : first, the semantic algebras are specified, representing the semantic domains of the language; second, the abstract syntax of the language is defined; third, the valuation functions define the meaning of programs, by mapping the abstract syntax to the semantic domains.
Semantic algebras The semantic domains for the specification layer of Pantagruel are listed in Figure  5. They show that the specification layer is mainly understood in terms of environments mapping identifiers of the language to some value. The environments are defined in the usual form of a Map domain as illustrated in Figure  4 , where X stands for the type of the value stored by the environment. For clarity, the Errvalue domain used for ill-typed values has been omitted from Figure  5. Let us examine the domains of the specification layer. m = λ i. inErrvalue() access m : Id → Map → (X + Errvalue) access m = λ i. λ m. m(i) update m : Id → X → Map → Map update m = λ i. λ x. λ m. [i → inX(x)]m Interface abstraction. Interfaces are values from the Interface domain (part III of Figure  5 ).
Definition of the specification layer The abstract syntax and the valuation functions for the specification layer appear in Figures  7  and 8. A specification S consists of a set of interfaces F and an initial set of entities O. Note that, at runtime, these entities can be removed and new entities can be deployed. The S valuation function produces a pair of two environments named Env-interface and Store, corresponding to a mapping from an identifier to an interface, and a mapping from an identifier to an entity, respectively. This valuation function produces the environment of entities of a given Pantagruel program by invoking the F function to produce an environment of interfaces that is passed as an argument to the O function. In doing so, the entities can be checked against the interface that they implement.
A simple reactive computation model Pantagruel is a reactive programming language in that a program constantly interacts with the outside, reacting to context changes that are observed by changes occurring on the sensed data and the attributes provided by entities. A program execution therefore corresponds to an infinite loop. Each iteration is called an orchestration step, where each step consists of executing actions on entities according to some conditions on the sensed data or the attributes of these entities. Each orchestration step produces a new state reflecting the actions performed. To facilitate reasoning about the orchestration steps of a program, we assume : i) Discrete time and atomic execution. Discrete time is modeled as clock ticks. Each tick corresponds to an orchestration step, where all the rules are evaluated within a tick.
Applying the semantics to an example The static semantics analysis of Rule (1) in the program example of Figure  2  is presented in Figures  15  and 16. This example demonstrates that the intended behavior of a Pantagruel program is covered by its semantics. In particular, as illustrated in Figure  16 , the store σ R1 produced by the execution of Rule (1), contains two events, reflecting the execution of the switch action on the l10 and l11 lights, located in room 101, where the m10 motion detector detected an event from σ 1 to σ 2. Most cases constructs for handling Reference elements are skipped in our example, in order to keep the clarity of the illustration. and an initial store σ 0 = l10 → Light , [ room → 101]empty, empty. containing the entities of Figure  1. Moreover, in this example, we assume that a motion was detected from σ 1 to σ 2.
Conclusion and Future Work In this paper, we presented the realisation of a user-oriented domain-specific language, named Pantagruel, aimed to ease the development of entity orchestration applications. The design of Pantagruel is supported by a thorough analysis of the entity orchestration domain, bringing out the domain requirements and the needs of users. In addition, we used the formal methodology for language development proposed by David Schmidt  [20]. It identifies the key concepts in language design and semantics. Throughout the realisation of Pantagruel, we shown how the denotational semantics of our language reflects the domain analysis, expressing the user-oriented concepts of the domain as first class domains of the semantics. Finally, we hope the example of Pantagruel serves as a basis to help and motivate language developers to provide a proper semantic definition of their DSL.
Once the semantics of our language is formally defined, it can be used both to derive implementations (i. e. , interpreters, compilers) and to reason about programs by expressing various program analyses. An interpreter for Pantagruel has been developed in OCaml; it is a straightforward mapping of the formal definition. An implementation of a compiler towards a Java platform has also been developed based on the semantics, and was used for a demonstration of Pantagruel at a conference  [9]. As for future work, we will use the semantics of Pantagruel to perform static program analysis, such as conflict detection when rule execution affects the state of the same entities. To do so, we can leverage Nakata's work on the While reactive language  [18]. Nakata uses the Coq proof assistant to perform property verifications on the While language, based on a denotational-style definition.
Acknowledgment The formal definition of a programming language can be intricate and dense. David Schmidt has made landmark contributions on this topic, providing researchers with a practical methodology to formalize a programming language definition without sacrificing underlying mathematical foundations. His approach makes the design of a language definition systematic, rigorous and tasteful. Resulting definitions are easier to understand by implementers, to use for formal reasoning, and to leverage to introduce nonstandard semantics. This paper is a testimony to the fact that the appealing nature of David Schmidt's methodology is strong across generations of researchers in programming languages.
g. 0. 15 kg DM m -2 ) is left in field. PaSim assumes that a certain amount (e. g. 5 %) of the grass harvest is lost as litter. For grazing, the version of the animal module of PaSim (version 4. 5) developed by  Riedo et al. (2000)  was further improved by  Vuichard et al. (2007a). Riedo et al. (2000)  simulated animal herbage intake, milk production (MP), returns, respiration and CH 4 emissions from pastures grazed by dairy cows or sheep with simplified equations. Vuichard et al. (2007a)  further developed this animal module by including (i) the detrimental effect of trampling on herbage and (ii) cattle selection among shoot compartments when accounting for the grass availability and digestibility (see also  Vuichard, 2005  for detailed equations). In the version of  Vuichard et al. (2007a) , CH 4 emissions are modeled following Pinares-Pati ňo et al.
This process results in an increasing age of the canopy during the growing period. We calculated SLA as: SLA = 4 i =1 sla i × f i , ( 3 ) where f i is the fraction of leaves in age class i , and sla i is the prescribed maximum SLA (SLA max ) for age class i. The value of sla 1 equals to SLA max , then to a fraction of 0. 90, 0. 85 and 0. 80 of SLA max for leaf age class 2, 3 and 4, respectively. In ORCHIDEE-GM, SLA max is set to 0. 048 m 2 g -1 C, a value chosen to fit the mean SLA value of C3 grass in the global TRAIT database (0. 0201 m 2 g -1 DM, equal to 0. 0422 m 2 g -1 C with mean leaf carbon content per dry matter of 47. 61 %;  Kattge et al. , 2011). Figures.
, 2001). For small gaps (e. g. one or two hours), linear interpolation was used; for bigger gaps (e. g. one or two days), data from days with similar pattern are adopted; for gaps longer than 10 days (e. g. in winter at cold sites, the data was gap-filled with data from similar previous year; if necessary, precipitations have been corrected in order to get the correct total annual sum. The long-wave incoming radiation (few measurements are available at the sites) and mean near surface atmospheric pressure (not measured at the sites) are extracted from the 6-hourly CRU-NCEP 0. 5 • × 0. 5 • global database (http://www. cru. uea. ac. uk/cru/data/ncep/) are linear interpolated to half-hourly.
Models set-up Site-level simulations were conducted with ORCHIDEE and ORCHIDEE-GM respectively. All simulations started from an equilibrium state of C pools with climate and management obtained with a model spin-up. To initialize ORCHIDEE and ORCHIDEE-GM we first ran each model without management until all ecosystem C pools reached steady state (spin-up 1); site specific meteorological data is repeatedly cycled to force each model (Table  1 ). Then starting from the end of spin-up 1, ORCHIDEE-GM was run for another 40 yr with the same meteorological data and management practices corresponding to the (idealized) management history of each site (spin-up 2). Finally, starting from the end of spin-up 2, simulations were conducted for the target period of evaluation (Table  1 ).
0201 m 2 g -1 DM (equal to 0. 0422 m 2 g -1 C, with mean leaf carbon content per dry matter of 47. 61 %) reported by  Kattge et al. (2011)  in the TRAIT database for 594 species (5033 observations) around the world. The dynamic SLA modeling accelerates grasses regrowth (higher LAI during growing season in Fig. 2 ), but the effect on LAI remains small (difference of 2. 35 % for annual mean LAI).
Initial soil organic matter All simulations in this study start from modeled steady state then an arbitrate management history (e. g. 40 yr), rather than based on real soil C conditions, since the latter would require more detailed data on initial C pools of different turnover rates, or on site history for the model to simulate the initial value of each carbon pool, compared to what is available. This initialization procedure may cause certain model-data discrepancies. At CH-Oe1 for example, lower TER is simulated in ORCHIDEE-GM than the observation, which probably results from the simulated low soil organic C and low litter input. Before the year 2002, this site was exposed to a ley-arable rotation management with a nitrogen fertilization of 110 kg N ha -1 yr -1. ORCHIDEE-GM simulates a lower soil organic C (12.
The 11 site simulations of this study show that European grasslands generally are C sink (positive NBP). At grazed grasslands, both C export in the form of milk production and CH 4 emissions by animals only consist a minor part of net primary production (NPP), and this means that NBP mainly depends on NPP. On the contrary, the cut sites accumulate less C in soils because a large part of NPP has been exported as forage production. However, it should be noted that our estimation of NBP is biased by the fact that the model initialization of soil C pools is not realistic. Only long term simulation with precise management history or initialization based on precise soil organic C (e. g. the European Soil Database;  Panagos et al. , 2012)  can avoid this uncertainty when running the model on a grid for future applications.
Acknowledgement. This work was made possible through the support of the  CARBOEUROPE-IP  and  Nitroeurope  project to eddy covariance flux sites. Special thanks go to PIs for giving us access to their anxillary and flux data. We also acknowledge the Ph. D. funding by  Commissariat  à l' énergie atomique (CEA) in France. The publication of this article is financed by  CNRS-INSU.
The automatic analysis of retinal blood vessels plays an important role in the computer-aided diagnosis. In this paper, we introduce a probabilistic tracking-based method for automatic vessel segmentation in retinal images. We take into account vessel edge detection on the whole retinal image and handle different vessel structures. During the tracking process, a Bayesian method with maximum a posteriori (MAP) as criterion is used to detect vessel edge points. Experimental evaluations of the tracking algorithm are performed on real retinal images from three publicly available databases: STARE  (Hoover et al. , 2000) , DRIVE (Staal et al. ,  2004), and REVIEW  (Al-Diri et al. , 2008 and  2009). We got high accuracy in vessel segmentation, width measurements, and vessel structure identification.
[24]  developed a recursive tracking technique guided by accurate vessel direction and robust a priori knowledge and termination criteria. Compared to others, this approach could extract automatically most of the vessels with accurate vessel characteristics. Among tracking methods, few probabilistic approaches have been reported in the literature  [32] [33] [34]. The main ideas of a probabilistic tracking method have been presented in our previous work  [35, 36] , which needed some improvements like modeling blood vessels more accurately, handling different vessel configurations, and evaluating it on large database images. In this paper, a novel fully automatic tracking based method using probabilistic formulation is introduced. First, seed points, located inside vessels, are obtained from the image.
Experiments and Discussion The performance of our method was evaluated on three publicly available databases: STARE  [6] , DRIVE  [7] , and REVIEW  [30, 43]. There are three initial parameters in our algorithm: the distance between grid lines in the selection of seed points, the look-ahead distance  (see (  2 )), and the length of the initial linear window  0. In our experiments, the distance between grid lines is fixed to 30 pixels,  is set to 3 pixels, and  0 is set to 10 pixels after many trials. These parameter values can give the best results, including computational time, when testing on the three databases. The STARE database contains 20 retinal images, which are captured by the TopCon TRV-50 fundus camera at a 35 ∘ field of view (FOV). 10 of the images are from healthy ocular fundus and the other 10 are from unhealthy ones.
All the images are segmented manually by two independent specialists. The proposed method is tested with the segmentation of the first observer as ground truth. The DRIVE database contains 40 retinal images which are captured by the Canon CR5 camera at 45 ∘ FOV. The 40 images were divided into a training set and a test set, each of which contains 20 images. They had been manually segmented by three observers trained by an ophthalmologist. The images in the training set were segmented once, while images in the test set were segmented twice, resulting in sets A and B. Our method is tested on the test set using the segmentations of set A as ground truth. The REVIEW database consists of four image sets which include 16 images with 193 vessel segments demonstrating a variety of pathologies and vessel types.
Segmentation Performance. We used STARE and DRIVE databases to evaluate the segmentation performance of the proposed method. In practice, our algorithm is developed in Matlab (version 7. 6. 0. 324) environment. Some functions are programmed using C language in order to save computation time. The average running time of our tracking method on one image is 9. 6 min on STARE and 6. 3 min on DRIVE. Our runtimes are higher than the ones obtained using nontracking vessel segmentation. For example, the processing time of Mendonca's method  [1]  is 3 min for a STARE image, and 2. 5 min for a DRIVE image. Mendonca and Campilho  [1]  used a pixel-based global approach and also implemented their algorithm using Matlab. In order to assess the proposed method and compare it with the other stateof-art methods, we use three widely known performance measures: the detection accuracy, sensitivity, and specificity.
The accuracy is defined as the ratio of the total number of correctly classified pixels to the number of pixels in the FOV (field of view). The sensitivity is defined as the ratio of the number of correctly classified vessel pixels to the number of total vessel pixels in the ground truth. The specificity is defined as the ratio of the number of correctly classified nonvessel pixels to the number of total nonvessel pixels inside FOV in the ground truth. First, we discuss the segmentation performance of the proposed method on 20 retinal images from the STARE database. For example, we discuss the test result of our method on a retinal image (im0077) from the STARE database as shown in Figure  11(a). The segmentation result of the proposed method and the ground truth are shown in Figures  11(b ) and 11(c), respectively.