Since the mid 2000s', the Linked Data principles, and the tools they inspired, became a solid foundation for a decentralized yet connected Web of Data where static (or slowly evolving) data can be shared and traversed. However, the growing popularity of (fast) streaming data is now calling for an extension of Linked Data towards a Web of Data Streams. In this paper, we identify several challenges to solve towards this vision. Moreover, we present VoIS, a Vocabulary of Interlinked Streams, and we show how it contributes in addressing such challenges.
Like static data, streams are referenced using URIs. Cross Links, i.e. the navigation from one data source to another, is possible from data items owing in the streams to Linked Data, but it is unclear how the opposite can work in the general case, due to the volatile nature of those owing data items.
Stream representation is an open problem. While many vocabulary are available to describe datasets, e.g. VoID, Dcat, DC terms, none of them is suitable to represent a data stream. Listing 1.1 clearly shows that some information is missing when we deal with streaming data. See for instance Line 9, how can we expect to dump a potentially in nite data stream? Moreover, the dump will be continuously updated, but how can we describe this phenomena? One may argue that Partition (see Lines 10-16) can solve the issue, but still metadata to describe the Window (e.g., length, starting time, or periodicity) are missing.
Last but not, streams are not generally served via HTTP. 1 : M i l a n T r a f f i c D S a v o i d : Dataset ; # No datastream c o n c e p t 2 dcterms : s u b j e c t dbc : T r a f f i c ; 3 dcterms : s u b j e c t dbc : Milan ; 4 dcterms : t i t l e " Milan t r a f f i c stream " ; 5 dcterms : d e s c r i p t i o n " Streaming t r a f f i c a s p e c t o f milan a r e a s " ; 6 terms : l i c e n s e <h t t p s : / / creativecommons . org / l i c e n s e s /by nc /4.0/ > ; 7 f o a f : homepage <http : / /www. example . com/ >; 8 v o i d : v o c a b u l a r y <http : / / dbpedia . org/> ; 9 v o i d : dataDump <http : / /www. example . com/dump . t t l > ; 10 v o i d : c l a s s P a r t i t i o n [ v o i d : c l a s s f o a f : O r g a n i z a t i o n ; ] ; 11 v o i d : p r o p e r t y P a r t i t i o n [ v o i d : p r o p e r t y f o a f : name ; ] ; 12 v o i d : s u b s e t : Window 1 . 13 : Window 1 a v o i d : Dataset ; 14 dcterms : t i t l e "Window o f Milan t r a f f i c stream " ; 15 dcterms : d e s c r i p t i o n "Window o f Milan t r a f f i c stream " ; 16 v o i d : dataDump <http : / /www. example . com/dump . t t l > .
Listing 1.1. VoID limits for stream representation
Linked Data Noti cation (LDN) [
Velocity in Linked Data [
In this paper, we investigate the following research question: Can we represent and publish data stream on the Web as Linked Data? In order to answer such a research question, we designed VoIS1, i.e. a Vocabulary of Interlinked Datastreams (VoIS), which is the main contribute of this paper.
The remainder of the paper is organized as follows. Section 2 reports on the requirement analysis we conducted starting from the challenge we perceive in Web of Data Streams. Section 3 illustrates the overall solution we propose with our Vocabulary of Interlinked Datastreams (VoIS). Section 4 explains how VoIS can be used to address the challenges introduced in Section 2. In Section 5, we position VoIS w.r.t. the state of the art. Finally, in Section 6, we draw some conclusions. 2
In this section, we present the challenges that we perceive in the Web of Data Streams. By discussing them, we elicit the requirements for a vocabulary able to positively answer our research question. Table 2 summarizes our requirement analysis.
Challenges Requirememnts Stream Discovery Metadata are required to enable lookup, selection, linking, and licensing of streaming data sources in a decentralized way.
Stream Access Applications must be able to negotiate access to data via streaming protocols and standards.
Stream Recall At least the most recent part of a data stream must be accessed via
Linked Data standards and protocols.
Provenance The provenance of operations that can generate, manipulate or delete a stream must be tracked.
Table 2. Challenges and requirements in the Web of Data Streams
Stream Discovery. For a Linked Data application, discovery is the process of
nding available datasets that are relevant to a certain task [
A vocabulary must enable the discovery process by specifying which annotations are relevant for a data stream, e.g. stream rate, source and content information. Moreover, it is worth to mention that licensing plays a crucial role in a decentralized Web environment where actors can exchange data for goods. Stream Access. In Linked Data, access usually refers to the problems of fetching a data dump or delegating the SPARQL query execution to some endpoint.
Generally, streaming data are not served using HTTP nor queried using Linked Data standards (RDF/SPARQL). It is rather provisioned via streaming APIs or queried by means of systems that support continuous queries.
A vocabulary is needed to de ne how to access streams, what are the available
options and who can access them. Moreover, it must describe, if the access
requires any extensions beyond HTTP-based content negotiation mechanisms.
Stream Recall. Changes in Linked Data are usually handled by versioning
system and data dumps; this allows to query the previous version of a dataset
by means of specialized endpoints and SPARQL extensions [
Unfortunately, a general assumption for stream processing is that streams are theoretically unbounded and it is not possible (or meaningful) to store them entirely. This practically means that any attempt to access streaming data with one-time queries hardly ends up with the same result twice.
A vocabulary must explain how to access past data when possible and how we can possibly do it using one-time access to data issued via traditional protocols (i.e. HTTP) and standards (RDF/SPARQL).
Provenance. A nal challenge regards tracking the provenance of those processes that generate or manipulate a data stream. Indeed, discovery, processing and recall need to trust the data provisioner and they have to be able to evaluate the semantics of the data stream. A vocabulary must capture the transformations that might in uence both the provenance of a stream as a whole and the one of the various time-varying data items that ow in the data stream. 3
In this section, we introduce the rst version of the Vocabulary of Interlinked Datastreams (VoIS) which extends VoID to represent streams as Linked Data.
As depicted in Figure 1, the following abstractions regulate
the de nition of a stream and, thus, the access to its content: a
(i) vois:InstantaneousStremElement is unit of content at a given time
instant. (ii) a vois:DataStream { which is usually served though a streaming
API [
VoIS design takes inspiration from the -architecture [
In this section, we show how VoIS solves the challenges we presented in Section 2. Table 3 summarizes how each requirement is satis ed in VoIS.
Challenges Vois Stream Discovery DataStream, SourceDescription and StreamDescription. Stream Access StreamEndpoint(ws), RSPEndpoint, SPARQLendpoint. Stream Recall FiniteStreamPartition, Windowing Provenance (S) StreamToRelation (R), R2R, R2S, S2S operators with PROV-O.
Table 3. Challenges and VoIS solutions for a Web of Data Streams.
Stream Discovery. As mentioned in Section 2, traditional data discovery is based on the dataset and endpoint metadata. Similarly, we identi ed di erent set of metadata to enable discovery of data streams: { stream metadata, i.e. time-varying metadata that refers to the stream content (e.g. rate), { source metadata, i.e. metadata that refer to the source of the stream (e.g.
sensor capabilities), { publication metadata, that connects sources, streams and possible samples and makes the stream actually ndable by means of registry or repositories.
VoIS allows to capture all these levels of metadata by means of three classes, i.e., vois:DataStream, vois:StreamSourceDescription, and vois:StreamDescription. Figure 3 depicts the structure of the representation, while Listing 1.2 shows an example that uses Dublin Core2 and VoID vocabularies for stream metadata about subject and licensing. SSN is used to describe the source, which is a sensor. The vois:StreamDescription is the le itself. Stream Access. In a Web of Data Streams, data are processed as soon as they arrive by systems capable to deal with information ows. Streaming data access relies either on protocols speci cally designed to reduce the overhead of the request or registering a continuous query to a Stream Processor that is exposed as an endpoint. Either ways require to extend the Linked Data content negotiation protocol to enable direct access and continuous querying, since streaming data are neither generally served using HTTP nor querable by with SPARQL engines.
VoIS captures this extension
by means of vois:Endpoint, that
describes the available endpoints
to access a data stream. Currently,
we de ned two types of endpoints
widely used in stream processing:
vois:StreamEndpoint that
represents streaming API (e.g. Web
Socket) [
Stream Recall. Versioning is not a traditional stream processing use-case, however, in a Web of Data Streams providing Liked Data compliant access to, at least, a recent part of past information serves the purposes of many applications.
In VoIS, we introduced two classes vois:InstantaneousStreamElement and vois:FiniteStreamPartition for this reason. As the name suggests, the former represents a single data item in the stream with temporal metadata, while the latter is a sample that contains stream elements. More precisely, we de ned vois:Window as a partition that is generated according to certain criteria and correspond to a time interval that contains some stream elements.
An crucial point is maintaining the order between stream elements. Indeed, anyvois:InstantaneousStreamElement are is linked with its predecessor by means of the property vois:previousElement. Similarly, any vois:Window is part of a list linked through the property vois:previousWindow.
Figure 5 illustrates the relation between window and stream elements. Thanks to these abstractions it is possible to locate and access stream data items in the past exploiting the temporal metadata as shown in Listing 1.3. 2 WHERE f ?w a v o i s : Window ; v o i s : s t a r t e d A t ? i n s t a n t . 3 ? i n s t a n t time : inXSDDateTime ? s . 4 FILTER( ? s > "2017 06 05T00 : 3 8 : 0 0 . 0 0 0 " ^^ xsd : dateTime . ) g Listing 1.3. SPARQL query retrieving window overlapping with speci c time instance Provenance. As mentioned in Section 2, two are the types of transformation that can in uence the provenance of a stream.
Figure 6 shows how the windowing mechanism is modeled in VoIS by means of PROV-O ontology. We used the Agent-Activity-Entity design pattern to represent the windowing action on a stream.
Figure 7 illustrates how to model Stream-level transformations in VoIS. A new relation vois:hasAffluent between streams was introduced to model the fact that a stream { namely a swollen one { is derived from others { namely a uent ones. Accordingly, two subtypes of streams are modeled: vois:SwollenStream to refer to a stream derived from other streams, and vois:AffluentStream to refer to stream contributing to a swollen stream.
In this section, we discuss the related work with regard to the challenges we presented in Section 2. Table 4 summarizes the discussion.
DCterms, DCAT and VoID. Several vocabularies exist to describe
dataset by means of metadata. Dublin Core Terms 3 is the rst one made to
describe both physical and Web resources. It provides fteen generic terms (eg.
Title, Creator, Subject and Description). Data Catalog Vocabulary (DCAT) [
None of these vocabularies fully solves the challenges we identi ed for a Web of Data Streams. They neither capture the dynamic nature of data stream nor to represent time-varying data elements. Although discovery is still possible relying on source metadata, streaming data access is never taken into account. Recall can be partially achieved by periodically creating dumps of the stream data. However, this approach does not scale well with streaming data. Provenance tracking is possible, but limited to stream data sources only.
Linked Stream Data [
Streaming Linked Data [
Linked Data Noti cation (LDN) [
In this paper, we advocated Data Streams as part of the Linked Data ecosystem. To this extent, we presented four challenges that we perceived in the Web of Data Streams. We elicit the requirements for a vocabulary able to support machines in automatically addressing those challenges in a decentralized environment and we contribute Vocabulary of Interlinked Datastreams (VoIS) as a solution.
VoIS has the potential to enable: { Stream Discovery { it allows identifying streams that are relevant to one task according to the metadata the publishers used to describe the nature of their streams, the endpoints where they can be accessed and any other relevant information (encoded with a specialized vocabulary). { Stream Access { it describes the information necessary to extend the Linked Data content negotiation approach in order to allow accessing data streams by the means of streaming APIs and consuming on the y the time-varying data that ows on them. { Stream Recall { it o ers a way for a stream publisher to exposed as Linked Data a recent portion of the (naturally unbounded) data streams and, thus, permits to issue one-time SPARQL query to recall recent time-varying data. { Provenance { it enables provenance tracking in terms of stream source and transformations both at the level of the entire data stream and at the level of the time-varying data elements that ow on it.
As for future works, evaluating the vocabulary both functionally and statistically is our current priority. We plan to do the former by asking for reviews to Semantic Web / Stream Reasoning experts, Linked Data practitioners and students. We plan to do the latter following ontology evaluation best practices.
Moreover, we are working on the implementations of a machinery (based
on [