Re: Updated proposal for updating schema.org Events spec

+guha

I think Guha mentioned earlier in one of the meetings that he would rather
have status enums that are specific to their types (e.g. ActionStatus and
EventStatus) rather than broad/generic (e.g. Status).

I don't feel strongly either way. If there is an enum that can be created
that expresses well the status of an action, an event (or any-Thing else
for what is worth) I'd be open to looking into it.

My intuition, though, is that we should start as private/specific as
possible and move organically towards something more generic over time.


On Thu, Oct 10, 2013 at 9:35 AM, Ian Niles <ianiles@microsoft.com> wrote:

> I’m not sure the solution to the problem of duplicative properties is to
> add yet another property :-).
>
> -Ian
>
> -----Original Message-----
> From: Dan Brickley [mailto:danbri@google.com]
> Sent: Thursday, October 10, 2013 1:21 AM
> To: Ian Niles
> Cc: Justin Boyan; W3C Web Schemas Task Force
> Subject: Re: Updated proposal for updating schema.org Events spec
>
> 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
> >
> >
> >
> >
>