Re: Scores for head to head events

Paul is absolutely correct in saying that event status is key and we should
work on defining an appropriate life cycle for events.

There are a number of nuances when it comes to event status, much like with
defining results. For example, games can be finished ("Completed,") but
official results are tabulated sometimes hours later, which often require a
separate state ("Closed, e.g.). At the most basic level we'd probably need
Scheduled--->In Progress--->Delayed--->Postponed, Cancelled--->Completed.
Plus sport-specific options where applicable. EventStatusType has
additionalType semantics which could be used to achieve this narrowing.

Richard, do you have any insight on the inference question?  If it's an
accepted practice to leave inference to consumers of the data I think it
would solve a number of problems and keep the data payloads lighter.



On Wed, Nov 25, 2015 at 9:17 AM, Jonathan Balls <Jonathan.Balls@bbc.co.uk>
wrote:

> The EventStatus enumeration is interesting. It doesn't have things like
> EventInProgress and EventCompleted. Maybe this is another area we want to
> consider?
>
> I was looking at the previous group's effort in this area. They seem to
> have come up with the idea of measurements. I like the idea. It feels like
> it could cover a much broader range of concepts than "score". I've tried
> working up another example based on that
>
> <script type="application/ld+json">
> {
>   "@context":"http://schema.org",
>   "@type":"SportsEvent",
>   "name": "Barclays Premier League Liverpool v Crystal Palace",
>   "competitor": [
>     {
>       "@type": "SportsTeam",
>       "name": "Liverpool",
>       "alignment": "home",
>       "measurement": {
>         "@type": "Measurement",
>         "measurementUnits": "Goals",
>         "measuredValue": "2",
>       }
>     },
>     {
>       "@type": "SportsTeam",
>       "name": "Crystal Palace",
>       "alignment": "away",
>       "measurement": {
>         "@type": "Measurement",
>         "measurementUnits": "Goals",
>         "measuredValue": "1",
>       }
>     },
>   ]
> }
> </script>
>
> Dan's question about inference is really key to this approach. With a
> eventStatus=InProgress the above would mean something very different to an
> eventStatus=Completed
>
>
> From: Daniel Stieglitz <dstieglitz@stainlesscode.com>
> Date: Wednesday, 25 November 2015 15:27
> 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>, BBC <Jonathan.Balls@bbc.co.uk>,
> "public-sport-schema@w3.org" <public-sport-schema@w3.org>
>
> Subject: Re: Scores for head to head events
>
> 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.
>> > >>> >> ---------------------
>> > >>>
>> > >>>
>> > >>
>> >
>> >
>>
>>
>