RE: Updated proposal for updating schema.org Events spec

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

Received on Thursday, 10 October 2013 16:36:19 UTC