Research
Publications
Presentations
Related Work and References
A work that is closely related to the EventFinder ontology is the Event ontology [20]. The creators of this ontology focused more on its simplicity in order to make the ontology more flexible. With this clever decision, they were able to construct an ontology that could handle all kinds of events, such as festivals or talks in a conference, using a simple model. The model they used revolves around an event as the main concept with connections to location, time, agents, factors, and products. The ambiguity of the terms serves as the backbone of the ontology’s flexibility to handle multiple types of events at different conceptual granularities.
The Event ontology also has the ability to answer queries that are similar to those handled by the EventFinder ontology. For instance, an example would be a query for ”a performance event, involving one performer and an instrument (the Santur) in London, the 15th of October 2007 at noon, and lasting an hour.” Although the Event ontology seems to work in the same way as the EventFinder ontology, the EventFinder ontology has a layer of personalization that differentiates its output from that of the Event ontology. Using the user’s history of liked and disliked events, the EventFinder ontology is able to find events that are more personalized to the user’s preferences.
References
[1] “Event,” Role. [Online]. Available: https://schema.org/Event. [Accessed: 04-Oct-2018].
[2] “IMDb Datasets,” IMDB. [Online]. Available: https://www.imdb.com/interfaces/. [Accessed: 03-Oct-2018].
[3] “Eventful API,” Documentation - Eventful API. [Online]. Available: http://api.eventful.com/docs. [Accessed: 04-Oct-2018].
[4] B. McBride, T. Grahame, J. Rayfield, S. Williams, and P. Wilton, “Ontologies - Sport Ontology,” BBC. [Online]. Available: https://www.bbc.co.uk/ontologies/sport. [Accessed: 02-Oct-2018].
[5] IPTC, “SportsML-G2,” IPTC. [Online]. Available: http://iptc.org/standards/sportsml-g2/. [Accessed: 03-Oct-2018].
[6] Discovery API 2.0. [online] The Ticketmaster Developer Portal. Available at: https://developer.ticketmaster.com/products-and-docs/apis/discovery-api… [Accessed 4 Oct. 2018].
[7] Merriam-webster.com. (2018). Dictionary by Merriam-Webster: America's most-trusted online dictionary. [online] Available at: https://www.merriam-webster.com/dictionary/ [Accessed 3 Oct. 2018].
[8] “Spectator Sports in Albany: Watch Professional & Collegiate Baseball, Basketball, Hockey & More,” Albany.com. [Online]. Available: https://www.albany.com/things-to-do/spectator-sports/. [Accessed: 06-Oct-2018].
[9] Dublin Core Metadata Initiative. 2012. Dc terms ontology. http://purl.org/dc/terms/ .
[10]EDM Council. 2017. Fibo currencyamount ontology. http://www.omg.org/spec/EDMC-FIBO/FND/Accounting/CurrencyAmount/ .
[11]EDM Council. 2018a. Fibo financialdates ontology. http://www.omg.org/spec/EDMC-FIBO/FND/DatesAndTimes/FinancialDates/ .
[12]EDM Council. 2018b. Fibo occurrences ontology. http://www.omg.org/spec/EDMC-FIBO/FND/DatesAndTimes/Occurrences/ .
[13]Eventful. 2018. Eventful. http://api.eventful.com .
[14]Glimm, B.; Horrocks, I.; Motik, B.; Stoilos, G.; and Wang, Z. 2010. Hermit: An owl 2 reasoner. http://www.hermit-reasoner.com/ .
[15]Miles, A., and Brickley, D. 2005. Skos core ontology. http://www.w3.org/2004/02/skos/core# .
[16]National Institute of Standards and Technology. 2018. Specificationmetadata ontology. http://www.omg.org/techprocess/ab/SpecificationMetadata/ .
[17]Object Management Group. 2017. Lcc countryrepresentation ontology. http://www.omg.org/spec/LCC/Countries/CountryRepresentation/ .
[18]OpenStreetMap Foundation. 2004. Openstreetmap. https://www.openstreetmap.org .
[19]Poveda-Villalon, M.; Suarez-Figueroa, M. C.; Garcia-Delgado, M. A.; and Gomez-Perez, A. 2009. Oops! (ontology pitfall scanner!): supporting ontology evaluation on-line. http://oops.linkeddata.es/ .
[20]Raimond, Y., and Abdallah, S. 2007. The event ontology. http://motools.sourceforge.net/event/event.html .
[21]Stardog. 2017. Pellet. https://github.com/stardog-union/pellet .
[22]Ticketmaster. 2016. Ticketmaster. https://www.ticketmaster.com/
Design
Use Case
Conceptual Model Overall Structure
The overall structure of the technical approach of the EventFinder ontology can be divided into three broad categories: Events, Performers, and Venues.
Events represent the events that are retrieved from TicketMaster’s Discovery API (Ticketmaster 2016) and the Eventful API (Eventful 2018). Events can be categorized as three different types of events that can be handled by the system. There are performance events (of which cover events that include creative works, such as plays and concerts), sporting events (which cover sports), and user history events (which cover events that were liked or disliked by the user). All of these types are subclasses of a main Event class. The Event class has various object and data properties of which resemble important information of the events, such as start and end times of the events, the ticket prices, and their ratings. Every subclass of event (excluding the user history events) will have a property that links it to a class representing the event’s type. For instance, every play event will be linked to a play.
Venues represent the venues where certain types of events could take place. These can include stadiums, arenas, concert halls, etc. Each Venue will have a name, a URL, information about accessibility, and a location. Each Event is linked to a Venue with EventFinder’s hasVenue object property. In other words, every Event will have a Venue.
Performers represent those who will be performing at the events. The Performer class has three subclasses: Actor, Artist, and Athlete. Each Performer has a name, a URL, and a biography. Every Performer is also a member of a PerformerCollection in order to handle groups. PerformerCollection is subclassed by PerformingArtsCompany, MusicalPerformers, and Team according to the three subclasses of Performer. Each Event is linked to a Performer.
Conceptual Model Diagrams
Conceptual Model of 'Event' Class
The diagram describes the conceptual model of the ‘Event’ Class. The event has ‘StartTime’, ‘EndTime’, ‘Title’, ‘Venue’, ‘Rating’, ‘Performer’, ‘URL’, ‘Price’, ‘Category’, ‘SubCategory’, ‘Price’, ‘Accessibility’, ‘Description’ properties. Here, ‘StartTime’ and ‘EndTime’ are the subclass of ‘Time’, and ‘SubCategory’ is the subclass of ‘Category’. In addition, ‘Event’ has two subclasses, i.e., ‘PerformanceEvent’ and ‘SportEvent’. ‘PerformanceEvent’ is subclassed by ‘PlayEvent’ and ‘SportEvent’. Each of the lower-level Event subclasses contain properties pointing to the ‘Sport’, ‘Play’, and ‘Concert’ classes. The ‘Play’ and ‘Concert’ classes are subclasses of the ‘CreativeWork’ class which is classified by a ‘Classifier’ class. This ‘Classifier’ class is subclassed by a ‘Genre’ class that represents the genre of a play or concert. Events in user history are represented via membership to a UserHistoryEvent class which subclasses Event.
Conceptual Model of 'Venue' Class
The diagram focuses on the ‘Venue’ of the event. The ‘Venue’ is at a particular ‘Location’ which is defined by the street address, city, state, country and zip code. The venue might also have a website specified by its URL.
Conceptual Model of 'Performer' Class
This diagram focuses on the ‘Performers’ in an event. Each performer may have a long biography and short biography describing them. These are subclasses of ‘Biography’. The performer is also associated with a particular date at which they were added to the database, a URL to their website, and a ‘Demand’ which indicates how many users have liked events involving the performer. Each performer also has a ‘hasName’ data property specifying that the performer has a name of type rdfs:literal.
Documentation
The following are the Conceptual Model Diagrams created over the course of the developments of this project:
Latest Conceptual Model
Conceptural Model Source Files
We use 'Draw.io' to draw the conceptual models. The source files are as follows.
- EventFinder Event Conceptual Model Source File
- EventFinder Venue Conceptual Model Source File
- EventFinder Performer Conceptual Model Source File
Conceptual Model PNG Files
- EventFinder Event Conceptual Model PNG
- EventFinder Venue Conceptual Model PNG
- EventFinder Performer Conceptual Model PNG
Latest Ontology
Term Lists
Demonstration and Queries
Table of Contents
Overview Example 1 Example 2 Example 3 Example 4 Example 5
Overview
The functionality of the EventFinder ontology is captured by five competency questions. These questions are designed to evaluate the different types of functionality that traditional event searching systems do not provide, such as the ability to query for more than one event type, for a specific time range like afternoon, or for similar events to other events or performers.
This demo supposes the user has three events in user history.
| Event | Type | Time | Location |
|---|---|---|---|
| Lucia Micarelli In Schenectady | Concert | 2018-11-20 20:00 | SEFCUArena |
| Rudolph The Red Nosed Reindeer | Play | 2018-11-20 13:00 | The Palace Theatre |
| Albany Great Danes VS Holy Cross Crusaders In Albany | Sport | 2018-11-20 18:00 | SEFCUArena |
Example 1: "Find classical music concerts and dramatic plays during November or December 2018"
One of the most simple functionalities that we aim for is to allow the user to query based on the time and category of the event. Users will often know what kind of events they are in the mood for and when they wish to see these events (most likely fairly close to the time of querying). The ontology must be able to reason about what events satisfy these properties specified by the user and take place during the specified time. Our ontology handles queries like these in two steps. First, events are found based on direct query results; after that, results from the user's history are searched. For the first step, we only need to find Concerts under the genre of Classical, and Plays that fall under the genre of Drama, that have the correct dates and times. The second step is almost the same as the first step, except events that are part of the user's history are also searched. The following images illustrate through the concept map for our ontology how this query is handled through the connection between an event, its category/genre, and its time information.
SPARQL QUERY: "Find classical music concerts and dramatic plays during November or December 2018"
PREFIX rdf: The results of this query over the latest release of our ontology are as follows: - Albany Symphony - The Magic of Christmas [Back to Top]
Example 2: "Find all basketball games happening in Albany between 1 December 2018 and 31 December 2018?"
In addition to time and category, we also aim to allow the user to query for events in a specific location, and to specify the sport type he/she is interested in along with a specified date range. We allow the user the ability to be more specific with their queries by either the type of sport being played or the genre of the play or concert for an event. On top of that, the ontology can use the user's history in order to infer which basketball teams the user may be interested in as well, based on the teams that participated in the basketball events in the user's history. In order to handle the query, our ontology follows a similar structure of steps to the previous example. It first searches for all upcoming events that are SportEvents that have a hasSport property for Basketball and that are being held in Albany with a start time within the month of December. Afterwards, it searches through the user's history for UserHistoryEvents that are in the specified date range and have the same sport of Basketball, the same Venue, and/or the same Team. The following images illustrate through the concept map for our ontology how this query is handled through the connection between an event, the sport event and user history event subclasses, the start time, and the location.
SPARQL QUERY: "Find all basketball games happening in Albany between 1 December 2018 and 31 December 2018?"
PREFIX xsd: The results of this query over the latest release of our ontology are as follows: - Monmouth Hawks vs. Albany Great Danes Basketball in Albany [Back to Top]
Example 3: "Do you have some recommendations for concerts similar to “Charlie Puth” and “Elton John” concerts in December?"
One of the main functionalities we aim to provide is the ability for a user to query based on similarity. A lot of times, a user might find themselves wanting to look for an event they might like, without being certain exactly what to search for. In such cases, we allow them the ability to pose questions such as "do you have some recommendations for concerts similar to “Charlie Puth” and “Elton John” concerts?" The ontology must support the ability to reason about what is similar between these two artists. The following connections within our ontology's concept map shows how such a query can be handled. We simply need to find all the events that have these artist as performers, and then, find the Genres associated with the Concerts played at these events. Once we have these genres, we can query for all events that match these genres and all the other constraints in the user's query query.
SPARQL QUERY: "Do you have some recommendations for concerts similar to “Charlie Puth” and “Elton John” concerts in December?"
PREFIX evt: The results of this query over the latest release of our ontology are as follows: New Holiday in New York Trans-Siberian Orchestra The Ghosts of Christmas Eve [Back to Top]
Example 4: "Find a theatrical play for me."
This competency question is designed to test the ontology's capabilities on broad queries that could potentially result in a very large amount of results, and demonstrates the need to recommend a list based not only on the query, but also on the user's history. The following connections within our ontology's concept map shows how such a query can be handled. As shown, the user history events are a sub class of events, which allows events that the user liked to be included as a member of this class as well. It will retain all its properties and remain query-able by these properties such as genre, venue and performer
Based on these portions of our ontology, we can obtain the relevant information about individuals that can help us answer such a question. The following images show a visualization in Protege, that presents information needed to answer such a query. For example, if the 'School of Rock" event was added to the user history, it would still retain its properties such as its association to the school of rock performance art play, which would then give us the play's genre information.
SPARQL QUERY: "Find a theatrical play for me."
prefix evt: prefix evt-indv: SELECT distinct ?e WHERE { ?h a evt:UserHistoryEvent . ?h evt:hasPlay ?hp. ?e a evt:PlayEvent. ?e evt:hasPlay ?p. { ?hp evt:hasGenre ?hg. ?p evt:hasGenre ?hg. } UNION { ?h evt:hasVenue ?hv. ?e evt:hasVenue ?hv. } UNION { ?h evt:hasPerformer ?hp. ?e evt:hasPerformer ?hp. } FILTER ( NOT EXISTS { ?e a evt:UserHistoryEvent } ) } The results of this query are: - School of Rock - The Musical [Back to Top]
Example 5: "I will go to Albany in December, do you have recommendations for any hockey events happening in the area during the afternoon?"
There are two steps for Event Finder to recommend events. In the first step, Event Finder will find 'hockey events' that is in 'Albany or the neighbour cities' and the time is 'December afternoon'. The conceptual model involved is shown in the picture below.SPARQL QUERY: "I will go to Albany in December, do you have recommendations for any hockey events happening in the area during the afternoon?"
PREFIX rdf: PREFIX owl: PREFIX rdfs: PREFIX xsd: PREFIX evt: PREFIX evt-indv: PREFIX fibo-fnd-plc-loc: PREFIX lcc-cr: PREFIX fibo-fnd-rel-rel: PREFIX fibo-fnd-dt-oc: SELECT distinct ?e WHERE { ?e a evt:SportEvent. { # type=Hockey ?e evt:hasSport evt-indv:Hockey. { # location=Albany ?e evt:hasVenue ?v. ?v fibo-fnd-plc-loc:isLocatedAt ?l. ?l evt:hasCity evt-indv:Albany. } UNION { # infer other locations near to Albany ?e evt:hasVenue ?v. ?v fibo-fnd-plc-loc:isLocatedAt ?l. ?l evt:hasCity ?c. ?c a evt:City. ?c lcc-cr:isPartOf ?r. ?r lcc-cr:hasSubregion evt-indv:Albany. } } Union { ?f a evt:UserHistoryEvent. ?f a evt:SportEvent. # infer other locations based on user's history ?f evt:hasVenue ?v. ?v fibo-fnd-plc-loc:isLocatedAt ?l. ?l evt:hasCity ?c. ?c a evt:City. ?e evt:hasVenue ?ev. ?ev fibo-fnd-plc-loc:isLocatedAt ?el. ?el evt:hasCity ?c. #infer other teams based on user's history ?f evt:hasTeam ?t. ?e evt:hasTeam ?t. } # December afternoon evt-indv:EventCalendar201812 fibo-fnd-rel-rel:comprises ?calendar12 . ?calendar12 fibo-fnd-dt-oc:hasOccurrence ?e . evt-indv:EventCalendarAfternoon fibo-fnd-rel-rel:comprises ?calendarAfternoon . ?calendarAfternoon fibo-fnd-dt-oc:hasOccurrence ?e . FILTER ( NOT EXISTS { ?e a evt:UserHistoryEvent } ) } The results of this query over the latest release of our ontology are as follows:
| Event |
|---|
| Union vs Canisius in Schenectady |
| Monmouth Hawks At Albany Great Danes Basketball in Albany |
Get Involved
All the artifacts that resulted from the development of this project can be found at the EventFinder project page. We gladly welcome feedback, suggestions, and collaborative efforts for the further improvement and maintenance of this project. Our contact information can be found below.
Contact Information:
- Manling Li (lim22@rpi.edu)
- Nasir Pauldon-Collins (pauldn@rpi.edu)
- Jon Harris (harrij15@rpi.edu)
- Ananya Subburathinam (subbua@rpi.edu)
- Theo Lipeles (lipelt@rpi.edu)
Our Maintenance Policy for the EventFinder project and ontology are as follows
- Incremental changes are versioned with increasing version numbers in the ontology URI
- All changes in any final release must be checked with a syntax validator
- Feedback on each new version was taken into account in the updates performed in the next new version
- All changes will be documented in the UseCase, Concept Model, and Term List as appropriate
- For each new release, the documentation and ontology will have consistent version numbers indicated by OE_[version_number]
- Currently merges of updates from team members is performed manually using a local diff tool by one of the team member. In the future development of the ontology could be moved to a git repository to facilitate easy version management and change merging.
Licence Information
The EventFinder Ontology and all documents generated by the EventFinder team are under The MIT License.
All the artifacts that resulted from the development of this project can be found at the EventFinder project page. We gladly welcome feedback, suggestions, and collaborative efforts for the further improvement and maintenance of this project. Our contact information can be found below.
Contact Information:
- Manling Li (lim22@rpi.edu)
- Nasir Pauldon-Collins (pauldn@rpi.edu)
- Jon Harris (harrij15@rpi.edu)
- Ananya Subburathinam (subbua@rpi.edu)
- Theo Lipeles (lipelt@rpi.edu)
Our Maintenance Policy for the EventFinder project and ontology are as follows:
- Incremental changes are versioned with increasing version numbers in the ontology URI
- All changes in any final release must be checked with a syntax validator
- Feedback on each new version was taken into account in the updates performed in the next new version
- All changes will be documented in the UseCase, Concept Model, and Term List as appropriate
- For each new release, the documentation and ontology will have consistent version numbers indicated by OE_[version_number]
- Currently merges of updates from team members is performed manually using a local diff tool by one of the team member.
In the future development of the ontology could be moved to a git repository to facilitate easy version management and change merging. Licence Information The EventFinder Ontology and all documents generated by the EventFinder team are under The MIT License.
Class Content
Assignments
Assignment 13
Assignment 13 Use Case
Assignment 13 Terminology
Assignment 13 Conceptual Model
Assignment 13 Ontology
Assignment 13 Ontology Individuals
Assignment 13 Report
Assignment 12
Assignment 12 Use Case
Assignment 12 Terminology
Assignment 12 Conceptual Model
Assignment 12 Ontology
Assignment 12 Ontology Individuals
Assignment 12 Report
Assignment 11
Assignment 11 Use Case
Assignment 11 Terminology
Assignment 11 Conceptual Model
Assignment 11 Ontology
Assignment 11 Ontology Individuals
Assignment 11 Presentation
Assignment 11 Report