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