dataesr/scientific-paragraphs-categorization huggingface dataset:
Manuals and guides from various sources are available to help implement and use it. It is possible to draw a problem or solution tree in PowerPoint or other software, or by using the ImpresS online tool (see the "ImpresS interface" section). The CCAFS program proposes the following facilitation methodology  (Jost et al. , 2014, p. 48  3. Look at the causes identified and ask why they exist. Write these second types of causes on the left and connect them to the causes identified first. 4. Notice that you are drawing a tree with branches to the left. We must continue to draw the other branches by asking "Why?" This exercise is called "5 Why," because one has to normally ask "why" five times to arrive at the determining and central causes (roots). These are all causes that need to be addressed in order to progress towards the vision of the future, and they help define the outputs that the intervention has to generate to contribute to the desired change; 5.
CloudSME platform concept and architecture The generic layered architecture of the CSSP is shown in Fig. 1. The platform was created by reusing, integrating and further developing existing technologies including the WS-PGRADE/gUSE gateway framework  [26]  and the CloudBroker Platform  [27] , and also extending these with new commercial components such as the CloudSME AppCenter. The primary target audience of CSSP are commercial independent software vendors and consultant companies developing and offering various simulation software solutions. However, the platform can also be utilised for academic/research oriented scenarios, as it was demonstrated for example by Temelkovski, et al. [28]  where the CSSP was used to execute large scale molecular docking experiments on heterogeneous cloud computing resources from the graphical user interface of the Raccoon2 desktop application  [29].
Simulation applications layer The top layer of CSSP is the Simulation Applications Layer that consists of the CloudSME AppCenter as a generic entry point to browse and execute various simulation applications. The AppCenter is a new component that was developed during the CloudSME project. The CloudSME AppCenter is a web-based one-stop-shop solution with the goal to provide software products and services by software vendors and service providers to end users that can utilise them via a single interface. For this, the AppCenter stores information about software products in an accessible way, provides usage scenarios for the software, and offers billing functionality that includes price setting, payment integration and tracking of users' spending. The AppCenter supports three main deployment models: Directly Deployed Applications, Web-based Applications, and Desktop Applications.
The default usage of the AppCenter is to deploy and offer cloud applications directly from there. After cloud-enabling the application via the CSSP, the software provider registers and publishes the application in the CloudSME AppCenter. Once published, endusers can access and execute these applications directly from the AppCenter and they will be charged for their utilisation based on software provider defined pricing policies (e. g. subscription-based pricing, resource consumption-based pricing, fixed charge for each simulation run, or even free of charge execution). The advantage of this solution is that the AppCenter provides easily customisable options to set up various pricing models and it is also responsible for accounting and billing. Users simply need to add credit to their account and can then execute simulation applications on all cloud resources supported by the selected application.
The complexity of multi-cloud execution and billing is handled by the platform. On the other hand, this solution has one notable disadvantage. Software vendors must market and promote the simulation solution via the AppCenter and are also restricted to its user interface. Many software vendors with well-established marketing channels and sophisticated user interfaces do not prefer this option. Our AppCenter therefore supports two additional models. In the first, vendors extend their traditional desktop software with cloud execution support. In this scenario, the desktop application is extended, using one of the suitable APIs offered by CSSP, to redirect computation intensive simulations to the cloud. In this case the application cannot be directly executed from the AppCenter. However, users can download the package from there, install it on their own machine, and then utilise its cloud extended capabilities.
Using the CloudBroker APIs bypasses WS-PGRADE/gUSE and provides direct access from the application to the multi-cloud resources supported by the CloudBroker Platform. Using the Remote API of WS-PGRADE/gUSE enables developers to execute complex application workflows linking multiple application components together. As WS-PGRADE/gUSE is integrated with the CloudBroker Platform, multi-cloud execution capabilities are still fully utilised in this scenario. In case of web-based applications, either the ASM (Application Specific Module) API of WS-PGRADE/gUSE is used that enables the rapid development of a custom portal/gateway in the form of customised Liferay Portlets or a completely custom web interface is developed by embedding either CloudBroker API or gUSE Remote API calls. Alternatively the standard web-based interface to WS-PGRADE/gUSE can also be applied to launch workflows.
The CloudBroker platform The CloudBroker Platform is a commercial PaaS that supports the management and execution of software on different cloud provider resources. The generic architecture of CloudBroker is shown in Fig. 3. At the bottom, CloudBroker uses IaaS clouds from resource providers and incorporates adapters both to public and private cloud infrastructures. The platform provides access to a wide range of resources including open source (e. g. OpenStack and OpenNebula) and proprietary (e. g. Amazon and CloudSigma) clouds, and also various HPC resources. In the middle layer the applications are deployed. CloudBroker supports non-interactive serial and parallel batch processing applications on both Linux and Windows operating systems. The platform itself consists of a set of modules that manage processes, applications, users, finance (accounting, billing and payment), and runtime issues (process monitoring, queuing, resources, storage and images).
A scalability and fault handler layer supervises scalability requirements and failure issues. Cloud Provider Access Management oversees the connection to each Cloud technology and can control the number of virtual machines (VMs) started for a given application on a given cloud. Application ''patterns'' are deployed to CloudBroker in a form that allows the platform when instructed to run the application on a particular cloud and cloud instance type. Two typical patterns are direct installation (an application package and deployment script that allows the installation of the software on a cloud instance) or virtualisation (virtual machine image containing installed software that allows direct deployment to a cloud instance). At the top, CloudBroker offers various interfaces for access. Its two main operation modes to manage and use software in the cloud are either as direct front-end, or as a back-end middleware service.
Usability of CSSP CSSP is a production level commercial product. Therefore, usability is one of the key issues when further utilising and marketing the platform. The targeted users of the above described technology stack are twofold. On the one hand CSSP targets application developers, typically Independent Software Vendors (ISVs), that can utilise the platform when cloud enabling their simulation products. ISVs use the CSSP as PaaS and develop custom solutions for their customers. On the other hand, end-users, typically manufacturing companies utilise SaaS solutions that are developed using CSSP technology. The complex technology stack is completely hidden from these end-users and they access either the AppCenter or a custom GUI provided by their ISV. CSSP technology is commercialised and marketed by start-up company CloudSME UG that was set up by CloudSME project partners.
A cloud-based application is implemented by creating an application package for CloudBroker. This consists of an installation shell script, the zipped solver and associated files (typically including MPI/PVM and scientific libraries) and a licence key (if needed). The deployment of the installation package is done by first requesting the specified cloud instance type, booting Linux virtual machines as necessary and then transferring the application package. The installation shell script is then run and compiles and builds simulation executables based on the designated model. The installation script also needs to build job run scripts needed by CloudBroker when startjob() (see Fig. 7 ) is called to run the application. Fig. 7  shows the sequence diagram describing the interactions between the user, the front end and our Platform.
The Front End can be linked to CloudBroker using several methods as described earlier. In this case we will assume the REST API. As can be seen, the user initially clicks on the ''Run on Cloud'' button on the Front End  (1). The user then specifies the project name, the cloud/instance type and the region (only applicable if the cloud provider has multiple regions) on a configuration form  (2) (3) (4) (5) (6). This is then translated into a XML job description and sent to CloudBroker using a POSTrequest command  (7). CloudBroker executes createJob() that uploads the installation package to the specified cloud/instance type and executes it. This installs and compiles the software on the multiple CPUs of the cloud instance  (8). When this is complete, the job is set up and CloudBroker returns a jobID  (9).
Fig. 8  shows the comparative runtime and Table  1  shows the comparative speedup. As can be seen the best relative speedup is 6. 28 for 8 CPUs on Amazon EC2 for the refined mesh. To support commercial application scenarios, the TransAT software was published in the CloudSME AppCenter as a downloadable desktop application, as illustrated in Fig. 9. AppCenter users can simply download the front-end package from the AppCenter free of charge. Once installed, simulations can be built exactly the same way as using the traditional desktop software. However, when the model is ready, users will be offered the option to execute the solver on cloud resources, as shown in Fig. 10. When executing the simulation, the CSSP will charge the user's account for the consumed resources.
RepastS deployment on the CloudSME simulation platform The deployment of RepastS consists of two parts: deployment on CloudBroker and creation of the parameter sweep workflow on WS-PGRADE/gUSE. Deployment on CloudBroker is done by creating an application package consisting of a deployment shell script, an execution shell script and the zipped RepastS environment. For each cloud deployment, CloudBroker is configured to create a virtual machine with a Linux Ubuntu OS image. Using its web interface, CloudBroker  creates this virtual machine, transfers the application package to the virtual machine and then runs the deployment shell script. This installs RepastS, Java Runtime Environment and the execution shell script. When a job is started (i. e. a simulation run), the simulation model (a TAR archive consisting of the model source code and the simulation scenario) and the parameter sweep data (an XML file specifying the input parameters) are transferred to the virtual machine.
The developer then has the option of creating a dedicated web-based interface using the ASM module of WS-PGRADE/gUSE or by integrating with an existing commercial desktop PC application using the gUSE Remote API. The cloud-based simulation application can then be made available through the AppCenter. Such a commercial application has been implemented based on the Simul8 discrete event simulation package. 8 The Simul8 desktop package has been extended with 8 www. simul8. com. cloud-based execution support using the gUSE Remote API. Additionally, a web portal has also been implemented that utilises Simul8 to support scheduling of production and distribution of products for microbreweries.
This can be done through Q&A sessions or panel discussions, but it also (and often more fruitfully) through informal consultations as part of the running feedback on data visualizations. 2) Operationalizing research questions into feasible digital methods projects. In a sense, this process begins already before the sprint where the organizers try to anticipate what type of projects the sprint might led to. We found that an excellent way of doing this initial vetting is to ask issue experts to suggest interesting datasets. This provides a chance to get back to the experts explaining why the proposed dataset may be unsuitable for certain research questions and thus getting them attuned to what a digital methods project can and cannot achieve. 3) Procuring and preparing datasets. As mentioned above, while it is desirable to have datasets available in advance, this is sometime at odds with the agility of the sprint and it is not uncommon that complementary data have to be search and collected in the first days of the sprint.
4) Writing and adapting code. Sprints are issue-specific (meant to address particular needs of the controversy actors) and their aim is less to develop generic tools than to adapt existing code to the research questions rose by the issue experts. This does not mean, however, that effort shouldn't be invested in making datasets, scripts and visualizations re-usable beyond their original projects. Sprints should remain faithful to their communitarian roots and ensure that all the data, code and contents produced are liberated through of open-source, copy-left and open-publishing licenses.
• Data Origins; if the data is generated first hand from lab/field work, then origin often corresponds to certain attributes of study subjects, e. g. , the gender and age of humans from which DNA has been sampled. If data is derived from already existing datasets then origin corresponds to attributes such as, data catalog names, versions, or access end-points. In order to provision this contextual metadata, in recent years, the practice of reporting has emerged. Several disciplines have introduced guidelines  [4]  and models  [5]  to ensure that core contextual metadata can be created. Reporting can describe both physical and computational parts of studies. One key characteristic of reporting is its emphasis on fine-grained modelling of context. A study may embody multiple contexts involving multiple subjects, factors and alternate source datasets.
Adhoc reporting relies on the fact that context information is implicitly available in file names, file headers or in data values. The reasons for the metadata disconnect are two fold: • Workflow provenance is generic. In order to allow processing of diverse scientific datasets using equally diverse tools; workflows systems are designed to be oblivious to what data and tasks internally represent. This is also known as the "black-box approach", which generates provenance graphs comprised of opaque nodes  [13]. Meanwhile, for reporting, we require domain-specific information on data and tasks. Henceforth workflow provenance requires further annotation in order to be useful in reporting.
Design annotations can state, for example, that a task (hence consequently all its executions) consume a genomic sequence and perform sequence alignment. Meanwhile reporting requires dynamic characteristics that surface only at runtime, such as, the specific species/subject whose genome is sequenced, or the values of parameters used during alignment. In  [17]  Ailamaki et al. observe that automated processing of this category dynamic metadata is a crucial requirement for scientific data management. Recently we observe that acquisition of runtime attributes as metadata and their propagation is being added as a feature to workflow systems, specifically in the Galaxy  [7]  and Wings  [8]. This feature relies entirely on the user's manual tagging of each individual input dataset. In the case of Galaxy, tags get propagated to all descendants of data regardless of the nature of data processing in individual steps.
In the case of Wings in addition to annotating datasets the user is expected to configure elaborate rules on how metadata may propagate from inputs to outputs, as a result we have not observed a use of this feature in existing Wings workflows  [18]. Scientific disciplines have standardised data formats, where data is accompanied with embedded contextual metadata. VOTable, HDF5, FITS in earth-observation and astronomy  [17] ; BAM, VCF, FASTQ, Blast Report in life science  [19]  are examples of such formats. The state of the art exploits data formats in two major ways. First one is raw-data processing tools such as NoDB  [20]  and Fastbit  [21] , which utilise various indexing techniques so that data can be kept in its raw form but can be loaded and queried when necessary. These approaches assume a vertical column-oriented organisation for data, where some of the columns may comprise metadata.
Layers of Provenance Taverna workflows are comprised of tasks, input/output ports of tasks and the dataflow links among ports. Figure  1  illustrates our workflow that takes as input a set of galaxy names (list_cig_name), and outputs extinction values per galaxy (data_internal_extinction). The workflow retrieves data, from remote astronomical databases (Steps 1 & 2) and uses this information to calculate extinction values (Step 3). The unnumbered tasks in between are adapters, which perform (Data) Extraction, Format Trans f ormation and similar. Taverna supports simple structural typing of data. Ports of tasks can be defined to hold data Items or nested Collections of data items. Figure  2  provides an illustration of the execution of this workflow with two input galaxies. The information given in Figure  2  also makes up the core of workflow provenance.
In order to represent the trace of Figure  2 , workflow systems utilise generic vocabularies. In Figure  3  the top "Workflow" layer contains the abstract specification of a workflow task in the Wfdesc model  [32]. Wfdesc is a "node and directed-arc" RDF graph  [33] , where nodes are typed as Processes (tasks), and their Input/Outputs (ports). The middle "Provenance" layer provides a PROV-compliant  [34]  graph, containing an Activity node (rectangle) representing one execution of the workflow task, and two Entity nodes (ovals) representing the data consumed and produced by the Activity. At the data layer in Figure  3  we have data values stored within files (denoted with disk shapes). Most workflow systems including Taverna, adopt a separated storage scheme for data and provenance, where data is often stored in the file system and the provenance metadata is stored in graph/triple stores or relational databases.
Q1-G: We can realise Q1 partially over generic provenance. For the first part, the intent is to obtain data retrieved from the Sesame database or its local copies generated through adapter steps. Here we use lineage as a pseudo (replacement) mechanism to denote data origin. We seek results, whose derivation path includes and invocation of the SesameXML processor, which we know accesses the Sesame database. We're unable to implement the second part of the query, which inquires catalog information. This is to be found embedded in the VO Table XML String, outputted from the SesameXML processor, as a combination of a tag name and a fragment of string value within that tag. Given that there are diverse data formats even in the context of astronomy there is no systematic way to place value restrictions with the provenance and query models outlined above.
• lineage based on any other analytical computation Designating origin via path-based linkage to an element identified in workflow design is weakly precise; yet it is robust to increases in the workflow inputs. Increasing the number of galaxies in a workflow run does not alter the fact that only one thirds of outputs are copies of data from the Sesame Database. The source catalog information sought in the second part of query is available within some of the data values, i. e. , in the XML output of the SesameXML activities, there is a field that specifies the catalog (the relevant subpart in Sesame DB) that the result comes from. However when these results are stripped of their XML padding the catalog information is no longer associated with retrieved coordinates (outputs of the Extract_RA and Extract_DEC steps).
We have relied on an API as we wanted to abstract away from any storage technology for labelling and querying is an aid to the labelling process. In our default (RDF-based) implementation a label definition is represented with an OWL Datatype property. Label instances are RDF statements where the subject corresponds to the target of the label, the predicate is the datatype properties and objects are metadata values of type xsd:string. The Provenance and Label spaces are RDF files in turtle syntax. For each workflow run we load these into in-memory Jena  [43]  models. These could also be loaded into a single model in case native (SPARQL) querying of labelled provenance is desired. The sample provenance and label spaces used in the performance evaluation of LabelFlow can be accessed from the source code repository here  [40].
We have tested the PROV compliance of provenance traces we use with the ProvToolbox online validator  [44]. Labelling pipelines are represented in an abstract manner with Wfdesc  [32]. This abstract representation can be converted to a concrete executable form using any workflow language that supports a simple data flow among activities, and can access resources exposed through Java APIs. For our case-study tests we interpret the abstract Wfdesc specification by traversing the activities in the topological order of their respective workflow elements in the scientific workflow, and make API calls to invoke respective operators. Note that the pipeline is only responsible for coordinating the execution of labelling operators, whereas the core of labelling takes place within operators.
• we associated Labelling Specs with workflow activities according to the information model given in Figure  12. For the data adapter activities, for which a corresponding labelling behaviour is given (Table  3 ), we created PropagateSpecs and for the scientifically significant activities, we created MintSpecs, pointing to the labelling functions. This time we implement the queries in Table  2  using label-based annotations (denoted with the "-A" suffix). The precision in obtaining relevant results for each query is given in Figure  16. Q1-A Rather than using lineage as a pseudo mechanism to seek coordinates retrieved from Sesame Database, we now inquire about data origin directly using labels. Formally; answer(E,C) :-L_ins("referenceURI, "http://cdsws. u-strasbg. fr/",E), L_ins("referenceCatalog", C, E) We use re f erenceURI, re f erenceCatalog datatype properties created for our case study.
Note we are now able to fully implement the query and seek the source catalog information about the coordinates. As Figure  16  shows, with label-based queries we are able to retrieve with 100% true accuracy the data that comes from the Sesame database and its local copies. Q2-A In this query we use the hasSubject label to seek results about a particular galaxy. Formally; answer(E,G) :-L_ins('"hasSubject",G,E), member(G,["M31","UGC 454"]), L_ins("referenceCatalog", G, E) Note that a typical characteristic of scientific data repositories is that they use heterogeneous identification schemes. So, in Astronomy a Galaxy has several identifiers from respective databases. The Visier and Sesame databases accesses within our example workflow use different identifiers. Therefore in our query, we need to refer to all possible domain identifiers of a Galaxy.