Re: Updated proposal for updating schema.org Events spec

I'd rather not ... HappeningStatus looks like Agent or one of those
constructs ...


On Thu, Oct 10, 2013 at 1:20 AM, Dan Brickley <danbri@google.com> wrote:

> On 10 October 2013 00:52, Ian Niles <ianiles@microsoft.com> wrote:
> > 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.
>
> How about we throw a common supertype over both of them, so that any
> ActionStatus or EventStatus will also be an, erm, HappeningStatus ?
>
> Dan
>
> > -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> wrote:
> >
> > Thanks Aaron and Ian for the comments. My replies:
> >
> > On Mon, Oct 7, 2013 at 4:12 PM, Aaron Bradley <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> 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 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
> >
> >
> >
> >
>
>