RE: Updated proposal for updating schema.org Events spec

Replies to Justin's replies below.

-Ian

From: Justin Boyan [mailto:jaboyan@google.com]
Sent: Saturday, October 5, 2013 4:51 AM
To: Dan Brickley
Cc: W3C Web Schemas Task Force
Subject: Re: Updated proposal for updating schema.org Events spec


On Fri, Oct 4, 2013 at 11:28 AM, Dan Brickley <danbri@google.com<mailto:danbri@google.com>> wrote:
The proposal is in "Google Docs exported to PDF format" for now,
here's a direct link
http://www.w3.org/wiki/images/a/ab/Events-proposalforupdatedschemav3-External.pdf

Thanks, Dan. All feedback welcome!

Ian made a few comments earlier, which I'll briefly respond to here to get the conversation started:

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.

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>

3. In light of eventCategory, should the categorical subtypes of Event be deprecated, so there's only one way of categorizing events? I would favor this approach, but others told me it would be better to merely de-emphasize the existing types.

<ian>In your mind, what is the difference between "deprecating" and "deemphasizing"?

4. The (previously proposed) occurrenceEvent property is too verbose. Agreed - deleted from proposal.

Justin