Event, reservation and time zone: model a Repair Day clearly

The hall is booked, the projector is ordered, and someone has written “Saturday, ten” in a message. That sounds organized until a volunteer asks which Saturday, which hall and whose ten o'clock.

Lantern Repair Day is EVT-REPAIR-DAY, planned for 14 November 2026 from 10:00 to 16:00 in Europe/Dublin. PLACE-HALL identifies its venue. RES-HALL identifies a reservation for that venue. ADDR-HALL describes the example address. Each record answers a different question.

All people, organizations, records and venue details here are invented. Dublin and the Europe/Dublin identifier provide real geographic and time-zone context. This demonstration does not advertise a real public event or venue booking.

Give the event an identity

The event is what people plan to attend. Its name, planned start and end, organizer and venue describe aspects of it. None is a substitute for its identity. If the start changes, the same event can retain a history of revised plans.

Schema.org Event describes events in terms of occurrences at a time and location. That supports the practical distinction here: an event has an identity while schedule and location describe it. This demonstration does not claim its vocabulary is identical to Schema.org or automatically publishes valid event structured data.

The interval 10:00–16:00 is planned. It does not establish that doors opened at 10:00, volunteers arrived or the projector worked. Keep planned, actual and recorded times recognizable. A message announcing a change is evidence of communication, not a second occurrence of Repair Day.

Keep the booking separate

RES-HALL is the reservation associated with EVT-REPAIR-DAY and PLACE-HALL. It supplies booking context, rather than another name for the gathering. An event can need several reservations; changing one booking does not automatically establish that the event was cancelled.

Schema.org Reservation describes reservation information separately from Event and distinguishes actual reservations from offers to reserve. A bookable hall listing therefore supplies different evidence from a confirmation for this particular booking.

Do not silently copy the event's interval into the reservation. A booking might include preparation or cleanup time. This example records RES-HALL from 09:00 to 17:00 on 14 November 2026 in Europe/Dublin, covering the event's 10:00–16:00 plan. The extra hour on each side is explicitly recorded booking time, not an inference from the event start. In a real system, obtain and compare the booking details before planning setup.

A place is more than its address text

PLACE-HALL identifies the place. ADDR-HALL is its address description. Display the fictional venue as “Lantern Hall, 14 Lantern Lane, Dublin, Ireland — fictional venue.” It is not a navigation instruction or an actual postal address.

A place can remain recognizable if entrance instructions change or an address is corrected. Conversely, several rooms or venues can share a building address. An address match alone is not sufficient evidence to merge place records.

The distinction also helps with delivery. SHIP-104 concerns the projector's shipment to PLACE-HALL. The event's venue and shipment's destination refer to the same place without becoming the same process. Check delivery instructions for the shipment's purpose instead of blindly copying attendee directions.

Organize the people without merging their roles

ORG-LANTERN is the organization. UNIT-OPS is its operations organizational unit. TEAM-AV is the audiovisual team supporting Repair Day. PERSON-MAYA is the fictional person coordinating this example.

The team groups people working together. The organizational unit supplies structural context inside Lantern. Those illustrative relationships do not prescribe a universal hierarchy, fixed membership or exclusive responsibility. A team and a unit remain distinct records even when some people participate in both.

CP-OPS is the operations contact point, displayed as ops@lantern.example. It is a way to reach operations, not Maya herself. Another coordinator can handle the mailbox while PERSON-MAYA remains the same person. Recording both prevents a shared address from becoming an accidental identity key.

Use this conceptual property checklist when reading the records:

• EVT-REPAIR-DAY: event name, planned start and end, time zone Europe/Dublin, place PLACE-HALL, organizer ORG-LANTERN and equipment ASSET-P17.
• RES-HALL: reservation reference, place PLACE-HALL, event EVT-REPAIR-DAY, recorded access from 09:00 to 17:00 on the same date in Europe/Dublin.
• PLACE-HALL: place name, address ADDR-HALL, time-zone context and a description distinguishing the venue.
• ADDR-HALL: fictional street, locality Dublin and country Ireland; postal code unspecified.
• UNIT-OPS: organizational unit name, organization and operations responsibility; TEAM-AV: team name, organization, members and contact point.
• CP-OPS: email channel, example address value, operations purpose and associated organization.

These are property meanings for readers, not an executable schema enforcing required values or cardinalities.

A time zone carries rules

The time zone Europe/Dublin gives the local schedule its rule context. IANA's Time Zone Database maintains location-based histories and rules for offsets and daylight-saving changes. Those rules can change, so a zone identifier expresses more than a permanent difference from UTC.

Do not replace Europe/Dublin with an unlabeled zero or a fixed offset and assume the meaning survives every date. Around clock changes, some local times repeat or do not exist. An application needs a resolution policy and sufficient information to identify the intended instant. This daytime event is not a worked ambiguous-time case; it simply preserves the zone needed to interpret its plan.

Does changing the date create a new event?

Not necessarily. Retain EVT-REPAIR-DAY when it still represents the same planned gathering, recording revisions. A recurring series may need distinct occurrence identities. This demonstration contains one occurrence.

Is a booked hall enough to prove readiness?

It establishes only the booking information supported by its evidence. Access, contacts and equipment readiness need their own checks. The maintenance demonstration follows that final thread through ASSET-P17.

Explore the connected records

Download all three connected example journeys, or inspect the versioned source and its validation checks. The JSON is an illustrative set of records, not an interchange standard or a complete application schema.