Re: Scores for head to head events

Eleni,

I agree with you about modelling and inference, which is up to the consumer.

Taking a look at what Jonathan proposed I decided to test it a little with
an extreme case - cricket.  Being English and having a couple of hours to
fill at an airport gate.  If what is proposed can handle cricket scores, it
can handle most anything!

The examples previously handle the
Schedules/Cancelled/Postponed/Rescheduled cases well.

See from below, I think there is justification for EventInProgress,
EventDelayed, and in addition EventPaused.

~Richard.

Example 1.  Football at half-time:
<script type="application/ld+json">
{
  "@context":"http://schema.org",
  "@type":"SportsEvent",
  “name": "Barclays Premier League Liverpool v Crystal Palace",
  “eventStatus”:{
      “@type”: “EventPaused”,
      “description”: “Halftime break”
   },
  "competitor": [
    {
      "@type": "SportsTeam",
      "name": "Liverpool",
      "alignment": "home",
      "measurement": {
        "@type": "Measurement",
        "measurementUnits": "Goals",
        “measuredValue": "0"
      }
    },
    {
      "@type": "SportsTeam",
      "name": "Crystal Palace",
      "alignment": "away",
      "measurement": {
        "@type": "Measurement",
        "measurementUnits": "Goals",
        “measuredValue": "0"
      }
    },
  ]
}
</script>
Example 2. Cricket - in progress (day2)
<script type="application/ld+json">
{
  "@context":"http://schema.org",
  "@type":"SportsEvent",
  “name”: “England Australia Ashes Test“,
  “eventStatus”:{
      “@type”: “EventInProgress”,
      “description”: “Day 2 - Morning”
   },
  "competitor": [
    {
      "@type": "SportsTeam",
      “name": "England",
      "alignment": "home",
      “measurement": [
           {
              “@type": "Measurement",
              “name”: “First innings”,
              “measurementUnits": "Runs",
              “measuredValue”: "152"
          },
           {
              "@type": "Measurement",
              “name”: “First innings”,
              “measurementUnits”: "Wickets",
              “measuredValue”: “3"
          },
              "@type": "Measurement",
              “name”: “First innings”,
              “measurementUnits”: “Innings",
              “measuredValue”: “1”
          }
       ]
    },
    {
      "@type": "SportsTeam",
      “name": "Australia",
      "alignment": "away",
      “measurement": {
         “@type": "Measurement",
         “name”: “First innings total”,
         “measurementUnits": "Runs",
         “measuredValue”: “210"
       }
    }
  ]
}
</script>

Example 3. Cricket - paused (day 4)
<script type="application/ld+json">
{
  "@context":"http://schema.org",
  "@type":"SportsEvent",
  “name”: “England Australia Ashes Test“,
  “eventStatus”:{
      “@type”: “EventPaused”,
      “description”: “Day 4 - Rain stopped play”
   },
  "competitor": [
    {
      "@type": "SportsTeam",
      “name": "England",
      "alignment": "home",
      “measurement": [
           {
              "@type": "Measurement",
              “name”: “First innings total”,
              “measurementUnits": "Runs",
              “measuredValue”: “457"
          },
          {
              "@type": "Measurement",
              “name”: “Second innings”,
              “measurementUnits": "Runs",
              “measuredValue”: “87”
          },
           {
              "@type": "Measurement",
              “name”: “Second innings”,
              “measurementUnits”: "Wickets",
              “measuredValue”: “5”
          },
              "@type": "Measurement",
              “measurementUnits”: “Innings",
              “measuredValue”: “2”
          }
       ]
    },
    {
      "@type": "SportsTeam",
      “name": "Australia",
      "alignment": "away",
      “measurement": [
           {
              “@type": "Measurement",
              “name”: “First innings total”,
              “measurementUnits": "Runs",
              “measuredValue”: “210"
          },
           {
              “@type": "Measurement",
              “name”: “Second innings total”,
              “measurementUnits": "Runs",
              “measuredValue”: “602”
          },
       ]
    }
  ]
}
</script>


Richard Wallis
Founder, Data Liberate
http://dataliberate.com
Linkedin: http://www.linkedin.com/in/richardwallis
Twitter: @rjw

On 25 November 2015 at 17:41, Eleni Mikroyannidi <
Eleni.Mikroyannidi@bbc.co.uk> wrote:

> I like the modelling around measurements; it is quite general so it can
> fit for multiple purposes.
>
> The status of an event can also be inferred from the start and endDate of
> the event; e.g. If a competition has a startDate and no endDate then it's
> probably in progress or it hasn't happened yet….
>
> I think stating these things explicitly rather than inferring them  its
> more to the general approach of modelling in schema.org. This can be
> modelled by extending the EventStatusType: At the moment it has the
> following enumeration:
>
>    - EventCancelled
>    - EventPostponed
>    - EventRescheduled
>    - EventScheduled
>
> So it's missing EventInProgress status and EventDelayed.
>
> On 25/11/2015 17:35, "Daniel Stieglitz" <dstieglitz@stainlesscode.com>
> wrote:
>
> 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.
>>> > >>> >> ---------------------
>>> > >>>
>>> > >>>
>>> > >>
>>> >
>>> >
>>>
>>>
>>
>

Received on Wednesday, 25 November 2015 19:42:36 UTC