Proposal: <podcast:event> tag for adding recurring or upcoming events

[theDanielJLewis]

With the hopes that #396 will be renamed to <podcast:webhook>, I'd like to propose an event/events tag for podcasts to list recurring or upcoming events. For example:

• Weekly live-streams
• Weekly tweetchats
• Ask Me Anythings
• Meetups
• Speaking events
• Roadtrip schedule
• Planned hiatus
• Conferences (attending, hosting, or presenting)
• Giveaways
• Monthly participation

Such events would most likely not be tied to individual items, except for a live item. So they should probably be channel-level.

The function of the tag would be for a podcast app, website, or automation to display upcoming events that an audience member could participate in and add to their own calendars (Google, Outlook, Apple, etc.).

The tag would need to support multiple instances for multiple events, simply recurring options, whole-day and time-specific dates, a title, maybe a description, a location, and a link to more information or GUID to reference a live item in the feed. It would look similar to the live-item tag, but would display as information only (maybe on a table) and not trigger any live player. The app could then offer to add any event to the user's calendar when tapping on the event.

Here are some examples of how the code could work:

<!-- A yearly all-day event -->
<podcast:event start="2022-09-30" repeatsEvery="year">
  <title>International Podcast Day</title>
  <description>Celebrate podcasts and podcasting with us all day!</description>
  <link>https://internationalpodcastday.com</url>
</podcast:event>

<!-- A weekly event that references the live-item tag, has a start time but no anticipated end time -->
<podcast:event start="2022-05-03T18:00:00Z" repeatsEvery="week">
  <title>Live-stream</title>
  <link>https://myawesomepodcast.com/live</url>
  <guid>LIVE ITEM GUID HERE</guid>
</podcast:event>

<!-- An in-person event with a location and start and end times -->
<podcast:event start="2022-11-15T23:00:00Z" end="2022-11-16T03:00:00Z">
  <title>Austin meetup</title>
  <description>Hang out with us and other listeners! No registration required, just show up!</description>
  <podcast:location geo="geo:30.2672,97.7431" osm="R113314">Austin, TX</podcast:location>
</podcast:event>
<podcast:event start="18:00:00Z" end="20:00:00Z" repeatsEvery="third,saturday">
  <title>Chicago meetup</title>
  <description>Join our monthly listener meetup</description>
  <podcast:location geo="geo:30.2672,97.7431" osm="R113314">Chick-Fil-A, 123 Street, Chicago, IL 12345</podcast:location>
</podcast:event>

<!-- An "FYI" scheduled event -->
<podcast:event start="2022-05-30" end="2022-09-05">
  <title>Hiatus</title>
  <description>We're taking a summer break.</description>
</podcast:event>

<!-- A couple of important events for the podcast and audience -->
<podcast:event start="2022-09-15" >
  <title>The Simpsons returns</title>
</podcast:event>
<podcast:event start="2022-06-01" repeatsEvery="year">
  <title>Our podcast anniversary!</title>
</podcast:event>
<podcast:event repeatsEvery="Friday">
  <title>Episode feedback deadline</title>
</podcast:event>

I've debated whether this should merely be an extension of the live-item tag, but I think it's best to be separate because events might be informational and have no live activity with them, or they might be a "live" event that happens offline.

[theDanielJLewis]

This could also work for podcasters running sales or promotions. Like 30% off T-shirts for the week, or a double-bonus on donations (like No Agenda recently had).

[theDanielJLewis]

A type attribute might be good, but I'm not sure what actual additional value it would provide.

[coldacid]

Rather than re-inventing calendaring in the podcast namespace, I think it'd be much more reasonable to be able to just reference a calendar URL.

<podcast:link rel="calendar" href="https://mypodcast.com/irl-events.ics" type="text/calendar"/>

Sadly the RSS standard element does not support the rel concept so useful in HTML or ontology schema links like in RDF, so we'd still need to create a new element for this purpose. Introducing the semantics of HTML into the namespace would also allow us to support further resource links at the channel (and perhaps also item!) level without having to add more tags.

[coldacid]

Actually, <atom:link> gives exactly what I'm going for (with the exception that the rel attribute defaults to "alternate" when not explicitly set).