Re: Updated proposal for updating schema.org Events spec

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