Season-element structure

[trondhuso]

This has been discussed during the 3.0 work. I have a need to mark up definition of seasons coming from either national federations or international federations. As requested, here is a markup which we can discuss in the next conference call.

<season>
      <!-- 
         start-date-time: Start date of season
         end-date-time: End date of season
         key: the id/key of the season. Can of course also use Id
         status: the status the season have. Could be a cv - active, ended, inactive
         statuskey: The status id really
         season-source: Who is the source for these definition
         season-source-id: The id of the organization who is the source of the definitions.
         season-source-short: The short definition of the organisation behind the definitions.
         ended -->
      <season-metadata start-date-time="1999-09-01T00:00:00"
                       end-date-time="2000-05-31T00:00:00"
                       key="nhf:27"
                       status="Avsluttet" 
                       statuskey="statuskey:3"
                       season-source="Norwegian Handball Federation" season-source-id="372" season-source-short="nhf">
         <!-- name: A descriptive name of the season -->
         <name xml:lang="nb-NO">Håndballsesongen 1999/2000</name>
      </season-metadata>
   </season>

[jolla56]

In our (TT) markup we have one id for the season and one label for the season. In SportsML we have season-key in the event metadata. That is a qcode and could be the same as our id like season-key="ttsid:4325". So maybe we should add a season-label so you could have season-label="Håndballsesongen 1999/2000". But that could be useful under tournament too. We have a group of attributes called coverage-attributes. Maybe we should add these season-things there.

[jolla56]

@trondhuso We talked about it during the meeting Feb 21th and the suggestion is to use sports-content-codes with the aproriate attribute values. If that does not work could you come back with a suggestion on how to solve this with some added attributes? We like to avoid new elements if possible.

[trondhuso]

scc is a kinda OK solution, but let's look at how this will be using scc:

Sports Content Codes sample:

<sports-content-codes>
    <sports-content-code code-type="sptype:season" code-name="Håndballsesongen 1999/2000" code-key="nhf:27" />
    <sports-content-code code-type="seasonstatus:ended" code-name="Avsluttet" code-key="statuskey:3" />
    <sports-content-code code-type="sptype:seasonStartDate" code-name="1999-09-01T00:00:00+01:00" />
    <sports-content-code code-type="sptype:seasonEndDate" code-name="2000-09-01T00:00:00+01:00" />
</sports-content-codes>

Season Sample

<season>
  <!-- 
     start-date-time: Start date of season
     end-date-time: End date of season
     key: the id/key of the season. Can of course also use Id
     status: the status the season have. Could be a cv - active, ended, inactive
     statuskey: The status id really
     season-source: Who is the source for these definition
     season-source-id: The id of the organization who is the source of the definitions.
     season-source-short: The short definition of the organisation behind the definitions.
     ended -->
  <season-metadata start-date-time="1999-09-01T00:00:00"
                   end-date-time="2000-05-31T00:00:00"
                   key="nhf:27"
                   status="Avsluttet" 
                   statuskey="statuskey:3"
                   season-source="Norwegian Handball Federation" season-source-id="372" season-source-short="nhf">
     <!-- name: A descriptive name of the season -->
     <name xml:lang="nb-NO">Håndballsesongen 1999/2000</name>
  </season-metadata>

Question: Which one is more descriptive? Let's say we also decide to make it possible to create or return snippets of SportsML, then returning a season-structure would be a sports-content-code structure.

So I am looking at this mostly from an API-design point of view, rather than as part of a larger structure. But I can also see season being a "root"-node containing tournament, sports-event or similar in order to markup and define sports data connected to the defined season.

[pauljkelly]

I don't think we should have another root node.

There are ways to define seasons using G2 concepts, which are valid with the SportsML schema.