dataesr/scientific-paragraphs-categorization huggingface dataset:
This effect is commonly found in tonal languages around the world, such as in the Bantu languages  (Downing 2010: p. 411 ). Lastly, the relevance of the variable SuffixChi pertains to the particular features of the suffix -chi ́, the use of which leads to infrequent but allowed tonal patterns such as HHH and HLH sequences. In addition to the identification of relevant variables, the performance of the two models implemented matched our expectations: they accurately predicted the tonal patterns of regular roots, and accurately filled parts of the verb paradigms absent from the database. The accurate predictions suggest that the qualitative analysis proposed is robust, as it systematically accounts for the majority of the data, and confidently predicts the surface tonal pattern of forms not attested in the corpus.
As an example, the decision tree has been used to fill parts of the verb paradigms that are less likely to be found in corpora given the preference for morphologically simple forms in discourse (verbs rarely show more than two suffixes), and the relative low frequency of some suffix combinations. For instance, although the verb /takha' HL / 'die' is relatively frequent in the corpus of narratives, it is found in only eight different forms out of the (at least) 30 possible combinations in the verbal paradigm. Thus, the decision tree created during the analysis was used to generate the less commonly used forms missing from the database (Table  11 ). These predictions were then tested based on the qualitative phonological analysis and on the intuition of native speakers. So far, the predictions of the tree match with both the qualitative phonological analysis and the intuition of the native speakers, suggesting that the rules detected by our machine learning approaches might have linguistic reality.
Quantitative methods inspired from modern statistics, data science and machine learning (among others), are increasingly being applied to issues in the language sciences ranging from the genealogical relationships between languages (e. g. , phylogenetic inferences of language families,  Dunn et al. 2011)  to the understanding of patterns of linguistic diversity and universals (e. g. ,  Blasi et al. 2019). In this particular case, we chose to focus on the tone system of Yukuna for two main reasons: First, we have access to a rich database of exemplars and first-hand experience in the description of the language. Second, Yukuna's tone system is simple enough (but not too simple) and well-understood enough for hypotheses to be generated and tested, and for probable influences to be identified.
Acknowledgements We address our deepest thanks to all the Yukuna, Matapi and Tanimuka collaborators who participated in the Yukuna documentation and description project led by the first author. We also thank our  Dynamique du Langage  colleagues who provided insightful comments on the phonology of Yukuna, in particular,  Prof. Denis Creissels ,  Prof. Gérard Philippson ,  Dr. Denis Bertet , and  Dr. Françoise Rose. Lastly , we thank the reviewers for their constructive remarks. All remaining errors are our own.
Funding information This project was funded by a  LabEx Aslan doctoral  grant " A grammar of Yukuna, an Arawak language of Colombian Amazonia " ( 2016-2019 ) to the first author. The second and the third authors are thankful for the support of grants from the  Université de Lyon  ( ANR-10-LABX-0081 ,  NSCO ED 476 ), the  IDEXLYON  Fellowship ( 2018-2021 ,  16-IDEX-0005 ), and the  French National Research Agency  ( ANR-11-IDEX-0007 ).
Semantic Web applications integrating very different software and data sources have to face the heterogeneity of the quality and compliance to standards exhibited by each involved resource. In this paper we propose a uniform way of adapting and customizing the behavior of both the client and the server components of an HTTP exchange to cope with this diversity. We revisit the classical SERVICE clause in SPARQL federated queries in order to parameterize the behavior of both the SPARQL client and the SPARQL service. We propose mechanisms to identify and specify SPARQL federated query services and extended SPARQL-based services.
Our proposal is motivated by the fact that, although the W3C standards provide an excellent common ground for interoperability, in practice applications integrating very different software and data sources have to face the heterogeneity of the quality and compliance to standards exhibited by each involved resource. One application of great interest is to cope with heterogeneity in the context of federated querying. In particular, in real-world scenarios, a SPARQL query processor evaluating a federated query must be able, on one side, to parameterize the remote SPARQL services' behaviors (for which it is the client) according to their capabilities and specificity, and, on the other side, to adapt its own behavior to the limitations and characteristics of these remote services. Nowadays, many national or international projects are facing such a situation, in particular any project targeting scientific data integration will have to address this heterogeneity, for example: the German DFG project FAIR Data Infrastructure for Condensed-Matter Physics and the Chemical Physics of Solids (FAIRmat 1  ) aiming to integrate and make accessible and reusable the enormous amount of data on materials (basic and applied science and engineering) produced in recent years; the French ANR project Data to Knowledge in Agronomy and Biodiversity (D2KAB 2  ) aiming to create a framework to turn agronomy and biodiversity data into an integrated, interoperable and open knowledge graph; the European ERIC project Analysis and Experimentation on Ecosystems (AnaEE 3  ) aiming to integrate all the steps of the scientific experimental methods, modelling and experimentation in order to understand the impact of change drivers on terrestrial and aquatic continental ecosystems across Europe; etc.
A common challenge in the development of such research infrastructures (RI) is to provide a unique entry point to the databases provided by the project partners; these are most of the time hugely heterogeneous, not only regarding the data they store and their schemas, but also regarding the servers chosen to store and serve them and the practices adopted by the research teams in charge of configuring them and managing their creation and maintenance. Thus, the main research question of this article is: do URI parameters provide an effective way to improve and extend SPARQL-based interaction between Web clients and services? It entails two specific subquestions : can URI parameters allow SPARQL-based interactions that could not be done before? and can URI parameters make existing SPARQL-based interactions more efficient in time, space, etc.
RELATED WORK Nowadays, there are many SPARQL endpoints and most of them suffer from partial coverage of the SPARQL query language together with a lack of availability for a great majority of them, as reported by  (Buil-Aranda et al. , 2013). In addition, one recurring problem when dealing with SPARQL endpoints is the limitation of the server's resources allocated to each individual query, often leading to timeouts, errors if the queries were too complex, or even incomplete results. To circumvent these limitations some efforts have been made to set up alternative solutions to the "traditional" SPARQL endpoints such as the SaGe initiative by Minier et al. which relies on Web preemption  (Minier et al. , 2019). Others like C. Buil-Aranda et al. (Buil-Aranda et al. , 2014)  propose to split the query into pieces so as to respect the various quotas of the distant SPARQL server.
Another approach tackles the challenge the other way around by providing specific interfaces, named Linked Data Fragments  (Hartig et al. , 2017)  to access the datasets which can then be chosen by users depending on their needs. For example, in the Triple Pattern Fragments approach  (Verborgh et al. , 2016) , the server only evaluates triple patterns. However, these fragment approaches generate a large number of subqueries and substantial data transfer. Unfortunately, all these methods are applied after reaching these limitations. We aim at preventing these situations. We propose to consider that a wide set of URI parameters -to tune the server's behavior-could prevent these issues by providing SPARQL practitioners with the useful tools. Moreover, we also introduce URI parameters to be interpreted by the client too; which is, to the best of our knowledge, unprece-dented.
1 standard anymore, at the time of writing of this article, in June 2021. Other solutions like RDF4J 10  (Broekstra et al. , 2002) , Virtuoso 11  (Erling and Mikhailov, 2010) , Anzo 12 or also BlazeGraph 13 extend the set of possible parameters. For example, RDF4J allows the practitioner to add timeout or limit; with explain, BlazeGraph enables a mode where the query results are extended with explanations of the query plan. When compared to these approaches, we notice that, while these SPARQL endpoint implementations support parameters, they remain specific to the server side and in particular the idea of using them in the context of SPARQL SERVICE clauses is not widespread yet. Alternatively to using the SERVICE keyword to access additional endpoints, one may use federated SPARQL services which provide a unified access interface to a set of autonomous data sources.
), the idea of using them in the context of SPARQL SERVICE clauses is not widespread yet. In this section, we first want to establish the interest of these parameters in the context of a SERVICE clause and then propose several new parameters for SPARQL query and update operations. The default-graph-uri and the named-graph-uri parameters provide an immediate and standard example as they are defined in the SPARQL 1. 1 Protocol to specify the dataset to be used by a SPARQL service in solving a query. In the context of a SERVICE clause, this ability addresses an important limitation of the SPARQL query language that does not support the declarative specification of the dataset for such a clause: FROM and FROM NAMED are not supported at the SERVICE clause level in SPARQL. Although this usage is neither documented in the standards nor widespread in online documentation, it is a perfect example from the standards of the impact of being able to parameterize the behavior of the invoked SPARQL service directly through the URL query string.
The URLs of this first implementation continue to use the /sparql that appears in the URL of standard SPARQL services to suggest that they do not change the query itself. The second implementation is what is commonly referred to as a "federation engine". It starts by asking remote SPARQL services which properties and classes occur in their datasets and builds an index from the results. Then, using this index, it rewrites the SPARQL query it received with SERVICE clauses. Each clause is targeting a SPARQL service that, according to the index, may contain results for the triple patterns it specifies. To distinguish this second implementation from the first one, the endpoint URL is minted with /federate in its name: http :// e. g/X/federate federate federate ? query = select * where {? x ?p ?y} Similarly to what we demonstrated in Section 4, like for any SPARQL service, we can tune the behavior of such a named SPARQL federated query service by adding query string parameters to its URL: The mode=provenance parameter enables to track the provenance of each result.
Binding variables: FILTER / VALUES The following query searches the URIs of some spatial entities in a local dataset, and tries to fetch additional information about each of them from Wikidata using a SERVICE clause. SELECT ?e ? label WHERE { [] dct : spatial ?e. SERVICE < https :// query. wikidata. org / sparql > { ?e rdfs : label ? label. FILTER ( lang (? label ) = " en ") }} When a SPARQL engine evaluates this query, a possible strategy is to first retrieve the values of variable e (91 distinct values in our case), then pass them to the SERVICE clause as variable bindings. The SPARQL federated query recommendation does not specify the way to pass such bindings. A possible way is to pass them using a filter, i. e. the following query is submitted to Wikidata: SELECT * WHERE { ?e rdfs : label ? label.
The URL of the second SERVICE clause is as follows: < http :// e2. g/ sparql ?binding binding binding = values &binding_slice binding_slice binding_slice =1 > The whole query processing completed in approximately 21 minutes, which is roughly half of the time it took to process the query without the binding slice. The improvement may be deemed modest. It is however important to remind that with a public SPARQL endpoint, where the time quota is typically in the order of one minute, the initial query would never complete, whereas, with our method, it will take time but will complete eventually. Without the URL query string parameters introduced in this paper and demonstrated in this section, it is hardly possible to obtain the results solely within SPARQL. Instead, the SPARQL practitioner would have to code a hack in another language to circumvent the limitations.
As a comparison, we developed a Python application to achieve the same goal. Based on the SPARQLWrapper library, the program evaluates the first SERVICE clause, stores the temporary results in a DataFrame, and submits the second SERVICE clause one value at a time. This does exactly the same that what we achieve declaratively with just one parameter: binding slice. While the SPARQL query is 10 lines long, the Python program is approximately 100 lines long. Besides, both solutions complete in a similar time since they submit the same number of queries. Ultimately, this example also shows that beyond the federated querying use cases we used to demonstrate the interest of URL parameters in SPARQL, this technique is also a way to provide customized proxies masking the limitations and specificities of SPARQL service implementations and supporting the loose-coupling that make the Web an attractive application integration platform  (Fielding et al.
This work has been funded by the  European Research Council  under the  European Unions ERC  Grant Agreement number  339025   GUDHI (Algorithmic Foundations of Geometric Understanding in Higher Dimensions ). This work has also been supported by the  French government , through the  3IA Côte d'Azur Investments in the Future  project managed by the  National Research Agency (ANR)  with the reference number  ANR-19-P3IA-0002. Mathijs Wintraecken also received funding from the  European Union 's  Horizon 2020 research and innovation programme  under the  Marie Sk lodowska-Curie  grant agreement No. 754411. J. -D. Boissonnat  ,  INRIA Sophia-Antipolis Tel.
This paper addresses these limitations and thereby proposes a novel generic testing approach for xDSLs. This approach uses TDL as a testing language and relies on three main contributions. First, we provide a model transformation to automatically generate a TDL library-i. e. all the TDL boilerplate code that the domain expert would otherwise write by hand-from the definition of an xDSL. Such generated TDL library can be used by the domain expert to write test cases for models conforming to the considered xDSL. This transformation relies on a mapping between the concepts of the Ecore metamodeling language  (Steinberg et al. 2008 ) and the concepts of TDL. Second, we provide an operational semantics for TDL, adapted to the testing of executable models. To be compatible with a wide range of diverse xDSLs, this operational semantics for TDL is not coupled to any specific xDSL, nor to any specific metaprogramming approach used to define the considered xDSL.
Third, the approach provides two different methods to interrogate the state of the runtime model: one relying on model comparison and the second relying on an OCL interpreter. This enables the definition of oracles for executable models in TDL test cases. We implemented the presented approach for the GEMOC Studio, a language and modeling workbench for xDSLs  (Bousse et al. 2016). We conducted an evaluation to assess the genericity aspect of our proposed approach considering the diversity of xD-SLs. More precisely, we aimed to answer the following research questions: RQ#1 Does the approach provide testing facilities for xDSLs in which their abstract syntax is designed for different domains? RQ#2 Does the approach provide testing facilities for xDSLs in which their operational semantics is implemented using different metaprogramming approaches? To this end, we applied the approach on five xDSLs covering various domains and implemented with different metaprogramming approaches.
Executable DSLs (xDSLs) In the present paper, we focus on executable DSLs (xDSLs), which are composed of two main parts: an abstract syntax 1  and an operational semantics. The abstract syntax defines the domain concepts while the operational semantics (i. e. the interpreter) specifies how the runtime state of a conforming model under execution varies over time. More specifically, we consider the abstract syntax of an xDSL to be defined as a metamodel using the Ecore metamodeling language  (Steinberg et al. 2008). A metamodel is commonly made of a set of metaclasses, each containing a set of features. A feature can be either an attribute typed by a primitive type or a reference to another metaclass. The operational semantics of an xDSL is composed of two parts: the definition of what are the possible runtime states of a model under execution and the set of execution rules that define how such a runtime state changes over time.
Description of the Generator Logic The output of the generator is a TDL library providing a set of TDL elements for the tester. The first set of generated TDL elements are the required data types for the definition of test data. These data types are provided through a model transformation which uses the Ecore metamodel of the xDSL as input and produces a set of xDSL-specific TDL data types as output. The second set of generated TDL elements are necessary to enable the TDL test cases to request the execution of the model under test, to write OCL queries in the TDL test cases, and to configure the TDL test cases for their execution. These elements are provided by a code generator which only requires the name of the xDSL as input.
Description of the Generated TDL Library Given an xDSL, three TDL packages are produced by the generator: the xDSL-Specific Types package, the common package, and the Test Configuration package. xDSL-Specific Types Package As discussed in Section 2. 2, to use TDL for a specific domain, all data types required for the specification of test data have to be provided to the tester. Yet, in the context of testing executable models, we can observe that these data types are in fact already defined as part of the definition of the considered xDSL, both in the abstract syntax and in the definition of the possible runtime states in the operational semantics. It is therefore possible to infer the required TDL data types from this information. As explained in Section 2. 1, we consider that the Ecore metamodel of the xDSL includes both the abstract syntax and the definition of the possible runtime states of conforming executed models.
To distinguish abstract classes from concrete ones and dynamic features from static ones, annotations are generated and assigned to the corresponding element. An inheritance relationship between two classes is transformed into an extension relationship in TDL. The transformation generates simple TDL data types for Ecore primitive data types and enums, and enum literals are transformed to the instances of the TDL data type corresponding to their related enum. Finally, an Ecore package is transformed to a TDL package that is the root container of all the generated TDL elements. We used the ATL language  (Jouault et al. 2006 ) to define the transformation rules. An excerpt of this transformation is shown in Listing 3, with the ATL code for transforming a concrete Ecore class containing features and superclasses, to a TDL structured data type containing members and an extension to the last super class.
This rule has several calls to other transformation rules that are not shown here (the source code of the complete ATL transformation is available here). Listing 4 presents the TDL DataTypes generated from the Ecore metamodel of the xFSM DSL (part a of Figure  1 ). The abstract Annotation element (line 2) is for specifying  model (line 8), resetModel for resetting its state to the default (line 9), and getModelState for getting its current state, i. e. , the content of its dynamic features (line 10). To enable the tester to use OCL queries in the test cases, this package provides a data type named OCL (line 12) and an instantiation of it (line 13). This instantiation uses the question mark TDL symbol (?) for the query attribute, which means that a value must be given to this attribute when the oclQuery instance is used.
Using the TDL Library to write Test Cases Listing 7 presents two test cases for the bit shifting FSM model (previously shown in Figure  3 ). The first test case (lines 10-21) is a more complete and executable version of the example test case previously introduced in Listing 2. Contrary to Listing 2, all the required data types and test configurations for writing test cases are provided by the generated TDL library and are obtained by import declarations. Using the data types provided by the fsmSpecificTypes package (line 3), the domain expert can define runtime states for the bit shifting FSM by instantiating the StateMachine type (stateMachineNewState in lines 6-7) and setting its dynamic features in the test case description (line 12 as test input data and line 19 as expected output). In the first test case, the tester component first sends the test input data-that is the bit shifting FSM in a runtime state where its unprocessedString is set as "10010110" (line 12)to the tested model, i.
e. , the bit shifting FSM. By using the model execution commands provided by the commonPackage (line 2), the tester component then requests a run of the model (lines 14-15), and also gets the current runtime state of the model (lines 16-17) to be asserted against the expected output data-the bit shifting FSM in a new runtime state where its producedString is "01001011" (line 19). In the second test case, we use OCL queries to check the value of specific dynamic features using the elements provided by the commonPackage (line 2). After sending the test input data (lines 23-25), and requesting for running the bit shifting FSM in the specified runtime state (lines 26-27), the tester component sends an OCL query (line 29) through the OCL gates to get the value of the currentState of the bit shifting FSM after its execution (lines 28-30).
In Section 4, the TDL Library Generator, takes these concerns into account by generating specific data types (ModelExecutionCommand and OCL in the common package) along with gate types that accepting data conforming to them (genericGate and oclGate in the testConfiguration package). Accordingly, our operational semantics must be able to interpret such generated elements. This will be presented in the next subsection. In addition, to specify the result of a test case execution, we support the verdicts provided by the TDL metamodel document, including PASS, FAIL, and INCONCLUSIVE (ETSI ES 203 119-1 2020). PASS and FAIL correspond to observing valid and invalid behaviors of the SUT, respectively, while INCON-CLUSIVE is used when neither pass nor fail can be assigned. For instance, if the tester sends a syntactically wrong OCL query to the SUT, the TDL Interpreter will interrupt the test case execution and the verdict will be assigned as INCONCLUSIVE.