dataesr/scientific-paragraphs-categorization huggingface dataset:
Syntax for storing annotations A common approach, when trying to add additional structured information to a language where it is either undesirable or infeasible to change the language itself, is to define a special way of using comments. This practice is long established for structured documentation or 'docstrings' in programming languages  (Acuff, 1988)  (https://www. gnu. org/prep/standards) and has been used for extending otherwise fixed data formats since punch cards were current technology  (Buneman, 2015). We adopt this approach so that models written using the conventions that we describe here do not require modification of the modelling software, KaSim (https://github. com/Kappa-Dev/KaSim) and RuleBender  (Xu et al. , 2011) , that is their primary target. We use the language's comment delimiter followed by the 'ˆ' character to denote annotations in the textual representation of rulebased languages.
Annotation format Annotations are serialized in the RDF/Turtle format. This representation balances the need for a machine-readable syntax and a human readable textual representation. As the rule-based modelling languages that we are annotating are themselves structured text formats, RDF/Turtle is more suitable than the XML-based representations of RDF. Annotations for a single rule-based model entity are simply a list of statements. Annotations may refer to other annotations within the same model. When all the lines corresponding to a rule-based model and the annotation delimiter symbols are removed, the remaining RDF lines represent a single RDF document. This enables annotations to be quickly and easily extracted without special tools (for example, on a UNIX system, the following pipeline can be used: grep fl ˆ#\ ˆfl-sed fls/ˆ#\ ˆ//fl).
Mapping between entities and annotations XML-based modelling languages such as SBML and CellML already provide opening and closing tags, and annotations are encapsulated within the definition of a modelling entity. In textual rule-based models, it is difficult to store annotations within a modelling entity since Kappa and BioNetGen represent modelling entities such as agents and rules as single lines of text. As a result, there is no natural location to attach annotations to an entity. Here, we propose to achieve the mapping between a modelling entity and its annotation by defining an algorithm to construct a URI from the symbol used in the modelling language. The algorithm used in this paper generates unique and unambiguous prefixed names that are intended to be interpreted as part of a Turtle document.
The rules are identified using Rule. The predicates hasSite and hasState and their inverses are used to link amongst agent, site and internal state declarations. Rules can also be composed of other rules, which are linked with the parent rule using hasSubrule and its inverse. Table  1  deals with terms related to the declaration of the basic entities from which models are constructed. The terms that begin with an uppercase letter are types (in the sense of rdf:type, and also in this instance owl:Class) for the entities in the model which the modeller could be expected to explicitly annotate. The predicates begin with a lowercase letter are used to link entities to their One would not like to materialize the representation of the rules by hand as it is somewhat verbose -conciseness is a virtue of these modelling languages, not of RDF -and it is not useful for simulation since the simulation tools do not understand it.
The rbmo ontology fills a necessary gap for describing rule-based models, but on its own it is not sufficient. Fortunately the openended nature of the RDF data model means that it is possible to freely incorporate terms from other ontologies and vocabularies, including application-specific ones. Two such terms are of structural importance here. The dct:isPartOf predicate from DCMI Metadata Terms is used to denote that a rule or agent declaration is part of a particular model (or similarly with its inverse, dct:hasPart). There is likewise a need to link internal states of sites to indicate biological meaning. The bqiol:is predicate from the Biomodels. net Biology Qualifiers is used for this purpose. Table  3  lists useful ontologies and vocabularies with their conventional prefixes that are used to annotate of rule-based models in this paper.
Adding annotations to rule-based models Models start with a list of prefix definitions representing annotation resources providing relevant terms for the annotation of all model entities such as agents and rules. These definitions are followed by statements about the title and description of the model being annotated, using the title and description terms from Dublin Core. Moreover, model level annotations can be expanded to include model type, the creator, creation time, its link to an entry in a model database and so on (Fig. 2 ). Table  4  shows how different entities in a rule-based model can be annotated using terms from rbmo and other vocabularies. Figure  3  shows examples of Agent annotations. In Figure  3A  the ATP token is annotated as a small molecule with the id of 15422 from CHEBI.
The term sbol:nucleotides is used to store the nucleotide sequences for these agents. A parent-child relationship between the promoter and the operator agents can be represented using an sbol:SequenceAnnotation RDF resource, which allows the location of an operator subpart to be specified. Patterns can also be annotated specifically. For example, this approach could be used to annotate a pattern with a specific entry from a database. Patterns can also be explicitly stated as observables of the model. Figure  3D  shows an example of such an observable. Spo0A_p represents the phosphorylated protein, which acts as a TF and is defined as an observable. Figure  4  demonstrates annotation of rules. The first rule (Fig. 4A ) describes the binding of LacI TF to a promoter. This biological activity is described using the GO:0008134 (transcription factor binding) term.
Annotated contact maps Once a complete uniform representation of the model in RDF has been generated, we can query it using SPARQL with a tool such as roqet (http://librdf. org). For example, a SPARQL query can deduce a contact map -pairings of sites on agents that undergo binding and unbinding according to the rules in the model. These pairings form a graph that can be visualized using tools such as GraphViz  (Ellson et al. , 2002). Indeed with an appropriate query (See the binding. sparql file in the krdf examples directory. ), roqet can directly output the result in a form that GraphViz consumes. An only slightly more sophisticated manipulation (see the contact. py script in the krdf examples directory) can extract annotations as well from the RDF representation of the TCS example model and easily create a richly annotated contact map diagram as shown in Figure  6.
Discussion We present an extension of rule-based models to incorporate annotations and a set of standardized terms, together with annotation guidelines, that can constitute a general proposal for annotating rule-based models. These terms can be used in a complementary manner with existing metadata resources such as MIRIAM annotations and URIs, and existing controlled vocabularies and ontologies. Such metadata is important for models that are computationally generated or served by model repositories, and opens up the possibility of using rule-based models in complex workflows. Annotations can also be used to link to human readable descriptions of models. Rules are modular and combined with annotations, can be reused in many applications. Although, we have demonstrated the annotation of textual Kappa and BioNetGen files, our approach can be easily applied to other rule-based models.
PySB  (Lopez et al. , 2013)  already includes a list of MIRIAM annotations at the model level, and can be extended to include the type of annotations presented here. Moreover, SBML's multi (http://sbml. org/Documents/Specifica tions/SBML_Level_3/Packages/multi) package is being developed to standardize the exchange of rule-based models. The entities in this format inherit the annotation property from the standard SBML and can therefore include RDF annotations. Such SBML models can thus be imported or exported by tools such as KaSim or RuleBender in the future, avoiding the loss of any biological information. Extensions of rule-based models such as MetaKappa makes possible to define rules using abstract agents and allowing agent inheritance  (Danos et al. , 2009). Modularity is especially important in synthetic biology to build complex models of intended biological systems from simple rules.
In general, automatic annotation of models can be challenging where the meaning of modelling entities are not known to computational tools and only the names of entities can be used to infer their semantics. This issue is an ongoing research subject and tools such as Saint  (Lister et al. , 2009)  and SyBIL  (Blinov et al. , 2010)  could be extended to automate the annotation of rule-based models. The extensive information available in biological databases and the literature can thus be integrated and made available via rule-based models, taking advantage of the syntax and the framework presented in this work. Enriching models through computationally tractable annotations has many benefits. The computational feasibility of the proposed annotation schema has been shown with the development of a simple tool that, exporting the embedded annotations, can be used to detect duplicate rules, inconsistencies and provide contact maps annotated with biological semantics.
Acknowledgements We acknowledge  Alejandro Granados  for helpful discussions on the biological examples and  Peter Buneman  for insights into the nature of annotation. W. W. has developed the krdf tool. Funding:  Engineering and Physical Sciences Research Council  grant numbers  EP/J02175X/1  (to A. W. , V. R. , G. M. and M. C. ),  EP/K039083/1  (to C. M. ), and the  European Unions Seventh Framework Programme  for research, technological development and demonstration grant number  320823  (to W. W. ).
The main approaches to developing proximity measures draw heavily on two alternative sources: primary data mainly from surveys and fieldwork research, and secondary data relying mainly on bibliographic and patent information. Cognitive proximity has been measured as the degree of overlap among the knowledge bases of potentially interacting actors. This overlap can be captured at the individual level by analysing the similarity between scientists' publications or patents profiles  (Kotha et al. 2013). The cognitive distance between actors can be captured by focusing on the patent subcategories in which their discoveries are classified  (Tzabbar 2009). Finally, science maps offer a visualization of the overlap between actors across scientific fields  (Rafols et al. 2010)  or patent categories  (Kay et al.
The Big Data challenge consists in managing, storing, analyzing and visualizing these huge and ever growing data sets to extract sense and knowledge. As the volume of data grows exponentially, the management of these data becomes more complex in proportion. A key point is to handle the complexity of the data life cycle, i. e. the various operations performed on data: transfer, archiving, replication, deletion, etc. Indeed, data-intensive applications span over a large variety of devices and e-infrastructures which implies that many systems are involved in data management and processing. We propose Active Data, a programming model to automate and improve the expressiveness of data management applications. We first define the concept of data life cycle and introduce a formal model that allow to expose data life cycle across heterogeneous systems and infrastructures.
The Active Data programming model allows code execution at each stage of the data life cycle: routines provided by programmers are executed when a set of events (creation, replication, transfer, deletion) happen to any data. We implement and evaluate the model with four use cases: a storage cache to Amazon-S3, a cooperative sensor network, an incremental implementation of the MapReduce programming model and automated data provenance tracking across heterogeneous systems. Altogether, these scenarios illustrate the adequateness of the model to program applications that manage distributed and dynamic data sets. We also show that applications that do not leverage on data life cycle can still.
To alleviate the complexity of data life cycles, solutions are needed to automate and improve the expressiveness of data management operations. The first challenge lies in the gigantism of these data sets which requires distributed storage and parallel processing  [3]. Recently, several popular programming languages and models have emerged, such as MapReduce  [4]  or Dryad  [5] , that offer simple yet high-level data-centric parallel interfaces. However these languages focus more on processing large data sets than on specifying management operations on the data. The second challenge is to capture the dynamicity of the data, i. e the fact that data may be produced incrementally, regenerated, modified or temporarily unavailable. Percolator  [6]  is an example of a language and its implementation, which takes into consideration data arrival, and incrementally updates the result of a computation according to modifications of the data sets.
The solution we propose is Active Data, a formal model for distributed data life cycles and a programming model to allow code execution at each stage of the data life cycle. On the one hand, the formal model allows to describe the life cycle of distributed data; the model can be shared with other scientists to build DLCM applications, dynamically check that an execution is valid in regards to the model and integrate dispersed data under a unique namespace. On the other hand, the programing model borrows from Active Message the idea of executing user-provided code when certain events occur (message reception in the case of Active Message  [8] ). With Active Data, once the data life cycle is known and formally defined, routines provided by programmers are executed when a set of events (creation, replication, transfer, deletion) happen to any data item.
This programming model would allow to develop a broad range of DLCM applications such as automated tiered storage, processing at any stage of the life cycle, coordination between acquisition mechanisms and remote storage, content delivery networks, deep storage archive, energy efficient storage, incremental workflows, logs processing and monitoring and so forth. Our contribution is the following: we first present a formalism inspired by Petri Networks allowing to expose data life cycles in heterogeneous distributed systems. We show that this model is able to capture the main stages of data life cycles, namely creation, deletion, scheduling, transfer and replication as well as transient unavailability. Next, we propose a new programming model called Active Data. We report on the design of the Active Data execution runtime, on its integration with data management systems and on performance evaluation, namely throughput, latency and overhead of the system.
To evaluate Active Data, we present four use cases that illustrate the versatility of the framework to program DLCM applications targeted at distributed and dynamic data sets. The first one shows how to program a local cache to a remote storage service in few lines of code allowing both performance improvement and cost reduction. The second scenario features a network of distributed sensors that cooperate to implement data acquisition throttling. The third example shows that an existing MapReduce runtime augmented with Active Data can turn into an incremental MapReduce. The last use-case features data provenance tracking across heterogeneous systems. We run these scenarios using the experimental platform Grid'5000  [9]  and report on the experiments. The rest of this paper is organized as follows.
Data life cycle management, the sequence of data operations, e. g copy, file transfer, reading, performed on a data item during its lifetime. Our objective is to provide a formal and infrastructure agnostic model to describe data life cycles in distributed systems and a programming model which facilitates data life cycle management for developers. We detail the requirements for the life cycle model, the programming model and its implementation: • Allow to reason about data life cycle: the formal model must capture the essential life cycle stages and properties: creation, deletion, faults, replication and error checking. It must allow system developers to share the data life cycle model as documentation with their users. • Allow coordination between multiple systems in different data centers: Datasets are heavily distributed, making collaboration between sites and systems necessary, even when those were not designed to collaborate.
• Allow to reason about data sets handled by heterogeneous softwares: The multiple systems involved in the management and the processing of datasets may not have been designed to collaborate (this is quite often the case with legacy software). The data management system must allow to integrate the multiple copies and identifiers of the same data concurrently living in various systems. • Allow data management systems to be extensible: Data life cycles in scientific applications are not fixed in time, in particular because datasets can be used years after they have been acquired or generated. The data life cycle management system must be extensible in order to handle every future treatments that scientists may want to execute. • Incremental processing: Many scientific and commercial applications treat streams of data, or datasets that are often partially modified.
Active Data at a glance Our response to the above requirements is Active Data, a formal model, a programming model and a runtime environment, which allow to program applications by specifying for each step of the data life cycle, the code that will be executed. In this subsection we give a first overview of Active Data and a first example, before detailing every aspect of the system in Section 3 and 4. In a nutshell, Active Data works as follows: data management systems expose their intrinsic data life cycle according to a well-specified formalism. We consider each creation, modification or deletion of a data item by the data management system as a progression of the data item through its life cycle. We call transition the move of a data item from one state to another state. Informally, the programming model proposed by Active Data could be called of transition-based programing model.
A programmer provides a routine or code that we call transition handler which is executed whenever a transition is triggered. In other words, when a transition happens to a data item, a message (or event) is sent to the other nodes of the system to notify them about the transition and this causes the transition handler code to be executed. The paradigm used by Active Data to propagate transitions is based on Publish/Subscribe  [10]. Data management systems publish transitions to a centralized service called Active Data Service. Thus, at the root of Active Data is a representation of data life cycles. We base our model on Petri Networks  [11] , which is a formalism and a graphical tool widely used for the analysis of systems with concurrency and resource sharing. Petri Nets can depict very intuitively data life cycles: Places, represented by circles are the states of the life cycle; Transitions, represented by rectangles are the operations that happen on data items; Tokens, represented by • in Places, are data items in a particular state of the life cycle.
Example To illustrate a data life cycle model, Figure  1  shows a representation of the "Write-Once, Read-Many" life cycle. A data item starts its life in the Created place, then is written once (Written place), may be read once or several times (loop between the Read place and t 3 transition) and finally deleted (Terminated place). In this example, the transition t 1 corresponds to the action of writing data, t 3 is triggered when reading data, and t 4 corresponds to a data item deletion. We present a short code sample that illustrates how to automatically perform curation when data get written in the system. Whenever transition t 2 is triggered, the application creates a md5 signature file. The programmer first writes the handler that contains the checksum computation: The handler in Listing 1 is a Java object that implements the TransitionHandler interface.
The handler() method is invoked by the system when the transition is triggered. The first argument is the transition that was triggered; the second argument indicates whether the transition was triggered on the same node. Here we do the same thing whether the transition was triggered locally or remotely. The last two arguments provides information about the tokens that went through the transition; we use them to get to the file path of the data item that was written. Then we compute the file's md5 sum and write it to a new file. The programmer further passes the code to the Active Data runtime, specifying it should be run after transition t 2 was triggered: client. subscribeTo (t2 , md5Handler ); Now, every time a process somewhere triggers the transition t 2 for any data item, the handler will be executed asynchronously and the signature file will be created.
Application scope The Active Data programming model offers the opportunity to develop a broad range of applications covering a wide range of scenarios. However, our approach differs from (and complements) existing workflow and dataflow systems  [12] ; Table  1   workflows and dataflows using six criteria: 1) whether the approach is data centric; 2) how the sequence of activities is determined; 3) how activities are chained and how control is passed from one to the next; 4) what events are usually monitored in such approaches; 5) how easily different system representations can be integrated; and 6) who is responsible for integrating an external system (or tool), for example in the case of Active Data this is the responsibility of the system developer to make a system "Active Data enabled". Moreover, the scope and the methodology for application development differs whether the data life cycle is known a priori or has to be defined.
We now review some of the application domains of Active Data. • Active Data is integrated into a particular data management software, such as a file storage, a data-flow scheduler or a file transfer service. In this case, the set of transitions is known by the programmer, so they can express their program as a set of transition handlers implementing data operations. For instance, the implementation of Active Data for BitDew (see Section 4. 3) would allow to program a wide range of DLCM applications such as backup system, distributed checkpoint servers, collective file operation (scatter/gather, alltoall), data-intense applications, execution runtimes such as MapReduce or Allpairs, automatedtiered storage systems etc. • Particular data management systems which lacks DLCM features. Active Data can be integrated after an analysis of the system to extract the data life cycle.
This would provide either additional programming functionalities, such as in the previous case, or permit specific optimizations to this system. • Users also have the possibility to implement from scratch their data life cycle based on their own needs, that is without any data management substrate. In this case, the application is expressed as set of operations on data and the developer takes care of generating the transition whenever operations are actually performed. In this case, the benefit of using Active Data is to have a clear specification of the data life cycle.