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
>
>
>
>

Received on Thursday, 10 October 2013 08:21:16 UTC