W3C home > Mailing lists > Public > public-vocabs@w3.org > October 2013

Re: Updated proposal for updating schema.org Events spec

From: Justin Boyan <jaboyan@google.com>
Date: Sat, 5 Oct 2013 07:51:24 -0400
Message-ID: <CABJSzUsUtyHdZx4-i55+SHoEu=ebUeYU91fJZRdFD=qcBNLryw@mail.gmail.com>
To: Dan Brickley <danbri@google.com>
Cc: W3C Web Schemas Task Force <public-vocabs@w3.org>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:32 UTC