Representing Videos Available Asynchronously

[thill-odi]

Proposer

@thill-odi (ODI)

Use Case

Many providers are making activity videos available for asynchronous viewing or download (contrast #224, which deals with streaming, or 'live', video). In addition, asynchronously-available video is a well-established distribution format for many providers.

Why is this not covered by existing properties?

The existing data model has heretofore dealt only with physical locations, not those available via online technologies.

Please provide a link to example data

See e.g. https://signup.lesmillsondemand.com/eu/?gclid=EAIaIQobChMIyZjZqqqp6AIVArTtCh2SfAvhEAAYASAAEgIozvD_BwE&gclsrc=aw.ds for this general model.

Proposal

Activity videos available for asynchonous playback or download can conveniently be represented using the schema.org VideoObject model.

While all attributes of VideoObject may be used within the OpenActive specification, particularly relevant are:

Technical Attributes

thumbnail
videoFrameSize
videoQuality
bitrate
contentSize
contentUrl
embedUrl
encodingFormat
height
playerType
width

Legal and other restrictions

conditionsOfAccess
copyrightHolder
copyrightYear
expires
regionsAllowed
license
typicalAgeRange

Accessibility

accessMode
accessModeSufficient
accessibilityAPI
accessibilityControl
accessibilityFeature
accessibilityHazard
accessibilitySummary

Metadata

duration
description
name
uploadDate
abstract
audience
creator
dateCreated
dateModified
datePublished
headline
keywords

Commercial

offers
isAccessibleForFree
requiresSubscription,
provider

Example

{
	"@type": "VideoObject",
	"name": "Yoga with Diane",
	"description": "One hour of intensive hatha yoga, followed by a relaxation meditation.",
	"duration": "T1H15M",
	"thumbnail": "dianeh-profile.jpg",
	"contentURL": "http://concentricyoga.ca/videos/bucket/dianeh-hatha.mpeg",
	"datePublished": "2020-03-19",
	"isAccessibleForFree": "True",
	"provider": {
		"@type": "Organization",
		"name": "Concentric Yoga",
		"...": "..."
	},
	"...": "..."
}

[nickevansuk]

Referencing another relevant issue here: #71 (comment)

Noting the other recently created proposals for virtual events relate to 2) Virtual fitness classes available anywhere via streaming, and this one relates to 3) On demand classes available anywhere.

Hence potentially OnDemandEvent is another route to consider here, and also allows us to keep our existing properties defined in the Modelling specification as it subclasses Event?

[thill-odi]

I like the idea of OnDemandEvent for the reason you mentioned.

The limitation of OnDemandEvent is that it doesn't have any playback information associated with it - things like size, resolution, or MIME-type. The user journey would then, I suppose, be to populate the url field with a link to a page that did provide this information.

I think this makes sense for aggregated activity finders: I don't think users would normally expect playback right from the finder itself. Are there other use-cases that need consideration, though?

[tommarley148]

It would be preferable to have playback within the Activity Finder itself from our perspective, we are building this in to the tool we are creating and would assume other use cases would want that as well if possible.

Other fields which would be useful to consider are views, likes, ratings etc which will be constantly changing and important for the end user.

[RoastVeg]

An example of how onDemandEvent might be used in conjunction with some inheritant schema type:

{
	"@type": "OnDemandEvent",
	"eventStatus": "https://schema.org/EventScheduled",
	"workFeatured": {
		"@type": "VideoObject",
		"name": "Yoga with Diane",
		"description": "One hour of intensive hatha yoga, followed by a relaxation meditation.",
		"duration": "T1H15M",
		"thumbnail": "dianeh-profile.jpg",
		"contentURL": "http://concentricyoga.ca/videos/bucket/dianeh-hatha.mpeg",
		"datePublished": "2020-03-19",
		"isAccessibleForFree": "True",
		"provider": {
			"@type": "Organization",
			"name": "Concentric Yoga",
			"...": "..."
		},
		"...": "..."
	}
	"...": "..."
}

[nickevansuk]

Updated proposal

The OnDemandEvent is adopted to represent on-demand fitness content, as an Event without a startDate or eventSchedule.

The workFeatured property is used to represent the actual media associated with the OnDemandEvent (where it is available free of charge), as shown in the example below. This media could be an VideoObject, AudioObject, or a more general MediaObject.

beta:participantSuppliedEquipment (#229) and beta:donationPaymentUrl (#234) should also both be available for use on the OnDemandEvent.

Example

{
  "@type": "OnDemandEvent",
  ...
  "eventStatus": "https://schema.org/EventScheduled",
  ...
  "workFeatured": {
    "@type": "VideoObject",
    "url": "https://www.youtube.com/watch?v=3fbCs0GVjgQ",
    "embedUrl": "https://www.youtube.com/embed/3fbCs0GVjgQ",
    "thumbnail": [
      {
        "@type": "ImageObject",
        "url": "http://example.com/static/image/speedball_thumbnail.jpg"
      }
    ],
    "beta:participantSuppliedEquipment": "https://openactive.io/Required",
    "beta:donationPaymentUrl": "https://www.paypal.com/donate/acme_fit"
  }
}

[nickevansuk]

From further discussions it seems we missed a nuance previously.

On the last W3C call on the subject we agreed that when a virtual event has occurred the recording should later appear as an OnDemandEvent.

However: should such a recording of a previous livestream still exist as part of a ScheduledSession, or SessionSeries? Is it best to separate archive recordings of events that were originally recorded and transmitted live, from a intentionally produced “OnDemandEvent” package like Insanity. Hence should we update the virtual event data to include workedFeatured of the recorded version after the fact? This way you could "catch up" on previous weeks for virtual SessionSeries, and still book into "next week" to participate live.

Another way of achieving the same might be to use EventSeries with OnDemandEvent, and allow the timestamps of the OnDemandEvent to naturally provide the same functionality?

We could in fact offer both of these options in beta, as the EventSeries is still a good way to present a collection of OnDemandEvent such as Insanity, then see whether workedFeatured for past ScheduledSession is adopted in practice for the "recorded live" usecase?