dataesr/scientific-paragraphs-categorization huggingface dataset:
Also, despite the growing attention paid to the cloud and its elasticity property in particular, there is still a lack of solutions that support the evaluation of elasticity strategies used to ensure the elasticity of processes at service-level. In this paper, we present a framework for describing and evaluating elasticity strategies for Service-based Business Processes (SBP), called StratFram. It is composed of a set of domain-specific languages designed to generalize the use of the framework and to facilitate the description of evaluation elements that are needed to evaluate elasticity strategies before using them in real cloud environment. Using StratFram, SBP holders are allowed to define: (i) an elasticity model with specific elasticity capabilities on which they want to define and evaluate their elasticity strategies, (ii) a SBP model for which the elasticity strategies will be defined and evaluated, (iii) a set of elasticity strategies based on the elasticity capabilities of the defined elasticity model and for the provided SBP model, and (iv) a simulation configuration which identifies simulation properties/elements.
The formal evaluation of elasticity strategies is an important step to be performed before using the strategies which allows to detect any suspicious behavior that may cost extra-utilization of resources. In this paper, we present our StratFram framework, for describing and evaluating elasticity strategies for servicebased business processes (SBPs). The StratFram framework enables the evaluation, through simulation, different elasticity strategies based on different elasticity models. It is designed based on a set of domain-specific languages (DSLs) for describing different simulation elements from the elasticity model to the simulation configuration in order to conceal the used formal methods/systems and the implementation complexity from SBP holders. Using StratFram, SBP holders are allowed to define (i) an elasticity model with specific elasticity capabilities on which they want to define and evaluate their elasticity strategies, (ii) a SBP model for which the elasticity strategies will be defined and evaluated, (iii) a set of elasticity strategies based on the elasticity capabilities of the defined elasticity model and the provided SBP model, and (iv) a simulation configuration which identifies the elements of the evaluation.
As results for an evaluation, StratFram provides a set of plots that allows the analysis and the comparison of strategies. This paper is organized as follows. Section 2 presents a review of related works for managing and evaluating elas-ticity in the cloud. In Section 3, we introduce our framework architecture and give an overview of its languages and their relationships. Then, we describe each of its components, namely, SBP language in Section 4, StratModel language in Section 5, Strat language in Section 6, and StratSim language in Section 7. We chain up with the evaluation of our framework in Section 8, which contains the implementation details and some experiment results. The final section presents the conclusions and proposes some lines of future work.
STRATFram: Elasticity Strategies Evaluation Framework for SBPs Elasticity strategies govern the provisioning of necessary (to respect the agreed QoS) and sufficient (to handle the amount of requests) resources despite variations in enactment requests load. Many strategies can be defined to steer processes elasticity. The abundance of possible strategies requires their evaluation in order to guarantee their effectiveness before using them in real Cloud environments. In this section, we present our elasticity strategies evaluation framework for SBPs, named StratFram. We first present StratFram overview, followed by the relationships between StratFram languages.
3. STRAT language  [26] : It is a rule-based domainspecific language for describing elasticity strategies for SBPs deployed in Cloud environments. It was initially proposed based on a specific elasticity model. Thereafter, we generalized the use of Strat to be able to adapt to any elasticity model provided by SBP holders. 4. STRATSim language: It is designed as domainspecific language for specifying simulation properties/elements in a declarative manner and providing SBP holders with a simulation launcher for their evaluation scenario. Each one of the StratFram languages is provided with a code generator that is responsible for generation a concrete implementation of the described element based on the formal method/system used in the second part of StratFram. The latter represents the StratFram engine which provides common classes and functions used and triggered by the generated items either for processing or profiling the SBP model.
Relationships between StratFram languages The design of StratFram was based on the idea of providing a language for describing elasticity strategies that is general enough to describe strategies for different elasticity models and allows the adding of new possible actions. The first solution was to provide Strat language grammar with a constant set of actions used in the commercial cloud-solutions and the research papers. Such solution makes the SBP holders constrained to a set of pre-defined actions and parameters and does not enable the adaptation to new elasticity capabilities that can be provided by the community. The second solution that we adopted in designing our framework is to provide a set of languages that allow users to separately define an elasticity model on which Strat language will be based.
So, the latter will provide SBP holders with only the elasticity capabilities defined in the elasticity model by the elasticity manager. This solution is based on the notion of "cross-reference" to create links between languages. The elasticity capabilities are defined using StratModel as objects and then their references are used in Strat language as part of its grammar. Along the elasticity capabilities, StratModel allows users to define a set of metrics that can be used as QoS metrics or functions called inside Strat script using their references, and to specify the properties that the users can reconfigure when applying an action according to a Strat strategy. The links created between the two languages, i. e. , StratModel and Strat, only constraints the users with the order of defining their system elements.
So, they have to first define an elasticity model using StratModel on which Strat will be based and then they can define their elasticity strategies. Other links has been made between StratModel and SBP language, and StratSim and all the other languages. Using StratModel, a user can (optionally) define his elasticity model for a specific SBP by indicating the reference to an already defined SBP model, using SBP language, as the managed component of the elasticity model. Since it is designed to indicate the elements of an evaluation scenario, StratSim provides users with references to the already defined elements that can be used in an evaluation. In the following sections, we describe the detail of each language in our framework with its use in defining an element of the elastic system given in Example 1.
SBP Grammar Based on the composition of an elastic execution environment, we define the grammar of SBP language that allows to specify SBP models using elastic execution environment components rather than using formal notation and terminologies of the used formal method. The toplevel of SBP specification grammar is given in Grammar 1 using the Backus Normal Form (BNF). A SBP model is composed of a structure and a marking that corresponds to a set of requests in the process. The structure description part is given in a block defined by the keyword Process (i. e. , indicates the beginning of the SBP model) and identified by a name. As described in the formal model, a SBP structure can be composed of four sets: (i) a set of groups, (ii) a set of nodes where a node can be either a service engine or a load balancer, (iii) a set of routers, and (iv) a set of links connecting nodes and router to each other.
SBP Core After describing a SBP model using SBP grammar, the script should be processed to generate its corresponding formal model according to the chosen technique. In order to do so, some basic functionalities are provided to the language composing its core. This part is composed of the three main components that can be adapted to the chosen formal technique by providing a new implementation: (1) a validator that is responsible for checking the model structure coherence and the provided expressions correctness which might be given to routers and links, (2) a scope provider which aids users to edit their script by providing a set of expected elements, and (3) a generator that translates a SBP script into a Petri net model according to the described model.
STRATModel Language In order to allow SBP holders to customize the evaluation framework to their needs, StratModel language has been designed to allow describing elasticity models and generating their associated elasticity controllers using a pre-defined elasticity controller template. An elasticity model defines the ground terms and functionalities that describe the elasticity of SBPs such as the elasticity actions to be undertaken, metrics to monitor to trigger the elasticity actions and properties to access and reconfigure. Hence, it is the basis for specifying elasticity strategies and constructing an elasticity controller that manages and evaluates SBPs elasticity. An elasticity controller is used to monitor a SBP execution and analyze its performance by inspecting an elasticity strategy in order to apply some actions whenever needed which may reconfigure some properties of the managed component  [29].
This transformation can be specified in StratModel as transformation cases. A transformation case is defined by giving an example of an initial state of the SBP model and the resulting state after applying the action by referring to the provided process states (cf. Grammar 13). The idea of using examples to specify the transformation on SBP model follows the byexample paradigm  [31]  which allows the software to drive information from a set of examples specifying how things are done or what the user expects. The most prominent approaches for by-example paradigm are Query by-example  [32]  which has been developed for querying database systems by allowing users to give examples of query results and Programming by-example  [33]  that permits to create a program from user's actions which are recorded as replayable macros.
StratModel core After describing an elasticity model using StratModel syntax, the StratModel document should be processed to generate its corresponding elasticity controller based on a pre-defined template that groups the common functionalities of a controller. In order to achieve this, StratModel language is provided with a set of functionalities constructing its core which includes: (1) a validator to check the coherence of the provided elements, (2) a scope provider, and (3) a generator that uses a pre-defined controller template grouping the common functionalities of a controller. Usually, a controller is represented by a control loop to provide autonomic management which gives the system the ability to manage its resources automatically and dynamically whenever needed. This loop consists in (i) harvesting monitoring data, (ii) analyzing them using (optionally) a knowledge base and (iii) generating reconfiguration actions to correct violation (self-healing and selfprotecting) or to target a new state of the system (selfconfiguring and self-optimizing)  [34].
STRAT Language Elasticity Strategy Description Language (Strat for short)  [26]  has been proposed as a rule-based Domain Specific Language for specifying strategies governing SBP elasticity. It allows to specify QoS requirements of a SBP at different granularity levels (i. e. , process, service, and instance level) with taking into consideration the fundamental characteristics of SBP. Strat is proposed based on a specific elasticity model that defines the actions that users can define to manage their process, the metrics that users can call in action's rules and the properties that users can access and reconfigure. In order to adapt the language to different elasticity models, we link Strat to StratModel that gives the description of the elasticity model that the Strat language will be based on.
This specification allows the SBP holder to define elasticity action rules that incorporate the characteristic of the processing requests into the decision making. We are currently working on providing a formal model of SBP elasticity that allows the distinguishing of services requests by their characteristics. Under the Actions section, elasticity mechanisms could be provided by setting a set of rules grouped by their intended elasticity action as shown in Grammar 16. The actions allowed in Strat are the ones defined in the given StratModel script. So, by changing the provided script, the actions allowed in Strat change as well. Moreover, we provide the grammar with a syntactic validator and scope provider modules to adapt actions parameters according to their definitions in the used elasticity model by dynamically activate and deactivate parts of syntactic definition of Action.
e. , and/or). Conditions are the reflection of system's state at a certain point of time. They are split into boolean (i. e. , true/false), boolean function, iteration, comparison, negation, time-based condition, or another rule. The timebased condition allows the execution of an action after some period of time or after the persistence of system's state for some period using for to specify that period, e. g. , the rule "Duplicate(s): true for 60 min" schedules a duplication of each elastic service s in every "60 min". Unlike existing languages in the literature for controlling elasticity, we incorporate the concept of iteration into the definition of Strat in order to get a global view of the system's state. For example, to be able to determine the state of a service at a given time we have to check the state of all its copies so we get a global perspective instead of a local one (i.
StratSim language StratSim is a simulation domain-specific language for specifying simulation properties/elements in a declarative manner and generating a simulator launcher. StratSim document is composed of a set of (property, value) pairs that represents the parameters that customize the simulator to perform the wanted simulations. As described in the Grammar 18, SBP holders have to provide the elasticity model on which the simulations will be based on, by referring to the existing elasticity model. Along this the elasticity model, they can specify a set of items composed of processes defined using SBP language, Strat strategies and workloads that represent different configuration of specifying the arrival law of process enactment requests. These items indicate to the simulator the series of simulations that have to be performed.
Implementation and evaluation We present in this section an overview of the implementation of StratFram framework. We also provide insights on its use through two evaluation scenarios. The first part is developed using Xtext 2  an eclipsebased development framework for creating DSLs. Each designed language in StratFram has its editor which provides user with code completion, syntax highlighting, automated parsing and quick fixes functionalities that facilities the edition of scripts. In addition to these functionalities, we provided each language with a scope provider that is customized according to the semantics of the language, along with a validator that is implemented to perform additional constraint checks. In the current implementation of StratFram, the second part of the framework is composed of a set of functions and classes designed and implemented based on SNAKES toolkit  [35]  a Python library that provides all the necessary to define and execute many sorts of Petri nets, in particular algebras of Petri nets.
2 nd Evaluation Scenario Using StratFram interface, we create two projects where in each one we create an elasticity model using StratModel editor, a SBP model using SBP editor, three elasticity strategies using Strat editor, and a simulator script using StratSim editor. In both projects, we pro- vide the SBP model for molecular evolution reconstruction (MER) described in Fig. 2  which is composed of eight services and six service out of eight are defined as elastic. We assume that each elastic service engine is provided with a maximum response time thresholds (execution time) depending on request groups as their required QoS given with the elasticity strategies. Above the maximum threshold, the QoS would no longer be guaranteed. We used the following QoS requirement in each elasticity strategy defined in the projects: • M ax t = {S1:{c1=12,c2=102,c3=202}, S2:{c1=10,c2=500,c3=1995}, S5:{c1=4,c2=255,c3=1005}, S6.
1:{c1=4,c2=130,c3=1005}, S6. 2:{c1=4,c2=130,c3=1005}, S7:{c1=100,c2=1005,c3=2005}} 1. Evaluation project 1: Along with the SBP model, this project is composed of the following elements : (a) The elasticity model on which SPEEDL language  [20]  is based is composed of four main actions: (1) Request scheduling that represents the mapping of a request to the next service engine in the process, (2) Request migration which re-maps an already existing request to another service engine copy, (3) scale-up that adds a new service engine copy, and (4) scale-down that remove unused service engine copy. With the set of actions, we define in this elasticity model 'executionT ime' metric that provides the age (execution time) of a given request. Fig. 8  illustrates the elasticity model script and its generated controller and actions implementation.
In this strategy as well, the conditions of elasticity actions do not consider the distinguishing between services requests and their different QoS requirements. So, we use the same defined fixed maximum response time threshold. This strategies provides a rule for migration action in addition to the rules defined in the strategy StrategyResponseTime. (e) A simulation script that specifies that the three provided strategies should be evaluated and compared on the SBP model using the elasticity controller generated from the SPEEDL elasticity model and the usage behavior. Fig. 9  illustrates the defined strategies and the simulation script. We use the Poisson distribution for dynamically generating the sequence of requests arrival. We set the mean of Poisson distribution to 4;.
Fig. 10  illustrates the elasticity model script and its generated controller and actions implementation. (b) A strategy named RTWithCategories that defines rules for duplicate action, consolidate action, routing action. It uses the provided QoS requirement as an elasticity indicator to duplicate the service engine and the minimum response time thresholds an indicator to consolidate a service engine copy. So, the duplication action for a specific service engine s is triggered when the maximum response time threshold has been reached for at least one of request groups and the same applied for all its copies. Otherwise, if the consumed capacity of a service engine copy is equal to 0 and the response time of the service is below its minimum threshold, a consolidate action is triggered by releasing the service engine copy.
Conclusion In this paper, we presented a framework for describing and evaluating elasticity strategies for service-based business processes, called StratFram. StratFram enables SBP holders through a set of editors for different DSLs to define their proper elastic systems by providing their proper elasticity model along with their SBP models and strategies. It provides SBP holders with a set of languages that facilitate the description and the evaluation of elasticity strategies that can be based on different elasticity models. It has been designed in a way to separate the description part from the functional part of the framework. The description part which represented by StratFram languages is designed to conceal the complexity and the type of underlying techniques and systems used for the evaluation which makes the framework extensible to other techniques and systems without affecting the users interaction with the framework and the previously defined scripts.
g. part relations and specialization relations with genus & differentia. When relevant, these sections present type definitions in OWL, as well as SPARQL queries or update operations, to illustrate how this ODR can be implemented. Figure  1  shows that SHACL (a constraint language proposed by the W3C) may also be exploited when its expressiveness is sufficient to express the constraint that needs to be represented. However, this exploitation is not described in this article. Section 4 provides more comparisons with other works and concludes. Representation Via OWL In this document, OWL refers to OWL-2 (OWL-2 DL or OWL-2 Full)  [9]  and OWL entities are prefixed by "owl:". All the types that we propose in this article are in http://www. webkb. org/kb/it/o_knowledge/d_odr_content/sub/ and the "sub" namespace is here used to abbreviate this URL.
Checking the "comparability of properties via subPropertyOf relations" is similar to checking the "comparability of classes via subClassOf relations". The above SPARQL query can easily be adapted. The first adaptation to make is to replace every occurence of "class" by "property", to replace "disjointWith" by "propertyDisjointWith" and to replace "complementOf" by "inverseOf". The second adaptation to make is to remove the lines about "AllDisjointClasses" and "disjointUnionOf" since in OWL these types do not apply to properties and have no counterpart for properties. Dealing with several datasets. A KB may reuse objects defined in other KBs; object identifiers may be URIs which refer to KBs where more definitions on these objects can be found. We abbreviate this by saying that these other KBs or definitions are reachable from the original KB.
Similarly, from this other KB, yet other KBs can be reached. One feature proposed in Figure  1  is to check all objects "in the KB and those reachable from the KB". Since comparability checking supports the detection of particular inconsistencies and redundancies (cf. next subsection and next section), the above cited feature leads to the checking that a KB does not have particular inconsistencies or redundancies with the KBs reachable from it. This feature does not imply fully checking these other KBs. The above presented SPARQL query does not support this feature since it checks classes in the dataset of a single SPARQL endpoint. Implementing this feature via SPARQL while still benefiting from OWL inferences unfortunately requires the SPARQL engine and the exploited OWL inference engine to work on a merge of all datasets reachable from the originally queried dataset.
For small datasets, one way to achieve this could be to perform such a merge beforehand via SPARQL insert operations. However, when it is not problematic to give up OWL inferences based on knowledge from other datasets, an alternative is to use a SPARQL query where i) "SPARQL services" are used for accessing objects in other datasets, and ii) transitive properties such as rdfs:subClassOf are replaced by property path expressions such as "rdfs:subClassOf+".
Comparability Via "Definition Element" Relations In this article, an object definition is a logic formula that all specializations of the object must satisfy. A full definition specifies necessary and sufficient conditions that the specializations must satisfy. In OWL, a full definition of a class is made by relating this class to a class expression via an owl:equivalentClass relation. Specifying only necessary conditions -e. g. using rdfs:subClassOf instead of owl:equivalentClassmeans making only a partial definition. An "element of a definition" is any target domain object which is member of that definition, except for objects of the used language (e. g. quantifiers and logical operators). A "definition element" relation is one that connects the defined object to an element of the definition.