RE: Updated proposal for updating schema.org Events spec

I'm OK with the first two bullets but not the third.  The same sorts of scheduling changes can be made with respect to both events and actions.  I can cancel or postpone eating my lunch, a dip in the pool, a wedding, a pedicure, etc.

-Ian

From: Justin Boyan [mailto:jaboyan@google.com]
Sent: Wednesday, October 9, 2013 4:41 PM
To: W3C Web Schemas Task Force
Subject: Re: Updated proposal for updating schema.org Events spec

Can folks live with the proposal with the following changes?

  *   remove eventCategory; it seems controversial and we can wait to see where the EnumConcept conversation lands.
  *   remove previousEndDate, to avoid schema complexity around repeated pairs of previousStartDate/previousEndDate.
  *   keep EventStatus and ActionStatus separate, so they can meet their separate needs separately.
Thanks,
Justin

On Tue, Oct 8, 2013 at 4:54 PM, Justin Boyan <jaboyan@google.com<mailto:jaboyan@google.com>> wrote:
Thanks Aaron and Ian for the comments. My replies:

On Mon, Oct 7, 2013 at 4:12 PM, Aaron Bradley <aaranged@gmail.com<mailto:aaranged@gmail.com>> wrote:

While I don't find it objectionable per se, I find the addition of eventCategory a curious approach, and the notion of adding one thing to "de-emphasize" another very odd indeed.  As I think of use cases for this schema, this approach - by dint of obviously moving from something structured to something less structured - will result in lower-confidence results for precise queries (e.g. "concerts in las vegas between nov. 1 and nov. 10")
....
This all bleeds somewhat into the concurrent SKOS discussion, IMO.  Would eventCategoy still be useful if there was a more general mechanism for denoting topicality?  I don't think so.

The current event subtypes don't support the notion of an event being in multiple categories. So I think it's important to make category a property. There isn't a clean way to make eventCategory use the existing Event subtypes as an enumerated range... and having a new set of enumerated types alongside the existing subtypes would be really confusing. That's why I went with a simple Text range for the new property. If anyone has a better alternative, I would love to hear it.


On Mon, Oct 7, 2013 at 5:19 PM, Ian Niles <ianiles@microsoft.com<mailto:ianiles@microsoft.com>> wrote:

1. Should eventStatus be merged with the proposed actionStatus enum? No, I don't think so - although they are superficially similar, the meaning is quite different since the person conceptually responsible for the status is an event organizer on the one hand, and an end user on the other. We're really trying to model the kind of info that would appear on, say, a Ticketmaster concert page. (Potentially the value of eventStatus should be an enum rather than text, though.)

<ian> I'm afraid I don't follow this.  First, "actionStatus" and "eventStatus" are not only similar, they're almost identical, and clearly we want to simplify the representation whenever possible.  Second, I have no idea what "conceptually responsible" means here, but presumably action/event statuses in Schema.org will be entered in the same way as all of the other elements of the schema, viz. by end users, by programs, by web masters, etc.
Let me try to convince you. schema.org/Event<http://schema.org/Event> is used by tens of thousands of websites (newspapers, venues, bands, etc.) to promote gatherings in place and time that people can come out to attend. The eventStatus field will be used to semantically annotate when the promoter has cancelled or postponed the event. By contrast, Actions are "verbs", describing activities from the point of view of the end user -- actions like playing a song, buying a shirt, sharing a link, or attending an event -- all very different from promoting an event. The actionStatus semantically refers to when the user will perform the action; the eventStatus semantically refers to changes an organizer has made to the scheduling of an event. (Indeed, several of the eventStatus values, such as "postponed" and "rescheduled", don't make sense for actionStatus.) Merging these two types is a false economy with little practical benefit.



2. Should previousStartDate and previousEndDate be modeled differently, because there's a pairing problem if an event is rescheduled multiple times? I don't think that case is common enough to warrant a more complex model. Most often there is only a startDate, which makes it unproblematic to repeat previousStartDate.



<ian>I don't follow this either.  There are many cases of events being postponed more than once. </ian>
I don't think it's worth the modeling complexity to capture a whole history of previous start/end date pairs for a multiply rescheduled event. With markup, it's really important to keep the model as simple and flat as possible. How about this alternative: we remove previousEndDate from the proposal, and include only previousStartDate (which of course can be repeated without ambiguity). That will cover the overwhelming majority of cases of postponed events, including multiply postponed events, and satisfy the main use case for the field, which is to match up the newly rescheduled event with its previous version so the consuming site doesn't create an incorrect dupe event.

Thanks,
Justin