dataesr/scientific-paragraphs-categorization huggingface dataset:
Identify The lifecycle's identification step aims to distinguish relevant resources and design IRIs to identify them. When discussing streaming data on the Web, two types of resources are critical: the stream itself and the elements that the stream contains. Indeed, data streams, like datasets, represent a collection of data points, each of which can be independently identified. Some important aspects of the data stream are highlighted by Tommasini et al. [9]  as they affect how data should be managed and identified, i. e. , they are unbounded and ordered  [32] : • Unboundedness refers to the stream's inability to be stored in its entirety. • Order refers to how data is consumed, i. e. , sequentially as soon as it arrives. Definition 6. 1. A Web data stream is a Web Resource that identifies an unbounded ordered collection of pairs (o, i), where o is a Web resource, such as a named graph, and i is a metadatum, e.
It borrows its conceptualization from the photography domain  [37]. As in photography, Frappe represents the world as a sequence of frames and events occurring within a spatio-temporal context. Listing 4 shows how Frappe can be use to model the dataset from the running example. Frappe borrows the instantaneous concept Event from the EventOntology. The Event concept represents something that happened in the real world at a given time. Notably, both SAO and Frappe make use of the OWL Time ontology to represent temporal concepts (see Listing 4 at line 17). Similarly to SAO, Frappe identifies time-varying concepts frp:Pixel and frp:Frame, which respectively correspond to the results of continuous computations over the Events occurring in a Cell or Grid. (see Listing 4 at lines 26 and 29. ) Frappe represents the continuous computations through the concepts frp:Capture and frp:Synthesize (see Listing 4 at line 34).
Annotate The annotation step of the lifecycle focuses on converting streaming data into a machine-readable format. As for Linked Data, RDF is the data model of choice for publishing data on the Web. However, data streams are not always produced directly in RDF. For instance, in the IoT, sensors usually push observations using a tabular format like CSV or document formats such as JSON. In many applications, data are also compressed to save bandwidth and reduce transfer costs. To tackle these problems, a conversion mechanism must be set up that can transform the data stream into a machine-readable format. In order to design an adequate conversion pipeline, the following questions should be answered first: • What is the model of the input data and what is the expected output? • Is there any contextual information that can be used during the conversion? • What mapping language is best suited for the conversion? • How can the streaming temporal dimension be treated during the annotation? The domain ontologies designed during the modeling step should be used in the conversion pipeline to annotate the raw data to the RDF model.
Additionally, streaming data may be combined with more contextual domain knowledge, which allows capturing the domain information collected in an ontological model. The result of the annotation step should shape the original stream as an RDF stream, according to the decision made at the previous step of the lifecycle. Thus, the RDF molecule described in the Shape step, also plays an important role in the annotation process. Technologies like R2RML  [29]  and RML  [31]  are adequate to set up static data conversion pipelines, but they are suited to deal with data streams. 14 In particular, due to the infinite nature of streaming data, the conversion mechanism does not terminate if it operates under the same assumptions used for static dataset annotation. In the literature, the most common workaround for this problem consists of annotating the stream one element at a time.
Describe The Describe step of the life cycle aims at providing useful representations of the data streams to be consumed by humans and/or Web agents. In practice, metadata must be written using formal language while sharing the used terminology. In the case of the description of static datasets, the use of standard vocabularies for metadata management, e. g. , DCAT or VOID, is established. Public data catalogues such as DataHub, Zenodo, or Google's dataset search then use the metadata for indexing purposes. The WebDataCommons indexes more than two million datasets that are annotated using schema. org. Although machinereadable metadata can be generated or extracted from the data, the curation work remains substantially manual. In addition, streaming data calls for domain-specific metadata that captures their time-varying nature.
The Stream Annotation Ontology (SAO) allows the publishing of derived data about IoT streams. SAO can represent both raw and aggregated data. The vocabulary allows the description of the VoCALS ✓ ✓ ✓ ✓ ✓ Apache 2 ✓ LDES ✓ ≃ ✓ CC SAO ✓ ✓ ✓ ✓ CC ✓ SORG ✓ ✓ ✓ ✓ CC ✓ aggregation transformations in depth. SAO relies on PROV-O to track the aggregation provenance and OWL-Time for the temporal annotations  [39]. Linked Data Event Stream (LDES) 17 defines a collection of immutable objects that evolve over time. It can describe both historical and real-time updates. LDES uses the TREE specification 18 for modeling the collections and data fragmentation purposes when the size of the collections becomes too large for a single HTTP response. TREE defines a collection of objects that adhere to a certain SHACL shape, and how these collections can be fragmented and interlinked using multi-dimensional HTTP pagination  [48].
SAO supports all the three metadata annotations. It is worth noticing the presence of specific classes and properties for annotating data quality by extending QOI. 22 LDES explicitly supports only contextual metadata as it directly relies on the TREE specification. Service. (A1) The FAIR prescription for serving data and metadata relies on standard protocols. While on the Web this usually means HTTP, it does not directly apply to streaming data that call for specific protocols. Except LDES, which inherits the HTTP access assumption from TREE, the other ontologies include a specific abstraction that aims at generalizing the access to the streaming data, i. e. , voc:StreamEndpoint, iots:Service, ces:EventService. License. (R1) All the selected ontologies have an explicit license. VoCaLS and LDES explicitly suggest associating a license with the annotated data streams.
Example 6. 4 (Cont'd). Carrying on the running example for the description step, Listing 6 describes the taxi stream using one of the presented vocabularies, i. e. , VoCaLS and DCAT Service metadata are listed at line 15 Provenance is limited to the publisher, see line 13, and could be extended for example by describing the annotation process. Finally, service metadata are listed at line 15. More details are given in Listing 7, which is discussed in the next section. Listing 6: Publishing taxi stream with Vocals and RSP-QL.
In addition, several streaming-oriented protocols exist (MQTT, CoAP  [53] , or STOMP  23. ) with as many advanced features, e. g. , pub/sub via topic management. However, they were not extensively used in the context of Web Stream publishing. Provisioning data does not only concern the choice of a protocol but also the data format. The recommendation is to follow the standard guidelines to share the stream metadata (e. g. , any suitable RDF serialization). On the other hand, for streaming data, the choice of serialization might hugely impact the performance  [41]. Moreover, Fernandez et al. [41]  clarified the need for a form of punctuation for the semantic stream that is called a molecule. Due to the strict latency constraints of stream processing applications, it is of paramount importance that the RDF stream serialization agrees with the molecule structure.
Finally, the RSP Services  [54]  allows to manage the stream resulting from a query either via WebSockets or asynchronous REST endpoint. Example 6. 5  (Cont'd). Carrying on the running example for the serving step, Listing 7 completes the stream descriptor presented in Listing 6 with the specification of the corresponding publishing service and access point. At line 4 the endpoint specifies the protocol, while at line 2 it specifies the format. In practice, multiple endpoints that provision alternative serialization of the stream is possible, following traditional content negotiation. Moreover, different protocols can be enabled to satisfy the needs of different clients. Listings 8 and 9 show the difference between the N-Quads and JSON-lD data formats, respectively. Listing 8: The RDF stream of taxi rides in N-Quads.
12 "@graph":{ "@id":"f0e58ce1c485", "@type":"taxi: PickUpEvent" } } Listing 9: The RDF stream of taxi rides in JSON-LD. Finally, streaming data are exchanged across actors that expose, provision, and manipulate them. In traditional Web architecture, the notion of Agent or Service was dedicated to identifying the actors interested in or responsible for given resources. In the content of SLD, a Web Stream Processing Service or Agent (if they employ some AI technique  [55] ) is a special kind of Web service that manipulates Web streams and, in particular, RDF Streams. Definition 6. 3. A Web Stream Processing Agent/Service (WSP) is a special kind of Web service that manipulates Web streams and, in particular, RDF Streams. Three main types of Web stream services are relevant for the SLD lifecycle: (i) Catalogs that provide metadata about streams, their content, query endpoints and more.
(ii) Publishers that publish RDF streams, possibly following a Linked Data compliant scheme (e. g. TripleWave in  Listing 10). (iii) Processors, which model a Stream Processing service that performs any kind of transformation on streaming data, e. g. querying. Intuitively, the first two services are relevant within streaming data publication, while the latter is relevant for querying and, thus, will be discussed in detail in the next section. Catalogs are a common abstraction in the Web of Data due to the widespread need for dataset search. Nonetheless, existing data catalogues are not capable to capture the data stream semantics. Specialized RSP Catalogs can interpret the semantic annotations (see Annotation Step) and enable streaming data discovery. The adoption of vocabularies like those mentioned above are steps towards solving this issue.
g. , Pearson correlation. Table  8  summarizes the analysis for the selected projects that provided detailed information regarding their Query step. Finally, to aid comprehension, the section provides a visual representation using the taxi example. Data streams are collected very close to their source at highfrequency with limited focus on data quality. Therefore, they are often filled with redundant, noisy, and non-relevant data. Therefore, data cleansing is a necessary step for most applications. In the mentioned frameworks, filtering is a stateless operation, i. e. , it operates on a single stream element at a time. In these cases, filtering is possible using traditional relational selection (σ ) or Triple pattern matching. More sophisticated forms of filtering are possible, e. g. , STAR-CITY employs the full expressive of SPARQL to select data from a view over the input sources.
An example of filtering from CityPulse requires removing observations regarding parking with no vacancy or selecting locations with low congestion levels; Example 6. 7. Listing 11 presents the filtering practice for the taxi examples. From the stream of taxi rides, the filter removes non-Dropoff events and outputs a DropOffEvent stream. Due to strict latency requirements, it is often a good idea to reduce the information to the minimum when publishing data streams. However, sometimes is necessary to put items in context by enriching streaming data with static ones. Indeed, static and slowly-evolving data should not be repeatedly streamed but instead made available with the stream's metadata. In CityPulse, Agri-IoT, and Optique, sensors' positions and rates evolve much slower than sensors' observations.
Therefore, it is reasonable to keep such metadata separate from the sensors' measurements and assume them as static. Sensor metadata enriches streaming observations with geo-spatial context, measure precision, or units of measure. Moreover, Optique also includes configuration regarding the platform as static metadata. Finally, BOTTARI and STAR-City show enrichment cases with sensor data joined with POIs, traffic, and weather history. Example 6. 8. One way to enrich the taxi ride stream is by linking the drop-off or pick-up locations with the static city map, which allows linking the Points of Interest near the drop-off or pick-up locations. The RSP-QL query to perform this enrichment is shown in Listing 12. The enrichment is done through the variable ?place that occurs both in the ride stream and in the static city map graph.
Similar to enrichment, lifting allows to leverage an external context for enhancing the analysis. In particular, logical reasoning can abstract the data in the stream to higher-level concepts defined in the domain knowledge. This can be useful for integration purposes. Considering the aforementioned frameworks, neither BOTTARI nor SLD performs any lifting. On the other hand, STAR-CITY and Agri-IoT adopt standard knowledge representation languages, i. e. , OWL 2 EL and RDFS, to define knowledgebased. CityPulse uses Answer Set Programming to perform lifting. Domain knowledge is captured in form of rules that are leveraged to raise the abstraction level of streaming data and operate on more complex concepts. Also, Streaming MASSIF employs Description Logics to abstract event types and combines them using complex event recognition rules.
Indeed, merging streams together is a standard practice in most commercial streaming applications. Without going indepth about streaming join algorithms, this section distinguishes two main approaches to merging, i. e. , Splice and Cross. The former consists of the point-wise union of two-stream without any temporal evaluation. This approach is common when multiple sources are annotated and converted locally, while data are rerouted within a mixed factory. Multiple streams can be combined to extend the analysis expressivity. Merging include both splice, i. e. , the element-wise union of two RDF streams, and crossing, i. e. , time-based windowed joins. For example, streams from different parking lots can be spliced into one and crossed with one or more streams that monitor the streets in the last 15 min.
Aggregations are an important querying step in RSP, as it allows to summarize the data that is captured inside a certain window. In summary, the query step of the lifecycle is the one with the highest maturity from a system standpoint: BOTTARI and SLD use the C-SPARQL engine to implement the querying step of the lifecycle. At the same time, AgriIoT, SpitFire, OpenIot and CityPulse also include a second RSP engine, i. e. , CQELS engine, for optimizing latency. Finally, STAR-CITY and Optique implement custom solutions. The former relies on existing reasoners for ontology stream reasoning, while the latter leverages ontologybased data access technologies for translating the queries that later developed into STARQL  [56]. Although each project organizes the pipeline independently, we can notice how they all agree on the design and implementation.
Related work In this section, we discuss the related work positioning our survey in the stream reasoning literature. At the center of our investigation, there is the life cycle of stream reasoning applications. Nonetheless, as the title suggests, the proposal of  [9]  is the first attempt to formalize the steps. On the other hand, there have been a number of proposals for non-SLD life cycles. The closest proposal to  [9]  is the one by Hyland et Wood  [57]. Indeed, Tommasini et al. explicitly reuse the same steps to stress the generality of the SLD approach. The main difference, which appears in all the traditional Linked Data life cycles, lies in the continuous nature of each step. Despite Hyland and Wood taking the problem of maintenance into account while facing dataset updates, the published resources are assumed to be finite.
This aspect emerges clearly in those steps that involve algorithmic work, e. g. , Conversion. Steps of the Life Cycle (underlying the relevant ones): Identify, Model, Name, Describe, Convert, Publish, Maintain. Auer et al. [58]  describe LOD2, i. e. , a tool that integrates different resources to support a circular life cycle. Their proposal contains eight steps. However, the authors recommend that such steps shall not be taken in complete isolation. The steps, which are listed below, are tailored for handling data that change slowly or not at all. Indeed, the proposal includes a storage step. On the other hand, both authoring and evolution/repair hint at the possibility of time-varying linked data. Nonetheless, neither LOD2 nor the described process suggests any continuous processing approach.
Maturity of the lifecycle steps In our investigation, we discern the presence of two underlying assumptions • A1: the Web architecture and its extensions are adequate for the distribution and consumption of data streams; • A2: Semantic technologies, except those related to querying, are sufficient to implement the life cycle steps. Such assumptions influenced the progress of research on Streaming Linked Data and, thus, the formulation of research questions and the emergence of best practices. Below we discuss our findings according to A1 and A2. Identify -Maturity: High (green). The identification step focuses on naming data streams as Web resources, i. e. , assigning an IRI. As a consequence of A1, HTTP IRIs are adopted for stream resource identification. This emerges also in state-of-the-art proposals  [20, 33].
On the other hand, time-varying concepts change over time. They represent the two conceptual sides of a streaming application that operate on the elements in a stream. (ii) Mind the Static-Streaming Gap: When modeling the application domain it is important to take into account links between static and streaming data. Such links should be time-agnostic and ease tasks like streaming data enrichment and augmentation. (iii) Representing Continuous Computations: Identifying continuous computations allows for characterizing the streaming application workflow. Moreover, they link instantaneous and time-varying concepts, enabling provenance tracking for streaming analyses and transformations. Relaxing A2 implies the investigation of continuous knowledge representation languages that are able to incorporate continuous computations in the language semantics.
To the best of our knowledge, such languages were not yet proposed. Nor a knowledge engineering method that is suitable for representing ephemeral knowledge. Therefore, we consider the maturity level medium. Shape -Maturity: Low (red). The shaping step concerns the choice of a data model. Currently, little work has been done which directly derives from A1, i. e. , RDF objects like triples, graphs, and datasets are used within the SLD context. We recommend to Align Shape and Instantaneous Concept. Notably, the stream shape directly impacts different aspects of the ingesting, e. g. , parsing and filtering. Aligning it with the instantaneous concepts simplifies the design of efficient querying steps. Without relaxing A2, the introduction of recent work such as SHACL are being investigating by the SR community.
Therefore, we consider the maturity level low. Annotate -Maturity: medium (yellow). The annotation step focuses on converting non-RDF streams into RDF ones to increase interoperability. On the one hand, such a step partially relaxes A2 as a minimal extension of RDF is adopted for SLD. However, such an extension does not impact RDF semantics but introduces a simple form of punctuation to order RDF objects. In addition, as for Step 1, mapping languages like R2RML/RML are designed for static data conversion. Therefore, we identified the following best practices when A2 holds: (i) Use Semantic Streams: like for Linked Data, the recommendation is to adopt semantic streams to foster data sharing and integration. (ii) Avoid Temporal Data Annotation: due to the limitations of existing mapping languages, it is recommended to annotate element by element or adopt a microbatching approach to ensure the termination of the conversion process.
Relaxing A2 would call for novel mapping languages that capture the continuous aspect of the annotation process. A step towards this direction is the work of Calbimonte et al. [44]  that extends the mapping language to incorporate windows. However, they propose a syntactic extension tailored for rewriting. Thus, we rank the maturity level as medium. Describe -Maturity: medium (yellow). The description step covers the need for extensive and interoperable metadata. Both assumptions directly impact such a step, as the access to data stream metadata follows traditional interaction patterns of the Web (client/server). Moreover, the focus has been on static stream metadata (e. g. , licensing and access). Nonetheless, some stream metadata are time-varying, e. g. , stream rate in the last 5 min. Under the aforementioned assumptions, it emerges the recommendation to Use Specialized Vocabularies, e.
g. , VoCaLS or SAO. Streamspecific metadata allows to correctly interpret the streaming data semantics, improving discovery. Moreover, they simplify the automation that concerns streaming linked data access. Relaxing the assumptions would allow imagining alternative Web representations for streaming data. Currently, this speculation is beyond the scope of this survey. Moreover, research in this direction is active. In summary, the maturity level is medium. Serve -Maturity: high (green). The serving step discusses how streaming data sharing, including their metadata, is done in practice. The emerging assumptions directly influence such a step. Indeed, the existing proposals adopt a client/server interaction pattern, except for web-socket-based communication (A1). Moreover, standard data formats are adopted for sharing data streams on the web.
Under such assumptions, we identified three best practices: (i) Use HTTP for metadata and Continuous Protocol for Streams: When publishing Web streams, it is essential to guarantee the reactivity of the stream content consumption as well as the backward compatibility of metadata retrieval. (ii) Use RDF Serialization that simplifies time annotation: in the absence of a standard RDF serialization, adopt those that simplify the temporal annotation, i. e. , JSON-LD and N-Quads. (iii) Describe known Services that are related to stream: Adding metadata about the services that are related to the stream helps contextualize the origin of the provided information and track the data's provenance. Relaxing assumption A1 suggests rethinking an interaction pattern tailored for streaming resources. For instance, content negotiation could be extended to obtain a streaming representation of a certain resource.
(b) Keep Static Data Small: To avoid performance loss in case of enrichment, keep the static data small and, whenever necessary, apply a cleansing technique to avoid errors. (c) Little Semantics goes the long way: Query rewriting is possible under certain conditions that limit the expressivity of the knowledge representation language. However, it gives substantial advantages in the streaming context, due to the long-lasting nature of continuous queries. (d) Opt for Crossing when streams are not synchronized: When the streams have different rates windowbased merging is preferred as it regularizes the output. (e) Use time-based windows to scope advanced practices: When it comes to Synthesizing, using window-based computation can reduce the computational effort. In practice, window-based processing trades latency for throughput, reducing the performance stress on the system.