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