W3C home > Mailing lists > Public > public-vocabs@w3.org > October 2013

Re: Updated proposal for updating schema.org Events spec

From: Martin Hepp <martin.hepp@ebusiness-unibw.org>
Date: Sun, 6 Oct 2013 22:29:35 +0200
Cc: W3C Web Schemas Task Force <public-vocabs@w3.org>, Justin Boyan <jaboyan@google.com>
Message-Id: <2F910017-7298-4A65-83C8-971E1343BA2F@ebusiness-unibw.org>
To: Dan Brickley <danbri@google.com>
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,


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.


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/
Received on Sunday, 6 October 2013 20:30:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:32 UTC