Re: Updated proposal for updating schema.org Events spec

I also haven't heard a response wrt Justin's comment about the difference
in agency (organizer vs. user).


On Thu, Oct 10, 2013 at 9:43 AM, Sam Goto <goto@google.com> wrote:

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