Add EventMovedOnline to valid eventStatus values / use affiliatedLocation

thill-odi commented 4 years ago

Proposer

@nickevansuk (imin/ODI), seconded by @thill-odi (ODI)

Use Case

An event organiser needs to indicate that an event previously scheduled for physical participation now has an online option available, or is only available online.

Why is this not covered by existing properties?

This property only becomes relevant with the addition of virtualLocation to the specification (see issue #224).

In addition, this property was only recently added to pending in the schema.org vocabulary.

Please provide a link to example data

See e.g. https://www.cococollective.co.uk/booking/ for a yoga studio that has recently moved to online events to replace physical ones.

Proposal

In addition to the values currently defined as valid for eventStatus, the value EventMovedOnline should be included.

thill-odi commented 4 years ago

See also issues #224, #225, and #226.

nickevansuk commented 4 years ago

Suggestion of two different rules that could be applied here:

A) EventMovedOnline is used for situations where the event has temporarily moved to online-only (e.g. during unexpected circumstances).

Data could be collected via a tick box labelled e.g. "Class has been temporarily moved to Online-only"
When eventStatus is https://schema.org/EventMovedOnline , eventAttendanceMode MUST be https://schema.org/OnlineEventAttendanceMode or https://schema.org/MixedEventAttendanceMode, and hence virtualLocation and location must respect these constraints.

B) EventMovedOnline is used for any situations where the event now has an online participation option when it did not previously

Data could be collected via a tick box labelled e.g. "Class now allows online participation"
When eventStatus is https://schema.org/EventMovedOnline , eventAttendanceMode MUST be https://schema.org/OnlineEventAttendanceMode, and hence virtualLocation and location must respect these constraints.

Both A and B are compatible with schema.org, and B is more directly in line with schema.org, however data collection for B seems more ambiguous?

nickevansuk commented 4 years ago

Noting concerns that that existing data users may not yet support this as an enumeration value for eventStatus, so it may break existing implementations.

Default behaviour for unrecognised eventStatus is undefined in the specification, however the specification does state:

If the status property is not provided then applications should assume a default value of https://schema.org/EventScheduled.

RoastVeg commented 4 years ago

It seems to me that the intended use case of this new enumeration can be inferred already in the context of an RPDE feed for any feed consumer that tracks the state of Events. For any that do not track this information, the only loss of clarity is whether the Event was always online versus moved online.

For instance: If an Event has been updated in the feed, retains an EventStatus of EventScheduled (or is undefined, according to the specification) and has #225 set to OnlineEventAttendanceMode combined with #224, then we can retain backward compatibility for existing feed consumers whilst providing enough information to up-to-date consumers about how to present the online event.

This aligns well with Events that have #225 set to MixedEventAttendanceMode, since those will already (I assume) be maintaining an EventStatus of EventScheduled.

nickevansuk commented 4 years ago

Further to this, as noted by Bookwhen: they don't retain any indication of whether an event has been "moved online" or whether it has always been online, so won't be able to give a valid representation as to whether it was or wasn't online before.

How much value is there in knowing that an event has "moved online", is the key question here? Who would be interested to know that it was once offline? What would the user experience be for this?

thill-odi commented 4 years ago

Leaving aside the user-experience for this, I think there are in fact two points that would be useful.

Knowing that an even was previously available offline is useful if you're trying to track what happened to your favourite gym class. But for this to be helpful some other attributes need to be maintained for the identity to be clear (e.g. name); otherwise a URL or text field would be needed to unpack the change that has been made.
It will also hopefully some day be useful to know if and when a class is moving back offline again.

To accommodate this we'd need to associate the eventStatus with a Date or Schedule.

nickevansuk commented 4 years ago

Noting that this property would need to live at ScheduledSession level, and replace the current values for EventScheduled

nickevansuk commented 4 years ago

Relevant points from the summary of the W3C call on 25 March 2020:

Add a new property beta:affiliatedLocation was proposed for the original locations of an online-only event, to ensure that the existing data users’ implementations would be intentionally broken by the lack of a location field in all cases, and hence they would not misrepresent virtual classes as physical ones.
This replaces the need for EventMovedOnline, which can therefore be removed.
Hence, for virtual events where eventAttendanceMode is set to https://schema.org/OnlineEventAttendanceMode, location MUST NOT be included.

nickevansuk commented 4 years ago

Updated proposal

beta:affiliatedLocation is defined on Event, and has a value of type Place, to describe the original location of the event before it was moved online, and MUST only be used when eventAttendanceMode is set to https://schema.org/OnlineEventAttendanceMode.

Additionally when eventAttendanceMode is set to https://schema.org/OnlineEventAttendanceMode, location MUST NOT be included.

Example

"beta:affiliatedLocation": {
    "@type": "Place",
    "name": "Middlesbrough Sports Village",
    "address": {
      "type": "PostalAddress",
      "streetAddress": "Alan Peacock Way",
      "addressLocality": "Village East",
      "addressRegion": "Middlesbrough",
      "postalCode": "TS4 3AE",
      "addressCountry": "GB"
    },
    "geo": {
      "type": "GeoCoordinates",
      "latitude": 54.543964,
      "longitude": -1.20978500000001
    }
},
"beta:virtualLocation": {
    "@type": "VirtualLocation",
    "name": "Zoom Video Chat",
    "url": "https://zoom.us/j/1234567890/signup",
    "description": "Please log into Zoom a few minutes before the event, and mute your mic while you wait for the session to start",
    "beta:maximumVirtualAttendeeCapacity": 20
}

lukehesluke commented 4 years ago

@nickevansuk sorry it's taken me so long to spot this but my actual intention was that beta:affiliatedLocation be more general than "original location before moving online".

Could it just mean "affiliated location"? Even if the session has always been virtual, but wants to associate itself with some borough/town/city so that it can participate in some local campaign, it could do this with the beta:affiliatedLocation field?

If so, then there are two reasons to have this as a separate field from location:

The reason discussed in the 25th March call: so that existing apps would not misrepresent a virtual session as occurring at a place. Another way to think of this is: it has a different semantic meaning from location which is literally the place that you go to join the session
Ease of modelling. If we were to use a more general definition of "affiliated location", then the various Place requirements can be relaxed e.g. PostalAddress fields could be partially completed e.g.
```
{
  "type": "PostalAddress",
  "addressCountry": "GB",
  "addressRegion": "Somerset",
  "addressLocality": "Bath"
}
```
For physical sessions, a location's address has all fields required (https://www.openactive.io/modelling-opportunity-data/#describing-addresses). This is fair because it is very important that an attendee knows exactly where to go in order to arrive at the session

Otherwise, we should call the field beta:originalLocation?

Admittedly, there is a problem with this proposal:

In order for it to be possible for, let's say, a city-specific app to find all sessions - including virtual that are associated with the city, it has to do a search which doesn't rely on the vagueries of the address fields (e.g. is an addressLocality=Bath search really going to cover all use case of people describing addresses of things in the city of Bath? What about "Cardiff" vs "Caerdydd"?), a geo search is required. In which case, all locations should be recommended to have latitude/longitude in the geo field. However, is it easy to determine a latitude/longitude for a partial address like "Bath, UK"?

My hunch is that this should be fine. For example, try getting the latitude / longitude for "Bath, UK" here: https://opencagedata.com/demo. It returns 51.3813864, -2.3596963, which is roughly the centre of Bath

nickevansuk commented 4 years ago

Great feedback @lukehesluke, and agree with relaxing the constraints for the PostalAddress for the property used in this context. Unfortunately the tooling does not currently support either (a) relaxed constraints for beta properties or (b) relaxed constraints based on anything further away than the immediate parent property name.

However luckily this exact issue is already being addressed for PostalAddress in general (https://github.com/openactive/modelling-opportunity-data/issues/209), so that will hopefully solve it for this scenario too. In the meantime, as in #209, we'll have to ignore the address component validation errors for now.

The more general beta:affiliatedLocation does sound more useful (and potentially accurate as time goes on) than beta:originalLocation, and agree does imply more than the current description suggests.

Have updated the description of the beta field to "The physical location affiliated with the virtual event, for example the original location of the event before it was moved online." to hopefully capture this more fully.

Further feedback welcome!

lukehesluke commented 4 years ago

Great! Thanks @nickevansuk - makes lots of sense!

openactive-bot commented 4 years ago

This proposal has been added to the Beta namespace as follows:

(Class) Property	Expected Type	Description
(`schema:Event`) `beta:affiliatedLocation`	`schema:Place`	The physical location affiliated with the virtual event, for example the original location of the event before it was moved online.

openactive / modelling-opportunity-data