What is an "Event", really? We need community stories and participation in understanding what constitutes events, schedules, etc. in HSDS

Data Management
,
1

Hi all,
@skyleryoung and I had a really good chat about our proposal to add support for Events in future versions of HSDS, and one of the outcomes was that we really need good community participation in adressing the core issue of What actually is an Event?

This arises from the fact that Schedules, Events, and Services are all similar but distinct, and yet interralated concepts.

We really need to go back to brass tacks and understand what problems people are trying to solve, what you’re trying to model, and what the reality of service provision is with regards to their business hours, schedules, and events.

Please write in any thoughts you have below, and consider getting in touch with your partners/clients to help bring some interesting real life situations to light.

1 Like
2

It seems like there are more than a few answers depending in the audience.

We are like a local wing of Sport England on the outskirts of this discussion (via OpanActive) and have the same challenge with ‘activities’.

A city fun run day is:

  • Particitation event
  • Spectator event
  • Volunteering event
  • Sponsorship opportunity event
  • Trade opportunity event

And we are still drawing the line between physical activities and cultural or creative activities.

Likewise our events calendar has

  • Conferences
  • Training
  • Spectator events

Several tags may be required to show the same entity to different audiences?

3

One of the exercises @mrshll and I went through that was helpful in ambiguating the distinction between hours of operation and events was to consider a spectrum of use cases for hours of operation.

For example:

  1. MON - FRI, 8:00AM - 5:00PM
  2. MON - THU, 8:00AM - 5:00PM; FRI 1:00PM - 4:00PM
  3. MON - THU, 8:00AM - 5:00PM; FRI 1:00PM - 4:00PM; JAN - AUG
  4. FRI 1:00PM - 4:00PM; third Friday of each month
  5. FRI 1:00PM - 4:00PM; third Friday of each month; JAN - AUG
  6. FRI, JAN 17, 1:00PM - 4:00PM

Any of these could be used to describe the time component of a “service”. Somewhere around scenarios 4 and 5 this could also describe what most people would imagine as the time component for an “event” too.

It made us think that we can’t describe the concept of “hours” vs “event” purely by the data structure, at least not in the abstract. We might say that for the purposes of HSDS “hours” can and should be described using a common seven-line format for daily business hours with extra notes, and that if it’s more complicated or specific than that (again, right around scenario 4 or 5) then it’s technical and “event”, for scheduling purposes. Before we start trying to enforce that kind of distinction, I think it’s critical to get some higher level community feedback on:

  1. What are hours of operation?
  2. What’s an event?
  3. What’s the difference between them anyway?
  4. How do they relate to services?
4

I’m creating a separate post so we can thread comments if we so choose.

Lest we lose track of why any of this matters, we have a technical problem in the HSDS schedule table, specifically around the byday field. I’ve seen this schedule:

  1. MON - THU, 8:00AM - 5:00PM; FRI 1:00PM - 4:00PM

… described two different ways:

  1. Two records where byday has a value of mo,tu,we,th in one and fr in the other, or
  2. Seven records, where each has a byday value one day of the week.

There may be other ways too. The spec require a particular way, which makes this the most difficult part of the spec to parse consistently, which I presume is one of the primary goals of the standard. When I as a user receive resource data in HSDS, I know ahead of time that I have no idea how the schedule table has been implemented, and how I will need to writer a parser for it.

It’s also been the most confusing part of HSDS, bar none, for users that I’ve seen trying to adopt the spec ranging from state-wide 211’s to small non-profits.

There could be several solutions ranging from interim to permanent, including:

  1. Write official guidelines or reference material the clarifies how the schedule table is intended to be implemented.
  2. Create explicit tables for the two different types that are more self-documenting.

I’ll personally have a more technical post on possible schemas forth coming.

1 Like
5

At the Standing Technical meeting we had yesterday (11 September 2024) we discussed, but did not conclude, whether it would be better to separate:

  • simple day-by-day (Google style) opening hours for each day of the week AND
  • use of the current “schedule” entity for what we are calling events

We’d appreciate feedback from users on this.

I also mentioned that version 3.0 adds to the schedule entity a schedule_link entity which is intended to go to somewhere that provides specific instances of an event. That link may, for instance, use the OpenActive events and booking data and optionally their booking system. The thinking was that HSDS (Open Referral) stops at a schedule of events (e.g. there’s a class every Thursday at a given time and location) and the schedule_link page/data describes specific events (e.g. next Thursday’s class is run by Kim and can be booked here).

6

I’ve been chewing on these questions as well in relation to an event calendar project meant to complement our services directory. Thinking conceptually and at a basic level, an event occurs whereas a service reoccurs. Taking Skyler’s 1-6 examples, example 5 could be a church’s free meals service, whereas example 6 is a spaghetti night event. Events are more granular than services, even if you can sometimes break down services into discrete events (free Friday meals–> spaghetti night, burger night, pizza night). If you want to express those granular details, you have an event, if you want to express reoccurrence you have a program.

I don’t know how exactly to map this, but when I try to express that granularity, the best option in my mind is a discrete date. Inherent to an event is a date (or date range), whereas a service may occur on certain days but the date of occurrence is ancillary.