W3C home > Mailing lists > Public > public-vocabs@w3.org > July 2012

RE: Last Call for Comments ... Re: proposal for updates to http://schema.org/Event

From: Michael Steidl \(IPTC\) <mdirector@iptc.org>
Date: Tue, 10 Jul 2012 18:47:53 +0200
To: "'Dan Brickley'" <danbri@danbri.org>
Cc: <public-vocabs@w3.org>
Message-ID: <015a01cd5ebb$bffe6cf0$3ffb46d0$@iptc.org>
Hi Dan
See below some IPTC comments on your thoughts.

What are the next steps in updating the Events class?

Michael

> -----Original Message-----
> From: Dan Brickley [mailto:danbri@danbri.org]
> Sent: Monday, May 14, 2012 7:22 PM
> To: Michael Steidl (IPTC)
> Cc: public-vocabs@w3.org
> Subject: Re: Last Call for Comments ... Re: proposal for updates to
> http://schema.org/Event
> 
>> On 2 May 2012 19:51, Michael Steidl (IPTC) <mdirector@iptc.org> wrote:
......
> > 1.1) on eventStatus: we support adding it. IPTC has already a
> > controlled vocabulary for that purpose [4] and we would be happy to
> > add the two proposed terms to it.
> 
> http://cv.iptc.org/newscodes/eventoccurstatus/ looks handy, and thanks for
> the offer of additions - that could make sense.
> 
> Let's look at this in the light of the 'external enumerations'
> http://www.w3.org/wiki/WebSchemas/ExternalEnumerations discussion last
> week, also re 'genre' codes, and check how some worked examples work.

All the intentions of the External Enumerations page sound very familiar to us. 
There is only one concern: it should be a goal - also for schema.org and such a guideline for external enumerations - to use language agnostic URIs. URIs like http://en.wikipedia.org/wiki/United_States or http://www.fao.org/countryprofiles/index.asp?lang=en&iso3=USA provide details about the entity only in a specific language, to get the same information in e.g. French or Spanish a different URI is required.

We appreciate to see that the WikiData project is aware of that and has defined that their URIs should not be based on any language [http://meta.wikimedia.org/wiki/Wikidata/Notes/URI_scheme#Issues_for_consideration]. And as http header may hold accepted languages there are technical means to select a language for the details of an entity.

> > 1.2) on eventCategory: IPTC supports adding this property.
> >
> > Further EventsML has a more generic property named “subject” to which
> > one may apply a wide range of categories and therefore we propose to
> > consider to adopt an additional “about” property as it already exists
> > for the CreativeWork class with the same semantics.  (Example: Why not
> > to apply a horse category to the Ascot event? Will help finding it.)
> 
> Sounds useful. We also btw have schema:keywords for more classically
> textual description of topics.
> 
> At the moment 'about'  (and 'keywords') is only for CreativeWork, should we
> attach it to Event also?

The IPTC would highly appreciate that 'about' is added to the Event class. By the experience from many news providers there are many - but not all - events that are about a topic or a person or location or ...

> > 1.3) on startDate and endDate: the EventsML-G2 structure for recurring
> > events follows the iCalendar design -
> > http://tools.ietf.org/html/rfc5545 – which is quite sophisticated, we
> > know. However allowing more than one startDate and endDate might not
> > work either. There is nothing which explicitly pairs a startDate with
> > an endDate, using only the sequence of properties for pairing is too open
> to simple syntax errors.
> This seems to be the central remaining problem: the start/end pairing isn't
> enough, since sequence is meaningless is many environments.

We propose this: use the Time Interval annotation of ISO 8601 - see http://en.wikipedia.org/wiki/ISO_8601#Time_intervals
This appears to be extremely flexible and fits into a single string = a single class property, could be named e.g. startAndEndDate or startEndDate.

> > 1.4) In addition we propose from the set of the core event properties
> > of
> > EventsML-G2 to add these two properties:
> > 1.4.1) organizer: Person or Organization. The party organizing the event.
> > 1.4.2) registration: Text. The how and when to register for the event.
> > Could also include information about the costs and more.
> >
> > IPTC adds: a complementary class for e.g. ordering tickets could be
> > added too.
> 
> I'll add these proposals to the Wiki...

May I ask where I can find this addition? 

> 
> Thanks for all this, and for the Sports analysis below (which I'll look at
> separately).

Did you post your Sports analysis?

> 
> One more ingredient re events that we'll also need to look at is
> http://historical-data.org  ... some interesting work around family history,
> genealogy and historical data. I hope we'll see a full proposal / submission
> from them in the v near future.
> 
> cheers,
> Dan
> 
> > 2) Comments on the ESPN/Google sports schema proposal
> > 2.1) First the IPTC comments on the proposal as it is [4]
> > 2.1.1) on the hierarchy and the properties: a couple of properties of
> > the proposed Thing > Event > SportsEvent > SportsMatch class are not
> > specific to a sports match and IPTC proposes to add them to super classes:
> > - association (if a property organizer is added to event there is no
> > need for association), stadium (the Event class already has a location
> > – so why a stadium at all) to the SportsEvent class
> > - broadcast, ticketsLink, liveStreamLink, timeStatus to the Event
> > class
> >
> > 2.1.2) these other proposed properties of SportsMatch are explicitly
> > supported by IPTC:
> > series
> > statusText -- eg. bottom of 6th inning
> > competitors
> > previewLink
> > liveUpdateLink
> > recapLink
> > boxScoreLink
> > periods
> >
> > 2.1.3) The IPTC proposed to add these properties from SportsML:
> > - status: enumeration, -- pre-event, mid-event, post-event, forfeited, etc.
> > - official: Person. Ensures that the sports match is played according
> > to its rules.
> > - award: Thing. A medal, ribbon, placement, or other type of award for
> > the winner of the match.
> >
> > 2.2) The IPTC proposes a modification of the basic design of the
> > ESPN/Google
> > draft:
> > The IPTC proposes to:
> > - enrich the SportsEvent class with the properties proposed for the
> > SportsMatch (see 2.1.2)
> > - not to define a SportsMatch class as subclass of SportsEvent to
> > qualify an event as sports match …
> > - … but to use the subEvent property of a SportsEvent instance to
> > refer to an event which is a match in a tournament.
> > Reason: the IPTC sees only minor differences in the definition of a
> > class SportsEvent and a class SportsMatch, having both raises ambiguity
> issues.
> >
> > [1] http://www.iptc.org/site/News_Exchange_Formats/EventsML-G2/
> > [2] http://www.iptc.org/site/News_Exchange_Formats/SportsML-G2/
> > [3]
> > http://www.w3.org/wiki/images/d/dc/Events-
> proposalforupdatedschema.pdf
> > [4] http://www.w3.org/wiki/WebSchemas/Sports
> > [5] http://cv.iptc.org/newscodes/eventoccurstatus/
> > Thanks for considering our comments,
> > and sorry for being a bit late.
> >
> > Michael
> >
> > Michael Steidl
> > Managing Director of the IPTC [mdirector@iptc.org]
> > International Press Telecommunications Council
> > Web: www.iptc.org - on Twitter @IPTC
> > Business office address:
> > 20 Garrick Street, London WC2E 9BT, United Kingdom
> > Registered in England, company no 101096
Received on Tuesday, 10 July 2012 16:48:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 10 July 2012 16:48:30 GMT