dataesr/scientific-paragraphs-categorization huggingface dataset:
The bioenergy crop simulations in ORCHIDEE-MICT-BIOENERGY generally reproduced the observation-based biomass yields for bioenergy crops at global level. However, it is still difficult to match observations site-by-site due to the uncertainties in the observation dataset and the lack of explicit managements in the model. Evaluations on soil carbon dynamics and biophysical variables are further needed. Our work improves the performance of ORCHIDEE on bioenergy crops modelling, and the parameters used in ORCHIDEE-MICT-BIOENERGY also provide guidance for other vegetation models on incorporating dedicated bioenergy crops.
on the 1:1 line, because of uncertainties in the observation dataset, e. g. treatments, genotypes, and local fertilization or irrigation practices as well as in soil characteristics and climate forcing variations prescribed in the model. The error bars of modelled yield (y-axis) come from the range of different harvest years and represents inter annual variability. The error bars of the observations (x-axis) represent the range from different sites, crop species, genotypes and treatments as well as the observation number in each grid cell. It is difficult to systematically synthesize all these factors to give an optimal observed yield in each grid cell. First, different species and genotypes are impossible to be accounted for in a global vegetation model, and thus a further classification of such information would not help the model evaluation.
Acknowledgements We acknowledge Vcmax and Jmax data compiled by Wullschleger (1993) and in the  Biofuel Ecophysiological Traits and Yields Database (BETYdb)  (LeBauer et al. , 2010) and the related references used in the their datasets are also included in Table S1 (part of the 26 publications). W. L. and C. Y. was supported by the  European Commission -funded project  LUC4C  (grant No. 603542 ). W. L. , C. Y. , D. G. and P. C. acknowledge the  European Research Council  through Synergy grant  ERC-2013-SyG-610028  " IMBALANCE-P ".
Trying to overcome these challenges is one of the main objectives of the GAMA (GIS Agent-based Modeling Architecture) platform. GAMA has been developed since 2007 as an open-source project, undergoing several improvements over the years in order to answer the needs of its growing user base: dealing with more and more data formats, improving its ergonomics, efficiency and stability. However, GAMA also aims at going further and providing new ways to create or simulate models. Its latest version, GAMA 1. 8, has brought in many improvements: its modeling language has been enriched with new data types, new supported data format and new agent architectures. Powerful in-house simulation capabilities have been integrated (side-by-side execution of simulations with different parameter sets, multi-threaded execution of agents within simulations, etc.
). In addition, its general user-interface has gained in flexibility and efficiency (editor, navigator, data viewers, etc. ). This article aims at presenting these enhancements individually but also in their general logic, as GAMA is evolving from a pure "agent-based" modeling platform to an "agentoriented" generic modeling and simulation platform, where the coupling of heterogeneous data and modeling paradigms is now the rule rather than the exception. It is structured as follows. Section 2 presents the state of the art of modeling platforms and highlights the specificities of GAMA. Section 3 presents GAMA 1. 8, and more particularly its modeling language, its capacity to manage the spatial dimension, and its new advanced features. In Section 4, the way real modeling projects make use of GAMA is detailed.
More specifically, GAMA, which is based on the Eclipse IDE, takes advantage of this IDE to offer to modelers numerous tools to manage models and simulations: flexible user interface including the possibility to arrange the different panels of GAMA using drag and drop or predefined layouts, powerful agent inspectors allowing to get information about one or several agents (tabular view), powerful search engine to get information and examples of uses of operators. As GAMA models are often centered around data, GAMA provides modelers with viewers for common files (CSV, shapefile, OSM file, ASC, Geotiff. ). The idea is to allow modelers to view the data they manipulate and the meta-data that are the most useful for their modeling task. As an example, the shapefile viewer allows the modeler to view the various geometries, but also each attribute name, the size of the bounding box or the projection.
The GAML modeling language One of the strengths of GAMA is its ease of use, thanks to its modeling language called GAML (GAma Modeling Language). GAML is an agent-oriented language, which means that everything "active" (entities of a model, simulations, experiments…) can be represented in GAML as an agent, and is thus a computational component owning its own data and executing its own behavior, alone or in interaction with other agents. The language takes its roots in object-oriented languages like Java or Smalltalk, but extends the object-oriented programming approach with powerful agent concepts (like skills, declarative definitions or agent migration) to allow a better expressiveness in models. It is close to the Netlogo's agent-based modeling language, but it enriches the traditional representation of agents with modern computing notions like inheritance, type safety or multi-level agency.
Spatial component of models The interests of coupling GIS and ABM have been identified by many works (see for example  [23] ). However, most of existing agent-based platforms still propose a weak integration of GIS data in simulations, in particular the ones that are usable even by non-computer scientists. GAMA was developed from the beginning to overcome this limitation. Indeed, contrary to other agent-based modeling platforms such as CORMAS or Netlogo, GAMA allows to naturally integrate GIS vector and raster data. In addition, it allows to manage several representations of the same environment with different spatial organizations (for example grid and graph). In GAMA, all models are provided with a continuous 3D environment. This environment will be nested with two main types of species: classic species that will have no specific spatial organization, and grid species, in which agents will represent cells organized as a grid.
g. building of a graph from a set of polylines). An important feature of GAMA is that, like in a GIS, all agents are spatialized, i. e. are provided with a georeferenced geometry. This geometry, which is based on a vector representation and is by default a point, can be simple (point, polyline or polygon) or complex (composed of several sub-geometries). The geometry of the agents can be directly defined by the modeler (by using a list of points or predefined graphical primitives) or loaded from geographical data (databases, shapefile, OSM, GML. ). Indeed, GAMA allows to use geographical data to create agents, each object of the geographical data will be automatically used to instantiate an agent, GAMA taking care of managing the coordinate reference system of the data (projecting the data to the coordinate reference system chosen by the modeler) and, if necessary, of reading the values of the attributes.
Risk mitigation Risk mitigation is an important topic, in particular for urban areas and many projects chose to tackle this issue with agent-based modeling and simulation using GAMA. Among these projects, some use the capabilities of GAMA concerning the development of serious games in which participants interact with a rich and credible model. For example, Sprite  [61]  allows a participant to play the role of the mayor of the Oleron island in France. The goal of the participant is to find an appropriate balance between popularity, economy, attractiveness, ecology and safety, in particular concerning the submersion risk. Sprite proposes a precise representation of the island through GIS data and integrates an advanced submersion model. In addition, it benefits from the capacity of GAMA regarding user interaction with the simulation in runtime.
This model is a good illustration of the capacity of GAMA for dealing with complex models (composed of more than 20 sub-models, several gigabytes of data. ). It also takes advantage of GAMA built-in capabilities in terms of multi-criteria decision making process. Another example is the PASHAMAMA model  [18]  that aims at evaluating the combined and retroactive effects of colonization of the northern part of "El Oriente", the Amazonian region of Ecuador, from the 70's following the oil exploitation of the area and the oil pollution hazards on the population. The model also proposes scenario based exploration in order to simulate the actual and possible future situations to assist stakeholder decision making process. Once again, this model serves as an example for GIS data importation in GAMA, but also uses Digital Elevation Model data to provide a better simulation of the water flow dynamics.
This plugin will allow to generate a synthetic population from data (census, sample of the population, GIS data…) through simple GAML operators. A last feature that is already tested internally (i. e. not available to the general public so far) concerns the possibility to run GAMA "in the cloud". As a matter of fact, nowadays, in order to run even a simple model, a user has to download a "complete" version of GAMA adapted to its working environment, to install it (with a correct Java virtual machine) and to maintain it over time (by downloading updates or new versions, especially when Java virtual machines or operating systems are updated). Even for experienced users, this can prove a source of difficulty. Not to mention the fact that, with the independent development of new GAMA plug-ins, some models may require additional installation steps.
Our proposed solution relies on EduProgression ontology  (Rocha et al. , 2016)  which is modelling the official common base of knowledge and skills, and which we extended to meet the specific needs of the Educlever solution. Starting from the technical solution originally adopted by Educlever, mainly based on a relational database of educational resources and a graph database of educational concepts and skills indexing these resources, we developed an alternative Semantic Web based solution with (1) an ontology of educational concepts and skills, (2) a repository of semantic annotations of pedagogical resources, and (3) a base of queries on this repository implementing the functionalities offered by the existing solution and additional ones. We show the feasibility of our solution in a real industrial context by implementing it within four off-the-shelf triplestores: Allegrograph, Corese, GraphDB and Virtuoso.
g. relational data) but adapted to store RDF data. Among native RDF triplestore, we distinguished between in-memory triplestores and triplestores with persistent storage. As a result, we chose the four following triplestores: Corese is an in-memory triplestore; it loads all the ontologies and RDF data when starting the application and saves it in an RDF file when exiting it. Allegrograph and GraphDB (OWLIM) both are native RDF triplestores with persistent storage capabilities. Finally, Virtuoso is a non native RDF triplestore. As detailed latter in the paper, for the benchmarking of these triplestores we translated the Educlever dataset into RDF, relying on a dedicated ontology and we considered the Educlever requirements and we implemented them with SPARQL. In the next section we present our Semantic Web based modeling of the Educlever data and needs.
Ontology based Modelling of Skills, Knowledge and Pedagogical Resources In this section, we propose an ontology-based model to represent knowledge and skills referential and also pedagogical resources. Beforehand, the Educlever solution relied on relational and graph databases to store them and had limitations to integrate heterogeneous data without losing information and to infer new information from it. The ontologybased model of skills, knowledge and pedagogical resources presented in the following has been setup in the Educlever software infrastructure. Our solution relies on two linked datasets. The first one is called Referential, it describes and contains all the elements of knowledge and skill available through the e-Education solution, Educlever for our case study. The main concept is Cocon, which stands for "COmpétences et CONnaissances" in French (skills and knowledge).
Knowledge and Skills Modelling The concept of Cocon is the keystone of the Referential modelling. It represents an atomic element of knowledge or skill learnt by students on the e-Education solution. An example of Cocon is the multiplication of two integers identified with URI educlever:MultiplyTwoIntegers 4  in the Educlever system. We formalize this concept as a class equivalent to EKS from the ontology Eduprogression, thus integrating public standards description. Figure  2a  presents the Educlever Referential ontology. Each Cocon can be described by indicating its learning domain(s), course and cycle using respectively properties hasLearningDomain, hasCourse and hasCycle defined on class EKS in ontology Eduprogression. For instance, the learning domain of the multiplication of two integers is the first domain of French education standards, languages for thinking and communicate, its course is Mathematics and its cycle is the second cycle.
The uses of the Referential ontology in the Educlever platform are twofold: (1) It enables to describe the knowledge and skills developed by the company for learners and to link them to the standard published by the French education ministry. (2) It is used in combination with the ontology of pedagogical resources described in the following, to evaluate the acquisition of elements of knowledge or skill by learners and to recommend them relevant pedagogical resources. Moreover, by relying on semantic Web models and technologies we can reuse, extend and align with existing vocabularies to increase interoperability. The adopted solution is compliant with linked data Web architecture and principles such as derefenceable URIs. There are two key properties: Property worksOn enables to link an instance of OPD and an instance of Cocon from the Referential ontology, representing an element of knowledge or skill tackled in the pedagogical resource.
Semantic Web based Architecture for e-Educational System In this section we propose a Semantic Web based architecture, relying on triplestores, to manage the above described ontology-based modelling of skills, knowledge and pedagogical resources. We use this architecture to upgrade the existing software architecture of the Educlever solution. We first briefly describe the initial industrial architecture before explaining the proposed evolution. The first version of the Educlever system was built on top of a relational database storing the pedagogical resources. Two tables were used: the first one storing OPD's attributes like status, title, author and type; the second one storing the course and cycle of each OPD and the partonomic relations between them. Based on this relational database, the three main functionalities implemented are: (i) find OPDs relative to a particular course and/or cycle, (ii) find OPDs contained in a given OPD and (iii) find OPDs by combining the two previous criteria.
The tree structure storing the partonomy of OPDs is also useful for interactive exploration of the dataset of pedagogical objects by users through a dedicated web interface. A second version of the Educlever platform was built to enable the implementation of new functionalities exploiting Cocons, to support the construction of learning paths and the evaluation of learners, e. g. the computation of the accessiblility of a Cocon by a learner, based on the evaluation of the acquisition of prerequisite Cocon, or the computation of the degree of understanding of a Cocon by a learner. To represent property chains on Cocons a relational database was not efficient, obliging to perform joins between table Cocon and itself. Then, Educlever upgraded its platform by adding a graph database (OrientDB) to represent the relations between Cocons.
Based on this graph database, the two main functionalities implemented are: (i) find all the prerequisites of a given Cocon and, recursively, the prerequisites of prerequisites, (ii) find all narrower Cocons of all direct prerequisites of a given Cocon. The overall architecture of the Educlever solution is depicted in Figure  3. What this description of a real industrial system also stresses is that there is a need for approaches taking into account the existence of legacy information systems and their integration, extension and evolution.
e-Education System Architecture based on Semantic Web Technologies We propose two architectures based on Semantic Web technologies to design an e-Education system. They are built on top of triple stores to store and process RDF data from the Referential and Corpus datasets: after mapping the Educlever relational and graph databases into RDF datasets, we chose to materialize the RDF data (and not only offer a virtual access to it). Our aim is to provide a basis for future versions of the Educlever solution natively based on semantic Web models and technologies. In the simple architecture we used a triplestore to store both Referential and Corpus datasets into a single graph. As depicted in Figure  4a , the Educlever solution relies on a SPARQL endpoint Web service queried with HTTP requests.
Cocon exploration Cocon & OPD Instances  In the current solution, the Educlever data relative to Cocons and OPDs are separated in two databases. This decision was motivated by the fact that these two databases can support different functionalities and are used in different processes. The graph database on Cocons is used for learning path design and Cocon evaluation while the relational database on OPDs is used for OPD creation by the pedagogical team and for learners training, learning and evaluation. So, a failure of one database does not affect the processes exploiting the other one which can continue their execution. With this architecture, the impact of a failure in exploitation is limited on one database. In order to add this flexibility in a semantic Web based architecture, we proposed a federated architecture relying on a SPARQL federated Endpoint.
Evaluation of the Semantic Web Integration Efficiency We led some experiments to evaluate the two proposed e-Education system architectures based on Semantic Web technologies. For this evaluation we implemented real use cases from the Educlever company, with its real data stored in the Referential and Corpus datasets. Here we report the results of (i) a qualitative evaluation of the proposed semantic Web based solution consisting in comparing the number of use cases that can be implemented within this solu-tion to the number of them that are implemented in the current Educlever solution (section 5. 1); and (ii) a quantitative evaluation of the proposed solution, focusing on the execution cost time of the queries implementing the use cases (section 5. 2).
Qualitative Evaluation: Implementability of the Use Cases 1. Find all direct prerequisites of a given Cocon c: this is used to check whether a learner is ready to work on c or if he needs to work on some prerequisites before. 2. Find all direct narrower cocons of a given Cocon c: this is mainly used for the exploration of the Referential dataset, starting with high level Cocons and iteratively going down by following the broader/narrower relations. 3. Find all the Cocons such that a given Cocon c is in their prerequisites: this is used to identify the candidate Cocons for the next learning step after working on Cocon c. and of its direct narrower cocons: this is used to score all these Cocons when a learner has successfully validated c. 5. Find all prerequisites of all the Cocons which are understanding levers of a Cocon c i which is a complexification of a given Cocon c: this is used to find alternative (longer) learning paths to learn a Cocon c which seems to be complex.
Infer implicit prerequisite paths between two Cocons c 1 and c 2 : find the simplest Cocons associated to more complex Cocons in the path. As Table  1  shows it, the semantic Web based proposed solutions implement all of the use cases while the current version of the Educlever solution implements only eight of them. The functionalities which are difficult or impossible to be implemented in the current solution are those requiring to jointly exploit the two databases, and those requiring a recursive traversal of the graph base. These can seamlessly be implemented with semantic Web models.
Quantitative Evaluation: Analysis of the Query Execution Times For the evaluation of the execution times of the queries implementing the use cases, we performed a two-step benchmarking. First, we evaluated and compared the proposed solution deployed in a local environment. Second we evaluated it when deployed in the Educlever industrial environment. We compared the execution times with those of the current version of the Educlever solution based on a relational database and a graph database. For the deployment of the semantic Web based solution, we compared the performances of four triplestores. In the following, we describe the experimental environment, protocol and results.
Experimental Environment and Protocol Hardware : In the first step of our benchmarking, we used a MacBook Pro with processor 3,3 GHz Intel Core i7, 16 GB for RAM and 1 To for hard disc. We used VirtualBox through Docker virtualization. We used only one Docker container at a time. In the second step, used a virtual Linux server host on a remote machine. The remote VMWare virtual machine has a processor AMD Opteron 3. 1 GHz, 6 GB of RAM and 85 GB for hard disc. DataSet : We used the exploitation data of Educlever for the experiments. Table  2  summarizes the characteristics of the datasets Corpus and Referential: the number of triples and the number of instances of Cocon Referential and of OPD in Corpus. Let us note that the size of Corpus is much greater than that of Referential, therefore the execution times of queries on Corpus may be higher than that of queries on Referential.
Triplestores : We tested four triplestores: (i) Allegrograph (alleg-cent), (ii) Corese (corese-cent), (iii) GraphDB (graphdb) and (iv) Virtuoso (virt) where we stored together the Referential and Corpus datasets, as described in the first proposed architecture 4a. We also setup two SPARQL Federated Endpoints with Allegrograph (alleg-fed) and Corese (corese-fed) storing Referential and Corpus datasets separately as proposed in the second proposed architecture 4b. The Allegrograph SPARQL Federated Endpoint uses two SPARQL Endpoints, each built with an Allegrograph repository. Similarly, the Corese SPARQL Federated Endpoint uses a Corese server for each SPARQL Endpoint. We compared the execution times of the SPARQL queries implementing the Educlever use cases with the execution times of the queries or codes in the current Educlever Information System described in 3 (educ-v2).
Results Use cases on dataset Referential. Figure  5  shows the query execution times of SPARQL queries on Referential for the four chosen triplestores deployed in a local context. First, we can observe that query execution time of first execution is greater than the average time and the median time. This is due to the use of cache memory for this execution. For the specific case of Q 1 , its execution time is very important (2s for graphdb) because it is the first query of the benchmark and cache is not efficient yet. The chart also shows that graphdb and virt got the best query execution times, and that the execution times of allegfed are better than those of alleg-cent, This is because only one dataset (Referential) is queried with alleg-fed while both datasets are stored together and queried with alleg-cent.