Prior art

Solves

The hardest parts of calendaring, and it has solved them since 1998: date-times in three flavours (floating, UTC, zoned via VTIMEZONE), recurrence (RRULE, RDATE, EXDATE, RECURRENCE-ID), all-day events, and subscription by URL. Every calendar client on earth reads it.

OTE reuses

The date model, near-literally: ISO 8601 plus an IANA timezone, convertible to all three iCalendar forms. Recurrence semantics follow RRULE rather than a new invention. The "subscribe to a URL" distribution idea is the same idea.

OTE adds

Things VEVENT has no field for: a CFP with its own open/close dates, an explicit online / in-person / hybrid distinction, structured organisers, a data licence, and per-event translations. In iCalendar these end up as prose inside DESCRIPTION, which is exactly the state we are trying to leave.

Where we stand

import-ics and export-ics are published, and the aggregated feed is served as feed.ics. The export is lossy by construction — CFP, attendance mode and structured speakers have nowhere to go — and we would rather say so than pretend otherwise.

RFC 5545

Solves

A widely understood vocabulary for describing an event on a web page, and the one search engines actually read: embed it as JSON-LD and you can get event rich results. It has the best online/hybrid modelling of anything we surveyed (eventAttendanceMode, VirtualLocation), plus eventStatus, performer and offers.

OTE reuses

The data model, close to one-to-one. Attendance mode, status, offers, organiser and location are shaped so that serialising an OTE event to schema.org/Event is a rename, not a redesign. This is our primary mapping target.

OTE adds

A feed. schema.org describes one event inside one HTML page; there is no notion of "all of this community's events" you can subscribe to without scraping. OTE adds the container (one URL, N events, an updatedAt), a small validatable core with real JSON Schemas — schema.org ships a huge and almost entirely optional vocabulary with no validation — plus CFP and a data licence.

Where we stand

import-jsonld is published and extracts Event JSON-LD from real pages. The exporter (OTE → schema.org/Event) is still proposed, not built — see the tools section. Until it exists, "maps 1:1" is a claim backed by the field survey, not by running code.

schema.org/Event

Solves

Marking up an event in the HTML you already publish, with no parallel file to maintain — the page is the data. Around it, IndieWeb has a decade of practice on the questions OTE also cares about: who owns the canonical copy (POSSE — publish on your own site, syndicate elsewhere), RSVPs, and replies via Webmention.

OTE reuses

The principle, not yet the markup. "The organiser is the authoritative source and the platforms are destinations" is POSSE restated for events, and we should say so plainly instead of presenting it as new.

OTE adds

A machine-readable feed decoupled from the page, for consumers that want N events in one fetch rather than a crawl, plus the tech-community fields (CFP, multi-part events, eligibility).

Open question

Should OTE be built much more directly on top of h-event instead of alongside it? Our survey rated h-event "low priority" as an HTML markup option, which is a decision about output formats — it never seriously tested whether the IndieWeb conventions should have shaped the model itself. That is a real gap in our homework, and feedback from people who have shipped h-event tooling would change our answer.

h-event · IndieWeb events · POSSE

Solves

Events that propagate between servers, and the social actions around them — RSVP, announcements, replies. FEP-8a8e is the in-progress convention for using ActivityStreams Event consistently enough that Mobilizon, GatherPress and others can actually interoperate; the Event Federation project (NLnet-funded, active) is working on parent/child events, recurrence, RSVP and discovery.

OTE reuses

Nothing yet, and that is the honest answer. This is the one standard in this section that our original research never covered — it surveyed calendar, web and feed formats, and stopped there.

Different problem

The distribution models genuinely differ: ActivityPub is a push protocol between actors on running servers, while OTE is a static file you can host on GitHub Pages. A community that cannot run a server can publish OTE today. That is complementary, not competing — an OTE ↔ FEP-8a8e adapter would let one published event reach the Fediverse.

Open question

Are we modelling concepts — event identity, organisers, parent/child events, recurrence — in a way that conflicts with FEP-8a8e for no good reason? We would like this reviewed before the model stabilises, not after.

event-federation.eu · NLnet project · SocialHub discussion

Solves

Syndication as a settled problem: one URL, many items, subscribers pull. Readers, bots and newsletters already speak it.

What they don't do

Model an event. There is no start date, no end date, no venue, no timezone — an event is just an <item> with a title and a link. They are a distribution format, not a data model.

Where we stand

export-rss is published: an OTE feed becomes RSS or JSON Feed, one event per item, with the structured data carried alongside and a link back to the full entry.