- From: Justin Boyan <jaboyan@google.com>
- Date: Sat, 5 Oct 2013 07:51:24 -0400
- To: Dan Brickley <danbri@google.com>
- Cc: W3C Web Schemas Task Force <public-vocabs@w3.org>
- Message-ID: <CABJSzUsUtyHdZx4-i55+SHoEu=ebUeYU91fJZRdFD=qcBNLryw@mail.gmail.com>
On Fri, Oct 4, 2013 at 11:28 AM, Dan Brickley <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.) 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. 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. 4. The (previously proposed) occurrenceEvent property is too verbose. Agreed - deleted from proposal. Justin
Received on Saturday, 5 October 2013 11:51:55 UTC