! ! Proceedings!of
! This volume contains the papers presented at DeRiVE2015: 4th Workshop on Detection Representation and Exploitation of Events in the Semantic Web held on Sunday May 31, 2015 in Portoroz (Co-located with the 12th Extended Semantic Web Conference - ESWC 2015)
In recent years, researchers in several communities involved in aspects of information science have begun to realise the potential benefits of assigning an important role to events in the representation and organisation of knowledge and media-benefits which can be compared to those of representing entities such as persons or locations instead of just dealing with more superficial objects such as proper names and geographical coordinates. While a good deal of relevant research for example, on the modeling of events has been done in the semantic web community, much complementary research has been done in other, partially overlapping communities, such as those involved in multimedia processing, information extraction, sensor processing and information retrieval research. However, these areas often deal with events with a di↵erent perspective. The attendance of DeRiVE 2011, DeRiVE 2012 and DeRiVE 2013 proved that there is a great interest from many di↵erent communities in the role of events. The results presented in there also indicated that dealing with events is still an emerging topic. The goal of this workshop is to advance research on the role of events within the information extraction and semantic web communities, both building on existing work and integrating results and methods from other areas, while focusing on issues of special importance for the semantic web.
We have defined questions for the two main directions that characterise current research into events on the semantic web. Orthogonal to that, we have identified a number of application domains in which we will actively seek contributions.
Question 1: How can events be detected and extracted for the semantic web? – How can events be detected, extracted and/or summarized in particular types of content on the web, such as calendars of public events, social media, semantic wikis, and regular web pages? – What is the quality and veracity of events extracted from noisy data such as microblogging sites? – How can a system recognise a complex event that comprises several subevents? – How can a system recognise duplicate events?
Question 2: How can events be modelled and represented in the semantic web? – How are events currently represented on the Web? In particular, how deployed is the schema.org Event class? Should scheduled events versus breaking events be represented the same way?
v – To what extent can the many di↵erent event infoboxes of Wikipedia be reconciled? How to deal with the numerous Timeline of xxx topics in knowledge bases? – How can existing event representations developed in other communities be adapted to the needs of the semantic web? To what extent can/should a unified event model be employed for di↵erent types of events? – How do social contexts (Facebook, Twitter, etc.) change the implicit content semantics?
Application Domains: Research into detection (question 1) and representation (question 2) of events is being implemented in various application domains. Known application domains that we target are: – Personal events – Cultural and sports events – Making something out of ”raw” events – Historic events and events in news and other media – Scientific observation events – Supply chain events Among the submissions we received, 6 papers were selected for full presentation at the workshop: – Jean-Paul Calbimonte and Karl Aberer - Reactive Processing of RDF Streams of Events – Selver Softic, Laurens De Vocht, Erik Mannens, Martin Ebner and Rik Van de Walle - COLINDA: Modeling, Representing and Using Scientific Events in the Web of Data – Michael F¨arber and Achim Rettinger - Toward Real Event Detection – Gregory Katsios, Svitlana Vakulenko, Anastasia Krithara and Georgios Paliouras - Towards Open Domain Event Extraction from Twitter: REVEALing Entity Relations – Loris Bozzato, Stefano Borgo, Alessio Palmero Aprosio, Marco Rospocher and Luciano Serafini - A Contextual Framework for Reasoning on Events – Jacobo Rouces, Gerard de Melo and Katja Hose - Representing specialized events with FrameBase
We would like to thank the members of the program committee and the additional reviewers for their time and e↵orts. All papers included here have been revised and improved based on your valuable feedback, thus setting the basis for an exciting workshop programme.
Finally, we would like to thank our sponsor, the Newsreader (www.newsreaderproject.eu) FP7 European Project, for funding the workshop.
Rapha¨el Troncy
Marco Rospocher Willem Robert Van Hage David A. Shamma Program Committee
Stefano Borgo Loris Bozzato Christian Hirsch Jane Hunter Tomi Kauppinen Azam Khan Erik Mannens Ingrid Mason Diana Maynard Adrian Paschke Giuseppe Rizzo Ansgar Scherp
LOA - CNR, Italy Fondazione Bruno Kessler University of Auckland, New Zealand University of Queensland, Australia Aalto University, Finland Autodesk Research, Canada Ghent University – IBBT, Belgium Intersect Australia Ltd University of Sheeld, UK Freie Universiteit Berlin, Germany EURECOM, France Kiel University and Leibniz Information Center for Economics, Kiel, Germany University of North Carolina at Chapel Hill, USA Google Inc, Germany CSIRO & Australian National University Agence France-Presse Reactive Processing of RDF Streams of Events
Jean-Paul Calbimonte and Karl Aberer Faculty of Computer Science and Communication Systems
EPFL, Switzerland.
firstname.lastname@epfl.ch Abstract. Events on the Web are increasingly being produced in the form of data streams, and are present in many dierent scenarios and applications such as health monitoring, environmental sensing or social networks. The heterogeneity of event streams has raised the challenges of integrating, interpreting and processing them coherently. Semantic technologies have shown to provide both a formal and practical framework to address some of these challenges, producing standards for representation and querying, such as RDF and SPARQL. However, these standards are not suitable for dealing with streams for events, as they do not include the concpets of streaming and continuous processing. The idea of RDF stream processing (RSP) has emerged in recent years to fill this gap, and the research community has produced prototype engines that cover aspects including complex event processing and stream reasoning to varying degrees. However, these existing prototypes often overlook key principles of reactive systems, regarding the event-driven processing, responsiveness, resiliency and scalability. In this paper we present a reactive model for implementing RSP systems, based on the Actor model, which relies on asynchronous message passing of events. Furthermore, we study the responsiveness property of RSP systems, in particular for the delivery of streaming results. 1
Processing streams of events is challenging task in a large number of systems in the Web. Events can encode dierent types of information at dierent levels, e.g. concerts, financial patterns, trac events, sensor alerts, etc., generating large and dynamic volumes of streaming data. Needless to say, the diversity and the heterogeneity of the information that they produce would make it impossible to interpret and integrate these data, without the appropriate tools. Semantic Web standards such as RDF1 and SPARQL2 provide a way to address these challenges, and guidelines exist to produce and consume what we know as Linked Data. While these principles and standards have already gained a certain degree of maturity and adoption, they are not always suitable for dealing with data streams. The lack of order and time in RDF, and its stored and bounded characteristics contrast with the inherently dynamic and potentially infinite nature
of the time-ordered streams. Furthermore, SPARQL is governed by one-time
semantics as opposed to the continuous semantics of a stream event processor.
It is in this context that it is important to ask How can streaming events can
be modeled and queried in the Semantic Web?. Several approaches have been
proposed in the last years, advocating for extensions to RDF and SPARQL for
querying streams of RDF events. Examples of these RDF stream processing
(RSP) engines include C-SPARQL [
Although these extensions target dierent scenarios and have heterogeneous semantics, they share an important set of common features, e.g. similar RDF stream models, window operators and continuous queries. There is still no standard set of these extensions, but there is an ongoing eort to agree on them in the community 3. The RSP prototypes that have been presented so far focus almost exclusively in the query evaluation and the dierent optimizations that can be applied to their algebra operators. However, the prototypes do not consider a broader scenario where RDF stream systems can reactively produce and consume RDF events asynchronously, and deliver continuous results dynamically, depending on the demands of the stream consumer.
In this paper we introduce a model that describes RSP producers and consumers, and that is adaptable to the specific case of RSP query processing. This model is based on the Actor Model, where lightweight objects interact exclusively by interchanging immutable messages. This model allows composing networks of RSP engines in such a way that they are composable, yet independent, and we show how this can be implemented using existing frameworks in the family of the JVM (Java Virtual Machine) languages. In particular, we focus on specifying how RSP query results can be delivered in scenarios where the stream producer is faster than the consumer, and takes into account its demand to push only the volumes of triples that can be handled by the other end. This dynamic push delivery can be convenient on scenarios where receivers have lower storage and processing capabilities, such as constrained devices and sensors in the IoT. The remainder of the paper is structured as follows: we briefly describe RSP systems and some of their limitations in Section 2, then we present the actor-based model on Section 3. We provide details of the dynamic push delivery on Section 4, and the implementation and experimentation are described in Section 5. We present the related work on Section 6 before concluding in Section 7. 2
In general RSP query engines can be informally described as follows: given as input a set of RDF streams and graphs, and a set of continuous queries, the RSP engine will produce a stream of continuous answers matching the queries (see Figure 1). This high-level model of an RSP engine is simple yet enough to describe most stream query processing scenarios. Nevertheless, this model, 3 W3C RDF Stream Processing Community Group http://www.w3.org/community/rsp and the existing implementations of it, does not detail how stream producers communicate with RSP engines, and how stream consumers receive results from RSP engines. This ambiguity or lack of specification has resulted in dierent implementations that may result in a number of issues, especially regarding responsiveness, elasticity and resiliency. To illustrate these issues, let’s consider first how streams are produced in these systems. On the producer side, RDF streams are entities to which the RSP engine subscribes, so that whenever a stream element is produced, the engine is notified (Figure 2). The issues with this model arise from the fact that the RSP engine and the stream producer are tightly coupled. In some cases like CSPARQL or SPARQLstream, the coupling is at the process level, i.e. both the producer and the engine coexist in the same application process. A first issue regards scalability: it is not possible to dynamically route the stream items from the producer to a dierent engine or array of engines, since the subscription is hard-wired on the code. Moreover, if the stream producer is faster than the RSP engine, the subscription notifications can flood the latter, potentially overflowing its capacity. A second issue is related to resilience: failures on the stream producer can escalate and directly aect or even halt the RSP engine.
Looking at the stream consumer side, the situation is similar. The continuous queries, typically implemented as SPARQL extensions, are registered into the RSP engine, acting as subscription systems. Then, for each of the continuous queries, a consumer can be attached so that it can receive notifications of the continuous answers to the queries (see Figure 2). Again, we face the problem of tightly coupled publisher and subscribers that have fixed routing configuration and shared process space, which may hinder the scalability, elasticity and resiliency of the system. Added to that, the delivery mode of the query results is fixed and cannot be tuned to the needs of the consumer.
It is possible to see these issues in concrete implementations: for instance in Listing 1 the C-SPARQL code produces an RDF stream. Here, the stream data structure is mixed with the execution of the stream producer (through a dedicated thread). Even more important, the tightly coupled publishing is done when the RDF quad is made available through the put method. The engine (in this case acting as a consumer) is forced to receive quad-by-quad whenever the RDF Stream has new data. public class SensorsStreamer extends RdfStream implements Runnable { public void run() { while(true){
RdfQuadruple q=new RdfQuadruple(subject,predicate,object,
System.currentTimeMillis()); } } } this.put(q);
Listing 1: Example of generation of an RDF stream in C-SPARQL.
A similar scenario can be observed on query results recipient. The continuous listener code for the CQELS engine in Listing 2 represents a query registration (ContinuousSelect) to which one or more listeners can be attached. The subscription is tightly coupled, and results are pushed mapping by mapping, forcing the consumer to receive these updates and act accordingly.
String queryString =" SELECT ?person ?loc " ContinuousSelect selQuery=context.registerSelect(queryString); selQuery.register(new ContinuousListener() { public void update(Mapping mapping){
String result=""; for(Iterator<Var> vars=mapping.vars();vars.hasNext();){ result+=" "+context.engine().decode(mapping.get(vars.next()));
System.out.println(result); } }); }
Listing 2: Example of generation of an RDF stream in CQELS. 2.2
Results Delivery for Constrained Consumers
In the previous section we discussed some of the general issues of current RSP
engines regarding producing and consuming RDF streams. Now we focus on the
particular case where a stream consumer is not necessarily able to cope with the
rate of the stream producer, and furthermore, when the stream generation rate
fluctuates. As an example, consider the case of an RDF stream of annotated
geolocated triples that mobile phones communicate to stationary sensors that detect
proximity (e.g. for a social networking application, or for public transportation
congestion studies), In this scenario the number of RDF stream producers can
greatly vary (from a handful to thousands, depending on how many people are
nearby in a certain time of the day), and also the stream rate can fluctuate.
In this and other examples the assumption that all consumers can handle any
type of stream load does not always hold, and RSP engines need to consider
this fact. Some approaches have used load shedding, eviction and discarding
methods to alleviate the load, and could be applicable in these scenarios [
An Actor Architecture for RDF Stream Processing
A central issue in the previous systems is that several aspects are mixed into a
single implementation. An RDF stream in these systems encapsulates not only
the stream data structure, but also its execution environment (threading model)
and the way that data is delivered (subscriptions). In distributed systems, one
of the most successful models for decentralized asynchronous programming is
the Actor model [
We can characterize an actor A as a tuple: A = (s, b, mb), where s is the actor state, b is the actor behavior and mb is its message box. The state s is accessible and modifiable only by the actor itself, and no other Actor can either read or write on it. The mailbox mb is a queue of messages mi that are received from other actors. Each message mi = (ais, air, di) is composed of a data item di, a reference to the sender actor ais, and a reference to the receiver actor air. The behavior is a function b(mi, s) where mi is a message received through the mailbox. The behavior can change the actor state depending on the message acquired. Given a reference to an actor a, an actor can send a message mi through the send(mi, a) operation. References to actors can be seen as addresses of an actor, which can be used for sending messages.
We propose a simple execution model for RDF stream processing that is composed of three generic types of actors: a stream producer, a processor and a consumer, as depicted in Figure 4. A producer actor generates and transmits messages that encapsulate RDF streams to the consumer actors. The processor actor is a special case that implements both a producer (producer of results) and a consumer (consumes the input RDF streams), as well as some processing logic. Following the above definitions the data di of a message mi emitted by a producer actor, or received by a consumer actor, is a set of timestamped triples. This model does not prevent these actors to receive and send also other types of messages.
In this model there is a clear separation of the data and the execution: the data stream is modeled as an infinite sequence of immutable event messages, each containing a set of RDF triples. Communication between producers and consumers is governed through asynchronous messaging that gets to the mailboxes of the actors. In that way, the subscribers are not tightly coupled with the producers of RDF streams, and in fact any consumer can feed from any stream generated by any producer. Moreover, this separation allows easily isolating failures in either end. Failures on consumers do not directly impact other consumers nor the producers, and vice-versa.
Event-driven asynchronous communication within RSP actors, as well as avoiding blocking operators, guarantees that the information flow is not stuck unnecessarily. Also, adaptive delivery of query results using dynamic push and pull, can prevent data bottlenecks and overflow, as we will see later. By handling stream delays, data out of order and reacting gracefully to failures, the system can maintain availability, even under stress or non-ideal conditions. Similarly, elasticity can boost the system overall responsiveness by eciently distributing the load and adapting to the dynamic conditions of the system. The actor model results convenient for RDF stream processing, as it constitutes a basis for constructing what is commonly called a reactive system4. Reactive systems are characterized for being event-driven, resilient, elastic, and responsive.
In RSP engines there are typically two types of delivery modes for the stream of results associated to a continuous query: pull and push. In pull mode, the consumer actively requests the producer for more results, i.e. it has control of when the results are retrieved. While this mode has the advantage of guaranteeing that the consumer only receives the amount and rate of data that it needs, it may incur in delays that depend on the polling frequency. In the push mode, on the contrary, the producer pushes the data directly to the consumer, as soon as it is available. While this method can be more responsive and requires no active polling communication, it forces the consumer to deal with bursts of data, and potential message flooding. In some cases, when the consumer is faster than the producer, the push mode may be appropriate, but if the rate of messages exceeds the capacity of the consumer, then it may end up overloaded, causing system disruption, or requiring shedding or other techniques to deal with the problem (see Figure 5a).
(a) Push: overload if the producer(b) Dynamic push: demand on the pushes too fast. side of the consumer.
Fig. 5: Delivery modes in RSP engines.
As an alternative, we propose using a dynamic push approach for delivering stream items to an RDF stream consumer, taking into consideration the capacity and availability of the latter (see Figure 5b ). The dynamic mechanism consists in allowing the consumer to explicitly indicate its demand to the producer. This can be simply done by issuing a message that indicates the capacity (e.g. volume of data) that it can handle. Then, knowing the demand of the consumer, the stream producer can push only the volume of data that is required, thus avoiding any overload on the consumer side. If the demand is lower than the supply, then this behavior results in a normal push scenario. Otherwise, the consumer can ask for more data, i.e. pull, when it is ready to do so. Notice that the consumer can at any point in time notify about its demand. If the consumer is overloaded with processing tasks for a period of time, it can notify a low demand until it is free again, and only then raise it and let the producer know about it.
In order to validate the proposed model, and more specifically, to verify the feasibility of the dynamic push in a RSP engine, we have implemented this mechanism on top of an open-source RSP query processor. We have used the Akka library5, which is available for both Java and Scala, to implement our
RSP Actors. Akka provides a fully fledged implementation of the actor model, including routing, serialization, state machine support, remoting and failover, among other features. By using the Akka library, we were able to create producer and consumer actors that receive messages, i.e. streams of triples. For example, a Scala snippet of a consumer is detailed in Listing 3, where we declare a consumer that extends the Akka Actor class, and implements a receive method. The receive method is executed when the actor receives a message on its mailbox, i.e. in our case an RDF stream item. class RDFConsumer extends Actor { def receive ={ case d:Data =>
// process the triples in the data message } }
Listing 3: Scala code snippet of an RDF consumer actor.
To show that an RSP engine can be adapted to the actor model, we have
used CQELS, which is open source and is written in Java, as it has demonstrated
to be one of the most competitive prototype implementations, at least in terms
of performance [
To show the feasibility of our approach and the implementation of the
dynamic push, we used a synthetic stream generator based on the data and
vocabularies of the SRBench [
PREFIX omOwl: http://knoesis.wright.edu/ssw/ont/sensor-observation.owl#.
CONSTRUCT {?observation <http://epfl.ch/stream/produces> ?time} WHERE {
STREAM <http://deri.org/streams/rfid> [RANGE 1000ms] {
?observation omOwl:timestamp ?time } }
Listing 4: Example of generation of CQELS query over the SRBench dataset.
In the experiments, we focused on analyzing the processing throughput of the CQELS dynamic push, compared to the normal push operation. We tested using dierent processing latencies, i.e. considering that the processing on the consumer side can cause a delay of 10, 50, 100 and 500 milliseconds. This simulates a slow stream consumer, and we tested its behavior with dierent values for the fluctuating demand: e.g. from 5 to 10 thousand triples per execution. The results of these experiments are depicted in Figure 6, where each plot corresponds to a dierent delay value, the Y axis is the throughput, and the X axis is the demand of the consumer.
As it can be seen, when the demand of the consumer is high, the behavior is similar to the push mode. However if the consumer specifies a high demand but has a slow processing time, the throughput is slowly degraded. When the processing time is fast (e.g. 10 ms), the push delivery throughput is almost constant, as expected, although it is important to notice that in this mode, if the supply is greater than the demand, the system simply drops and does not process the exceeding items. In that regard, the dynamic push can help alleviate this problem, although it has a minor penalty in terms of throughput. 6
RDF stream processors have emerged in the latest years as a response to the
challenge of producing, querying and consuming streams of RDF events. These eorts
resulted in a series of implementation and approaches in this area, proposing
their own set of stream models and extensions to SPARQL [
For handling continuous queries over streams, several Data Stream
Management Systems (DSMS) have been designed and built in the past years, exploiting
the power of continuous query languages and providing pull and push-based data
access. Other systems, cataloged as complex event processors (CEP), emphasize
on pattern matching in query processing and defining complex events from basic
ones through a series of operators [
More recently, a new sort of stream processing platforms has emerged, spinning o the massively parallel distributed Map-Reduce based frameworks. Examples of this include Storm6 or Spark Streaming7, which represent stream processing as workflows of operators that can be deployed in the cloud, hiding the complexity of parallel and remote communication. The actor based model can be complementary to such platforms (e.g. Spark Streaming allows feeding streams from Akka Actors on its core implementation). 7
Event streams are one of the most prevalent and ubiquitous source of Big Data on the web, and it is a key challenge to design and build systems that cope with them in an eective and usable way. In this paper we have seen how RDF Stream Processing engines can be adapted to work in an architecture that responds to the principles of reactive systems. this model is based on the usage of lightweight actors that communicate via asynchronous event messages. We have shown that using this paradigm we can avoid the tight coupled design of current RSP engines, while opening the way for building more resilient, responsive and elastic systems. More specifically, we have shown a technique for delivering the continuous results of queries in an RSP engine through a dynamic push that takes into consideration the demand of the stream consumer. The resulting prototype implementation, on top of the well known CQELS engine, shows that is feasible to adapt an RSP to include this mode, while keeping a good throughput.
When processing streams of data, whether they are under the RDF umbrella or not, it is important to take architectural decisions that guarantee that the system aligns with the characteristics of a reactive system. Otherwise, regardless of how performant a RSP engine is, if it is not able to be responsive, resilient to failures and scalable, it will not be able to match the challenges of streaming applications such as the Internet of Things. we have seen that there are many pitfalls in systems design that prevent most of RSP engines to be reactive, in the sense that they do not always incorporate the traits of resilience, responsiveness, elasticity and message driven nature. We strongly believe that these principles have to be embraced at all levels of RDF stream processing to be successful.
As future work, we plan to extend the reactive actor model to all aspects of an RSP engine, including the stream generation, linking with stored datasets and dealing with entailment regimes. We also envision to use this architecture to show that dierent and heterogeneous RSP engines can be combined together, forming
a network of producers and consumers that can communicate via messaging in a fully distributed scenario.
Acknowledgments Partially supported by the SNSF-funded Osper and NanoTera OpenSense2 projects.
COLINDA: Modeling, Representing and Using
Scientific Events in the Web of Data
Selver Softic1, Laurens De Vocht2, Martin Ebner1,
Erik Mannens2, and Rik Van de Walle2 Abstract. Conference Linked Data (COLINDA)3, a recent addition to the LOD (Linked Open Data) Cloud4, exposes information about scientific events (conferences and workshops) for the period from 2002 up to 2015. Beside title, description and time COLINDA includes venue information of scientific events which is interlinked with Linked Data sets of GeoNames5, and DBPedia6. Additionally information about events is enhanced with links to corresponding proceedings from DBLP (L3S)7 and Semantic Web Dog Food 8 repositories. The main sources of COLINDA are WikiCfP9 and Eventseer10. The research questions addressed by this work in particular are: how scientific events can be extracted and summarized from the Web, how to model them in Semantic Web to be useful for mining and adapting of research related social media content in particular micro blogs, and finally how they can be interlinked with other scientific information from the Linked Data Cloud to be used as base for explorative search for researchers . 1
Introduction and Motivation
COLINDA11 contains information about scientific events worldwide (including
location and proceedings references), published as Linked Data. The data contained in
COLINDA is extracted and accumulated from the data dumps of WikiCfP , which are
published yearly and freely available on request for research12 purposes, and from data
3 http://colinda.org
4 http://lod-cloud.net/
5 http://www.geonames.org/
6 http://dbpedia.org
7 http://dblp.l3s.de/d2r/
8 http://data.semanticweb.org/
9 http://www.wikicfp.com/
10 http://eventseer.net/
11 Available at: http://colinda.org/, see also http://datahub.io/dataset/colinda
12 http://www.wikicfp.com/cfp/data.jsp
gathered via JSON interface from Eventseer. WikiCfP and Eventseer are two very
popular online scientific event archives. WikiCfP contains calls for paper for about
approximately 30.000 conferences and has approximately 100.000 registered users. Eventseer
contains according the latest information13 calls for around 21000 events and serves
more then 1 million users. We also track the Twitter14 feeds of both sites integrating
on the fly arrival of upcoming scientific events using the Twitter API15 to recieve the
data from Twitter profiles of Wiki CfP and Eventseer. Currently COLINDA includes
data about more than 15000 conferences. Event instances are enriched with
information from Linked Data proceedings repositories DBLP (L3S)16 and Semantic Web Dog
Food17 as well by location information from Geonames and DBPedia. Primary intention
of COLINDA was to provide hashtag based identification system for scientific events
in Twitter in the manner of the "5-star" quality Open Data18. Researchers are using
very often hashtags, while they are discussing on Twitter. Specially during scientific
events, they are using hashtags as abbreviated reference to the event they are
attending [
Extraction, Modeling, Creation and Publishing of Linked
Scientific Events COLINDA data covers generally three domains: The first domain originates from WikiCfP and Eventseer and describes the Conference as basic scientific event with a start date, location, description, label and link to the event web page. Second domain is the Location of the event with geographic parameters resolved using the GeoNames and DBPedia data set in interlinking process. Each location contains reference to the city, country and coordinates of the location. Further as extension and third domain we have Proceedings of the conference represented by the links from DBLP (L3S) or Semantic Web Dog Food. The data creation process comprises the following steps: 13 http://eventseer.net/data/ 14 http://www.twitter.com/ 15 COLINDA 16 http://datahub.io/dataset/l3s-dblp 17 http://datahub.io/dataset/semantic-web-dog-food 18 http://5stardata.info/ 19 e.g. for ’iswc2012’ at DBLP(L3S): http://dblp.l3s.de/d2r/page/publications/conf/ISWC/2012 20 e.g. for ’iswc2012’ at SW Doog Food: http://data.semanticweb.org/conference/iswc/2012/
COLINDA: Modeling, Representing and Using Scientific Events in the Web of Data – Extraction - extraction and pre-processing of data sources (Subsection 2.2) – Modeling of Events using SWRC Ontology - concept coverage (Subsection 2.3) – Triplification - creating RDF data triples (Subsection 2.4) – Interlinking - connection to other Linked Data sets (Subsection 2.5) COLINDA is constructed from variously structured sources. Therefore we defined a minimal set of properties that describe the Conference concept for a single RDF instance. During extraction, all properties from sources are being mapped to defined normalized set in order to harmonize the federated data. The Location and Proceedings concepts related to conference events as such are considered as optional enrichment which will be treated in the interlinking process. We made this decision having in mind that all conference descriptions do not explicitly include the venue information. The quality of source data depends on the users that provide the information. Thus such data sources implicitly exclude assumption of completeness. Table 1 represents the minimal set of properties a Conference and Location instance should include. The Extraction process includes steps of either pre-processing of XML dumps from WikiCfP or JSON from Tweets and Eventseer into the temporary tables of values formatted as Comma
Separated Value (CSV). During the pre-processing cycle data fields like e.g. date or labels are being normalized to achieve uniform representation, and to provide easier processable input for triplification step which converts the extracted values from temporary tables into RDF formatted instances of Linked Data.
Modeling Scientific Events in the Web of Data
Basic representation of scientific events was well elaborated in previous research work
about the SWRC ontology introduced by Sure et al [
Complete model with interlinked properties (proceeding and location) can be seen in figure 2, where a single complete and interlinked instance of a conference (ISWC2012) is depicted. Matchings between features and the vocabulary properties is shown in table 2. 2.4
Triplification - Creation of RDF Instances of Scientific Events The triplification25 process uses as input temporary data tables in CSV like format generated in extraction and pre-processing step. Input generated in this way represents tab21 http://ontoware.org/swrc/ 22 http://www.w3.org/TR/rdf-schema/ 23 http://www.geonames.org/ontology/ 24 http://www.w3.org/2003/01/geo/wgs84_pos# 25 Under ’triplification’ we understand ’triple-wise’ creation of Linked Data instances as RDF
graphs
defining the structure of contexts. The CKR framework has not only been presented as
a theoretical framework, but also actual implementations based on its definitions [
From a formal ontology point of view, in the approach we propose in this paper we clearly distinguish ontology from knowledge. The upper layer of our system contains the underlying ontology, that is, the description of the organization of the world.
This part lists types of entities, relations and constraints that are assumed to exist or to simply be possible. More generally, the upper layer should be thought as including two elements: a general (foundational or domain) ontology describing what can exist, and the organization of a set of knowledge modules characterizing roles and relationships in (typically social) standardized scenarios like economic transactions or soccer games.
Regarding the first, we do not make a specific commitment towards one ontology or another although we explicitly commit to the existence of physical and social objects, like people and organizations, and temporal happenings like weddings and thunderstorms.
These entities come with their usual physical and temporal properties: weight, shape, duration and so on. Regarding the modules, we do explore their role in the system to infer new facts from given knowledge and thus we will present their general setting and how they are used. The lower layer of the system, on the other hand, collects claims about what happens in the world, that is, claims about how things are or change at some time. Throughout the paper these are what we call events, but note that they are not events in the ontological sense, rather they are descriptions of happenings.
Each event is associated with three state-like entities, namely happenings
characterized by some continuously holding property or relation like “begin married”, “being
running” or “being employed by” (e.g. see the notion of stative perdurant in DOLCE [
These state-like entities are called situations in our system; more specifically the situation holding before the event is called pre-situation, the one holding after post-situation and the one holding during the event itself is the during-situation. Informally, these situations are used to make explicit relevant properties that (a) persist during the whole event, or (b) hold (or don’t hold) before/after the event and their truth values change “because” of the event. We will use situations to formalize (and reason on) the preconditions for an event of a certain type to happen, the postconditions (or consequences) of its happening, and what can be taken as stable during the whole event of that type.
Although we take the received events at face value, it is possible that the news are imprecise or incomplete, that the text processing used to acquire the news is faulty and misinterprets them, that statements extracted from di↵ erent sources about the same happenings contradict each other. For this reason, we take each piece of information extracted from an outside source as a contextual perspective on the world. This means that the content of a news is not equated to absolute knowledge (it is not indisputable). Indeed, the extracted information constitutes a context annotated with its original source (possibly with di↵ erent degrees of reliability which can change over time). This allows to integrate pieces of information coming from di↵ erent sources into large and articulated event descriptions by integrating di↵ erent contexts (in turn, news statements).
These extrapolated events reconstruct how an entity like a person or an organization, changes over time by changing its status (size, capacity, death) or its relationships with other entities (property acquisition, employment, marriage). Furthermore, missing information on these complex events can be detected via logical reasoning based on the ontology at the upper layer, leading to infer changes that have not been reported (or detected) in the news. Finally, note that, when a contradiction arises, the system can isolate the conflicting pieces of information and establish which contexts are to be kept apart and need to be verified.
In this paper we propose the first sketch and example of use for the contextualized ESO model: in the next section we briefly present the ESO model and provide an example of event modelling; in Section 3, we summarize the base definitions for the CKR framework; in the following section we describe the CKR-ESO model, that is our contextual based realization of ESO, we show how it models the previously presented event example and provide some insights in the advantages of such representation; we conclude by outlining some of the current and future directions for our work. 2
Events and Situations One of the objectives in the NewsReader project is the representation of events and of their e↵ ects on the entities participating in them. For example, in a “giving” event, we have at least two actors (people, organizations) and an object, e.g., a person A giving something to another person B at some time T . The event also describes a change in these entities: at the time T , person A owns the object, while person B does not (aka, pre-situation); after T , the opposite is true (aka, post-situation).
To achieve this objective, the Event and Situation Ontology (ESO) [
For instance, in the sentence: “The chairman of India’s Tata Group has confirmed that his company is acquiring the Jaguar and Land Rover businesses from Ford.”, an event is described: the acquisition by Tata Group of Jaguar and Land Rover from Ford. The event is represented in ESO terminology as follows: <:evID, rdf:type, sem:Event> <:evID, rdf:type, eso:Getting> <:evID, rdfs:label, acquire> <:evID, eso:possession-owner 1, dbp:Ford> <:evID, eso:possession-owner 2, dbp:Tata Group> <:evID, eso:possession-theme, :Jag and L. Rover> <:evID, sem:hasTime, #tmxID> where #tmxID is the RDF representation of “August 26th, 2007”.
According to ESO, the event eso:Getting has both pre- and post-situation,
containing eso:hasInPossession and eso:notHasInPossession assertions, respectively. In the
pre-situation of our example, Ford has in possession Jaguar and Land Rover, and Tata
Group does not have in possession them; in the post-situation, the contrary holds. In the
ESO model, such facts specific to a situation are stored in a RDF named graph identified
by the URI of the situation. Therefore, the following set of n-tuples is generated:4
<:evID, eso:hasPreSituation, :evID pre>
<:evID pre, rdf:type, eso:Situation>
<:evID pre, sem:hasTime, #tmxID>
<dbp:Ford, eso:hasInPossession, :Jag and L. Rover, :evID pre>
<dbp:Tata Group, eso:notHasInPossession, :Jag and L. Rover, :evID pre>
<:evID, eso:hasPostSituation, :evID post>
<:evID post, rdf:type, eso:Situation>
<:evID post, sem:hasTime, #tmxID>
<dbp:Ford, eso:notHasInPossession, :Jag and L. Rover, :evID post>
<dbp:Tata Group, eso:hasInPossession, :Jag and L. Rover, :evID post>
In NewsReader, all the events and related information, instantiated according to the
ESO metamodel, are stored, together with the original news article from where they
were extracted in the KnowledgeStore [
A CKR is a two layered structure: (1) the upper layer consists of a knowledge base G, called global context, containing (a) meta-knowledge, i.e. the structure and properties of contexts, and (b) global (context-independent) object knowledge, i.e., knowledge that applies to every context; (2) the lower layer consists of a set of (local) contexts that contain locally valid facts and can refer to what holds in other contexts. The intuitive structure of a CKR knowledge base is depicted in Figure 1: in the following we detail its formal components and interpretation.
Syntax. The meta-knowledge of a CKR is expressed in a DL language containing the elements that define the contextual structure: the meta-vocabulary is a DL signature containing, in particular, the sets of symbols for context names N, module names M and context classes C, including the class of all contexts Ctx. Intuitively, modules represent pieces of knowledge specific to a context or a context class. The role mod defined on N ⇥ M expresses associations between contexts and their modules. The meta-language L of a CKR is a DL language over .
The knowledge in contexts of a CKR is expressed via a DL language L⌃ , called object-language, based on an object-vocabulary ⌃ . The expressions of the object language are evaluated locally to each context, i.e., contexts can interpret each symbol 4 Whenever applicable, default named graph is omitted.
Metaknowledge
Global object knowledge mod_cls1 mod_ctx1
Class1 mod_ctx2
Rel1
mod_ctx3 Context1
Context2 Context3
A⊑ B, B⊑ C, ...
R⊑ S, ...
A(a), B(a), ...
R(a, b), S(a, c) ...
D⊑ B, D(a)...
mod_cls1
C⊑ B, C(a)...
mod_ctx1
E⊑ B, E(a)...
mod_ctx2
D⊑ E, D(b)...
mod_ctx3
Fig. 1. CKR structure independently. To access the interpretation of expressions inside a specific context or context class, we extend L⌃ to L⌃e with eval expressions of the form eval(X, C), where X is a concept or role expression of L⌃ and C is a concept expression of L (with C v Ctx). Intuitively, eval(X, C) can be read as “the interpretation of X in all the contexts of type C”.
We define a Contextualized Knowledge Repository (CKR) as a structure K = hG, {Km}m2 Mi
where: (i) G is a DL knowledge base over L [ L ⌃ ; (ii) every Km is a DL knowledge
base over L⌃e , for each module name m 2 M. We note that the knowledge in a CKR can
be expressed by means of any DL language: in our work, we consider SROIQ-RL [
Semantics. The semantics of CKR basically extends the usual model-based semantics of DL knowledge bases to the two layered structure of the framework. A CKR interpretation is a structure I = hM, Ii s.t.: (i) M is a DL interpretation of [ ⌃ (respecting the intuitive interpretation of Ctx as the class of all contexts); (ii) for every context x 2 CtxM, I(x) is a DL interpretation over ⌃ (with same domain and interpretation of individual names of M). The interpretation of ordinary DL expressions on M and I(x) is as usual while eval expressions are interpreted as follows: for every x 2 CtxM, eval(X, C)I(x) represents the union of all elements in XI(e) for all contexts e in CM.
A CKR interpretation I is a CKR model of K i↵ : (i) for ↵ 2 L ⌃ [ L in G, M |= ↵ ; (ii) for hx, yi 2 modM with y = mM, I(x) |= Km; (iii) for ↵ 2 G \ L ⌃ and x 2 CtxM, I(x) |= ↵ . Intuitively, this means that I verifies the contents of global and local modules associated with contexts and global object knowledge has to be propagated to local contexts.
Materialization calculus. Reasoning in CKR has been formalized as a materialization
calculus [
Intuitively, the calculus is based on a translation to datalog of the input CKR. It has three components: (i) the input translations Iglob, Iloc, Irl, where given an axiom ↵ and c 2 N, each I(↵, c) is a set of datalog facts or rules encoding the contents of input global and local DL knowledge bases; (ii) the deduction rules Ploc, Prl, which are sets of datalog rules representing the inference rules for the instance-level reasoning over the translated axioms; and (iii) the output translation O, where given an axiom ↵ and c 2 N, O(↵, c) is a single datalog fact encoding the ABox assertion ↵ that we want to prove to be entailed by the input CKR (in the context c).
Intuitively, SROIQ-RL input Irl and deduction Prl rules provide the translation and interpretation of SROIQ-RL axioms from the input CKR. Global input rules in Iglob encode the interpretation of Ctx in the global context. Similarly, local input rules Iloc and deduction rules Ploc provide the translation and rules for the local eval expressions.
The rules in O provide the translation of ABox assertions that can be verified to hold in a context c by applying the rules of the final program.
The translation of a CKR K to its datalog program PK(K) proceeds in four steps:
we first translate G in the global program PG(G) by applying input rules Iglob and Irl
to G and adding deduction rules Prl; then, for every context name c 2 N appearing in
PG(G), we compute its knowledge base Kc as the set of modules Km 2 K s.t. mod(c, m)
is proved by PG(G); we translate each local program PC(c) by applying input rules Iloc
and Irl to Kc and adding deduction rules Ploc and Prl; the final CKR program PK(K)
is then obtained as the union of PG(G) with all local programs PC(c). We say that K
entails an axiom ↵ in a context c 2 N if PK(K) |= O(↵, c). We can show (see [
CKR implementation on RDF. We recently presented a prototype [
The distribution of knowledge in di↵ erent named graphs asks for a component to
compute inference over multiple graphs in a RDF store, since inference mechanisms
in current stores usually ignore the graph part. This component has been realized as a
general software layer called SPRINGLES (SParql-based Rule Inference over Named
Graphs Layer Extending Sesame) [
In our case, the ruleset basically encodes the rules of the presented materialization calculus. The rules are evaluated with a strategy that follows the same steps of the translation process defined for the calculus. The plan goes as follows: (i) we compute the inference closure on the graph for global context G, by a fixpoint on rules corresponding to Prl; (ii) we derive associations between contexts and their modules, by adding dependencies for every assertion of the kind hasModule(c, m) in the global closure; (iii) we compute the closure of the contexts, by applying rules encoded from Prl and Ploc and resolving eval expressions by the metaknowledge information in the global closure. 5 http://www.openrdf.org/
Representing events in CKR: CKR-ESO ontology We can now describe how we translated and implemented a first prototype of the ESO model in the form of a contextualized ontology for the CKR, that we call the CKR-ESO ontology.
In this model, the event and situation structures are modelled in the metaknowledge.
Similarly to the ESO model, each event instance is associated in the metaknowledge with its pre-, during- and post-situations using the object properties hasPreSituation, hasPostSituation and hasDuringSituation, subproperties of hasSituation. Situation elements associated with events can be generated automatically by SPRINGLES rules when importing an event.
Each event is represented in the metaknowledge as an instance of the class Event: in particular, each event is associated, analogously to the ESO model, with a subclass of the Event class that determines the type of associated situations: in particular, DynamicEvents (e.g. ChangeOfPossession, Constructing) are typically characterized by their pre- and post-situations, while StaticEvents (e.g. BeingOperational) by their during-situations.
This classification is provided by restrictions over the definition of such classes. For example, for the ChangeOfPossession event class, the CKR-ESO ontology states that:
ChangeOfPossession v 8 hasPreSituation.Pre ChangeOfPossession
ChangeOfPossession v 8 hasPostSituation.Post ChangeOfPossession Each event individual is associated with a knowledge module that corresponds to the RDF graph of the event in the ESO model. This association is represented in the metaknowledge by the property hasEventModule. The following chain axiom is defined over this property, asserting that situations related to an event inherit the facts asserted in the event module: (hasSituation) hasEventModule v hasModule. As defined by the ESO model, we expect to find in the event module the instantiation for all the required roles involved in the event.
The class Situation is defined as a subclass of the Context class in the CKR vocabulary: in other words, in our model we consider situations and their local knowledge as contexts. The particular (pre, post and during) situations associated with event types are modelled by specific context classes. Thus, for example, we have that the pre- and post-situations for events of type ChangeOfPossession are classified as members of the classes Pre ChangeOfPossession and Post ChangeOfPossession. The association between such type of situations and their local axioms (i.e. what its modelled in the ESO ontology by situation assertions) is performed by linking specific knowledge modules to these context classes. For example, in CKR-ESO we declare that every pre-situation of ChangeOfPossession is associated with the knowledge module pre change-of-possession-m and post-situations to post change-of-possession-m:
Pre ChangeOfPossession v 9 hasModule.{pre change-of-possession-m}
Post ChangeOfPossession v 9 hasModule.{post change-of-possession-m} Situation assertions are thus encoded inside these specific modules: the assertions can be basically translated to chain axioms across the roles specified in the event. For example, assertions for pre-situations of ChangeOfPossession stating that: hasInPossession(possession-owner 1, possession-theme) notHasInPossession(possession-owner 2, possession-theme)
Context
Situation pre_cop-m
Pre_CoP
Post_CoP pre-event1 post-event1
post_cop-m hasPostSituation hasPreSituation
Event DynamicEvent possession-owner_1(event1,Ford) possession-owner_2(event1,Tata_Group) possession-theme(event1,Jaguar_and_Land_Rover)
Fig. 2. Example event in CKR-ESO model. is translated in CKR-ESO to these chain axioms across role properties: (possession-owner 1) (possession-owner 2) possession-theme v hasInPossession possession-theme v notHasInPossession We now can show how to represent our example event from Section 2 using the CKRESO model: we depict this modelling in Figure 2. In the global context, we define event1 to be of type ChangeOfPossession and associate it with its situations:
ChangeOfPossession(event1) hasPreSituation(event1, pre-event1) hasPostSituation(event1, post-event1) By the above axioms for such event type, we know that the pre- and post-situations of event1 have to be of type Pre ChangeOfPossession and Post ChangeOfPossession.
By metalevel reasoning, this implies that: hasModule(pre-event1, pre change-of-possession-m) hasModule(post-event1, post change-of-possession-m) and thus the situation assertions associated with the pre- and post-situations of ChangeOfPossession are imported in the two situations6. Moreover, the graph associated with the original event is now defined as a module associated with event1 in the metalevel: hasEventModule(event1, event1 m). The event1 m module (i.e. the associated RDF graph) now contains the following facts that are shared with all the situations associated with this event: possession-owner 1(event1, Ford) possession-owner 2(event1, T ata Group) possession-theme(event1, Jaguar and Land Rover) 6 In Figure 2 we abbreviate classes of pre- and post-situations of ChangeOfPossession with
Pre CoP and Post CoP and their modules with pre cop-m and post cop-m.
Using the situation assertions in the module associated with the pre-situation, the CKR thus derives the following facts in the context of pre-event1: hasInPossession(Ford, Jaguar and Land Rover) notHasInPossession(T ata Group, Jaguar and Land Rover) Similarly, in the context of post-event1 we obtain: notHasInPossession(Ford, Jaguar and Land Rover) hasInPossession(T ata Group, Jaguar and Land Rover) We note that representation of the described event can be completed with its associated during-situation: among the facts that are known to hold during the event, for example, we can assert the existence of the actors and of the possession theme (using the exists property in the ESO).
This contextual re-interpretation of the ESO model can bring several advantages from
the point of view of reasoning capabilities inside and across events. First of all, every
aspect of the reasoning procedure is now strictly ruled by logical reasoning: situation
assertions and their association with the type of situation are now directly modelled
by the CKR structure and local axioms, without demanding an external reasoner to
consider the situation rules and the local reasoning inside situations. Furthermore, the
propagation of global object knowledge to local knowledge allows the use of context
independent background knowledge in local reasoning. In our example, we can assert
in the global knowledge that both actors (Ford and T ata Group) are classified as car
companies and their features can be used in local reasoning. More in general, the
advantages of an explicit and structured representation of contexts (as the one o↵ ered by
the CKR) with respect to a modelling based on reification have been shown in [
On the other hand, the clear separation of meta and object level reasoning can be exploited to exchange information across the two levels. For example, depending on the type and specific patterns of situation and events, by adding custom SPRINGLES rules it is possible to generate implicit events that have to occur for the completion of the event sequence in a story. In our example, if we have a second event event2 representing another ChangeOfPossession of Jaguar and Land Rover between two companies Company1 and Company2, di↵ erent than the two companies from event1, and event2 has a timestamp greater than event1, then we can infer that there have been another two events (possibly being the same one): in one Jaguar and Land Rover has been sold from T ata Group and in the other it has been acquired from Company1. Similarly, we can recognize cases in which we can assert the equality of certain situations: this can be used to compile sequences of events in a story.
Metalevel information for situations and events can be derived from local reasoning: we might recognize incompatible descriptions of the same event from di↵ erent news. For example, let us suppose a di↵ erent representation of the scenario shown in the example in Figure 2: assume that event1 is now classified as Buying (subclass of ChangeOfPossession) while another event event2 is extracted as Selling (also subclass of ChangeOfPossession), but they both represent the same conceptual event (i.e. the acquisition of Jaguar and Land Rover by T ata Group from Ford). Thus, at the level of the metaknowledge, the two events are modelled as: Selling(event2) hasPreSituation(event2, pre-event2) hasPostSituation(event2, post-event2) Since they represent the same happening, the event modules event1 m and event2 m basically share the same contents: that is, the actors are the same and they take the same role. However, suppose that, due to the extraction from di↵ erent news sources, the metamodel property sem:hasTime associated to post-event1 has value “August 26th, 2007” while the value associated to pre-event2 is “August 28th, 2007”. Then, using this metalevel information and the local contents of the event modules, we can easily write a reasoning rule that recognizes that the two events are incompatible and adds the assertion event1 incompatibleWith event2 in the global context. Similarly, we can recognize inconsistent situations by local reasoning: this can be used both to exclude further inferences from inconsistent contexts, by marking as “inconsistent” the situation individual in the metaknowledge, but also to repair (possibly with some ad-hoc rules) the local axioms. We note that, on the other hand, this kind of reasoning requires to define ad-hoc rules to recognize such di↵ erent situations.
Another interesting possibility is the one of having inter-situation knowledge
propagation. For example, if two situations or two events are recognized as consequent in a
story, unmodified knowledge from the previous situations can be propagated to
subsequent situations (e.g. the marital status of Obama did not change when he was elected
US president). This clearly presents problems of non-monotonicity, since one has to
consider which knowledge can be seamlessly propagated without incurring in
contradictory states. In this regard, we recently introduced in CKR a notion of defeasible
axioms and their overriding across di↵ erent contexts [
Conclusions and future works In this paper we introduced the model of the CKR-ESO ontology, a re-interpretation of the Event and Situation Ontology under the contextual view of knowledge o↵ ered by the CKR framework. We discussed informally the advantages of such representation and demonstrated its application by means of an example.
We are currently completing the translation of the full ESO ontology to its contextualized version: we remark that, given the direct translation across the two models, we can easily automatize this transformation.
Our goal is to be able to apply some of the proposed complex reasoning services to the events currently represented in the KnowledgeStore of the NewsReader project: to this aim, we plan to integrate the RDF-based CKR implementation with the KnowledgeStore and encode such reasoning services with respect to CKR contextual model.
Acknowledgments. The research leading to this paper was supported by the European Union’s 7th Framework Programme via the NewsReader Project (ICT-316404).
Representing Specialized Events with FrameBase
Jacobo Rouces1, Gerard de Melo2, and Katja Hose1
1 Aalborg University, Denmark jrg@es.aau.dk, khose@cs.aau.dk 2 Tsinghua University, China
gdm@demelo.org Abstract. Events of various sorts make up an important subset of the entities relevant not only in knowledge representation but also in natural language processing and numerous other fields and tasks. How to represent these in a homogeneous yet expressive, extensive, and extensible way remains a challenge. In this paper, we propose an approach based on FrameBase, a broad RDFS-based schema consisting of frames and roles. The concept of a frame, which is a very general one, can be considered as subsuming existing definitions of events. This ensures a broad coverage and a uniform representation of various kinds of events, thus bearing the potential to serve as a unified event model. We show how FrameBase can represent events from several different sources and domains. These include events from a specific taxonomy related to organized crime, events captured using schema.org, and events from DBpedia. 1 Introduction The surge of research on large-scale knowledge bases in recent years has largely been driven by the availability of new sources of information about entities. While structured data about millions of places, people, or companies are very valuable, there have been comparably few new results on capturing events of various sorts. Most existing eventoriented ontologies have introduced only a few abstract classes of events, and typical knowledge bases tend to describe just a small number of specific types of events.
Often, however, there is a need to talk about a broad range of very specific sorts of
events. For instance, one might want to distinguish battles from both gunfights and from
wars, and capture the class-specific details of such events. We adopt a broad notion of
events here. This includes the prototypical cases, e.g. local happenings such as concerts,
gatherings, or competitions, and world events such as those reported in the news. It also
encompasses the more general abstract definition of events, for instance as “happenings
in the real world” [
In this paper, we address this challenge of representing many different notions of
events under a common schema, from the very prototypical cases to the very abstract, in
a way that has both a broad coverage yet supplies sufficient detail to model event-specific
properties. For this, we present a new approach for representing event information that is
based on FrameBase [
FrameBase provides a predefined vocabulary with event-specific properties for thousands of different kinds of events. For instance, FrameBase’s schema accounts for the fact that a battle takes place in a certain time and place and normally involves two parties.
For this, the schema draws on two linguistic resources, FrameNet [
As these describe important fragments of the English lexicon, their coverage is quite substantial. Additionally, as we illustrate later on, FrameBase can be easily extended.
In the following, we prove the suitability of FrameBase for representing different
kinds of events by creating rules that integrate instances from different domains:
– A taxonomy of event classes relating to organized crime from the EU FP7 project
ePOOLICE3. In the project, the event classes in the taxonomy are used as types
of entities that are extracted from documents crawled from the web, as part of a
strategic early-warning system. The taxonomy was originally captured using the
Conceptual Graphs formalism [
extracted from the infoboxes in Wikipedia.
– We conclude with a more general overview of how salient aspects of events [
This paper is structured as follows. After describing previous approaches and research
in Section 2, a brief overview of the FrameBase schema is given in Section 3. Section 4
then shows how we can rely on the FrameBase schema to represent events from several
different sources and domains. Finally, Section 5 provides concluding remarks and
describes avenues for future research and applications of our work.
2
Considering their importance and unique characteristics, events have been included in
numerous upper-level ontologies and vocabularies. In [
For instance, the Simple Event Model (SEM) Ontology [
Similarly, the LODE (Linking Open Descriptions of Events) model [
FrameBase’s schema instead aims at a broader coverage of many domains by
building on natural language resources. Previous work has made use of natural language
processing techniques to extract events from text. For instance, one study [
Examples include commercial exchanges, marriages, or the act of stomping. The frame elements refer to the participants or properties that are involved in a particular frame instance. Common general frame elements include those of agent, patient, time, and location, but not all frames involve these. Frame elements are sometimes also referred to as semantic roles, roles, or theta roles, especially when they are very general.
The frames and the frame elements in FrameBase are organized in hierarchies of
classes (based on subclass relationships) and of properties (based on subproperty
relationships), respectively. There are three kinds of frames in FrameBase: LU-microframes,
synset-microframes and non-lexical frames. Non-lexical frames are very general and are
situated in the upper part of the hierarchy. LU-microframes (lexical unit microframes)
descend from non-lexical frames, but are much more specific by being associated with
the meaning of particular words (the lexical units). They come from FrameNet [
Synset-microframes allow an intermediate level of granularity connecting synonymous
LU-microframes, e.g. for marriage and matrimony. These are based on WordNet [
In the field of linguistics, frames are said to be evoked by words: for example, both the verb to create and the noun creation evoke the Creation frame.
FrameBase additionally provides direct binary predicates to directly connect certain values for elements of a given frame. For example, in a creation event, the agent and the place are directly connected via the establishesInPlace relation. This enables more concise queries and representations when only two elements are involved in a particular frame. The frame patterns and the direct binary predicates are logically connected by means of definite clauses that can be used with different kinds of inference systems.
For interoperability with existing resources, FrameBase relies on the standard RDF
model [
Event frames are specific kinds of frames, subsuming a range of different notions
of events, from the very abstract (e.g., “a natural abstraction of happenings in the real
world” [
We believe that the advantage of FrameBase over the existing event models lies on the fact that while extensible as the others, it already provides a broad-coverage vocabulary out of the box in order to bootstrap widespread adoption. Besides, its connection to natural language provides potential advantages, like interfacing with text for question answering or text mining.
FrameBase includes, from FrameNet, an Event frame, which inherits from the Change of state scenario frame, and includes a relatively rich hierarchy below for events like creation and destruction events (including more specific ones such as births and deaths), and some others. However, not every event must necessarily fall below this event frame, nor does doing so preclude it from being mapped to other frames that represent other conceptualizations for events, or reflect other perspectives of the frame that stress different aspects than the eventive one. Therefore, the representation of events in FrameBase is not confined to the Event frame and its subframes. We will see examples of this in the next section. 4 Integrating Events In the first subsections of this section, we present manually built rules for integrating events from three different sources into FrameBase. Later, we add further explanations about these rules and discuss the complexity of the integration rules, and the challenges they present, in particular when they are to be established automatically. The following list of integration rules shows, for each instance of an event class in the organized crime conceptual graph (in bold), the corresponding representation in RDF that it would have in FrameBase. In particular, the main event instance is represented by the anonymous node _:e. The default prefix indicates elements that already existed in the core FrameBase schema created from FrameNet and WordNet.
Event _:e a :frame-Event-event.n
Act _:e a :frame-Intentionally_act-act.n
Arrest _:e a :frame-Arrest-arrest.n
Drug Possession Arrest _:e a :frame-Arrest-arrest.n . _:e :fe-Arrest-Offense _:e2 . _:e2 a :frame-Offenses-possession.n Human Trafficking Arrest _:e a :frame-Arrest-arrest.n . _:e :fe-Arrest-Offense _:e2 . _:e2 a :frame-Commerce_scenario-trafficker.n . _:e2 :fe-Commerce_scenario-Goods :frame-People-human.n Metal Theft Arrest _:e a :frame-Arrest-arrest.n . _:e :fe-Arrest-Offense _:e2 . _:e2 a :frame-Theft-theft.n . _:e2 :fe-Theft-Goods :frame-Substance-metal.n .
_:e2 a :frame-Offenses-theft.n Buy _:e a :frame-Commerce_buy-buy.v Crime _:e a :frame-Committing_crime-crime.n
Illegal Drug Use _:e a :frame-Ingest_substance-use.v
Consume _:e a :frame-Ingestion-consume.v Inhale _:e a :frame-Ingest_substance-sniff.v Inject _:e a :frame-Ingest_substance-inject.v Possession _:e a :frame-Offenses-possession.n
Smoke _:e a :frame-Ingest_substance-smoke.v
Organised Crime _:e a fbe:frame-Organization-criminal%20organization.n
Theft _:e a :frame-Theft-theft.n . _:e a :frame-Offenses-theft.n
Metal Theft _:e a :frame-Theft-theft.n . _:e :fe-Theft-Goods :frame-Substance-metal.n . _:e a :frame-Offenses-theft.n Trafficking _:e a :frame-Commerce_scenario-trafficker.n
Drug Trafficking _:e a :frame-Commerce_scenario-trafficker.n . _:e :fe-Commerce_scenario-Goods :frame-Intoxicants-drug.n
Human Trafficking _:e a :frame-Commerce_scenario-trafficker.n . _:e :fe-Commerce_scenario-Goods :frame-People-human.n
Seizure _:e a :frame-Taking-seizure.n
Drug Seizure _:e a :frame-Taking-seizure.n . _:e :fe-Taking-Theme :frame-Intoxicants-drug.n
Sell _:e a :frame-Commerce_sell-sell.v Transaction _:e a :frame-Commercial_transaction-transaction.n
Crime Transaction _:e a :frame-Commercial_transaction-transaction.n . _:e a :frame-Committing_crime-crime.n
Drug Trafficking Transaction _:e a :frame-Commercial_transaction-transaction.n . _:e a :frame-Committing_crime-crime.n . _:e :fe-Commercial_transaction-Goods :frame-Intoxicants-drug.n
Metal Theft Transaction _:e a :frame-Commercial_transaction-transaction.n . _:e a :frame-Committing_crime-crime.n . _:e :fe-Commercial_transaction-Goods :frame-Substance-metal.n
The hierarchy in the original ontology is not necessarily consistent with the hierarchy in FrameBase. Only in certain cases does a superclass relationship between two elements of the source also exist between the two elements’ respective translations to FrameBase.
Therefore, for each translation of an original class of event, the translations of the parents in the original ontology can be added to the set of instances (ABox) in FrameBase, and this will provide additional knowledge that would not always be inferred by the FrameBase schema alone.
We minimize the need for declaring new frames and frame elements for specialized domains by making use of the compositionality of most specialized terms, creating complex structures that combine the semantics of simpler, basic elements. For instance, the translation for the event of type “Drug Possession Arrest” declares an event of type arrest, and specifies that it is about drug possession by assigning drug possession (Offenses-possession.n) as the offence.
Owing to this flexibility, we merely needed to mint one single new entity that had not existed in the core FrameBase schema (the microframe Organization-criminal%20organization.n, with the prefix fbe: denoting that this is an extension). This exemplifies the potential of FrameBase to represent events from relatively specialized domains, but at the same time the capacity to be extended to fill any possible gaps.
For representing timelines, the frame Individual_history-history.n can be used. Each timeline can be represented with one instance of that frame. This instance can be linked with the frame element Individual_history-Domain to the topic, which is preferably an entity (or alternatively, a literal or an anonymous node or dummy entity named with a literal). The instance can also be linked with the frame element Individual_history-Event to each of the elements in the timeline. Additional frame elements are available in FrameBase, originating from FrameNet, for expressing participants, total duration, etc.
Then, complex queries such as retrieving all events in a given timeline between two given dates, can be built in SPARQL. Similarly, sub-events can be represented with the property path: ^:fe-Part_whole-Part/:fe-Part_whole-Whole. 4.2 Representing Events from DBpedia.org We now turn to the Event class in DBpedia, and its subclasses, showing how these can be integrated into FrameBase. The integration is implemented using SPARQL CONSTRUCT rules because DBpedia is already in RDF. We only add a couple of subclasses, but most of the properties belong to the parent Event class itself.
Top event CONSTRUCT { ?e a :frame-Event-event.n . For sub-classes of dbpedia-owl:Event CONSTRUCT {
?e a :frame-Social_event-meeting.n . } WHERE {?e a dbpedia-owl:SocietalEvent} For sub-classes of dbpedia-owl:SocietalEvent CONSTRUCT { ?e a :frame-Project-project.n .
?e :fe-Project-Activity dbpedia:Space_exploration . } WHERE {?e a dbpedia-owl:SpaceMission} For sub-classes of dbpedia-owl:SocietalEvent CONSTRUCT {
?e a fbe:frame-Social_event-convention.n . } WHERE {?e a dbpedia-owl:Convention}
Out of the 9 properties of the class Event, the only omitted one was numberOfPeopleAttending, because the class Event is too general for it, as it has subclasses such as NaturalEvent (SolarEclipse) and PersonalEvent (Birth, etc.).
The SocietalEvent class appears more appropriate for this. 4.3 Representing Events from schema.org Finally, we present the translation of the Event class in schema.org. Again, SPARQL CONSTRUCT rules are used because schema.org can be expressed using RDFa, and SPARQL offers a standard way of representing knowledge graph transformations. Due to space restrictions, we omit the subclasses here, but these have very few genuine properties, and therefore the specialization is relatively simple. Besides, the taxonomy of schema.org events has some inconsistency issues that makes its use complex: the Event class is defined as capturing events such as concerts, lectures, and festivals, with properties such as “typical age range”, but there are sub-events such as UserInteraction and UserPlusOnes that actually represent a more general kind of events.
CONSTRUCT { ?e a :frame-Social_event-meeting.n . ?e :fe-Social_event-Time _:timePeriod .
_:timePeriod a fbe:frame-Timespan-period.n ;
fbe:fe-Timespan-Start ?Osta ; fbe:fe-Timespan-End ?Oend . ?e :fe-Social_event-Duration ?Odur . ?e :fe-Social_event-Place ?Oloc . ?e :fe-Social_event-Attendee ?Oatt . ?e :fe-Social_event-Host ?Oorg . ?e :fe-Social_event-Occasion ?Osup . ?Osub :fe-Social_event-Occasion ?e . ?Ooff a :frame-Offering-offer.v ;
:fe-Offering-Theme ?e . ?e a :frame-Performing_arts-performance.n ; :fe-Performing_arts-Performer ?Oper ; :fe-Performing_arts-Performance ?Owor . _: a :frame-Recording-record.v ; :fe-Recording-Phenomenon ?e ; :fe-Recording-Medium ?Orec . } WHERE { ?e a sch:Event . # Unambiguous translation OPTIONAL{?e sch:startDate ?Osta} OPTIONAL{?e sch:endDate ?Oend} OPTIONAL{?e sch:duration ?Odur} OPTIONAL{?e sch:location ?Oloc} OPTIONAL{?e sch:attendee ?Oatt} OPTIONAL{?e sch:organizer ?Oorg} OPTIONAL{?e sch:superEvent ?Osup} OPTIONAL{?e sch:subEvent ?Osub} OPTIONAL{?e sch:offers ?Ooff} OPTIONAL{?e sch:performer ?Oper} OPTIONAL{?e sch:workPerformed ?Owor} OPTIONAL{?e sch:recordedIn ?Orec} # Ambiguous translation OPTIONAL{?e sch:doorTime ?Odoo} # No translation OPTIONAL{?e sch:eventStatus ?Oeve} OPTIONAL{?e sch:typicalAgeRange ?Otyp}
OPTIONAL{?e sch:previousStartDate ?Opre} }
The only extension of the FrameBase schema used here was the frame :frame-Timespan-period.n with the start and end frame elements, used to denote periods of time. This, however, is not an ad-hoc extension motivated by a particular need of only one source, but a very general one. Out of the 16 properties of the Event class, 12 were translated without loss of meaning. One was translated with partial loss of meaning (doorTime, translated as a generic start time) and 3 of them were not translated.
Whether these can be integrated too, by means of more complex structures, is something
we are investigating.
4.4 Mapping Event Aspects to Frame Elements
The survey by Scherp and Mezaris [
– Time and Space: When applicable, frames include frame elements Time and Place.
– Participation: The classification defines this as “participation of objects in event,
where objects can be any living as well as non-living things and include
people, buildings, and other even intangible objects like the roles a person plays
in a specific situation” [
• Mereology: The relation between two events, when one is part of
another. Some frames will have a frame element that will fill this role,
like :fe-Social_event-Occasion in the example of the Event class
in schema.org. In other cases, an additional frame instance of type
:frame-Part_whole can be used.
• Causality: One event is the cause of another. Some frames will have a frame
element that will fill this role, like :fe-Event-Reason in the example for the
Event class in DBpedia. In other cases, an additional frame instance of type
:frame-Causation can be used.
• Correlation: When “two (or more) events have a common cause, but this
common cause cannot be explained”. If we can assume there is a common cause
as in the definition, then the causal relationships can be represented with two
instances of :frame-Causation connecting with an anonymous node for the
unknown cause.
– Documentation: Events can be “documented using some media like photos or
videos captured during the event”. This relation is between an event and such
documentation. It can be expressed connecting the events by an additional frame
of type :frame-Recording-document.v, :frame-Recording-record.v, and
:frame-Recording-register.v, or some extension if needed.
– Interpretation: This aspect aims at capturing “subjectivity that may exist on the
other aspects of events”. This is a very broad category that may include different
phenomena. The perspectivization relation in FrameNet [
For instance, :frame-Commerce_Sell and :frame-Commerce_Buy are perspectivizations of :frame-Commerce_Scenario. In other cases, an additional frame instance of a pertinent type can be used, for instance :frame-Becoming_aware. 4.5 Complex Transformations Most of the integration rules we have described follow a pattern which involves an event class in the source being translated as a frame class, and each of their outgoing properties being mapped to individual frame elements. However, there are multiple ways in which the rules can differ from this basic pattern. 1. Sometimes, a class integration rule may need to instantiate multiple frames rather than just a single one. We distinguish two main types of this phenomenon. a) The instantiated frame instances may be connected by frame elements. Examples of this include the frame :frame-Timespan-period.n created to represent time periods, and the subframes of Relative_time to express precedence between events (all in the example for dbpedia-owl:Event). The same applies when a frame element is used to specify a frame beyond the lexical unit (see the rule for dbpedia:Space_exploration). b) Several frames can also be evoked separately, without the instances being directly connected by any frame element. When these frames describe different perspectives of the same event, there is the possibility that FrameNet links them by means of perspectivization, and therefore FrameBase can infer one from another. For example, classes :frame-Commerce_buy-buy.v and :frame-Commerce_sell-sell.v, which are used for classes Buy and Sell in the organized crime taxonomy, are both perspectivizations of :frame-Commerce_goods-transfer. In this case, inference is possible because RDFS subclass and subproperty properties are used in FrameBase to reflect the perspectivization relation between frame classes and frame elements respectively. Another example are :frame-Receive_visitor_scenario and :frame-Visit_host, which are perspectives of :frame-Visitor_and_host. However, in other cases one cannot rely on existing inference. For instance, see how the rule to translate Event from schema.org, besides frames Event-event.n and Timespan-period.n, also instantiates Performing_arts-performance.n, Recording-record.v and Offering-offer.v when certain properties are present. 2. Another possible source of complexity is that frame elements can be inverted. In this case, the integration rules need to invert the order of the arguments, like in the second appearance of :fe-Social_event-Occasion in the integration rule for the class Event in schema.org. 3. Oftentimes, a property (rather than a class) in the source can be translated as evoking a frame on its own. In this case, the two involved entities become connected to the new frame by means of frame elements. This would be the case for a property like fightAgainst, which might evoke an event or frame of type armed conflict, about which additional information could be added. None of the examples we have covered above are of this kind, because we use sources that explicitly represent, or reify, events. In other sources, however, this phenomenon appears quite frequently.
Arbitrary combinations of these phenomena are possible (e.g. the rule integrating the Event class from schema.org). Overall, this makes automatic generation of the integration rules a very hard task, because it generates so many free variables that any attempt to train a system would face extreme sparsity. In some cases, it may thus make sense to sacrifice some recall, developing a system that only covers simpler transformations. 4.6 Representational Flexibility Finally, another potential challenge for data integration is that even when a homogeneous schema such as FrameBase is used, certain kinds of knowledge can still be expressed in multiple possible ways.
– One example is that there are several ways of narrowing down the meaning of
a frame instance. One is creating a new sub-microframe associated with a new
lexical unit. Another one is assigning a value to a frame element (see example
for SpaceMission), as mentioned above. This may lead to divergent choices of
representation even within the core part of the schema that comes from FrameNet.
– Another example of this is when a frame element needs to be reified, i.e. represented
as a frame instance, to express something additional about it (as would be the case
of the property previousStartDate in schema.org), or when there is no direct
frame element available and creating it would lead to a combinatorial explosion
in the size of the schema. An example of the latter is the difference between our
proposal for using the frame Part_whole for expressing sub-event relations, and
how we used the frame element Occasion for the frame Social_event, but this is
a particularity of that frame. Again, this may lead to an incoherent representations
in the knowledge base. One potential way of addressing this would be extending the
reification–dereification mechanism of FrameBase [
Conclusion We have shown how events from specialized domains can be represented with the FrameBase schema under a unified model, integrating events in the prototypical sense with more general kinds of events in the sense of abstract happenings or situations. This model has proven to have a high degree of coverage because it needed just few extensions to accommodate the integrated knowledge, and we have illustrated how these extensions can be performed when needed. We have also discussed the various challenges and problems one faces when the integration rules from disparate structured sources of event information are to be built automatically.
Extremely specialized domains, such as quantum physics, may produce lower coverage and need more extensions, although in some cases the creators of FrameNet have also been involved in projects that led to the inclusion of specific scientific and technical domains.
The integration rules that we produce can be used in the future as gold standards for training and testing automatic methods for creating rules from other schemas. We are currently performing research on these methods to integrate further sources such as YAGO2s, Freebase, and Wikidata.
Acknowledgments The research leading to these results has received funding from the European Union Seventh Framework Programme (FP7/2007-2013) under grant agreement No. FP7-SEC-2012-312651 (ePOOLICE project). as well as China 973 Program Grants 2011CBA00300, 2011CBA00301, and NSFC Grants 61033001, 61361136003, 61450110088.
References