Page Comparison

When exchanging data between different sources it is common that each source uses a different identifier for the same entity and there is no universal identifier. TODS allows entities to contain multiple ids to facilitate easier data transfer.

Primary identifier

Each entity in a TODS message has an attribute for the identifierIt is important to identify where data sent in the TODS came from. To do this, an identifier can be used. For example, every Tournament entity tournament must have a TournamentId. This primary identifier is always the identifier Id used by the source. The source knows this the sender of the TODS data and is unique. Each Id in TODS sits in a URN-style namespace . in the following format:

Tennis:<Entity>:<Provider>:<Identifier>

Let's consider a Tournament exchanged between two sources Source A (whose ProviderId is SOURCE-A) and Source B (SOURCE-B).

Source A could send a message like thisIt is important to note that when, for example, entering a TournamentId, the entity is already a tournament and does not need to be re-entered.

To clarify, please see the example below where provider 'The Northern Lawn Tennis Club' is sending data using the TODS to the 'LTA':

<Tennis>
	<Header>
		<ProviderId>SOURCE-A<<ProviderId>The Northern Lawn Tennis Club</ProviderId>
		<Date>2019-04-17</Date>
		<DataStandardsVersion>Draft 0.3<5</DataStandardsVersion>
	</Header>
		<Tournament>
			<TournamentId>T182747</TournamentId>
			<Name>Junior<Name>The EasterManchester Cup<Trophy</Name>
			…
		</Tournament>
</Tennis>

...

{
	"Tennis": {
		"Header": {
			"ProviderId": "SOURCE-AThe Northern Lawn Tennis Club",
			"Date": "2019-04-17",
			"DataStandardsVersion": "Draft 0.35"
		},
		"Tournament": {
			"TournamentId": "T182747",
			"Name": "JuniorThe EasterManchester CupTrophy"
		}
	}
}

The ProviderId in the header tells us which provider all the primary ids are from. So this Tournament is Tennis:Tournament:SOURCE-A:T182747

Source B receives this Tournament, adds it to it's systems and generates its own id for it. If we assume Source A is the national association and Source B is the organiser we can imagine that Source B will now update the Tournament with more information and send that update to Source A.

Source B will set the Primary Identifier to its own id - but it wants to make sure that Source A knows this is an update to an existing Tournament. So Source B will include an additional identifierWe can see that The Northern Lawn Tennis Club sent data from a tournament, the Manchester Trophy, with the unique TournamentId of T182747. So, our Id is Tennis:Tournament:The Northern Lawn Tennis Club:T182747. This allows the recipient of TODS data to know exactly what it is and where it came from, in this case the LTA.

It is likely that the LTA would receive this tournament and add it to their own system, generating a new Id in the process. This would change ONLY the provider name and TournmentId, making their identifier Tennis:Tournament:LTA:ghttERaaI as you can see in the example below. If they wanted to add more data, sharing it back with The Nothern Lawn Tennis Club, it would be imperative to use both provider's unique reference Id to understand that they are sharing data on the same tournament.

<Tennis>
	<Header>
		<ProviderId>SOURCE-B<<ProviderId>LTA/ProviderId>
		<Date>2019-04-18</Date>
		<DataStandardsVersion>Draft 0.3<5</DataStandardsVersion>
	</Header>
		<Tournament>
			<TournamentId>ghttERaaI</TournamentId>
			<Ids>
				<Id>SOURCE-A<Id>The Northern Lawn Tennis Club:T182747</Id>
			</Ids>
			<Name>Junior<Name>The EasterManchester Cup<Trophy</Name>
			…
		</Tournament>
</Tennis>

...

{
	"Tennis": {
		"Header": {
			"ProviderId": "SOURCE-BLTA",
			"Date": "2019-04-18",
			"DataStandardsVersion": "Draft 0.35"
		},
		"Tournament": {
			"TournamentId": "ghttERaaI",
			"Ids": {
				"Id": "SOURCE-AThe Northern Lawn Tennis Club:T182747"
			},
			"Name": "JuniorThe EasterManchester CupTrophy",
		}
	}
}

The Primary Identifier has been set to Source Bthe LTA's (Tennis:Tournament:SOURCE-BLTA:ghttERaaI in full) and Source AThe Northern Lawn Tennis Club's identifier has been included too. Both sources now know this is a single Tournament and how each identifies it.

...

This is not limited to two identifiers, Sources may also want to include other idsother Id's can be included too. Let's assume that this Tournament is also exchanged with the ITF. Source B The ITF could also include that identifier when sending messages about the Tournament.

<Tennis>
	<Header>
		<ProviderId>SOURCE-B<<ProviderId>LTA</ProviderId>
		<Date>2019-04-18</Date>
		<DataStandardsVersion>Draft 0.3<5</DataStandardsVersion>
	</Header>
		<Tournament>
			<TournamentId>ghttERaaI</TournamentId>
			<Ids>
				<Id>SOURCE-A<Id>The Northern Lawn Tennis Club:T182747</Id>
				<Id>ITF:2019-J-O-NOR</Id>
			</Ids>
			<Name>Junior<Name>The EasterManchester Cup<Trophy</Name>
			…
		</Tournament>
</Tennis>

...

{
	"Tennis": {
		"Header": {
			"ProviderId": "SOURCE-BLTA",
			"Date": "2019-04-18",
			"DataStandardsVersion": "Draft 0.35"
		},
		"Tournament": {
			"TournamentId": "ghttERaaI",
			"Ids": {
				"Id": [
					"SOURCE-AThe Northern Lawn Tennis Club:T182747",
					"ITF:2019-J-O-NOR"
				]
			},
			"Name": "JuniorThe EasterManchester CupTrophy",
		}
	}
}

Related Information

...