Updated proposal for updating schema.org Events spec

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.

Received on Friday, 4 October 2013 15:29:23 UTC