Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add EventMovedOnline to valid eventStatus values / use affiliatedLocation #227

Open
thill-odi opened this issue Mar 19, 2020 · 13 comments
Open
Assignees
Labels
proposal Proposed changes to the specification virtual events Properties for events held online (e.g. via streaming)

Comments

@thill-odi
Copy link
Contributor

thill-odi commented Mar 19, 2020

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 thill-odi self-assigned this Mar 19, 2020
@thill-odi thill-odi added the proposal Proposed changes to the specification label Mar 19, 2020
@thill-odi
Copy link
Contributor Author

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

@nickevansuk
Copy link
Contributor

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
Copy link
Contributor

nickevansuk commented Mar 20, 2020

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
Copy link

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
Copy link
Contributor

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
Copy link
Contributor Author

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

  1. 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.

  2. 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
Copy link
Contributor

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

@nickevansuk
Copy link
Contributor

nickevansuk commented Mar 26, 2020

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
Copy link
Contributor

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
Copy link

@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:

  1. 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
  2. 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
Copy link
Contributor

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 (#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
Copy link

Great! Thanks @nickevansuk - makes lots of sense!

@openactive-bot
Copy link

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-bot openactive-bot changed the title Add EventMovedOnline to valid eventStatus values Add EventMovedOnline to valid eventStatus values / use affiliatedLocation Mar 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal Proposed changes to the specification virtual events Properties for events held online (e.g. via streaming)
Projects
None yet
Development

No branches or pull requests

5 participants