- From: Daniel Stieglitz <dstieglitz@stainlesscode.com>
- Date: Wed, 25 Nov 2015 07:27:06 -0800
- To: Paul Kelly <paul@xmlteam.com>
- Cc: Eleni Mikroyannidi <Eleni.Mikroyannidi@bbc.co.uk>, Richard Wallis <richard.wallis@dataliberate.com>, Tom Grahame <tom.grahame@bbc.co.uk>, Vicki Tardif Holland <vtardif@google.com>, Jonathan Balls <Jonathan.Balls@bbc.co.uk>, "public-sport-schema@w3.org" <public-sport-schema@w3.org>
- Message-ID: <CAJ1p+m3Ue3sV_v_MJaYvmdudVj14N-VV9HJMebx4V7LCRAwjmA@mail.gmail.com>
Ok I think I understand where you're coming from now Paul. SportsEvent does have an eventStatus predicate of type EventStatusType which is an enumeration. If we add an EventInProgress enum and introduce the concept of EventSegment I think it would be a good start to handling many of the aggregate cases for reporting live results. Is it sufficient to omit those results items for anything in the scheduled phase? I have a more general question also: what is the policy for leaving inference to a consumer of the data? For example, it can be inferred that an event with eventStatus==EventInProgress does not have a final result. Do we need different terms for results prior to the outcome being known? On Wed, Nov 25, 2015 at 7:12 AM, Paul Kelly <paul@xmlteam.com> wrote: > Yes, you are right Dan. > > What I’m questioning is whether a sports-event result should have a > different structure, using different terms, than the same event prior to > the outcome being known. Anything we come up with has to work for schedule > and live requirements. > > > > On Nov 25, 2015, at 9:56 AM, Daniel Stieglitz < > dstieglitz@stainlesscode.com> wrote: > > > > Please correct me if I'm wrong but my understanding was, at least for > this first pass on the model, that we *would* fixate on results? > > > > In general I agree we should consider all aspects of the model, but I > thought results was made a priority in order to narrow the scope on our > work for the time being. > > > > Paul does bring up some interesting points with regard to how the state > of the event is modeled while it is in progress, which is something we deal > with exhaustively on a daily basis. The notion of the "last known" results > of an event, as well as recalling the results at arbitrary times is worth > at least a quick think at this stage IMHO. What I like about the *Result > model, e.g.: > > > > Event--->competitor(Person|Team)--->CompetitorResult > > > > we can "double down" on the Result at both the Competitor and Event > level for last known state, as well as on a (future) "segment" based model: > > > > Event--->EventResult--->competitor (e.g. Win, final score) > > Event--->competitor--->CompetitorResult (e.g., score) > > (future) Event--->Event Segment (e.g., inning, period, > over)--->SegmentResult--->competitor... > > > > Maybe that's a bit too normalized? > > > > Dan > > > > On Wed, Nov 25, 2015 at 6:25 AM, Paul Kelly <paul@xmlteam.com> wrote: > > We shouldn’t fixate on results. A sports event is represented before it > starts (as a "fixture" or in a schedule), while it is in progress (live > updates) and after the results are in. Not to mention other states (some of > them specific to sport) such as postponed, suspended, forfeited, delayed > (due to weather), etc. > > > > Would we recommend using different terms for different stages in the > life cycle of an event? > > > > > > > On Nov 25, 2015, at 5:00 AM, Eleni Mikroyannidi < > Eleni.Mikroyannidi@bbc.co.uk> wrote: > > > > > > Hello, > > > > > > Some comments inline: > > > > > > On 25/11/2015 08:55, "Richard Wallis" <richard.wallis@dataliberate.com> > wrote: > > > > > >> From <http://schema.org/Action> > > >> > > >> “An action performed”…”The execution of the action may produce a > result” > > >> > > >> I would suggest that winning the Booker prize was an action that > occurred, or was completed, though it might not have been previously > defined [by the eventual winner] as a potential action. > > > > > > Yes I agree. It's the outcome of the action not a potential outcome. > In the same way, the score can be the outcome of a sports competition. > > > > > > Nevertheless, I think the definition of a SportsResult concept is > needed either if it's used in the Actions or directly in the competition. I > was looking into the Actions modelling, because it already provides a > general result predicate and it also has some modelling in actions around > Win and Loss so it can be reused in a head to head competition. > > > > > > > > > On 24 November 2015 at 14:47, Paul Kelly <paul@xmlteam.com> wrote: > > >> Also, I see below that this means distinguishing between the agent > and the participant? > > > > > > Yes, in actions, the agent is distinguished from the participant. I > think the agent it is the subject of the action. > > > > > > Many thanks, > > > Eleni > > > > > > > > >> > > >> On 24 November 2015 at 14:47, Paul Kelly <paul@xmlteam.com> wrote: > > >>> Are those outcomes really actions, though? A team sets out to win > and acts accordingly but there’s no intention to lose. Somebody writes a > book (to use schema.org’s "*John* wrote a book" example) but the action > wasn’t directly to win the Booker prize. Also, I see below that this means > distinguishing between the agent and the participant? > > >>> > > >>> > > >>> > On Nov 23, 2015, at 12:43 PM, Eleni Mikroyannidi < > Eleni.Mikroyannidi@bbc.co.uk> wrote: > > >>> > > > >>> > I was wondering if we could make use of the Action concept for > representing head to head actions/results. Schema.org already has the > concept of WinAction, TieAction and LoseAction. In this case, a football > WinAction could be modelled as: > > >>> > > > >>> > <!-- Liverpool won a football competition against Crystal Palace. > --> > > >>> > <script type="application/ld+json"> > > >>> > { > > >>> > "@context": "http://schema.org", > > >>> > "@type": "WinAction", > > >>> > "agent": { > > >>> > "@type": "SportsTeam", > > >>> > "name": "Liverpool", > > >>> > "@id": "https://dbpedia.org/resource/Liverpool_F.C." > > >>> > }, > > >>> > "object": { > > >>> > "@type": "SportsEvent", > > >>> > "name": "Barclays Premier League Liverpool v Crystal Palace" > > >>> > }, > > >>> > "result": "2-0", > > >>> > "agentScore": 2, > > >>> > "participantScore": 0, > > >>> > "participant": { > > >>> > "@type": "SportsTeam", > > >>> > "name": "Crystal Palace", > > >>> > "@id": "https://dbpedia.org/resource/Crystal_Palace_F.C." > > >>> > } > > >>> > } > > >>> > </script> > > >>> > > > >>> > The Action concept has the general https://schema.org/result > predicate, which can be used within any Action. A SportsResult could be > defined within that context. > > >>> > > > >>> > Cheers, > > >>> > Eleni > > >>> > > > >>> > On 23/11/2015 10:14, "Tom Grahame" <tom.grahame@bbc.co.uk> wrote: > > >>> > > > >>> >> > > >>> >> For info and not intended to sway the conversation in any > particular direction: > > >>> >> > > >>> >> home/awayCompetitor lifts from the Sport ontology: > > >>> >> http://www.bbc.co.uk/ontologies/sport#terms_homeCompetitor > > >>> >> http://www.bbc.co.uk/ontologies/sport#terms_awayCompetitor > > >>> >> > > >>> >> There’s a gist I did a while ago here: > > >>> >> https://gist.github.com/tfgrahame/8974800 > > >>> >> > > >>> >> Scoring gets hard when scores can be applied variously to events > and/or competitors, we got stuck on this last time. > > >>> >> > > >>> >> Tom > > >>> >> > > >>> >> From: Daniel Stieglitz <dstieglitz@stainlesscode.com> > > >>> >> Date: Friday, 20 November 2015 16:25 > > >>> >> To: Vicki Tardif Holland <vtardif@google.com> > > >>> >> Cc: Paul Kelly <paul@xmlteam.com>, Jonathan Balls < > Jonathan.Balls@bbc.co.uk>, "public-sport-schema@w3.org" < > public-sport-schema@w3.org> > > >>> >> Subject: Re: Scores for head to head events > > >>> >> Resent-From: <public-sport-schema@w3.org> > > >>> >> Resent-Date: Friday, 20 November 2015 16:26 > > >>> >> > > >>> >>> Hi folks: > > >>> >>> > > >>> >>> SportsEvent also supports the SportsEvent-->competitor > relationship, where competitor can be SportsTeam or Person. Oddly enough > this seems to be the way homeTeam and awayTeam are also mapped which seems > confusing (they can be Persons?) > > >>> >>> > > >>> >>> Perhaps homeTeam and awayTeam should be refactored out and > replaced by the competitor relationship, where cardinality is enforced by > subtypes (e.g., if SportsEvent is a FootballGame, competitor max > cardinality is 2 and competitor types are restricted to Team). > > >>> >>> > > >>> >>> For results I think a CompetitorResult object may be required > (or CompetitorScore [subclass?]) that is then applied to the Event object. > > >>> >>> > > >>> >>> Of course the issue of tracking how the CompetitorScore might > change over time is also a consideration. > > >>> >>> > > >>> >>> Dan > > >>> >>> > > >>> >>> On Fri, Nov 20, 2015 at 8:15 AM, Vicki Tardif Holland < > vtardif@google.com> wrote: > > >>> >>>> > > >>> >>>> On Thu, Nov 19, 2015 at 5:20 PM, Paul Kelly <paul@xmlteam.com> > wrote: > > >>> >>>>> Also, how general do we need to be? Are we going to draw a > distinction between team events, head-to-head sports (boxing, fencing) and > race-type events (F1, athletics, swimming)? Or do we want a general > formation for all three of those types of competition (to use the north > american sense of that word :) > > >>> >>>> > > >>> >>>> This is the crux of the issue. To support events with more than > two competitors, we will need more than a simple homeScore/awayScore model. > With the Olympics coming up again, I think we should consider supporting > these events sooner rather than later. > > >>> >>>> > > >>> >>>> - Vicki > > >>> >>>> > > >>> >>>> Vicki Tardif Holland | Ontologist | vtardif@google.com > > >>> >>>> > > >>> >>> > > >>> >> > > >>> >> > > >>> >> ---------------------------- > > >>> >> > > >>> >> http://www.bbc.co.uk > > >>> >> This e-mail (and any attachments) is confidential and may contain > personal views which are not the views of the BBC unless specifically > stated. > > >>> >> If you have received it in error, please delete it from your > system. > > >>> >> Do not use, copy or disclose the information in any way nor act > in reliance on it and notify the sender immediately. > > >>> >> Please note that the BBC monitors e-mails sent or received. > > >>> >> Further communication will signify your consent to this. > > >>> >> --------------------- > > >>> > > >>> > > >> > > > > > >
Received on Wednesday, 25 November 2015 15:27:57 UTC