## 4 Data Stream Management System in Haskell
### The Haskell Platform  
The advantages that Haskell brings in this landscape--lazy evaluation and implicit parallelism--are significant features when dealing with huge data streams that are parallel in nature. The parallel performing of reasoning tasks is of significant importance in order to provide answers in due time [3]. The Haskell's polymorphism allows to write generic code to process streams, which is particularly useful due to the different usages of the same data stream. The absence of side effects means that the  
Figure 2: The architecture of the PSRH (Plausible Stream Reasoning in Haskell).  
order of expression evaluation is of no importance, which is extremely desirable in the context of data streams coming from different sources.  
One challenge in answering many continuous queries in real-time is query optimisation. Allowing equational reasoning, the platform can be exploited for automatic program and optimising queries. A premise specified as lazy is matched only when its variables are anticipating to participate in the answer to a pending conclusion or query.  
The continuous semantics of data streams assumes that: (i) _streams are volatile_--they are consumed on the fly and not stored forever; and (ii) _continuous processing_--queries are registered and produce answers continuously [5]. In our case, the rules are triggered continuously in order to produce streams of consequents. The stateless feature of pure Haskell facilitates the conceptual model of networks of stream reasoners as envisaged in [26], where data is processed on the fly, without being stored.  
The lazy evaluation in Haskell provides answers perpetually, when the queries are executed against infinite streams. One does not have to specify the time steps when the query should be executed. By default, the tuples are consumed when they become available, and only in case they contribute to a query answer.  
The computational efficiency is supported by the fact that a function is not forced to wait for a data to arrive--the possible computations are executed instead. Moreover, one can use the about-to-come data by borrowing it from the future, as long as no function tries to change its value. The non-strict semantics of Haskell allows the functions not to produce errors that can be avoided. Consequently, some noise data can be avoided, without disturbing the computations.  
There is no constraint on the nature of data fed by a stream. The functions can be applied on RDF streams as follows: A triple object is created by the _triple_ function  
\begin{tabular}{l l} data Triple & = triple!Node!Node!Node \\ triple & :: Subject -\textgreater{} Predicate -\textgreater{} Object -\textgreater{} Triple \\ \end{tabular}  
**Definition 4**: _An RDF stream is an infinite list of tuples of the form \(\langle subj,pred,obj\rangle\) annotated with their time stamps \(\tau\)._  
\[type\ RDFSream=[((subj,pred,obj),\tau)]\]  
**Example 3**: _An RDF stream of auction bids comprises the bidder agent, its action (sell or buy), and the bid value:_  
\[[((a_{1},sell,30\$),14.32),((a_{2},sell,28\$),14.34),((a_{3},buy,26\$),14.35),((a_{1},sell,27\$),14.36)]\]  
In the first tuple the agent \(a_{1}\) wants to sell a specific item for 30$, the offer being made at the time step 14.32. The stream is implemented with the infinite list data structure in Haskell.