Special Issue on Stream Processing, Call for Papers

Another call for papers: the Journal of Web Semantics invites submissions to a special issue on Stream Processing to be edited by Monika Solanki and Jean-Paul Calbimonte. Submissions are due by 1st July 2015.

(I am on the Programme Committee.)

Important Dates and Submission Guidelines

From the call:

[...] we expect submissions on (but not restricted to) the following topics.

Processing RDF Data Streams
    Producing and consuming streams of RDF graphs
    Modelling streams of structured data
    Theoretical modelling of RDF streams
    Automatic annotation of raw data streams
    Processing noisy data, uncertainty, incomplete information
    Semantic mining of RDF data streams
    Mechanisms for integrating historical data with streaming data
    Publishing Linked Stream Data
Querying semantic streams of data
    Extensions to SPARQL for data streams
    Complex event processing on semantic data
    Ontology-based data access to data streams
    Data dynamics, update, and synchronization
    Optimisation of stream query processing
    Correctness of stream query processing
    Synthetic RDF streams and benchmarking
Reasoning with data streams
    New stream reasoning algorithms
    Incremental reasoning on dynamic ontologies
    Temporal logics for reasoning over Semantic streams
    Multicore scalable stream reasoning
Applications of stream processing
    Semantic sensor networks
    Social network streams and microposts
    Stream processing in the Internet of Things
    Smart cities
    Activity streams
    Gamification

Workshop on Situation Recognition (SIREMTI2015)

UPDATE 2: The deadline for submissions was extended to 30th September, 2015.

UPDATE: The workshop was relocated to MobiCASE2015 conference in November
2015, Berlin, Germany. The deadline for submissions is currently 11th September 2015.

(I am on the Programme Committee.)

Important dates and submission information: Workshop Homepage

From the CfP:

This workshop aims at merging research works relevant to mining temporal information from any kind of data with a special focus on (but not limited to) the following methods:

  • Trend Mining
  • Temporal Data Mining
  • Topic Mining and Mining of Users Posts
  • Data-based Situation Recognition
  • Intelligent Situation Recognition
  • Wireless Data Mining
  • Signal Detection and Analysis
  • Complex Event Processing and Messaging Analytics
  • Semantic Complex Event Processing
  • Data Stream Processing
  • Data Mining on Streaming Data
  • Semantic Technologies for Situation Recognition

An RDF Model for Events

Event Model - Class Diagram

Why do we need an event model? Many RDF streaming systems discussed have little or no model for the real-time data they ingest. These systems make the lowest common assumptions about the structure of the data, i.e. that the data consist of a stream of RDF triples. Thus, each piece of real-time data (event) is one triple. One triple, however, cannot hold a lot of information. For example: flexibility in timstamping (one vs. two timestamps or application time vs. system time) is only possible if timstamps can be attached to event structure. Flat triples cannot do that. Another example is when typing data, the triple <myInstance> rdf:type <MyClass> can introduce a type, but the event (one triple) is "full". This means that any structure in the data must be inferred from more than one event. However, consumers cannot make assumptions about events which are not yet received: Events occur spontaneously and event consumers are often decoupled from the senders (cf. publish/subscribe systems). Therefore, structure is needed in individual events.

Events should be self-describing. A common understanding of data is crucial for consumers and producers 1, especially in a distributed and heterogeneous system such as the Web. Therefore, a consumer must find a way to understand received events which entails the need for a universal event model 1.

Model

The figure shows the event model in a class diagram 2. The class "Event" at bottom left of the figure is the superclass for any event to conform to our model. This class makes use of related work by inheriting from the class "DUL:Event" from Dolce Ultralight based on DOLCE 3. That class provides a notion of time and helps distinguish events (things that happen) from facts (which are always valid).

Event Model

In accordance with our requirements 2 some properties are mandatory while the rest are optional. An instance of class Event MUST have (i) a type, (ii) at least one timestamp and (iii) a relevant stream. We describe the event properties in detail as follows.

The type of an event must be specified using rdf:type. The type must be the class Event or any subclass.

The event model supports interval-based events as well as point-based events by either using just the property :endTime for a point or both :startTime and :endTime for an interval. The property :endTime thus has a cardinality of [1..1] whereas :startTime has a cardinality of [0..1]. Both temporal properties are subproperties of DUL:hasEventDate from the super class. We improve the semantics by distinguishing start from end whereas the superclass has an alternative, more difficult way of formulating intervals using subobjects reifying the interval.

The property :stream associates an event with a stream. Streams are used in our system as a unit of organisation for events governing publish/subscribe and access control. Streams themselves are modelled using title, description and a topic needed for topic-based publish/subscribe.

The first optional property is :location. For for geo-referencing of events (where necessary) we re-use the basic geo vocabulary from the W3C 4. The property may be used to locate events in physical locations on the globe. The property is subproperty of DUL:hasLocation and geo:location to inherit the semantics from those schemas.

Inter-event relationships may be supported by linking a complex event to the simple events which caused it. Thus, RDF Lists may be used in :members to maintain an ordered and complete account of member events. The linked events are identified by their URI. These linked events could have further member events themselves. This facilitates modelling of composite events 5. The :members property is a subproperty of DUL:hasConstituent from the superclass.

The property :eventPattern may be used to link a complex event to the pattern which caused the event to be detected. Direct links to event patterns may be provided by RESTful services. Using such links can help in recording provenance of derived events.

The source of an event may be specified using the :source property. This is an optional property to record the creator of an event where needed. The property is a subproperty of DUL:involvesAgent. Agents may be human or non-human.

A human readable synopsis of an event may be added using the :message property. This proves useful in scenarios where events are received by human end users. The :message property is a subproperty of dc:title, a popular way of describing things using natural language. Multilingualism is provided by the feature of language tags for string literals in RDF 6.

N-ary predicates 7 may be used to maintain event properties which are valid only for a specific event, e.g. a volatile sensor reading such as the temperature measurement belonging to a specific event. For example, instead of plainly stating the disputable fact that "the city of Nice has a temperature in Celsius of 23 degrees" which looks like this:

dbpedia:Nice :curTemp "23" .

We can instead state that the city of Nice has said temperature but qualified by the conjunction with a given event "e2" in the following n-ary predicate:

dbpedia:Nice :curTemp [
    rdf:value "23" ;
    :event  <http://events...org/ids/e2#event>
] .

Endowment of further structure for events is left to domain-specific schemas. For example the W3C Semantic Sensor Network (SSN) Ontology may be added if fine-grained modelling of sensors and pertaining sensor readings is needed.

Example

The listing below shows several facts about our event model along an example. The listing uses the example of a Facebook event generated by our event adapter described in 2.

@prefix :       <http://events.event-processing.org/types/> .
@prefix e:      <http://events.event-processing.org/ids/> .
@prefix user:   <http://graph.facebook.com/schema/user#> .
@prefix xsd:    <http://www.w3.org/2001/XMLSchema#> .

e:5534987067802526 {
    <http://events.event-processing.org/ids/5534987067802526#event>
        a :FacebookStatusFeedEvent ;
        :endTime "2012-03-28T06:04:26.522Z"^^xsd:dateTime ;
        :status "I bought some JEANS this morning" ;
        :stream <http://streams...org/ids/FacebookStatusFeed#stream> ;
        user:id "100000058455726" ;
        user:link <http://graph.facebook.com/roland.stuehmer#> ;
        user:location "Karlsruhe, Germany" ;
        user:name "Roland Stühmer" .
}
  1. The example shows an event using quadruples in TriG syntax 8. The graph name (a.k.a context) before the curly braces is used as a unique identifier, e.g. to enable efficient indexing of contiguous triples in the storage backend for historic events.
  2. The event in this example has the ID 5534987067802526 as part of its URI. There is a distinction made between URIs for things and URIs for their information resources, i.e. the event object 5534987067802526#event and the Web document 5534987067802526 describing the event. The two URIs might carry, e.g. a different creation date, which is why it can be important to separate them. The fragment identifier #event is used to differentiate them. See 9 for an in-depth discussion of the matter of disambiguation (also known as the httpRange-14 issue).
  3. There is an event type hierarchy from which the type Facebook-StatusFeedEvent is inherited. This hierarchy can be extended by any user by referencing the RDF type :Event as a super class.
  4. The event may link to entities from static Linked Data where further context for the event can be retrieved. In this example the event uses user:link where further context for the event can be retrieved, in this case from the Facebook Graph API. Facebook started publishing Linked Data as RDF 10.
  5. The event links to a stream which is a URI where current events can be obtained in real-time by dereferencing the link.
  6. The namespace event-processing.org is chosen as a generic home for this schema.

Conclusion

We are re-using and creating domain vocabularies to subclass the class Event. For example in the Facebook case we use the schema from the RDF/Turtle API provided by Facebook 10.

We developed this event model to satisfy requirements of an open platform where data from the Web can be re-used and which is extensible for open participation. Future updates to the event schema can be tracked on-line at 11.


  1. Rozsnyai, S.; Schiefer, J. & Schatten, A. Concepts and models for typing events for event-based systems Proceedings of the 1st ACM International Conference on Distributed Event-Based Systems, ACM, 2007, 62-70 

  2. Stühmer, R. Web-oriented Event Processing Karlsruhe Institute of Technology, KIT Scientific Publishing, Karlsruhe, 2014 

  3. Gangemi, A.; Guarino, N.; Masolo, C.; Oltramari, A. & Schneider, L. Sweetening Ontologies with DOLCE Proceedings of the 13th International Conference on Knowledge Engineering and Knowledge Management. Ontologies and the Semantic Web, Springer-Verlag, 2002, 166-181 

  4. Brickley, D. Basic Geo (WGS84 lat/long) Vocabulary, 2003 

  5. Luckham, D. C. & Schulte, R. Event Processing Glossary – Version 2.0, 2011 

  6. Klyne, G. & Carroll, J. J. Resource Description Framework (RDF): Concepts and Abstract Syntax 2004 

  7. Noy, N. & Rector, A. Defining N-ary Relations on the Semantic Web World Wide Web Consortium, 2006 

  8. Bizer, C. & Cyganiak, R. RDF 1.1 TriG, 2014 

  9. Berners-Lee, T. What HTTP URIs Identify? — Design Issues, 2005 

  10. Weaver, J. & Tarjan, P. Facebook Linked Data via the Graph API Semantic Web Journal, IOS Press, 2012 

  11. Harth, A. & Stühmer, R. Publishing Event Streams as Linked Data Karlsruhe Institute of Technology, FZI Forschungszentrum Informatik, 2011 

Definition of “Event” for Event Processing

I collected some definitions of event from the view of event processing research and practise. The emphasis is mine:

  • (Etzion & Niblett 2010)1 wrote:

    An event is an occurrence within a particular system or domain; it is something that has happened, or is contemplated as having happened in that domain. The word event is also used to mean a programming entity that represents such an occurrence in a computing system.

  • (Luckham & Schulte 2011)2 wrote:

    Anything that happens, or is contemplated as happening. Or: An object that represents, encodes, or records an event, generally for the purpose of computer processing.

  • (Gupta and Jain 2011)3 wrote:

    Events are first-class objects which means a fundamental information unit which can be stored, queried and merged with other events

  • (Hinze & Voisard 2002)4 wrote:

    An event is the occurrence of a state transition at a certain point in time.

  • (Michelson 2006)5 wrote:

    A notable thing that happens inside or outside your business.

  • (Mühl et al. 2006)6 wrote:

    Any happening of interest that can be observed from within a computer is considered an event. […] A notification is a datum that reifies an event, i.e., it contains data describing the event.


  1. Etzion, O. & Niblett, P. Event Processing in Action Manning Publications Co., 2010 
  2. Luckham, D. C. & Schulte, R. Event Processing Glossary – Version 2.0, 2011 Link 
  3. Gupta, A. & Jain, R. Managing Event Information: Modeling, Retrieval, and Applications, Morgan & Claypool Publishers, 2011 
  4. Hinze, A. & Voisard, A. A parameterized algebra for event notification services Ninth International Symposium on Temporal Representation and Reasoning, 2002. TIME 2002, 2002 
  5. Michelson, B. M. Event-Driven Architecture Overview Patricia Seybold Group, Feb, 2006 Link 
  6. Mühl, G.; Fiege, L. & Pietzuch, P. Distributed Event-Based Systems Springer-Verlag New York, Inc., 2006 

Highlights from Research Project PLAY

My research project PLAY has had its final review meeting on Tuesday, November 26th, 2013.

Notable highlights from the project are:

  • Use of open Web Standards for event modelling, pattern modelling, access control for real-time/streaming data
  • Integrated Prototype (delivering a runnable architecture with all Open Source components)
  • Contribution to Open Source community, e.g. continued maintenance of RDF2Go, MultiActive objects for ProActive

Benefits PLAY can provide as a semantics-based event-driven platform for a use case of nuclear crisis management:

  • Eliminating superfluous, inaccurate or irrelevant information
  • Automating some analysis or actions based on predefined business rules
  • Reducing the time of information transmission between devices, stakeholders and decision makers
  • Increasing the reliability of knowledge (exhaustiveness)
  • Improving the agility capability of the crisis stakeholders

Benefits and opportunity PLAY can provide as an Event-driven Architecture and elastic platform to ORANGE Telecom:

  • QoS problems experienced by customers of LiveBox Pro can be detected in real-time
  • Improvement of knowledge about customer experience, reduction of after-sales costs with residential customers of 2G/3G data mobile services
  • Ability to to compare/challenge other Open Source platforms with PLAY such as Storm/kafka  + Hadoop/Hbase and commercial middleware products

Links:

  1. Opher Etzion (who is reviewer of PLAY together with Silvia Vecchi) blogged about PLAY: http://epthinking.blogspot.de/2013/11/on-play-project.html
  2. Project reports and published papers are here: PLAY publications

Tutorial on Complex Event Processing

Videolectures - Tutorial on Complex Event Processing

I gave a tutorial about Complex Event Processing and more specifically the PLAY semantic event format and query language at the Winter School on Knowledge Technologies for Complex Business Environments in Ljubljana on December 2, 2011 at the Faculty of Mechanical Engineering (FME).

CEP – Complex Event Processing
Roland Stühmer

Abstract:

Real-time has become one of the crucial characteristics of modern applications and is completely changing the game in the data processing. Due to its capability to support continual monitoring, real-time data processing has become a very important mechanism in many application areas: traffic management, logistics, eHealth, smart grids, to name but a few. In this talk we present technologies to deal with real-time data on-the-fly, challenges and possible solutions to deal with these challenges such as using Web-friendly standards to create open and extensible systems for real-time data.

See also: