Add Event Series support #446
23 participants
and others
Thanks for the detailed proposal (and illustration :) We do need to do more in this area.
Could you add a non-pull-request issue for this too, and some links to existing other issues on events? e.g. #240 is being actively discussed. Also #406 seems relevant, as well as various considerations around opening hours markup - https://github.com/schemaorg/schemaorg/issues?utf8=%E2%9C%93&q=opening+hours
Can't we handle those cases with the existing property
http://schema.org/superEvent
?
Then, the Salzburger Festspiele 2015 would be an event, and a single concert will also be an event, and the latter have the former as its schema:superEvent.
Or if you want to model the Salzburger Festspiele as a super-super event, just define all three:
foo:SalzburgerFestspiele a schema:Event.
foo:SalzburgerFestspiele2015 a schema:Event;
schema:superEvent foo:SalzburgerFestspiele.
foo:ConcertABC a schema:Event;
schema:superEvent foo:SalzburgerFestspiele2015.
AFAIK, this should cover all what is needed.
Re property: @danbri has stressed recently that a specific property for parthood like superEvent is much better than expanding the use of isPartOf.
Re EventSeries - I think that the SalzburgerFestspiele is covered by the existing, broad notion of schema:Event. Unless we need specific properties for EventSeries, I would rather not add a new type for this.
I would say that an EventSeries is also an Event. They will often have the same properties as singular events, like a location (e.g. Wagner festival in Bayreuth), they may have a startDate and endDate (e.g. an event like "Summer Classics in XYZ", which would run for a few months).
Many of the properties of http://schema.org/Series look weird to me when attached to an event series.
So I think we should simply use schema:Event for EventSeries and maybe expand the domain of a few properties from http://schema.org/Series to include schema:Event.
I disagree with that, @mfhepp, EventSeries is not an Event, FMPOV that would be the wrong semantics.
Let's take Salzburger Festspiele as example, with my proposed model the data would look like:
<http://www.salzburgerfestspiele.at/> a schema:EventSeries ;
schema:name "Salzburger Festspiele"@de ;
schema:name "Salzburg Festival"@en .
<http://www.salzburgerfestspiele.at/#2015> a schema:Event ;
schema:superEvent <http://www.salzburgerfestspiele.at/> ;
schema:startDate "2015-07-18"^^xsd:date ;
schema:endDate "2015-08-30"^^xsd:date ;
schema:name "Salzburger Festspiele 2015"@de ;
schema:name "Salzburg Festival 2015"@en ;
schema:subEvent <http://www.salzburgerfestspiele.at/opera/eroberung-2015> .
<http://www.salzburgerfestspiele.at/opera/eroberung-2015> a schema:Event ;
schema:startDate "2015-07-20T20:00"^^xsd:dateTime ;
schema:endDate "2015-07-20T22:00"^^xsd:dateTime ;
schema:name "Wolfgang Rihm, Die Eroberung von Mexico"@de ;
...
<http://www.salzburgerfestspiele.at/#2014> a Event ;
schema:superEvent <http://www.salzburgerfestspiele.at/> ;
schema:startDate "2014-07-DD"^^xsd:date ;
schema:endDate "2015-08-DD"^^xsd:date ;
schema:name "Salzburger Festspiele 2014"@de ;
schema:name "Salzburg Festival 2014"@en .
...
Actually... reading the current description of both superEvent and subEvent I do not think they have the right meaning for relating an event with the series it belongs to.
Would the Olympic Games then be an EventSeries? Would you attach a schema:location property to an EventSeries?
Yes @rtroncy, Olympic Games could be a EventSeries. But it wouldn't have location, and actually that's a good example to argument why an EventSeries is not an Event.
I'm trying to grasp the semantics of your EventSeries proposal and whether or not it implies some sort of grouping of events + having some recurrence. In your example, your EventSeries is a yearly? festival, the super Event is the particular year edition and the subEvents are all the things organized within this year (Opera, etc.), right? How is this different from the Olympic Games?
Yes, that's more or less the idea. I used a yearly event as an example, but a series does not need a fixed periodicity.
Let's use the Olympic Games to evolve a bit more the explantation: "Rio 2016 Olympics" is a Event, with concrete dates, all the subevents for each concrete sport, etc.; I think we all agree on that. But "Olympic Games" itself is a EventSeries, it does not have all the stuff around e concrete event (location, date, etc). Basically the semantics defined for Series, but for a concrete type I think was missed.
I would counter that most recurring music festivals, including the following
http://en.wikipedia.org/wiki/Bregenzer_Festspiele
http://en.wikipedia.org/wiki/Mozart_Festival_W%C3%BCrzburg
http://en.wikipedia.org/wiki/Bayreuth_Festival
would well work with schema:Event, same as most of
http://en.wikipedia.org/wiki/List_of_music_festivals
Even the modern Olympic Games could be modeled with schema:Event.
The three example given have a start date (first actual event) and a location.
I agree that we might need to improve the wording for schema:Event, but I hesitate to add a new type for this. I would not fight against EventSeries, but I do not see any actual benefit for neither publishers nor consumers of data. In the end, what matters is not whether you can disambiguate a concept by a philosophical analysis but whether the distinction brings any benefits for automated data processing.
Note that the Wikipedia definition for festival starts with
"A festival or gala is an event ..."
http://en.wikipedia.org/wiki/Festival
;-)
Freebase also has an "EventSeries" Type ... it was called Recurring Event and note its properties - https://www.freebase.com/time/recurring_event?schema=&lang=en
In issue #417, we are considering renaming Series to CreativeWorkSeries, which I think clarifies why the properties look weird when attached to EventSeries. (And also why we need better names.)
It would seem better to either make EventSeries a subtype of Event as previously suggested or create new properties to capture hasPart. I prefer the former, as I think there are times when EventSeries have the same properties as the individual Events.
@mfhepp This is not that much a philosophical analysis, I'm all for being pragmatic but there are many many cases where even Wikipedia is struggling with this distinction between Event and EventSeries or whatever you want to name it. Take for example the series of G8 events, or G20, or EU Summit, etc. In Wikipedia, some G8 event or G20 events or EU Summit or you name it, have a dedicated wiki page because there has been some violence (Gothenburg, Heiligendamn) or some important decisions while for others, you will just find a trace in a list of ... type of wiki page.
All I am saying is that schema:Event would work for most (if not all) event series, with maybe a minor tweak of of the description. In the end, an event series can be considered a meta-event (an ideal). Same as we treat product models as subtypes of product, even though their ontological nature is quite different.
Again, I will not fight against adding an EventSeries type, but it will not add much value IMO.
For the records: Other vocabs for events also use a very broad notion of events:
- http://linkedevents.org/ontology/#term-Event "Class: Event
Definition: "Something that happened," as might be reported in a news article or explained by a historian.
An event consists of some temporal and spatial boundaries subjectively imposed on the flux of reality or imagination, that we wish to treat as an entity for the purposes of making statements about it. In particular, we may wish to make statements that relate people, places, or things to an event.
Note that, unlike some defintions of "event," this definition does not specify that an event involves a change of state, nor does it attempt to distinguish events from processes or states."
"Event - An arbitrary classification of a space/time region, by a
cognitive agent. An event may have actively participating agents,
passive factors, products, and a location in space/time."
"Any physical, social, or mental process, event, or state. More theoretically, events can be classified in different ways, possibly based on 'aspect' (e.g. stative, continuous, accomplishement, achievement, etc.), on 'agentivity' (e.g. intentional, natural, etc.), or on 'typical participants' (e.g. human, physical, abstract, food, etc.). Here no special direction is taken, and the following explains why: events are related to observable situations, and they can have different views at a same time. If a position has to be suggested here anyway, the participant-based classification of events seems the most stable and appropriate for many modelling problems. (1) Alternative aspectual views Consider a same event 'rock erosion in the Sinni valley': it can be conceptualized as an accomplishment (what has brought a certain state to occur), as an achievement (the state resulting from a previous accomplishment), as a punctual event (if we collapse the time interval of the erosion into a time point), or as a transition (something that has changed a state to a different one). In the erosion case, we could therefore have good motivations to shift from one aspect to another: a) causation focus, b) effectual focus, c) historical condensation d) transition (causality). The different views refer to the same event, but are still different: how to live with this seeming paradox? A typical solution e.g. in linguistics (cf. Levin's aspectual classes) and in DOLCE Full (cf. WonderWeb D18 axiomatization) is to classify events based on aspectual differences. But this solution would create different identities for a same event, where the difference is only based on the modeller's attitude. An alternative solution is applied here, and exploits the notion of (observable) Situation; a Situation is a view, consistent with a Description, which can be observed of a set of entities. It can also be seen as a 'relational context' created by an observer on the basis of a 'frame'. Therefore, a Situation allows to create a context where each particular view can have a proper identity, while the Event preserves its own identity. For example, ErosionAsAccomplishment is a Situation where rock erosion is observed as a process leading to a certain achievement: the conditions (roles, parameters) that suggest such view are stated in a Description, which acts as a 'theory of accomplishments'. Similarly, ErosionAsTransition is a Situation where rock erosion is observed as an event that has changed a state to another: the conditions for such interpretation are stated in a different Description, which acts as a 'theory of state transitions'. Consider that in no case the Event is changed or enriched in parts by the aspectual view. (2) Alternative intentionality views Similarly to aspectual views, several intentionality views can be provided for a same Event. For example, one can investigate if an avalanche has been caused by immediate natural forces, or if there is any hint of an intentional effort to activate those natural forces. Also in this case, the Event as such has not different identities, while the causal analysis generates situations with different identities, according to what Description is taken for interpreting the Event. On the other hand, if the possible actions of an Agent causing the starting of an avalanche are taken as parts of the Event, then this makes its identity change, because we are adding a part to it. Therefore, if intentionality is a criterion to classify events or not depends on if an ontology designer wants to consider causality as a relevant dimension for events' identity. (3) Alternative participant views A slightly different case is when we consider the basic participants to an Event. In this case, the identity of the Event is affected by the participating objects, because it depends on them. For example, if snow, mountain slopes, wind, waves, etc. are considered as an avalanche basic participants, or if we also want to add water, human agents, etc., makes the identity of an avalanche change. Anyway, this approach to event classification is based on the designer's choices, and more accurately mirrors lexical or commonsense classifications (see. e.g. WordNet 'supersenses' for verb synsets). Ultimately, this discussion has no end, because realists will keep defending the idea that events in reality are not changed by the way we describe them, while constructivists will keep defending the idea that, whatever 'true reality' is about, it can't be modelled without the theoretical burden of how we observe and describe it. Both positions are in principle valid, but, if taken too radically, they focus on issues that are only partly relevant to the aim of computational ontologies, which only attempt to assist domain experts in representing what they want to conceptualize about a certain portion of reality according to their own ideas. For this reason, in this ontology both events and situations are allowed, together with descriptions, in order to encode the modelling needs independently from the position (if any) chosen by the designer."
I think there is utility in being able to explicitly differentiate the EventSeries from the individual events. For example, the website for the Academy Awards, is largely about the 2015 event. At some point, it will be about the 2016 event. It would be nice if they could mark up information about the Academy Awards as a series differently from the most current Academy Awards presentation.
I think @danbri has to establish the foundations of such semantic, specially regarding the Series refactoring is being discussed at #417. I find a bit weak base the arguments on wikipedia textual descriptions.
Clearly a EventSeries and a Event have different meanings. How we want to model (different classes, same class with different properties, etc) it's a discussion can tak eplace later. This PR only proposes something, but grasp the semantics is needed before.
@vholland the difference between the proposed EventSeries and (CreativeWork)Series is that the latter serves largely as an organizing supertype (which we don't do much of) for more specific subtypes that would get widely deployed, whereas it sounds like EventSeries would be expected to be used for in-page markup directly.
My main concerns remain 1. clarifying relationship between a group of events linked by a common EventSeries, and a group of events linked by a common http://schema.org/superEvent 2. finding a model for repeating events and opening/closing hours that is simple enough to understand but that has some strategy for overriding defaults e.g. for holidays.
I just wanted to interject here and flag a project that I am currently working on with the Southbank Centre, Barbican Centre and Culture Kent. We are developing an open event data model, API design principle and, hopefully, a platform for delivering our shared event data. One of the key issues that we have been working on is how to model groups (series) of events. Most of the big organisations in the project have complex relationships amongst events, e.g., an event may be part of one or more series and these series may also be part of a larger series, such as a season.
While we have tried to stay in line with the schema.org model, we have found that it does not address our aims of using the model across the entire organisational landscape. Specifically when it comes to grouping events together, we have gone down the route of having a grouping entity with one attribute (type) that defines what kind of grouping it is. Events then can be associated with with one or more groupings.
If you are interested, I would be happy to share more about our model. I am also keen to see the outcome of this discussion as it will have an impact on how our model develops.
Hi folks
I'm a colleague of Stephen's working at Southbank Centre.
When @danbri mentions an override for holidays, it makes me think calendar applications, and hence ...
I'm wondering if someone cleverer than me can think whether there is anything to be gained from what Google have done for their Calendar API.
See https://developers.google.com/google-apps/calendar/concepts#recurring_events
and the RFC mentioned there:
http://www.ietf.org/rfc/rfc2445
It's way over my head, but it's work that has been at least considered in another context. Any thoughts?
@scdba
Very good point! We should take this as input when working on recurring dates, but at least I will not be able to touch this for sdo-gozer, so it is likely a task for the Q2 release.
Also, let us please separate the two issues of
a) modeling recurring dates and
b) whether we need an EventSeries type.
Recurring dates will be relevant for many branches of schema.org, namely for opening hours, but also offer validity and prices specifications, so I prefer a generic solution. Once we have this, there is IMO no need for a specific mechanism for recurring events, because we can simply use the recurring dates mechanism to specify the dates of the event.
@mfhepp Your comment about recurring dates actually points to the issue of the EventSeries type. Suppose in a run of a play, at certain matinee performances, the star actor will not appear. In her place is an understudy. We would want to be able to identify these events as being separate from the others as the customer may want see the star specifically.
The approach that the Southbank event model takes is that each event is the "atom" of data that we want to deal with. These atoms can then be grouped in a number of ways, depending on the needs of the organisation. You can either roll all the event dates into the grouping date range, or specify a specific data range for the grouping.
@StephenMoffitt This is why in general I prefer materialization over proprietary rules for repetition in markup. It simply gives you a natural mechanism for representing exceptions from the rule, and a querying client does not have to handle materialized and rules-based information, which can be very complicated.
However in the examples you describe, you could always update the data, i.e. exclude the one event from the recurrence rule and materialize the exception.
In a nutshell, I think we need to find a sweet spot that covers 80 - 90 % of the cases. A formally proven perfect solution for the underlying problems is IMO beyond what schema.org can achieve.
We could also expand / reuse the isVariantOf mechanism from schema:ProductModel, see
https://schema.org/isVariantOf
But I guess all this is post-gozer work ;-)
mfhepp - 'prefer materialization over proprietary rules for repetition in markup. '
I tend to agree and I've a feeling the google calendar stuff I mentioned would use just such 'proprietary rules - e.g. from the google URL
"recurrence": [
"RRULE:FREQ=WEEKLY;UNTIL=20110701T160000Z",
# EXRULE, RDATE, EXDATE...
],
However - I'm wondering if another source of guidance (again I've not looked in detail) might be what the BBC have done - I'm sure they will have recurring events.
There's a diagram of their model at
http://www.bbc.co.uk/ontologies/po
From a brief look they have a recursive series with an 'atomic' episode below it.
Very similar to what Southbank have done with our grouping (= bbc series) and event (= bbc programme = schema.org event)
So perhaps some of the difficulty in schema.org event etc comes from having the recursion too 'low' so the grouping and atomic level are done with the same object/entity,
whereas the needs of the grouping and the atomic are different?
I've not thought it through in a 'formally proven' way but have a hunch, so offer it for exploration and discussion.
danbri
added schema.org vocab cluster: Date/Time/Event and opening hour vocab issues and removed schema.org vocab labels 
The PR was from a very old branch, so we'll continue this feature at #1088.
Would anyone here object to EventSeries being subtype of Event? please follow up general design discussion in the issue at #447 rather than in specific pull requests.
Currently
schema.orgmisses support for event series.The following diagram depicts the proposal:
The proposal tries to minimize the impact on the current vocabulary by reusing already available terms, for instance
hasPart/isPartOf. The design is based on the assumption that is better to materialize descriptions of each event rather than base the model on using the recurrence rule.The Salzburger Festspiele could be the typical example where such construction would be necessary to model the different editions every summer.
This proposal has been developed by Redlink GmbH in the context of TourPack, a research project partially funded by the Austrian Research Promotion Agency (FFG).