Re: Updated proposal for updating schema.org Events spec

My only comment is in regard to the eventCategory part of proposal, and to
Justin's question here:

> In light of eventCategory, should the categorical subtypes of Event be
deprecated, so there's only one way of categorizing events? I would favor
this approach, but others told me it would be better to merely de-emphasize
the existing types.

I agree with those "others" that deprecating the existing subtypes is
unnecessary, and I think deprecation could be problematic if this leads to
diminished support for events already encoded using a more specific type.

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").

Yes, I understand that this is in response to way in which the subtypes are
observed as being rarely used in the wild.  But I wonder then whether
real-world adoption is becoming the acid test for more specific subtypes.
There's probably several thousand types of LocalBusiness not covered by
that schema's more specific subtypes, but I've not (yet) seen any argue for
the introduction of localBusinessCategory.

And on the flip side there's no more specific type of
schema.org/Productavailable at all (in the same topical sense as
MusicEvent or AnimalShelter,
like ElectronicsCategory), nor do I think that would be useful.

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.



On Sun, Oct 6, 2013 at 1:29 PM, Martin Hepp <martin.hepp@ebusiness-unibw.org
> wrote:

> Hi Dan, folks:
>
> nice - just keep in your head that if we want to model tickets for events,
> all we need to to is import a few elements from the GoodRelations extension
> for tickets,
>
>     http://www.heppnetz.de/ontologies/tio/ns.html
>
> into schema.org, and we would be all set. No need to start thinking about
> new types for prices of tickets etc. - they are all offers to grant you the
> right to access something, in this case an event. It will be
> straightforward.
>
> Martin
>
> On Oct 4, 2013, at 5:28 PM, Dan Brickley wrote:
>
> > I've just posted an update to
> > http://www.w3.org/wiki/WebSchemas/EventSchemaUpdate which simplifies
> > the most recent proposal, most notably by removing the 2nd mechanism
> > for describing recurrent events.
> >
> > Note that you can still use http://schema.org/superEvent and
> > http://schema.org/subEvent to link events into hierarchies (e.g. an
> > enumerated workshop series, giving specific dates each time), and you
> > can still use ISO notation for repeated events. We have just removed
> > one extra way of trying to handle repetition.
> >
> > The proposal is in "Google Docs exported to PDF format" for now,
> > here's a direct link
> >
> http://www.w3.org/wiki/images/a/ab/Events-proposalforupdatedschemav3-External.pdf
> >
> > I've copied a text version below. Next step is to get it into
> > RDFS/RDFa machine-friendly form.
> >
> > Any questions/comments welcome here, in the Wiki, or direct to Justin
> > Boyan (cc'd) who has been leading this work. Public commentary is
> > preferred :)
> >
> > cheers,
> >
> > Dan
> >
> >
> > -------
> >
> > Proposed enhancements to schema.org/Event
> > version 3, 10/1/2013
> >
> >
> > As the search Events team at Google has worked on features using
> > marked up data, several limitations of the existing spec have emerged.
> > This is a proposal to enhance the schema.org spec to handle the top
> > limitations we’ve seen.
> >
> >
> > v2, May 2013: It has been revised in light of public feedback on an
> > earlier version of the proposal, see
> > http://www.w3.org/wiki/EventSchemaUpdate for links.
> > v3, Oct 2013: Further revisions in response to additional public and
> > internal feedback.
> >
> >
> > Summary of proposed changes
> >
> >
> > Goal
> > Spec modification
> > 1. Support markup for canceled or rescheduled events
> > Add three new properties: eventStatus, previousStartDate, previousEndDate
> > 2. Allow more event sites to mark up event categories
> > Add one new property: eventCategory. De-emphasize existing categorial
> > subtypes of Event.
> > 3. Document how to link to official pages
> > Use the “url” and “sameAs” properties (this is not a modification;
> > these features already exist in schema.org)
> > 4. Model sold-out or nearly sold-out events.
> > Add two new values, “Limited” and “SoldOut”, to the
> > schema.org/ItemAvailability enumeration
> >
> >
> >
> > 1. Canceled/rescheduled events
> >
> >
> > Add three new properties:
> > * eventStatus (Text): this property is only required if the event is
> > canceled or rescheduled. It however can be used for tentatively
> > scheduled events and events that are scheduled with a definite time.
> > The property can take five possible values: canceled, rescheduled,
> > postponed, tentative, and current. Current is optional as it is the
> > default. Notes:
> >   * When an event is listed as canceled the whole event is considered
> > canceled. This means that all the dates for that event are canceled.
> > This is the behavior we observe today on sites today. They will create
> > individual events if there is a canceled instance.
> >   * Although this field superficially resembles the proposed
> > schema.org/ActionStatus, it is used quite differently in practice and
> > should not be conflated.
> > * previousStartDate (Date): this property is used in conjunction with
> > eventStatus for rescheduled or canceled events. This property contains
> > the previously scheduled start date. For rescheduled events, the
> > startDate property should be used for the newly scheduled start date.
> > In the (rare) case of an event that has been postponed and rescheduled
> > multiple times, this field may be repeated.
> > * previousEndDate (Date): this property is used in conjunction with
> > eventStatus for rescheduled or canceled events. This property contains
> > the previously scheduled end date. For rescheduled events, the endDate
> > property should be used for the currently scheduled end date, whereas
> > for canceled events, the endDate property should be left blank.
> >
> >
> > How date fields should be filled in:
> >
> >
> > eventStatus
> > startDate / endDate
> > previousStartDate / previousEndDate
> > Notes
> > "current"
> > yes
> >
> > eventStatus is optional in this case
> > "canceled"
> >
> > yes
> > either field is fine for date info but previousStartDate /
> > previousEndDate is more clear
> > "rescheduled"
> > new
> > old
> >
> > "postponed"
> >
> > yes
> > either field is fine for date info but previous is more clear
> > "tentative"
> > yes
> >
> >
> >
> >
> >
> > Why the change?
> > This helps with normalization of events across sites and prevents
> > systems from showing bad/stale data. This is a particularly nasty
> > problem because even if many sites remove old events, some others on
> > the web do not, so it is algorithmically hard to tell if the old event
> > still exists.
> >
> >
> > 2. Support for event categories as a property
> >
> >
> > Add one new property: eventCategory (Text)
> >
> >
> > The new property would permit sites to specify the event’s category as
> > part of schema.org/Event, as an alternative to using subtypes to
> > indicate the category. This model is more appropriate and simpler, as
> > event sites generally format events using one event template
> > regardless of their category. Furthermore, an event may belong to
> > multiple categories (“theater”, “dance”, “kid-friendly”); this is
> > natural to model using a repeated text property. In practice, the
> > current categorical subtypes of schema.org/Event (BusinessEvent,
> > ChildrensEvent, ComedyEvent, DanceEvent, EducationEvent, Festival,
> > FoodEvent, LiteraryEvent, MusicEvent, SaleEvent, SocialEvent,
> > SportsEvent, TheaterEvent, and VisualArtsEvent) are little used and
> > should be de-emphasized in favor of eventCategory.
> > 3. How to link to official event pages
> >
> >
> > This is not a change to the existing spec, but simply a clarification
> > of how to link to the url of the event’s web page:
> >
> > * Use the “schema.org/sameAs” property to link to the official page of
> > the event, typically on another site.
> > * Use the “schema.org/url” property to link to the event details page
> > on the same site containing the markup.
> >
> >
> > 4. Modeling sold-out or nearly sold-out events
> >
> >
> > There is already a natural place to model an event’s availability
> > status: on the event’s offers, using the availability property of
> > schema.org/Offer. That property has an enumerated range of
> > schema.org/ItemAvailability, which currently provides these possible
> > values: { Discontinued, InStock, InStoreOnly, OnlineOnly, OutOfStock,
> > PreOrder } . We propose adding two new values to that enumeration to
> > better serve the events use case:
> >
> >
> > * SoldOut
> > * Limited
> >
> >
> > Both of these would have natural application to both event ticket and
> > physical product availability.
> >
>
> --------------------------------------------------------
> martin hepp
> e-business & web science research group
> universitaet der bundeswehr muenchen
>
> e-mail:  hepp@ebusiness-unibw.org
> phone:   +49-(0)89-6004-4217
> fax:     +49-(0)89-6004-4620
> www:     http://www.unibw.de/ebusiness/ (group)
>          http://www.heppnetz.de/ (personal)
> skype:   mfhepp
> twitter: mfhepp
>
> Check out GoodRelations for E-Commerce on the Web of Linked Data!
> =================================================================
> * Project Main Page: http://purl.org/goodrelations/
>
>
>
>
>