ndr - interface dependency agreement€¦ · national data repository (ndr) interface dependency...

Greyhounds Australasia

National Data Repository (NDR)

Interface Dependency Agreement

Document ID:

Version: 1.5.1

Date: March 06 2013

Status: Approved – with Updates

`

Commercial-In-Confidence

NDR - Interface Dependency Agreement – v1.5.1 – March 2013 of 104

Table of Contents

1. Document Control ................................................................................................. 4

1.1. Document Owner .........................................................................................................4

1.2. Document Contribution List ...........................................................................................4

1.3. Document History ........................................................................................................4

1.4. Stakeholder Signoff .................................................................................................... 10

2. Introduction .......................................................................................................... 11

2.1. Document Purpose ..................................................................................................... 11

2.2. Intended Audience ..................................................................................................... 11

2.3. Document Scope ........................................................................................................ 11

2.4. Guiding Principles ....................................................................................................... 11

2.5. Decision Register ....................................................................................................... 12

2.6. Items Known to be Incomplete .................................................................................... 16

3. Business Overview .............................................................................................. 18

3.1. Business Context........................................................................................................ 18

3.2. Business Entities ........................................................................................................ 19

3.3. Business Operations ................................................................................................... 20

4. Logical Interface .................................................................................................. 23

4.1. Logical Data Model ..................................................................................................... 23

4.2. Data Ownership ......................................................................................................... 31

4.3. Logical Events ........................................................................................................... 33

5. Physical Interface ................................................................................................ 34

5.1. Web Services ............................................................................................................. 34

5.2. Encryption ................................................................................................................. 50

5.3. Authentication ........................................................................................................... 50

5.4. Change Detection ...................................................................................................... 51

5.5. Schemas ................................................................................................................... 53

5.6. Validation .................................................................................................................. 58

5.7. Status Codes ............................................................................................................. 59

`



6. End to End Scenarios .......................................................................................... 61

6.1. Success Scenarios ...................................................................................................... 61

6.2. Failure Scenarios ........................................................................................................ 63

7. Backwards Compatibility .................................................................................... 67

7.1. Operation .................................................................................................................. 67

7.2. Existing NDR files ....................................................................................................... 67

7.3. Legacy Unknown Data ................................................................................................ 69

8. Definitions, Acronyms and Abbreviations ........................................................ 70

9. Reference Documents ......................................................................................... 71

10. Appendix: Use of ETags ..................................................................................... 72

11. Appendix: Description of Attributes .................................................................. 74

11.1. Attributes of Dogs ...................................................................................................... 74

11.2. Attributes of Litters .................................................................................................... 76

11.3. Attributes of Meetings ................................................................................................ 77

11.4. Attributes of Persons .................................................................................................. 81

11.5. Attributes of Groups ................................................................................................... 82

12. Appendix: Description of Types ......................................................................... 83

12.1. Basic Types ............................................................................................................... 83

12.2. Types used across Entities .......................................................................................... 83

12.3. Types relating to Dogs and Litters ................................................................................ 83

12.4. Types relating to Meetings and Races ........................................................................... 92

12.5. Types relating to Persons and Groups......................................................................... 101

12.6. Types relating to Events ........................................................................................... 103

`



1. Document Control

1.1. Document Owner

If you have any feedback, questions, or require an electronic copy of this document, please contact:

Author: Chris Hawken

Email: [email protected]

1.2. Document Contribution List

Name Title Key Areas

David Elias Consultant All

1.3. Document History

Version Date Author Version Update Details

0.1 August 2 2011 Idan Manor Initial Draft.

0.2 October 21 2011 David Elias Updated with Business Overview and description of Logical Interface.

0.3 October 26 2011 David Elias Draft circulated for comment.

0.4 October 28 2011 David Elias Document updated with feedback from Craig Taberner.

0.5 November 21 2011 David Elias Document updated based on feedback from State Bodies.

0.6 November 30 2011 David Elias Key changes in this version:

Section 2.5 Decision Register updated.

Section 4.1 Logical Data Model refined. Events added to Logical Data Model.

Section 4.2 Data Ownership refined.

Section 5.1 Web Services refined. Search methods (Identify) added.

Section 5.5 Schemas updated.

Previous Section 6 Service Level Requirements removed from this document. These will be specified in the contractual arrangement between the State Bodies and GA.

Section 10 Description of Types added to document. This section lists all types used in the Logical Data Model.

mailto:[email protected]

`




0.7 December 2 2011 David Elias Key changes in this version:

Section 2.5 Decision Register updated.

o Item 4: Multiple sires: Business impact updated.

o Item 8: NDR will store a history of previous owners and previous trainers of a Dog. This change is reflected in Sections 4.1.1 and 5.1.1.

o Item 16: Moving group: Noted that this is

pending definition of Business Rules.

1.0 January 13 2012 David Elias Document baselined as representing the agreed position of all parties at the date of release.

Section 11 has been added to provide a description of the attributes of each Entity.

Substantial change to dog penalties. It is now possible to specify that a penalty requires a satisfactory trial. Any authority can clear a penalty, allowing the possibility of a satisfactory trial being performed in a state other than the one that originally issued the penalty. Affects Section 2.5 (decision 15), Section 4.2.2, 5.1.1, 11.1, 0 and the schemas types.xsd, dog.xsd, dog_in.xsd, dog_penalty.xsd.

At the suggestion of WA, modified Dog Lifestate to clearly distinguish “retired” and “deceased”, and to

add extra reasons for each. Affects Section 12.3 and the schema types.xsd.

At the request of Queensland: Added Novice to Dog Grade Type. Affects Section 12.3 and the schema types.xsd.

At the request of GA: Added “service method” (i.e. natural / FSI) to Litter Entity. Affects Sections 4.1.2, 12.3 and the schemas types.xsd, litter.xsd, litter_in.xsd. In addition, added details for a FSI service, including inseminator, facility name, breeding unit ID. Affects Sections 4.1.2 and 12.3, and the schemas types.xsd.

Explanatory Material: Section 6.1.1. Added description of the End to End Process for Assigning / Updating a Dog Name.

Minor correction: Added the correct type (i.e. Dog Name Type) to Dog names in Figure 3 and Figure 5.

Minor amendments to phone numbers: Extended phone type to allow domestic or international phone numbers. Mobile number changed to non-mandatory. Affects Sections 4.1.4, 12.5 and schemas types.xsd,

`




person.xsd, person_in.xsd.

Modified API to reflect the fact that all events will be published to the same queue. Affects Sections 5.1.1-5.1.6.

Removed redundant authority field from person_penalty.xsd.

Minor change to Litter entity to include the name of the breeder. Affects Section 4.1.2 and schemas litter.xsd, litter_in.xsd, litter_whelping.xsd.

Extended maximum margin to 40 lengths, in increments of 0.25 between 1 and 5; increments of 0.5 between 5 and 10; increments of 1 between 11 and 40. Affects Section 0 and schema types.xsd.

At the request of WA, the time of an individual dog in a race result is now optional. Affects Section 4.1.3 and the schemas meeting_in.xsd, meeting.xsd.

1.1 January 31 2012 David Elias Functional modifications:

o Modified FSI Details Type to allow multiple Breeding Units. Affects Sections 11.2, 12.3, and the schema types.xsd

o Modified Dogs in Race to include a link to the Owner of the Dog (at the time of the race). Affects Section 4.1.3 (Figure 5), and the schema meeting_in.xsd.

o Modified the interface to the Dog – Update (trainer) transaction to allow the removal of the current Trainer, without assigning a new Trainer. Affects Section 5.1.1.

o As agreed between WA and GRV: Added the following fields to the data recorded when a Dog completes a Satisfactory Trial: Distance, Number of Runners, Box No, Weight, Time, Place, Margin. Affects Section 12.3, and the schema types.xsd.

o Margin Type modified to allow a margin of “0”. Affects Section 12.4, and the schema types.xsd.

Modifications to facilitate data migration:

o Modified Person Name Type to make Middle Initial optional: affects the schema types.xsd.

o Added Box Type and Rug Type as enumerations, mainly to allow “unknown” box no and rug no: affects Section 4.1.3 (Figure 5), Section 12.4, and the schema types.xsd.

`




o Modified Margin Type, Race Result Type, Dog Grade Type to allow “unknown”: affects Sections 12.3-12.4, and the schema types.xsd.

o Within Dog Race Result, margin is made optional (aligned with the attribute time). Affects Section 4.1.3 (Figure 5), and the schema race.xsd.

o Race Result Info Type modified so that all fields non-mandatory. Affects schema types.xsd.

Cosmetic changes:

o Modified names in Figure 2 to match text.

o Modified Figure 3 and Figure 5 to clearly show a Person or Group can own a Dog.

Modified description of Event / Meta data:

o Included API functions to read metadata. Affects Sections 5.1.1 – 0.

o Removed the schema event_extension.xsd. Affects Section 5.5.3.

o Included the schema: meta.xsd. Affects Section 5.5.4.

o Modified Event Type to match implementation. Affects Section 12.6 and

schemas types.xsd.

o Added Event Details Type. Affects Section 12.6 and the schema types.xsd.

1.11 July 3 2012 Chris Hawken Updated Litter API – Should be Sire then Dam for Earbrand

1.2 August 3 2012 Chris Hawken Update Decision Register (section 2,5) with outcomes from NDR meeting held in Melbourne on 27th June 2012

Update Items Known to be Incomplete (section 2.6) with outcomes from NDR meeting held in Melbourne 27th June 2012

Remove embedded schema documents (section 5.5) from the IDA document. Schemas now available on NDR homepage.

Added Backwards Compatibility (section 7)

Split into separate elements within the race schema PIR and comments (section 11.3 and 12.4)

Add split rug number element to the Result in the

`




races schema (section 11.3 and 12.4)

Separate out results (section 11.3) between dogs that:

o Do not start in a race

o Do not finish a race

o Finish a race and given a placing

Added email address to person schema (section 11.4)

Removed Unknown Dog Grade Type value (section 12.2)

Removed Unknown Rug Type value (section 12.4)

Removed Unknown Box Type value (section 12.4)

Changed Margin from enumerated type to decimal value (section 12.4). Margins no longer need to be rounded.

Removed Injured and Unknown Race Result Type value (section 12.4)

Sorted Track Code Type values (section 12.4)

Changed Dapto code (DAP) to DTO (section 12.4)

Changed BGC track name from Brisbane to Albion Park(section 12.4)

Added track code INT International (section 12.4)

Add 31 Race Grade Type values to cover missing and

New Zealand grades

Added PersonUpdateGroupMembership Event Type (section 12.6)

Remove “Identify” Business Operation from each API in section 5.1.

Removed “Unassigned” from the Box Type value (section 12.4)

Added to Lifestate “Retired” reason of “Other” (section 12.3)

1.3 September 13 2012

Mark Dodgson Removed Etag attribute from entry element (section 5.5.3).

Removed Etag property from image (section 4.1.5).

Modified Etag and added version number information

(section 5.4).

Added GET dog version number to Dog API (section 5.1.1).

Added GET litter version number to Litter API (section 5.1.2).

Added GET meeting version number to Meeting API

`




(section 5.1.3).

Added GET person version number to Person API (section 5.1.4).

Added GET group version number to Group API (section 5.1.5).

Removed etag field from event details type (section 12.6).

Added information about meta version index (section 5.5.4).

Section 7 still under discussion/review.

1.31 September 27 2012

Chris Hawken Update entity diagrams

Add additional information about the processing of events (section 5.1.6)

Add race grade of JG (Juvenile Graduation) and remove ST (stewards trial) (section 12.4)

Update events table (section 12.6)

October 2 2012 Mark Dodgson Added additional information about the Margin for dog race results (section 2.5).

Added additional information about the Margin for dog race results (section 11.3).

1.31 November 7 2012 Mark Dodgson Section 11.5 edited to add fromDate and linkType attributes.

1.4 November 9 2012 Mark Dodgson Added AuthorityToBreed to Dog entity transactions (section 4.2.2 part 5).

Added Dog – Authority to breed (section 5.5.2).

November 12 2012 Mark Dodgson Added dog without current active trainer (section 4.1.1 diagram).

Edited for group being active (section 4.1.4 diagram).

Edited DogTrialUpdated to Dog entity transactions (section 5.1.1).

Dog penalty updated (types.xsd).

The element 'trialCompletedInfo' has been rename to 'dogTrialType' and is part of 'trials' element (dog.xsd).

The child element 'trialCompleted' has been removed from 'penaltyClearanceInfo' element and now forms part of 'dogTrialType' (dog.xsd).

1.4.1 December 21 2012 Gayle Martin Updated disjointed Document History table.

January 21 2013 Mark Dodgson Added further information about the Margin for the dog race results (section 11.3).

1.5 February 1 2013 Gayle Martin Added comment to Group Move

Inserted Penalty (Dog and Person) information

`




(Note: ER diagrams not have not been updated)

Removed “Unknown” as a gender option on dog/litter and service_type.

1.5.1 March 5 2013 Gayle Martin Reinstated “Unknown” as litter and service_type as GA require this setting for creating international litters for pedigree purposes.

Added Dog Penalty Codes:

o OT = Other

o VC = Vet certificate required

Added Trial Reason

o BM = Box manners

March 27 2013 Gayle Martin Added Group Move event.

1.4. Stakeholder Signoff

Name Title Sign-Off Received (Yes / No)

Date

Craig Taberner CEO GA

Geoff Milner GRV Project Sponsor

Mark Bottcher Manager Greyhound Racing

Racing and Wagering Western

Australia

(on behalf of NSW, WA)

Yes 23/12/2011

Stuart Cashen NZGRA Yes 7/12/2011

David Rowan GRQ Yes 8/12/2011

(Other State Bodies will need to nominate appropriate Stakeholders)

`



2. Introduction

2.1. Document Purpose

This Interface Dependency Agreement (IDA) describes the interface provided by the National Data

Repository (NDR).

2.2. Intended Audience

This document is intended to be used by:

Development and test teams of all parties (both within GA and State Bodies) who interact with the

NDR via the interface.

2.3. Document Scope

2.3.1. Inclusions

A description of the Logical Interface provided by the NDR;

A specification of the Physical Interface provided by the NDR;

Data Validation rules applied by the NDR;

Description of error scenarios, and best practices to assist in resolving errors.

2.3.2. Exclusions

Any item not explicitly listed as being within scope.

2.4. Guiding Principles

The National Data Repository (NDR) is the master repository for greyhound data that is common between

GA and the State Bodies.

The following principles are used to guide decisions concerning what data should be stored in the NDR,

how it should be named, and how it should be accessed.

# Principle Business Impact Approved By

Date

1 The NDR will store the minimum of data that needs to be common

between GA and the State Bodies.

GA and each State Body will have to maintain their own data

repository for specific needs which are not met by the NDR.

2 The NDR will use naming

conventions that are meaningful

Bodies will have to use NDR

naming when communicating with

`



# Principle Business Impact Approved By

Date

across jurisdiction boundaries. the NDR, which may require converting from a local naming

convention.

3 Every data item stored in the NDR has an Owning Authority.

Only the Owning Authority of a data item is able to modify the

data item. (Note: There are some specific exceptions to this rule,

which are specified later in the

document.)

4 Regardless of Owning Authority, all

data stored in the NDR is readable

by GA and every State Body.

5 When data is updated in the NDR,

the NDR will internally update other linked data to maintain

internal consistency.

6 NDR maintains a single record for each Person, which is maintained

when the Person moves from one

state to another.

2.5. Decision Register

The following table summarises key Business Decisions that impact on the interface provided by the NDR:

# Decision Business Impact Approved By

Date

1 The NDR will support creation of a Litter at the time of Service.

The NDR will support updating of a

Litter at the time of Whelping.

The NDR will support updating of a

Litter at the time of Registration.

2 The authority which provides

notification of Service is the initial

Owning Authority of a Litter.

`




Date

Owning Authority of a Litter passes to the authority which provides

notification of Whelping (where

this is different from the authority which provided notification of

Service).

3 Earbrand is the primary business

identifier for a Dog.

If another identifier, e.g. microchip,

becomes the primary identifier in future,

this will necessitate modification to the NDR and its interface.

4 Where multiple Sires are involved

in creating a Litter, separate Litter records are created in the NDR for

each Sire.

The following considerations apply to State

Body Systems (e.g. those that are part of OzChase) that internally maintain a Service

/ Litter record with multiple Sires:

When transferring data from the State

Body System to the NDR, the State

Body System Litter record needs to be split into separate NDR Litter records for

each Sire. Given that the association

between pups and Sires is only established at the time of Litter

Registration, this implies that multiple Sire Litters cannot be notified to the

NDR prior to Litter Registration.

When receiving data from the NDR, the

State Body System may choose to merge individual NDR Litter records into

a single multiple Sire Litter record. Any NDR Litter records that have the same

Dam, the same Service Date, but a different Sire, can be merged into a

single multiple Sire Litter record.

5 The NDR will maintain Late Name as part of the Dog Entity.

The NDR will record when a name

is re-used.

GA is responsible for Dog naming, including maintaining Late Name, and managing re-

use of names.

This information may be required by State Bodies in publishing Form Guides.

6 The NDR will maintain a maximum

of two microchips per dog.

This caters for the situation where a

greyhound is re-chipped, when it is not possible to locate the original microchip.

Both microchips may end up still being

`




Date

readable and are therefore valid.

7 The NDR will maintain a “stud sire” flag on a Dog.

Required by GA.

8 The NDR will maintain a history of the previous owners and the

previous trainers of a Dog.

9 As part of Race results, the NDR will maintain the Name, Owner and

Trainer of a Dog that was current

at the time of the race.

This information is needed for the Stud Book.

10 Within Race results, “Position in

Running (PIR)” is a free text field.

There is no guarantee that State Bodies will

use this field in a consistent or compatible manner.

Rejected. See

point 21

11 It is the responsibility of a State

Body to determine whether a Person already exists in the NDR

prior to creating a new Person

Entity in the NDR.

State Bodies will need to adopt appropriate

matching procedures (e.g. using full name, date of birth, etc) to determine whether an

individual is already present in the NDR.

12 The NDR needs to be able to

maintain an “Authority to Breed” on a Dam (with respect to Frozen

Semen Service).

“Authority to Breed” is maintained by the

State Bodies, but needs to be available in the GA portal.

13 The NDR needs to be able to maintain an “Authority to Bred” /

“Stud Master” on a Sire.

14 Dogs will be automatically created in the NDR when a Litter is

registered.

State Bodies never need to create a Dog in the NDR.

GA will still need to create Dogs in the NDR, when Dogs are imported from overseas.

15a A Penalty on a Person can only be

cleared by the authority that applied the penalty.

There may be more than one Penalty on a

person at the same time – especially if more than authority apply a different penalty

type.

15b A Penalty on a Dog can be cleared by any authority.

Clearance will depend on the

This enables a Satisfactory trial to be performed in a state other than the one that

applied the original penalty.

`




Date

Penalty type and trial track requirements.

16 The NDR will not provide a means

of moving a Group from one authority to another.

Note: this item is still under consideration, and may change if Business Rules can be defined describing the expected behaviour.

If a Group (e.g. a Syndicate) moves

interstate, and wishes to be recognised in the NDR in the new state, they need to

create a new registration for the Group in their new state.

Rejected. See

point 20

17 As part of Race results, the NDR

will record the time of each Dog.

18 Any authority may update the following details of a Dog:

Microchip number(s)

Certificate number

Lifestate (e.g. racing / retired /

deceased)

These attributes will usually be updated in the state where the greyhound is racing.

19 The NDR will only store persons who are registered as Owners or

Trainers.

Other categories of Person will need to be maintained in the State Body Systems.

20 The NDR will allow a Group to move from one authority to

another.

A group will change authority when the residential address of the manager of the

group changes state. E.g. SA to QLD.

21 Within Race results, “Position in

Running (PIR)” is a string field

made up of numeric vales.

PIR can be recorded in a consistent form,

regardless of how states record other race

comments such as speed and checks.

22 Within Race results, “Comments” is

a free text field.

There is no guarantee that State Bodies will

use this field in a consistent or compatible

manner.

23 Historical prize money other won

by a dog will not be migrated (where available) from the old

NDR to the new NDR.

Prize money other (breeder bonus, trophy)

in the existing NDR is incomplete and would provide an incorrect prize money total.

24 Parameters for Data Migration from the old NDR to the new NDR

are as follows:

`




Date

Dog – Whelped on or after 01

January 2000

Litter – Whelped on or after 01

January 2000

Person/Group – Has an expiry date greater than now or the

person/group is linked to any

of the Dog/Litter records described above

Meeting/Results – Meetings

held on or after 01 January 2005

Penalties – all created since

01/01/2009.

25 Margin for the first dog is the margin the dog beat the 2nd dog

by (or 3rd dog for a dead heat).

Margin is in dog length(s).

Provides richer race result information for the winning dog

26 Remove defined margin distances Actual margin distance can be recorded

without the need for rounding the margin, thus increasing the accuracy of the margin.

27 The clearing of a penalty where a

dog has performed a satisfactory trial in a state different to the state

that imposed the penalty

Any state can update or clear a dog penalty

even if they didn’t impose the penalty – as long as the clearance requirements are met.

20/02/2102

2.6. Items Known to be Incomplete

The following table summarises key items relating to the NDR which are known to be incomplete in the current document.

# Issue Note

1 The NDR will need to be backwards compatible

to the existing CSV file based interface for a period after go live.

RESOLVED – see section 7 on backwards

compatibility

The requirements for backward compatibility are dependent on the cutover approach to the

`



# Issue Note

new NDR, which is yet to be finalised.

2 Parameters surrounding Data Migration to the

new NDR need to be agreed.

RESOLVED – see section 2.5, number 24

Some particular matters that need

consideration:

Which records will be migrated to the new NDR;

e.g.

Meeting entities will include meetings held

since a particular (to be agreed) date;

Litter entities will include Litters registered

since a particular (to be agreed) date;

Person entities will only include currently

registered persons.

The quality of the data migrated to the new

NDR is dependent on the quality of data in the existing NDR. There is limited scope for data

cleansing during the migration.

In some cases, data might be mandatory in the

new NDR, but is not available in the current

NDR.

`



3. Business Overview

3.1. Business Context

The National Data Repository (NDR) is the master repository for greyhound data that is common between

GA and the State Bodies.

The NDR also acts as a mechanism for GA and the State Bodies to publish data changes to other parties.

Whenever GA or a State Body update locally held data, they may also choose to push any relevant changes to the NDR. The NDR, in turn, publishes any such changes as events, which can then be picked

up by other interested parties.

Figure 1 - Context Diagram

Figure 1 shows the interaction between the following systems:

The GA Web Portal is the GA system for maintaining greyhound data;

A State Body System is a state based system for maintaining greyhound data;

The National Data Repository (NDR).

`



3.2. Business Entities

The following table shows the Entities stored by the NDR, as well as a high-level summary of the data

stored for each. (Section 4.1 provides a definitive listing of the Entities and Attributes held by the NDR.)

Entity Summary of Data Held in the NDR

Dog Identifying information

Ownership (current and historical)

Trainer (current and historical)

Penalties (current and historical)

Racing history

Litter Dam

Sire

Service date

Whelping date

List of dogs that resulted from the litter

Meeting Location

Date

List of Races, each including:

o Identifying information

o Prize money

o List of participating dogs

o Results

Person Identifying information

Contact details

Registered roles, e.g. owner, trainer

Group memberships

Penalties

Group Group type, e.g. Syndicate, Partnership

Group name

List of members

`



3.3. Business Operations

3.3.1. Operations

The interface supports the following high-level operations on each Entity:

Operation Description

Create Create a new instance of the Entity.

Update Modify an existing instance of the Entity.

Identify Perform a search against some specified search criteria.

Get Get the details of an instance of the Entity.

Publish NDR publishes details of an updated instance.

Note: It is not possible to Delete an Entity via the interface. If an Entity is no longer current, this is

indicated by performing an Update either on a status field, or on a date field. For example, when a Dog dies, the Dog Entity remains in the data store, but the status is updated to “Deceased”.

`



3.3.2. Sequence of Operations to Update and Publish Data

This section describes the sequence of operations involved, when a party makes use of the interface to

Update data, then the NDR Publishes the updated data to other interested parties.

The scenario is written in terms of an update that is entered by GA, and which is then published to the

State Body Systems via the NDR. The reverse scenario, where the update originates in one of the State Body Systems, may also occur.

Figure 2 – Update and Publish Data via NDR. Operations shown in blue correspond to NDR operations listed in Section 3.3.1.

The sequence of steps shown in Figure 2 is as follows:

Step Description

1 A GA users logs into the GA system, and loads data for a specific Entity (e.g. a Dog)

into their web browser.

2 The GA user updates the Entity, and Submits.

3 The update is written to the GA data store.

`



Step Description

4 The GA system initiates an Update operation on the NDR.

5 The update is written to the NDR data store.

6 NDR Publishes an event, indicating that an update has occurred.

7 The State Body System polls the NDR to pick up the latest Events.

Polling is performed by performing a Get operation on all Events.

8 The State Body System determines that it is interested in the Event.

The State Body System performs a Get operation on the updated Entity.

9 The updated data is written to the State Body System data store.

GA, NDR and the State Body System are now synchronised.

Note that the sequence of events shown here is not intended to be prescriptive; clients are not required to perform the listed operations in precisely the manner listed above.

`



4. Logical Interface

4.1. Logical Data Model

The Logical Data Model defines, and specifies the relationship between:

The Dog Entity;

The Litter Entity;

The Meeting Entity;

The Person Entity;

The Group Entity;

Events.

Note that Events are not Entities in their own right; the presence of an Event simply reflects a change to one of the previously mentioned Entities: Dog, Litter, Meeting, Person or Group.

Most of the attributes specified in the Figure 3 - Figure 7 are considered to be self explanatory; however for completeness, a description of each attribute is provided in Section 11.

`



4.1.1. Dog Entity

Figure 3 - Dog Entity. See footnote 1 for an explanation of the types and numbering used in this diagram.

The Dog Entity, shown in Figure 3, defines the attributes of a Dog.

A Dog is identified in the NDR by its earbrand.

The NDR stores a dog’s identifying information, as well as its current Owner, Trainer and Authority to

Breed (if applicable).

The NDR maintains a history of:

Ownership;

Trainer;

Penalties;

Races where the Dog has been a participant.

1 The types referred to in this, and later, diagrams are described in Section 1. The numbers in this, and

later, diagrams are used to indicate which elements in the model are mandatory. A [1] indicates that an element is mandatory; [0..1] indicates an element is optional. [0..*] indicates an element is optional, but

if present, there may be many such elements.

`



Other data maintained in the Dog Entity include a link to the Litter it was part of, and its “lifestate”.

4.1.2. Litter Entity

Figure 4 - Litter Entity

The Litter Entity, shown in Figure 4, defines the attributes of a Litter.

A Litter is identified in the NDR by a combination of dam earbrand, sire earbrand, and service date.

The Dam, Sire and service date are known at the time of Service. The Whelping Date and Litter Dogs (if any), are known after Whelping has occurred. The earbrand and microchip no of each Litter Dog is known

once Litter registration has occurred.

Note that only one Sire is associated with each Litter. Where multiple Sires were involved in creating a Litter, separate Litter records will be maintained for each Sire.

In order to maintain internal consistency between Litter and Dog entities, the NDR will automatically create Dog entities in the NDR when a Litter is registered. The NDR will create a Dog Entity for every dog

in the Litter, using the following attributes:

Attributes used to create Dog Entity Value

authority The authority who registers the

Litter.

earbrand Taken from the Litter attributes

`



Attributes used to create Dog Entity Value

color for each individual Litter Dog.

sex

microchip no

whelping date Taken from Litter attributes.

lifestate Set to ”unnamed”.

stud sire flag Set to “false”.

This implies that a State authority should never need to create Dog entities directly in the NDR. The NDR

will automatically create a Dog Entity for each registered pup.

`



4.1.3. Meeting Entity

Figure 5 - Meeting Entity

The Meeting Entity, shown in Figure 5, defines the attributes of a Meeting.

A Meeting is identified in the NDR by its Track Code, Date and Time Slot.

A Meeting consists of a number of Races. Each Race has some static data, such as Title, Grade and

Distance, which can be entered prior to the day of the race. The list of “Dogs in Race” is known once the field is graded. “Result” and “Dog Race Result” are known after the race has concluded.

Note:

The “track code” field of Meeting is set when the Meeting Entity is created in the NDR. The “track

held” field of Meeting is used to record the code of the track where the meeting was actually held.

“track held” will only differ from “track code” when there was a last minute change in the location of the meeting.

the “name”, “owner name” and “trainer name” fields of Dogs in Race are used to preserve the

snapshot of information that was current at the time of the race.

In order to maintain the internal consistency of the NDR, when updating the results of a Meeting, the NDR will automatically update the corresponding Races information maintained within the linked Dog Entity.

Note that this update will occur even if the Owning Authority of the Meeting is not the Owning Authority of the Dog.

`



4.1.4. Person Entity and Group Entity

Figure 6 – Person Entity and Group Entity

The Person Entity and the Group Entity, both shown in Figure 6, define the attributes of a Person and a

Group, and the relationship between them.

A Person or Group is identified in the NDR by their State (authority) and a state issued ID (state person id

/ state group id).

A Person may be registered as a Trainer or Owner, and these are maintained separately within

Registrations. A Group may be a Syndicate or a Partnership. Each Group consists of number of Members,

one of whom is given the role of Manager.

Note that both Person and Group have an identifier assigned by their local authority (shown in Figure 6 as

“state person id” and “state group id”). Such identifiers are not guaranteed to be globally unique, so a Person or Group must always be identified by a combination of authority and identifier.

When a Person moves state, they are obliged (within a short period) to register with the authority in their

new state. The authority in their new state will update their details in the NDR. This scenario is described in more detail in Section 6.1.1.

When a Person moves interstate the authority of the state the person is moving to must move all the Groups that person is a Group Manager of – in order to allocate new IDs.

As Person and Group are separate Entities within the NDR, they may be updated separately, which could in certain cases lead to inconsistencies. In order to maintain internal consistency, the NDR will perform

the following actions:

# Action initiated by a State Body System Action Performed by NDR to Maintain

Consistency

1 State Body System updates the Groups field of The Members field of the corresponding Groups

`



# Action initiated by a State Body System Action Performed by NDR to Maintain

Consistency

a Person. will also be updated by the NDR.

2 State Body System updates the Members field of a Group.

The Groups field of the corresponding Person will also be updated by the NDR.

`



4.1.5. Events

Figure 7 – Events

Figure 7 define the attributes of an Event File and an Event Entry. (Note that Events are not Entities in their own right; the presence of an Event simply reflects a change to one of the previously mentioned

Entities: Dog, Litter, Meeting, Person or Group.)

An Event File is identified in the NDR by its date, and has a timestamp showing the time of last update.

Time will be UTC time (TBC).

Each Event Entry includes both the Owning Authority (of the created or updated Entity), and the authority which requested the modification of the data. The Owning Authority will be different from the Previous

Owning Authority in cases where the event resulted in a change of Owning Authority.

In addition, each Entry has:

The type of event;

The name of the Entity to which the event occurred, e.g. the name of the Dog;

A link to the underlying Entity.

`



4.2. Data Ownership

4.2.1. Owning Authority

The following Business Rules arise from the principle that all data stored in the NDR has an Owning Authority.

# Business Rule Business Impact

1 Ownership is defined at the Entity level.

2 Each Entity has an Attribute named

“authority” which stores its Owning Authority.

3 When an Authority requests creation of an Entity, they become the Owning Authority of

the Entity created within NDR.

4 For the following Entities, the Owning

Authority never changes after creation:

Dog

Meeting

For international dogs, the owning authority is

GA.

5 The Owning Authority can change for a Litter Entity when Whelping has occurred.

The authority that lodges the notification of Whelping will become the Owning Authority of

the Litter Entity.

6 The Owning Authority can change for a Person Entity, when that Person physically

moves and registers with a new authority.

The authority which wishes to claim ownership will need to make a request to the

NDR via the interface.

4.2.2. Ability to Modify Data Held by the NDR

The following Business Rules govern the ability to modify data held by the NDR:


1 Except as stated under rules 3 to 8 below:

The Owning Authority can modify any aspect

of an Entity.

2 Except as stated under rules 3 to 8 below:

Any authority which is not the Owning

Authority cannot modify any aspect of an Entity.

`




3 GA is the only authority permitted to modify

the following fields of the Dog Entity:

Naming (including Late Name and name

re-use)

DNA no

Stud Sire flag

4 Any authority can add a new record to the

following fields of any Dog Entity:

Penalty

5 Any authority can update the following fields

of any Dog Entity:

Lifestate

Microchip no(s)

Certificate no

Owner

Trainer

Penalty

Authority to breed

6 Any authority can notify the NDR that Whelping has occurred.

The authority that lodges the notification of Whelping will become the Owning Authority of

the Litter Entity.

7 Any authority can add a new record to the following fields of any Person Entity:

Penalty

8 Only the authority that originally applied a

Penalty to a Person Entity can update or clear that Penalty.

9 If a Penalty is incorrectly applied to a Person or Dog, the owning authority will be required

to re-load the Person or Dog to remove

incorrect the Penalty.

Owning authority of the Dog or Person will be required to perform the refresh as a support

function.

`



4.3. Logical Events

The following table describes the Logical Events (i.e. occurrences that cause a change in the state of the

NDR) and the resulting action:

Event Description Resulting Action

Entity Created

The NDR receives a request to create a

new Entity.

The new Entity is created within the NDR.

An Event is Published notifying other

parties of the new Entity.

Entity

Update

The NDR receives a request to update an

existing Entity.

The Entity is updated within the NDR.

An Event is Published notifying other

parties of the update.

`



5. Physical Interface

5.1. Web Services

The following points apply to the tables included in Sections 5.1.1-5.1.6.

The “Permitted Authority” column lists the authorities who are permitted to make the request. If any authority makes a request they are not permitted to

make, they will receive an “Unauthorised” error (see Section 5.7 for a full list of error responses).

The “Input” column refers to various Entities and Components; these are defined via the schemas included in Sections 5.5.1 and 5.5.2.

Where available, a specific transaction should be used to update data rather than a general update. For example the Update(lifestate) transaction

should be used to update the lifestate for a dog, rather than the Update transaction for a dog.

`



5.1.1. Dog API

Business

Operation (per Section 3.3.1)

Permitted

Authority

Entity is

Identified by

HTTP Method URL Input Success

Response

Error Condition

Error Response

Create GA earbrand POST /dog/<earbrand

>

A Dog Entity The URL for the

new Dog Entity.

(None – if earbrand not found, a new dog created)

Update Owning Authority earbrand POST /dog/<earbrand>

A Dog Entity The URL for the updated Dog

Entity.

(None – if earbrand not found, a new dog created)

Update

(earbrand)

Owning Authority earbrand POST /dog/<earbrand

>/earbrand

(where

<earbrand> is the old earbrand)

Earbrand

component

(containing the

new earbrand)

The URL for the

updated Dog Entity.

Dog does not

exist

Item not found

error

Update (name) GA earbrand POST /dog/<earbrand

>/name

Name

component

The URL for the

updated Dog Entity.

Dog does not

exist

Item not found

error

Update (dna) GA earbrand POST /dog/<earbrand

>/dna

Dna component The URL for the

updated Dog

Dog does not

exist

`



Business Operation (per

Section 3.3.1)

Permitted Authority

Entity is Identified by

HTTP Method URL Input Success Response

Error Condition

Error Response

Entity. Item not found error

Update (studsire)

GA earbrand POST /dog/<earbrand>/studsire

Studsire component

The URL for the updated Dog

Entity.

Dog does not exist

Item not found

error

Update

(lifestate)

Any earbrand POST /dog/<earbrand

>/lifestate

Lifestate

component

The URL for the

updated Dog Entity.

Dog does not

exist

Item not found

error

Update (microchip)

Any earbrand POST /dog/<earbrand>/microchip

Microchip component


Entity.

Dog does not exist

Item not found error

Update (certificate)

Any earbrand POST /dog/<earbrand>/certificate

Certificate component


Entity.

Dog does not exist

Item not found

error

Update Any earbrand POST /dog/<earbrand Owner The URL for the

updated Dog

Dog does not

`




Section 3.3.1)

Permitted Authority



Error Condition

Error Response

(owner) >/owner component Entity. exist

Item not found

error

Update

(trainer)


>/trainer

Trainer

component (to

add a new trainer)

Or

Leave the body

of the HTTP

request empty (to remove the

current trainer, without assigning

a new trainer)

The URL for the

updated Dog

Entity.

Dog does not

exist


Update

(penalty) – add

a new penalty


>/penalty

Penalty

component

The URL for the

updated Dog

Entity.

Dog does not

exist


Update (penalty) –

modify an

Any earbrand

penalty code

POST /dog/<earbrand>/penalty

Penalty component


Dog does not exist

`




Section 3.3.1)

Permitted Authority



Error Condition

Error Response

existing penalty

penalty commencement

date

Entity. Item not found error

Get (entity) Any earbrand GET /dog/<earbrand

>

- The matching

Dog Entity.

Dog does not

exist

Item not found

error

Get (entity) Any earbrand GET /dog/<earbrand

>/n

- The matching

Dog Entity for

version number n.

Dog does not

exist


Get (metadata)

Any earbrand GET /dog/<earbrand>/meta

- The metadata for the matching

Dog Entity.

Dog does not exist


Update

(authority to breed)


>/authoritytobreed

Breeder

component

The URL for the

updated Dog Entity.

Dog does not

exist

Item not found

`




Section 3.3.1)

Permitted Authority



Error Condition

Error Response

error

Update (trial)

– add a new trial


>/trial

Trial component The URL for the

updated Dog Entity.

Dog does not

exist

Item not found

error

Update (trial) Any earbrand POST /dog/<earbrand>/trial

Trial component The URL for the updated Dog

Entity.

Dog does not exist


`



5.1.2. Litter API

Business


Permitted

Authority

Entity is

Identified by


Response

Error Condition

Error Response

Create Any Sire earbrand

Dam earbrand

Service date

POST /litter/<sire_earb

rand>/<dam_ear

brand>/<service_date>

A Litter Entity The URL for the

new Litter Entity.

State / Dam

does not exist


Update Owning Authority Sire earbrand

Dam earbrand

Service date

POST /litter/<sire_earbrand>/<dam_ear

brand>/<service_date>

A Litter Entity The URL for the updated Litter

Entity.

State / Dam does not exist


Update

(whelping)

Any Sire earbrand

Dam earbrand

Service date

POST /litter/<sire_earb

rand>/<dam_earbrand>/<service

_date>/whelping

Whelping

component

The URL for the

updated Litter Entity.

State / Dam

does not exist

Item not found

error

Get (entity) Any Sire earbrand

Dam earbrand

Service date

GET /litter/<sire_earb


_date>

- The matching

Litter Entity.

Litter does not

exist

Item not found

error

`




Section 3.3.1)

Permitted Authority



Error Condition

Error Response

Get (entity) Any Sire earbrand

Dam earbrand

Service date

GET /litter/<sire_earbrand>/<dam_ear

brand>/<service_date>/n

- The matching Litter Entity for

version number n.

Litter does not exist


Get

(metadata)

Sire earbrand

Dam earbrand

Service date

GET /litter/<sire_earb


_date>/meta

- Metadata for the

matching Litter Entity.

Litter does not

exist


`



5.1.3. Meeting API

Note: In the following table, the Meeting Time Slot is one of “M” (morning), “D” (day), “T” (twilight), “N” (night).


Section 3.3.1)

Permitted Authority



Error Condition

Error Response

Create Any Track code

Meeting date

Meeting time slot

POST /meeting/<track

_code>/<date>/<time_slot>

A Meeting Entity The URL for the

new Meeting Entity.

Track doesn’t

exist

Item not found

error.

Update Owning Authority Track code

Meeting date

Meeting time slot

POST /meeting/<track


A Meeting Entity The URL for the

new/updated Meeting Entity.

Track doesn’t

exist

Item not found

error.

Get (entity) Any Track code

Meeting date

Meeting time slot

GET /meeting/<track


- The matching

Meeting Entity.

No meeting

found

Item not found

error.

Get (entity) Any Track code

Meeting date

Meeting time slot

GET /meeting/<track_code>/<date>/

<time_slot>/n

- The matching Meeting Entity

for version number n.

No meeting found

Item not found

`




Section 3.3.1)

Permitted Authority



Error Condition

Error Response

error.

Get

(metadata)

Track code

Meeting date

Meeting time slot

GET /meeting/<track

_code>/<date>/<time_slot>/met

a

- Metadata for the

matching Meeting Entity.

Meeting does

not exist

Item not found

error

`



5.1.4. Person API

Business


Permitted

Authority

Entity is

Identified by


Response

Error Condition

Error Response

Create Any State

State person id

POST /person/<state>/

<state_person_id

>

A Person Entity The URL for the

new Person

Entity.

State does not

exist


Update Owning Authority State

State person id

POST /person/<state>/<state_person_id

>

A Person Entity The URL for the updated Person

Entity.

State does not exist


Update

(Owning Authority) – i.e.

when the Person has moved state

The authority of

the state to which the Person

has moved

State

State person id

(of the old state)


<state_person_id >/move

(the state and id of the old state)

A Person Owning

Authority component

(the body of the input includes

the new

authority and id)

The URL for the

updated Person Entity (i.e. in the

new state)

State does not

exist

Item not found

error

Update

(penalty) – add a new penalty

Any State

State person id


<state_person_id >/penalty

A Person penalty

component

The URL for the

updated Person Entity.

State does not

exist

Item not found

error

`




Section 3.3.1)

Permitted Authority



Error Condition

Error Response

Update (penalty) –

modify an existing

penalty

The Authority who applied the

Penalty.

State

State person id

Penalty code

Penalty

commencement

date

POST /person/<state>/<state_person_id

>/penalty

A Person penalty component

The URL for the updated Person

Entity.



Get (entity) Any State

State person id

GET /person/<state>/<state_person_id

>

- The matching Person Entity.

No matching person

Item not found

error.


State person id

GET /person/<state>/<state_person_id

>/n

- The matching Person Entity for

version number n.

No matching person

Item not found error.

Get (entity) – when the Person

Any State GET /person/<state>/<state_person_id

- The URL for the updated Person

No matching

`




Section 3.3.1)

Permitted Authority



Error Condition

Error Response

has moved state State person id

(of the old state)

> Entity (i.e. in the new state)

person

Item not found

error.

Get

(metadata)

Any State

State person id

GET /person/<state

>/<person_state

_id>/meta

- Metadata for the

matching Person

Entity.

State / Person

Id does not

exist

Item not found

error

`



5.1.5. Group API

Business


Permitted

Authority

Entity is

Identified by


Response

Error Condition

Error Response

Create Any State

State group id

POST /group/<state>/

<state_group_id

>

A Group Entity The URL for the

new Group

Entity.

State does not

exist


Update Owning Authority State

State group id

POST /group/<state>/<state_group_id

>

A Group Entity The URL for the updated Group

Entity.




State group id

GET /group/<state>/<state_group_id

>

- The matching Group Entity.

No matching group

Item not found error.


State group id

GET /group/<state>/

<state_group_id>/n

- The matching

Group Entity for version number

n.

No matching

group

Item not found

error.

`




Section 3.3.1)

Permitted Authority



Error Condition

Error Response

Get (metadata)

Any State

State group id

GET /group/<state >/<state_group_

id>/meta

- Metadata for the matching Group

Entity.

State / Group Id does not

exist

Item not found

error

Update (Owning

Authority) – i.e. when the

Manager of the

Group or the Group has

moved state

The authority of the state to

which the Group Manager has

moved.

State

State group id

(of the old state)

POST /group/<state>/<state_group_id

>/move

(the state and id

of the old state)

A Group Owning Authority

component

(the body of the

input includes

the new authority

The URL for the updated Group

Entity (i.e. in the new state)



5.1.6. Events API

Business

Operation (per

Section 3.3.1)

Permitted

Authority

Entity is

Identified by


Response

Error Condition

Error Response

Get (events) Any - GET /events/<date>* - Atom feed of

events for the

specified date.

No events

found

Atom feed is

`




Section 3.3.1)

Permitted Authority



Error Condition

Error Response

empty.

* As events are processed in batches it is possible that events processed just after 00:00:00 time can appear in the previous day’s events folder. Events

should not be read based on a folder date, rather events should be processed based on the ID of individual event entries. The ID of each event is the system tick time.

`


NDR - Interface Dependency Agreement – v1.5.1 –March 2013 of 104

5.2. Encryption

Each HTTP request is encrypted via SSL.

5.3. Authentication

Each authority will be issued with a unique key <apikey> which must be included with each HTTP

request.

Two methods are supported for doing this:

# Method Details Example

1 Query

String

The key can be appended to the HTTP request

as follows:

<HTTP method> <URL>?authority=<apikey>

Where

<HTTP method> is either “GET” or “POST”

<URL> is as shown in the “URL” column of

the tables included in Section 5.1

<apikey> is the unique API key.

GET /dog/abc123?authority=562AFA

Host: ndr.galtd.org.au

…

2 HTTP

Header

The key can also be included in the HTTP

header, on a distinct line of the form:

“Authority: <apikey>”

Where

<apikey> is the unique API key.

GET /dog/abc123

Host: ndr.galtd.org.au

Authority: 562AFA

…

The means of distributing the key is yet to be determined. Each authority is responsible for maintaining

the security of the issued key. The key will be changed on request.

`



5.4. Change Detection

The HTTP Entity Tag (ETag) is used to identify a particular version of an Entity within the NDR and is designed to prevent the overwriting of entities.

In addition, a version of the entity can be accessed using the GET method using an integer to represent the version. For example, the following URI for a GET operation will return version 1 of the Person

300037 entity:

http://machineURI/person/NSW/300037/1

As can be seen below, the response header contains both an ETag value and entity version 1:

HTTP/1.1 200 OK Cache-Control: private, no-store

Content-Type: text/xml; charset=utf-8 Expires: Wed, 31 Dec 1969 13:00:00 GMT

ETag: "0x8CF5F5F26695B60"

Server: Microsoft-IIS/7.5 X-AspNetMvc-Version: 3.0

EntityVersion: 1 X-AspNet-Version: 4.0.30319

X-Powered-By: ASP.NET

Date: Thu, 13 Sep 2012 00:41:51 GMT Content-Length: 1306

...

The standard usage of ETags in relation to GET and POST methods is as follows:

http://machineuri/person/NSW/300037/1

`



Method Request If the NDR holds a later

version of the Entity than the client making

the request …

If NDR does not hold a

later version of the Entity than the client

making the request …

GET Header includes a line of the

form:

“If-None-Matches: <ETag>”

where <ETag> corresponds

to the version of the Entity held by the client.

NDR returns the requested

Entity.

The header of the response includes a line of the form:

“ETag: <ETag>”


to the requested Entity.

NDR returns a response

with Status Code “304 Not

Modified”.

The body of the response is

empty.

POST Header includes a line of the form:

“If-Match: <ETag>”


to the version of the Entity

held by the client.

NDR does not accept the update.

NDR returns an error response with Status Code

“412 Precondition Failed”.

NDR accepts the update.

The header of the response

includes a line of the form:

“ETag: <ETag>”


to the updated Entity.

Further detail, including more details of the request and the response, is laid out in Section 10.

`



5.5. Schemas

5.5.1. Entities

Entity Schema (returned by

GET operation)

Schema (used to

Create or Update

Entity)

Dog dog.xsd dog_in.xsd

Litter litter.xsd litter_in.xsd

Meeting meeting.xsd meeting_in.xsd

Person person.xsd person_in.xsd

Group group.xsd group_in.xsd

Note that two schemas are provided for each Entity:

Schema (returned by GET operation): This is the full schema, that specifies the Entity returned by a

GET method;

Schema (used to Create or Update Entity): This is the schema used by the Owning Authority to Create

or Update an Entity. The following attributes (which are present in the full schema) are omitted from this schema:

o authority: always omitted, as this is implied by which ever authority calls the method;

o any elements already present in the URL are also omitted (to avoid duplication); e.g.

earbrand is omitted from Dog.

o Dog: name, dna, studsire are omitted, as these can only be set by GA.

`



5.5.2. Components

Business Operation

(refer Section 5.1)

Component

Dog – Earbrand Update (earbrand) dog_earbrand.xsd

Dog – Name Update (name) dog_name.xsd

Dog – Dna Update (dna) dog_dna.xsd

Dog – Studsire Update (studsire) dog_studsire.xsd

Dog – Lifestate Update (lifestate) dog_lifestate.xsd

Dog – Microchip Update (microchip) dog_microchip.xsd

Dog – Certificate Update (certificate) dog_certificate.xsd

Dog – Owner Update (owner) owner.xsd

Dog – Trainer Update (trainer) trainer.xsd

Dog – Penalty Update (penalty) dog_penalty.xsd

Dog – Trial Update (trial) dog_trial.xsd

Dog – Authority to

breed

Update (authority to breed) dog_authority_to_breed.xsd

Litter – Whelping Update (whelping) litter_whelping.xsd

Person – Owning

Authority

Update (Owning Authority) person_owningauthority.xsd

Person – Penalty Update (penalty) person_penalty.xsd

`



5.5.3. Events

The following schemas define the XML component that is returned from one of the Get (Events)

operations. In each case, the returned component is an Atom feed (defined by atom.xsd), extended in accordance with an element of type Event Details Type (defined within the schema types.xsd).

Entity Business Operation (ref

Section 5.1)

Schema

All Get (events) atom.xsd

Note that the NDR will only populate a small subset of the attributes defined in the Atom feed. The list of attributes to be populated is as follows:

`



Element Defined in Schema Attribute Meaning

feed atom.xsd updated The time stamp on the Feed.

title The title of the Feed, e.g. “NDR Events”.

subtitle The subtitle of the Feed, e.g. “Ndr Events

for 2012-01-30”

id The unique identifier of the feed.

link The link to the Events file.

entry types.xsd

(within eventDetailsType)

owning authority The Owning Authority of the Entity after

the event has occurred.

previous authority The Owning Authority of the Entity before

the event has occurred (this will only differ

from the “owning authority” if the Owning Authority has changed).

transaction authority

The authority that made the request that gave rise to the event.

name The human readable name of the Entity on

which the event occurred; e.g. the full name of a Person.

eventType The type of event.

description A free text description of the event.

atom.xsd

5.5.4. Metadata

Metadata refers to the data associated with each record in the NDR, such as ownership, relative links, current version index and versions. This data can be read, but cannot be written, by clients.

The current version of the entity is stored in the <versionIndex> element.

The following schema defines the XML component that is returned from one of the Get (metadata)

operations.

`



Entity Business

Operation (ref Section 5.1)

Schema

All Get (metadata) meta.xsd

Note that the information contained within an Events file and the Metadata is essentially the same. It is

just that the Events file contains all updates for a given date, whereas Metadata contains all updates for a given Entity.

5.5.5. Type Definitions

The following schema defines types used in the previously listed schemas.

Schema

Types types.xsd

`



5.6. Validation

The following validation is performed on each request:

Request Validation Test Performed

Any Authentication Has the user provided a valid API key, in accordance with

Section 5.2?

Any Integrity of URL Is the URL correctly formed?

POST Structural Integrity Does the body of the request conform to the relevant XSD?

POST Write Permissions Is the authority permitted to make the request, as defined in Section 4.2.2?

POST Update is not based on stale data

Does the ETag included in the POST request correspond to the latest version of the Entity that is being updated?

`



5.7. Status Codes

The response to each HTTP request will include a standard HTTP Status Code, as per the following tables:

5.7.1. Valid Requests

Request Success Scenario HTTP Status Code

GET The data corresponding to an Entity is read from the

NDR.

200 OK

POST A new Entity is created in the NDR. 201 Created

GET There is no update since the previous GET. 304 Not Modified

GET The requested resource does not exist.

(Note: This is still considered a valid request.)

404 Not Found

GET (Dog) The Dog earbrand has changed.


301 Moved Permanently

GET (Person)

The Person has moved state.


301 Moved Permanently

`



5.7.2. Invalid Requests

The following error scenarios correspond to failure of the validation outlined in Section 5.6.

Request Validation Error Scenario HTTP Status Code

Any Authentication Invalid credentials. 401 Unauthorized

Any Integrity of URL The URL is malformed. 404 Not Found

POST Structural Integrity The body of the request is

malformed (i.e. it does not conform to the XSD).

400 Bad Request

POST Write Permissions The request attempts to

modify read-only data.

401 Unauthorized

POST Update is not based on

stale data

The ETag included in the

POST request does not correspond to the version

of the Entity held by the

NDR.

412 Precondition Failed

`



6. End to End Scenarios

This section describes some key end to end scenarios which make use of the NDR interface.

6.1. Success Scenarios

6.1.1. End to End Process for Assigning / Updating a Dog Name

The following diagram and table defines the sequence of events involved in assigning or updating the name of a greyhound.

Figure 8 – Sequence of Events in Naming a Greyhound. The steps highlighted in blue impact the NDR.

Step Description Call to NDR Comment

1 An individual lodges a naming

application through their State Body.

(none) This process by which this

occurs may vary from state to state.

2 The State Body validates the

request.

(none) This process by which this

occurs may vary from state to state.

3 The State Body lodges the

naming application with GA via the Naming Application

interface.

(none) The Naming Application

interface is supported by the GA Web Portal, rather than by

the NDR. It is not defined in the current document.

`




4 GA applies business rules to determine which, if any of the

requested names are assigned to the greyhound.

(none) GA may, at its discretion, assign a name other than one

of the requested names.

5 If a name is assigned, the new

name is pushed from GA into the NDR.

Dog – Update (Name)

6 The State Body receives

updates from the NDR.

Get (Events)

6.1.2. Registered Person Moves Interstate

The following table summarises the changes to the NDR when a registered person moves interstate:

Timing Business Event Data Known Call to NDR Comments

Person moves

interstate

(none) (none) (none) Person remains

registered with their old State

Body.

Within 3 months Person registers with new State Body, and

is assigned a new

state person id.

Old state body

Old state person id

New state body

New state person id

The new state body posts a

Person - Update

call to the old URL (i.e. the URL

defined by the old state body /

old state person id).

The response

from the NDR contains the URL

of their new registration (i.e.

the new state

body / new state person id).

The NDR will from this point on

automatically

redirect requests to the old URL to

the new URL.

* People moving

between states that use the

OzChase system

will retain their OzChase ID.

However the owning authority

will change to the

new state.

`



6.1.3. Expected Updates of the Litter Record

The following table summarises the expected updates to the NDR at Service, Whelping and Registration of

a Litter:

Timing Business Event Data Known Call to NDR Comments

Service Service Dam

Sire

Service Date

Litter – Create

Whelping Whelping As for Service, plus:

Whelping Date

Pups, for each:

Colour

Sex

Litter – Update

Whelping + 12 weeks (typically)

Registration As for Whelping, plus:

Earbrand

Microchip No

Litter - Update The NDR will automatically

create Dog entities for each Dog in the

litter at this point.

6.1.1. Importation of an International dog

GA records the importation of international dogs into Australia and therefore is the owning

authority of the dog.

An international dog must be owned by a person who is registered participant with a racing

authority of Australia. Eg. RWWA, GRV

As itt is unlikely the whelped date or the pedigree of the Sire and Dam of an imported dog is

known, the Sire and Dam’s whelped dates cannot be entered, nor their litter details.

This is an exception to the rule in the NDR that requires DOG.whelped date and

LITTER.service_date to be mandatory values.

Ie. If the DOG.owning_authority = ‘GA’,

DOG.whelped_date is optional.

LITTER is optional

`




1 Dog details are entered in GA - Dog is created in GA

2 If Sire and Dam of dog are not

known in the NDR, they are

created in GA.

Owning authority of dog =

‘GA’.

Create dog (Sire)

Create dog (Dam)

Sire and Dam Whelped date may not

be known so can be left blank (if

owning authority of a dog = “GA”).

3 Dog’s litter details are entered (if known).

Create Litter Litter is created using Sire and Dam.

4 Person is created Create Person Person must be a registered participant.

5 Person is assigned as dog’s

Owner in GA.

Create Dog Dog is created in NDR with Owner

assigned.

6 The State Body receives updates from the NDR.

Get (Events) Owning authority of the dog, sire and dam = “GA”).

`



6.2. Failure Scenarios

This section describes some key high-level failure scenarios, and provides guidance on best practice on the client side to avoid the scenario.

In each of these cases, the “local system” is any consumer of the GA interface; e.g. could be the GA Web Portal, or it could be a State Body System.

Scenario Description What NDR Will Do … Best Practice on Client Side …

Local System Unable

to Push Update to NDR

The local system

has applied an

update to its local data store.

The local system

tries to push change to NDR, but fails

e.g. due to network

failure.

Nothing; the NDR is

not aware of the

attempted update.

Retry, e.g.

overnight.

If the retry also

fails, log a notification

according to a suitable (local)

mechanism – e.g.

write to an error log.

Once connectivity is

restored, the local system will have to

re-POST the update (possibly with

manual intervention

by local system admin).

Local System

Attempts to Push and Update to NDR

Without Sufficient Privileges

The local system

has write privileges

to certain fields, but tries to update other

fields.

NDR responds with

“invalid” request, as

per Section 5.7.2.

Local system should

ensure such data is

“read only”, so the local operator does

not inadvertently edit such data.

If multiple POST

transactions are available (e.g. to

Dog Entity) then the

local system should use the most

appropriate POST – e.g use Update

(owner) rather than

Update on the entire Dog Entity.

`



Scenario Description What NDR Will Do … Best Practice on

Client Side …

Client Attempts an

Update Based on Stale Data

The local system

attempts to update

the NDR based on stale data (i.e.

without having first

picked up previous changes).

NDR responds with

“invalid” request, as

per Section 5.7.2.

Local system should

perform a GET just

prior to allowing a user to modify data.

Note that this will

minimise the chance

of collision; however collision is still

possible.

Update Missed by Local System

Local system was

down when update was published.

Nothing; the NDR is

not aware this has occurred.

Local system should

regularly poll the NDR to ensure if

picks up all changes.

Local system should

perform a GET just

prior to allowing a user to modify data.

Local system should

maintain a log of

which events have been processed.

`



7. Backwards Compatibility

This section describes the backwards compatibility supported by the NDR. The NDR will be populated

with data received from the existing CSV files as defined in the “Technical Specification Document – National Data Repository Revision 03” document dated 17th November 2008.

7.1. Operation

The NDR will provide “one way” backwards compatibility. This means the NDR will be populated with

data received from the existing CSV files supplied by state bodies. To receive data from the NDR, state bodies will need to ensure their systems support the reading of published events from the NDR as defined

in this document.

7.2. Existing NDR files

The following is a list of the current files that will be supported by the NDR (all files are to be supplied in CSV format)

1. RF – Race Fields

2. RR – Race Results 3. DD – Dog Details

4. PR – Person Registration 5. LD – Litter Details

To ensure the correct operation of the NDR, the following sections outline the critical pieces of data that

must be supplied for each of the existing file types. The items listed in the next section are already supplied according to the current NDR specification, therefore the next section is a reminder of how the

data is to be supplied.

The only additional piece of data is in the PR – Person Registration file and the GM (Group member)

record. In this record the state (code) must be supplied (currently optional). The state code will identify the group member as not being from the state sending the PR file and will therefore take the NrdId in the

GM record to link the group to the group member in the NDR.

7.2.1. RF – Race Fields

To support backwards compatibility for this file, the following must be observed:

1. TrainerState must be supplied 2. StateTrainerID must be supplied where the trainer is from the state uploading the RF file

3. NdrId(Trainer) must be supplied where the trainer is NOT from the state uploading the RF file. This needs to be the full NDR entity ID e.g. person/WA/12345

All other existing rules for the RF file will apply.

`



7.2.2. RR – Race Results

Existing rules for the RR file will apply.

7.2.3. DD – Dog Details


1. DS Record – Existing rules for the DS record will apply

2. DT Record a. StateTrainerID must be supplied where the trainer is from the state uploading the

DD file b. NdrID (trainer) must be supplied where the trainer is NOT from the state uploading

the DD file. This needs to be the full NDR entity ID e.g. person/WA/12345 c. All other existing rules for the DT record will apply

3. DO Record

a. NdrID (owner) must be supplied. This needs to be the full NDR entity ID e.g. person/WA/12345 or group/WA/3214 for dogs owned by a group

b. All other existing rules for the DO record will apply 4. DP Record – Existing rules for the DP record will apply

7.2.4. PR – Person Registrations


1. PI – Person Individual

a. State must be supplied

b. PersonID must be supplied where the state is the same as the state uploading the PR file

c. NdrId must be supplied where the state is NOT the same as the state uploading the PR file. This needs to be the full NDR entity ID e.g. person/WA/12345

d. All other existing rules for the PI record will apply

2. PG – Person Group a. State must be supplied


c. All other existing rules for the PG record will apply 3. GM Group Member

a. State must be supplied


c. NdrId must be supplied where the state is NOT the same as the state uploading the PR file. This needs to be the full NDR entity ID e.g. person/WA/12345

d. All other existing rules for the GM record will apply

7.2.5. LD – Litter Detail


`



1. BreederNDRID must be supplied. This needs to be the full NDR entity ID e.g. person/WA/12345 or group/WA/3214 for breeders that are a group

2. All other existing rules for the LD file will apply

7.2.6. Person and Dog Penalty

1. Limited backward compatibility exists for Penalties - when the NDR goes live and not all states are using the new NDR. ie. those states that are still sending data to PICK, any unknown or incomplete values should be set to “LegacyUnknown”.

7.3. Legacy Unknown Data

In the process of migrating data from the old NDR to the new NDR, valid values for some data could not

be determined or was missing. To ensure significant amounts of data was not lost in transferring data from the old NDR to the new NDR of value of “LegacyUnknown” was supplied to enable partially complete

data to be migrated to the new NDR. For example, for a race result where a box number for a dog was missing, the value of “LegacyUnknown” was loaded into the new NDR as the box number.

Local systems will need to determine how to handle data received from the NDR with values of “LegacyUnknown”. Local systems will not be permitted to update the NDR with a “LegacyUnknown”

value. Where a local system has received data with the NDR with a value of “LegacyUnknown” and the local system has the authority to update the entity, then it is expected the local system will replace the

“Legacy Unknown” value with the correct value.

`



8. Definitions, Acronyms and Abbreviations

Term Meaning

API Application Programming Interface.

CSV Comma Separated Values.

Dam A female greyhound that is registered for breeding.

DNA Number An encrypted set of numbers that reflect a greyhound’s DNA makeup. It is used for unique identification of the greyhound, and for determining its pedigree.

ETag HTTP Entity Tag.

GA Greyhounds Australasia.

GRV Greyhound Racing Victoria. The body that administers greyhound racing in Victoria.

HTTP Hyper Text Transfer Protocol.

IDA Interface Dependency Agreement.

Late Name The previous name of a Dog, which has been renamed due to an explicit renaming request.

Litter The dogs born at the same time to a single Dam.

Markings The markings of a dog, such as colour, patterns, toe colours etc that are used to identify a dog.

NDR National Data Repository. A common data store used by all State Bodies for the

exchange of information relating to greyhounds, registered people, race form, race results and litters.

Owner A person who is registered to own a racing greyhound and has responsibility for the welfare of the greyhound.

PIR Position in Running

Service The natural or artificial joining together of a Sire’s semen with a Dam.

Sire A male greyhound that is registered for breeding.

SSL Secure Socket Layer

State Body A body that administers greyhound racing in an Australian state or territory, or in New Zealand.

Stud Book A book that records the official registration of all stud and breeding activity for a

greyhound association in a particular year.

Trainer A person who is registered to train, kennel, nominate and race a greyhound.

URL Universal Resource Locator.

XML eXtensible Markup Language.

XSD XML Schema Definition.

`



9. Reference Documents

Ref Name

Version

Date

Version Date Link

1 Business Requirements

Document

0.1 April 2011 http://grvwiki.onconfluence.com/download/attachments/2032710/GA+Business+Requirements+Docum

ent.docx

2 Functional Solution

Document

0.6 June 2011 http://grvwiki.onconfluence.com/download/attachments/2032714/GA+-

+Functional+Solution+Document+v0.5.docx

3 Architecture

Design

1.0 May 2011 http://grvwiki.onconfluence.com/download/attachm

ents/2032712/GA+Portal+and+NDR+Architecture+Design+v1.0.docx

4 Minutes of User

Group Workshop, 20

July 2011

July 2011

USER_GROUP_WORKSHOP_NOTES_27072011.doc

http://grvwiki.onconfluence.com/download/attachments/2032710/GA+Business+Requirements+Document.docx



http://grvwiki.onconfluence.com/download/attachments/2032714/GA+-+Functional+Solution+Document+v0.5.docx



http://grvwiki.onconfluence.com/download/attachments/2032712/GA+Portal+and+NDR+Architecture+Design+v1.0.docx



`



10. Appendix: Use of ETags

The following tables provide further detail of the use of ETags, as introduced in Section 5.4.

Method Condition Result Request Response

Header Body Status Code

Header Body

GET If ETag

included in request

AND ETag is up-to-

date.

No Entity

is returned,

as client is already

up-to-

date.

Includes a

line of the form:

“If-None-Matches:

<ETag>”

where <ETag> is

up-to-date.

Empty 304 Not

Modified

(Does not

include ETag)

Empty

GET ETag not

included in request

Latest

Entity is returned.

(Does not

include ETag)

Empty 200 OK

Includes

the ETag, in a line of

the form:

“ETag:

<ETag>”

The

requested Entity

GET ETag is included in

request,

but is not up-to-date

Latest Entity is

returned.

Includes a line of the

form:

“If-None-Matches:

<ETag>”

where

<ETag> is

NOT up-to-date.

Empty 200 OK

Includes the ETag,

in a line of

the form:

“ETag:

<ETag>”

The requested

Entity

`



Method Condition Result Request Response

Header Body Status Code

Header Body

POST If ETag

included in request

AND ETag is up-to-

date.

NDR

accepts updated

Entity.

Includes a

line of the form:

“If-Match: <ETag>”

where

<ETag> is up-to-

date.

An Entity 201

Created

Includes a

new ETag, correspond

ing to the updated

Entity, in a

line of the form:

“ETag: <ETag>”

Empty

POST ETag not

included in request

NDR

rejects updated

Entity, as the client

did not

specify the latest

ETag.

(Does not

include ETag)

An Entity 412

Precondition Failed

(Does not

include ETag)

Empty

POST ETag is

included in

request, but is not

up-to-date

NDR

rejects

updated Entity, as

the client was not

up-to-

date.

Includes a

line of the

form:

“If-Match:

<ETag>”

where

<ETag> is

NOT up-to-date.

An Entity 412

Preconditio

n Failed

(Does not

include

ETag)

Empty

`



11. Appendix: Description of Attributes

The following tables provide a general description of the attributes of the Entities described in Section 4.1.

Note that the precise definition of each attribute, including the full list of permissible values, is provided in

the relevant schema (included in Section 5.5).

11.1. Attributes of Dogs

Entity

Dog

Attribute Sub Attribute Description

Authority The Owning Authority of the dog.

Earbrand The earbrand of the dog.

Name The current name of the dog.

Late name The previous name of the dog (set when the dog is

renamed).

Name reused from This date is set if another dog has been assigned the dog’s name. This can occur once the dog is e.g.

more than 15 years old. In some State Body

Systems, the dog’s name may be displayed with the suffix “(OLD)” to reflect the fact that the name has

been re-used.

Color The markings of the dog.

Sex The sex of the dog.

Microchip 1 The primary microchip of the dog.

Microchip 2 The secondary microchip of the dog.

Whelped date The date when the dog was whelped.

Certificate no The certificate number of the dog.

Cleared to race date The date the dog was first cleared to race.

Registration date The date the dog was first registered.

Dna no The DNA signature of the dog.

Lifestate Indicates whether the dog is active, racing, retired or deceased.

Stud Sire Flag Indicates whether the dog is a stud sire.

Owner

Name The name of the owner of the dog.

From date The date that the owner commenced owning the dog.

`



Entity

Dog


Trainer

Name The name of the trainer of the dog.

From date The date that the trainer commenced training the dog.

Previous Owner

Name The name of the owner of the dog.

From date The date that the owner commenced owning the dog.

To date The date that the owner ceased owning the dog.

Previous Trainer

Name The name of the trainer of the dog.

From date The date that the trainer commenced training the dog.

To date The date that the owner ceased training the dog.

Authority to Breed

Name The name of the individual who has been given

authority to breed the dog.

From date The date that the authority to breed was granted.

Penalty 1. A dog may or may not have a Dog Penalty. 2. A Dog Penalty may or may not have one or

more Penalty Clearances. 3. A Dog Penalty may require a trial to be

completed,

Authority The authority which applied the penalty.

Dog Penalty Code The code that specifies the penalty.

Commencement date The date the penalty commences.

Expiration date Optional.

The date the penalty expires.

This will be populated if the penalty is a fixed

number of days, commencing at the commencement date and expiring at the expiration date.

Trial required (Type) Optional.

Indicates whether a trial is required to clear the

penalty, and specifies which track the trial must be

performed it.

Penalty Clearance Optional.

`



Entity

Dog


(Type) Provides details relating to the clearance of the penalty, including the authority which cleared the

penalty, the date, and the result of satisfactory trial (if a satisfactory trial was required).

Race

Race no The race number.

Race title The race title.

Track The track where the race was held.

Date The date of the race.

Distance The distance of the race.

Trial Dog Trial (Type) Trials may or may not be associated with Dog Penalties

There may be one or more Dog Trial for a single Dog Penalty.

A Dog Penalty may require a trial to be completed,

Dog trials are recorded against the dog, not the Penalty.

11.2. Attributes of Litters

Entity

Litter


Authority The Owning Authority of the Litter.

Dam earbrand The earbrand of the dam.

Sire earbrand The earbrand of the sire.

Service date The date on which service occurred.

Whelping date The date whelping occurred.

Service status Indicates whether the service is active, missed, whelped.

`



Entity

Litter


Service method Indicates whether the service is natural, FSI Or Unknown (International).

FSI details Includes details of FSI, including the name of the

inseminator, the name of the facility, and the Breeding Unit IDs.

Breeder

Name The name of the breeder of the litter.

Litter Dog

Color The markings of the dog.

Sex The sex of the dog.

Earbrand The earbrand of the dog.

Microchip The primary microchip of the dog.

11.3. Attributes of Meetings

Entity

Meeting


Authority The Owning Authority of the meeting.

Track code Indicates the track where the meeting was scheduled.

Date The date of the meeting.

Time slot The time slot of the meeting (Morning / Day / Twilight / Night).

Meeting cancelled Set to true if the meeting was cancelled.

Track held The track where the meeting was actually held.

Meeting type The type of meeting, e.g. TAB, non-TAB.

Race

Race no The number of the race.

Race abandoned Set to true if the meeting commenced, but this particular race was abandoned.

Race title The title of the race.

`



Entity

Meeting


Event type A free text field providing further detail of the type of event.

Grade The grade of the race.

Distance The distance of the race.

Start time The start time of the race. Note that this specifices both the time and time zone. All times are to be submitted in local time. Other states reading this

time can convert as necessary.

Prize1 – Prize8 The prize money awarded for positions 1-8 in the

race.

Prize other Additional prize money that may be allocated for a race event (e.g. GOBIS prize money).

Prize code Indicates the reason for the additional prize money.

Result The winning time, and the times recorded at each of the splits and the rug number of the first dog at

each split

`



The following table describes the sub sub attributes of Dogs in Race (refer Figure 5):

Entity

Meeting – continued

Sub Sub Attribute Sub Sub Sub

Attribute

Description

Name The name of the dog.

Owner name The name of the owner of the dog (i.e. at the time of the race).

Trainer name The name of the trainer of the dog (i.e. at the time

of the race).

Dog grade The grade of the dog (i.e. at the time of the race).

Rug no The rug worn by the dog.

Dog Result (Non Starter)

Result Why the dog didn’t start

Dog Other Result (Non finisher)

Box No The number of the box where the dog started the race.

Weight The weight of the dog.

Start price The starting price of the dog.

PIR The Position in Running of the dog at each of the

position markers.

Comments This is a free text field, and different states may choose to populate this field using differing

conventions.

Result Why the dog didn’t finish

Dog Race Result

(Finished)

Box no The number of the box where the dog started the race.

Place The place achieved by the dog in the race.

Time The time achieved by the dog in the race.

Weight The weight of the dog.

Margin Margin is the accumulated dog length(s) from the winner of the race. This implies that the margin of

the lead dog is the margin to the second dog, and

that the margin of the second dog is the margin to

`



Entity

Meeting – continued

Sub Sub Attribute Sub Sub Sub

Attribute

Description

the lead dog.

Start price The starting price of the dog.

PIR The Position in Running of the dog at each of the position markers.

Comments This is a free text field, and different states may choose to populate this field using differing conventions.

`



11.4. Attributes of Persons

Entity

Person


Authority The Owning Authority of the person.

State person id The identifier of the person, as assigned by the Owning Authority.

Full name The full name of the person.

Address The address of the person.

Date of birth The date of birth of the person.

Registry expiry date The expiry date of the person’s registration with their state authority.

Phone number The phone number of the person.

Mobile number The mobile phone number of the person.

emailAddress The email address of the person

Registration

Type Indicates whether the person is registered as an owner or a trainer.

From date The date on which the registration commenced.

Group

Name The name of the group the person belongs to.

From date The date when the person joined the group.

Penalty

Authority The authority which applied the penalty.

Rule Number Optional.

Free text field for the rule number (national or local) that was breached.

Person Penalty Code Mandatory.

The code that specifies the type of penalty.

Commencement date Mandatory.

The date the penalty commences.

Expiration date Optional.

The date the penalty expires.

Penalty status Mandatory.

Indicates the status of the Penalty. There are 3

`



Entity

Person


mutually-exclusive states a Person Penalty can be in at any point in time: Issued, Stayed, Quashed.

Stayed From Date Optional.

Start Date of Stay of Proceedings.

11.5. Attributes of Groups

Entity

Group


Authority The Owning Authority of the group.

State group id The identifier of the group, as assigned by the Owning Authority.

Name The name of the group.

Type The type of group, e.g. partnership or syndicate.

Member

Full name The name of the member.

Is manager Indicates whether the person is the manager of the group.

From date The date the group was created.

Person link Link to the person.

`



12. Appendix: Description of Types

The Logical Data Model (Section 4.1) specifies a type for each attribute. These types are listed in the tables below.

12.1. Basic Types

The following basic types are considered self-explanatory:

Boolean

Date

Time

String

Integer

Decimal

12.2. Types used across Entities

The following enumerated types are restricted to the Possible Values listed in the table:

Type Possible Values

Authority Type ACT, NSW, NT, NZ, QLD, SA, TAS, VIC, WA, GA

12.3. Types relating to Dogs and Litters



Gender Dog, Bitch, Hermaphrodite

The following types are Strings of limited length:

Type Based on Restriction

Earbrand Type String Maximum 250 characters

Dog Name Type String Maximum 250 characters

`



Each of the following tables defines a single enumerated type, and provides a description, whether a trial is required and whether a Track-specific trial is required for each possible value:


Description Trial Required?

Track-specific trial

required?

(Information only)

Dog Penalty

Code

F1 Marring (1st Offence) Yes Yes

F2 Marring (2nd Offence) Yes Yes

F3 Marring (3rd Offence) Yes Yes

IL Illness - -

IN Injury - -

N1 Failing to pursue (1st Offence) Yes Yes

N2 Failing to pursue (2nd Offence) Yes Yes

N3 Failing to pursue (3rd Offence) Yes Yes

NI Failing to pursue - injured Yes Yes

NP Not Presented - -

SE Seasonal - -

SI Subject to inquiry - -

TR Transferred - -

UP Unsatisfactory Performance Yes Yes

WV Weight Variation - -

TB Turned in Boxes / Box manners Yes Yes

WT Whelping Trial Yes No

NW Nomination Withdrawal - -

NR No Registration Papers/Card - -

SP Stewards Permission (with stand-down)

- -

SS Stud Service - -

WS Withdrawal by Stewards - -

UB** Unsatisfactory behaviour ** Yes No

VE Veterinary endorsed condition Yes No

CR Cramping Yes No

OT Other - -

VC Vet certificate required - -

** Note: UB - Suggest to proceed with Yes & No for now.

`



RWWA will propose a rule amendment for 2014 to ensure the trial requirements for the UB penalty are specified in the rules. It appears the UB penalty may have been added via R71(A), without R72 being updated to include the exclusion of a venue-specific trial for this new penalty type.

R71(A) quotes a ‘conditional satisfactory trail’. If Stewards wish to make it venue-specific, they can always use a UP penalty instead, which is venue-specific.

Type Possible Values Description

Service Status Type Active Service has occurred.

Missed Expected whelping data has passed, but no pups have been

born.

No Live Pups Pups were born, but none survived until notification of

Whelping.

Whelped Whelping has occurred, and at least one pup survived until

notification of Whelping.

Invalid The record contains invalid data,

and should be ignored.


Service Type Natural Natural Service.

FSI Frozen Semen Service.

Unknown Type of Service is unknown.

(Used to record the litters of international dogs).


Dog Grade Type 1 Grade 1

2 Grade 2

3 Grade 3

4 Grade 4

5 Grade 5

6 Grade 6

M Maiden

G Graduation

J Juvenile

`




Q Qualify

N Novice

Type

Dog Marking Type

Possible Values Description Possible Values Description

U Unknown LTF Light Fawn

BD Brindle LTFW Light Fawn & White

BDW Brindle & White RBD Red Brindle

BDWT Brindle & White Ticked RBDW Red Brindle & White

BE Blue RF Red & Fawn

BEBD Blue Brindle RFW Red Fawn & White

BEBDW Blue Brindle & White W White

BEDUN Blue Dun WBD White & Brindle

BEF Blue Fawn WBDT White with Brindle Ticking

BEFW Blue Fawn & White WBE White & Blue

BEW Blue & White WBEBD White & Blue Brindle

BK Black WBEF White & Blue Fawn

BKBD Black Brindle WBET White with Blue Ticking

BKBDW Black Brindle & White WBK White and Black

BKW Black & White WBKBD White & Black Brindle

DKBD Dark Brindle WBKBE White Black & Blue

DKBDW Dark Brindle & White WBKT White with Black Ticking

DKF Dark Fawn WDKBD White and Dark Brindle

DKFW Dark Fawn & White WDKF White and Dark Fawn

DUN Dun WDUN White and Dun

DUNB Dun Brindle WF White and Fawn

DUNF Dun Fawn WFT White with Fawn Ticking

DUNW Dun & White WLTBD White and Light Brindle

F Fawn WLTF White and Light Fawn

FBD Fawn Brindle WRBD White and Red Brindle

FW Fawn & White WRF White and Red Fawn

LTBD Light Brindle WDUNBD White and Dun Brindle

`



Type

Dog Marking Type


LTBDW Light Brindle & White DUNBDW Dun, Brindle and White

Dog Lifestate is a complex type, consisting of a status, sub status, and further information:

Type Status Sub Status Further Information

Possible Values

(for Further Information)

Dog

Lifestate

Unnamed (none) (none) (none)

Racing (none) (none) (none)

Retired Pet Keeper owner

trainer

third party

Breeding Keeper owner

leased

GAP (none) (none)

Surrendered to another agency

(none) (none)

Exported (none) (none)

Other (none) (none)

Deceased Euthanised Reason injury

unsuitable for rehousing

lack of ability

at track

other

Natural Causes (none) (none)

Accident (none) (none)

`



Type Status Sub Status Further

Information

Possible Values

(for Further Information)

Other (none) (none)

The following table defines a single multi-field type:

Type Field Type Description

FSI Details Type Inseminator String The individual (typically a vet) who performed the insemination.

Facility String The name of the facility where the insemination was performed.

Breeding Unit Service Set

Sequence of Strings

The IDs of the Breeding Units.

Trial Required Type

A Dog Penalty may or may not require a trial to be completed,


Trial Required Type Track Track Code Type Optional.

Code of the track where the

penalty was imposed and where the trial is required to be

performed.

Track Expiration Date

Date Optional.

Date the dog penalty expires at the originating track.

Distance Integer Optional. Not used by all states.-eg. Not used by Vic, but are required for SA and WA.

Distance (in meters) the trial is required to be conducted over to to meet Penalty Clearnace requirements.

Dog Trial Type


Dog Trial Type Authority Authority Type The authority which posted the

`




trial to the NDR

Track Track Code Type Mandatory.

The code of the track where the trial was performed.

Date of Trial Date Mandatory.

The date the trial was performed.

Distance Integer Mandatory.

The distance of the trial.

Field

Trial Field Type

Mandatory.

The number of runners in the

trial,.

Box No Integer Mandatory.

The number of the box where the

dog started the trial.

Weight Decimal Optional.

The weight of the dog.

Time Decimal Optional.

The time achieved by the dog in the trial.

Place

Either Finished Result Type

or Other Result

Type can be

entered.

Optional.

The place achieved by the dog in the trial.

Margin Margin Type Optional.

The margin of the dog with respect to the winner of the trial.

Trial Reason Trial Reason Type Mandatory.

The reason a trail was required.

Trial Result Trial Result Type Mandatory.

Whether the Trial was successful (pass) or not (fail).

`



Dog Penalty Clearance Type

Multiple Dog Penalty Clearance rows may be created for a single Dog Penalty.

For example, multiple Dog Penalty Clearance rows may be required when a Clearance Type is Cleared all tracks except originating track (CATEX). In this case a second row may be created to record the fact that a trial was run at the originating track and the Clearance Type is now Cleared All Tracks (CAT).


Dog Penalty Clearance Type

Track Track Type Mandatory.

The track at which the Clearance Type is recorded. This will assist when looking for the completed clearance trial.

Cleared date Date Mandatory.

The date the dog is partially or completely cleared of the penalty.

Clearance Code Penalty Clearance Code Type

Mandatory.

Whether the clearance covers all tracks or all except the originating track.

For further clearance conditions, such as distance, each state can assess the trial results.


Trial Reason ST Satisfactory

CR Cramping

WH Whelping

WV Weight Variation

EX Exhibition

BN Blinkers on

BF Blinkers off

VE Veterinary endorsed condition

UB Unsatisfactory behaviour

BM Box manners

`




Trial Field S Solo

F Field


Trial Result P Pass - trial was successful.

F Fail - trial was unsuccessful.

(Dog) Penalty Clearance Code Type

A Dog Penalty may or may not have one or more Dog Penalty Clearances.


Penalty Clearance Code Type CATEX

Cleared All Tracks – except originating Track

Dog is cleared of penalty and can race at all tracks - except the originating track that applied the penalty.

CAT Cleared All Tracks

Dog is cleared of penalty and can race at all tracks.


Penalty Status Type

1 Issued. The normal status.

2 Stayed. Indicates an appeal is in process.

To record a stay, update the Stayed From Date and change the status to ‘Stayed’. To remove the stay, set the Stayed From Date to null and changed the status back to ‘Issued’ or ‘Quashed’.

3 Quashed. For Quashed Penalties update the status to “Quashed” and update the Expiration Date to the date it was quashed.

`



12.4. Types relating to Meetings and Races

Each of the following tables defines a single enumerated type, and provides a description for each possible value:



PIR String Maximum 5 characters

Comments String Maximum 40 characters


Meeting Type 1 TAB

2 Non-TAB

3 Qualifying


Meeting Slot Type M Morning

D Day

T Twilight

N Night


Rug Type 1 Rug 1

2 Rug 2

3 Rug 3

4 Rug 4

5 Rug 5

6 Rug 6

7 Rug 7

8 Rug 8

`




9 Rug 9

10 Rug 10


Box Type 1 Box 1

2 Box 2

3 Box 3

4 Box 4

5 Box 5

6 Box 6

7 Box 7

8 Box 8


Prize Code Type 1 Owners & Breeders incentive

2 Breeders

3 Trophy

4 (undefined)


Finished Result Type 1 1st Place

2 2nd Place

3 3rd Place

4 4th Place

5 5th Place

6 6th Place

7 7th Place

8 8th Place

1= Equal 1st

2= Equal 2nd

3= Equal 3rd

4= Equal 4th

`




5= Equal 5th

6= Equal 6th

7= Equal 7th


Other Result Type T Tailed Off

P Pulled Up

F Fell

D Disqualified

B Stayed in Box


Non Started Result Type S Scratched

R Reserve

N No Race

A Abandoned

NS Non-Starter

`



Type

Track Code type

Code Track State (info only) Code Track State (info only)

DAR Winnellie Park NT

ALB Albury NSW APP Appin NSW

ARM Armidale NSW BAT Bathurst NSW

BUL Bulli NSW BHL Broken Hill NSW

CAS Casino NSW CES Cessnock NSW

CON Coonabarabran NSW COO Coonamble NSW

COT Cootamundra NSW COW Cowra NSW

DTO Dapto NSW DUB Dubbo NSW

FOR Forbes NSW GBN Goulburn NSW

GOS Gosford NSW GRA Grafton NSW

GRF Griffith NSW GUN Gunnedah NSW

HPK Harold Park NSW KEM Kempsey NSW

LIS Lismore NSW LIT Lithgow NSW

MAT Maitland NSW MOR Moree NSW

MVL Moss Vale NSW MUD Mudgee NSW

MUS Muswellbrook NSW NAR Narrabri NSW

NCL Newcastle NSW NOW Nowra NSW

ORG Orange NSW PEN Penrith NSW

PPK Potts Park NSW QBN Queanbeyan NSW

RIC Richmond NSW SIG Singleton NSW

TAM Tamworth NSW TAR Taree NSW

`



Type

Track Code type


TEM Temora NSW GAR The Gardens NSW

TWH Tweed Heads NSW WAG Wagga Wagga NSW

WAU Wauchope NSW WEN Wentworth NSW

WPK Wentworth Park NSW WOL Wollongong NSW

WYG Wyong NSW YNG Young NSW

ACT Canberra ACT

BAL Ballarat VIC BEN Bendigo VIC

CRN Cranbourne VIC GEL Geelong VIC

HVL Healesville VIC HOR Horsham VIC

SLE Sale VIC SAN Sandown Park VIC

SHP Shepparton VIC MEA The Meadows VIC

TRA Traralgon VIC WTA Wangaratta VIC

WGL Warragul VIC WBL Warrnambool VIC

BGC Albion Park QLD BEE Beenleigh QLD

BUN Bundaberg QLD CAI Cairns QLD

CAP Capalaba QLD GAB Gabba QLD

GCT Gold Coast QLD IPS Ipswich QLD

LAW Lawnton QLD AYR Ayr QLD

MCK Mackay QLD MTI Mt Isa QLD

ROC Rockhampton QLD TOW Townsville QLD

`



Type

Track Code type


TWB Toowoomba QLD

APK Angle Park SA BAR Barmera SA

GAW Gawler SA KUL Kulpara SA

MTG Mount Gambier SA PTA Port Augusta SA

PTL Port Lincoln SA PTP Port Pirie SA

STR Strathalbyn SA WHY Whyalla SA

CAN Cannington WA MAN Mandurah WA

NOR Northam WA

DEV Devonport TAS HOB Hobart TAS

LCN Launceston TAS

ASH Ashburton NZ AUK Auckland NZ

CCH Christchurch NZ MAW Manawatu NZ

OTG Otago NZ PNN Palmerston

North

NZ

SOU Southland NZ TAK Taranaki NZ

TOK Tokoroa NZ WAN Wanganui NZ

WAK Waikato NZ WAI Wairarapa NZ

WEL Wellington NZ ADD Addington NZ

`



Type

Track Code type


INT International Other

Type

Race Grade Type


1 Grade 1 X12 Mixed 1/2




5 Grade 5 X45H Mixed 4/5 Heat

5Q Grade 5 Quali X45F Mixed 4/5 Final

5QF Grade 5 Quali Final X123 Mixed 1/2/3

FFA Free for All X12NP Mixed 1/2 Non Penalty

FFANP Free for All Non Penalty X23NP Mixed 2/3 Non Penalty

I Invitation X34NP Mixed 3/4 Non Penalty

J Juvenile X45NP Mixed 4/5 Non Penalty

X345 Mixed 3/4/5 X234 Mixed 2/3/4

M Maiden 5NP Grade 5 Non Penalty

MSF Maiden Semi Final 5NPH Grade 5 Heat Non Penalty

MHH Maiden Heat (Half Stakes) 4NP Grade 4 Non Penalty

MF Maiden Final 3NP Grade 3 Non Penalty

MH Maiden Heat 2NP Grade 2 Non Penalty

MQH Maiden Quali Heat 1NP Grade 1 Non Penalty

MQF Maiden Quali Final NNP Novice Non Penalty

5N Novice Grade 5 5F Grade 5 Final

NNP Novice Non Penalty MH Maiden Heat

NNPH Novice Non Penalty Heats 5H Grade 5 Heat

NH Novice Heat 5QH Grade 5 Quali Heat

`



Type

Race Grade Type


HCP Handicap SH Special Event Heat

S Special Event SSF Special Event Semi Final

SH Special Event Heat AAX All Age Mixed

SF S/E Final HDL Hurdle

GRP1 S/E Group 1 B8 Best Eight

GRP2 S/E Group 2 GRAD Graduation

GRP3 S/E Group 3 N Novice

GL S/E Group Listed JG Juvenile Graduation

SNP S/E No Penalty RWNP Restricted Win Non Penalty

X Mixed RWH Restricted Win Heat

XM5 Mixed M/5 O Open

SHNP Special Event Heat Non Penalty T3-M Tier 3 Maiden

NF Novice Final XM6 Mixed Maiden Grade 6

6Q Grade 6 Quali MJ5 Maiden Juvenile Grade 5

X45M Mixed Grade 5 Grade 5 Maiden 2Q Grade 2 Quali

C Consolation T3-5H Tier 3 Grade 5 Heat

VET Special Event Veteran 3Q Grade 3 Quali

JM Juvenile Maiden 4Q Grade 4 Quali

AMM Maiden QF Qualifying Final

GQ Graduation Quali T3-5 Tier 3 Grade 5

6 Grade 6 RWF Restricted Win Final

RW Restricted Win XMG Mixed Maiden Graduation

XP Mixed Non Penalty VETH Veteran Heat

VETF Veteran Final 2F Grade 2 Final

3F Grade 3 Final 4F Grade 4 Final

XRA Mixed Restricted Age XRAF Mixed Restricted Age Final

XRAQ Mixed Restricted Age Quali

Each of the following tables defines a single multi-field type:


`




Race Results Info Type Win Time Decimal Winning time.

Split1 Decimal Time recorded for 1st split.

Split1RugNo Integer Rug number of the dog that set the 1st split time

Split2 Decimal Time recorded for 2nd split.

Split2RugNo Integer Rug number of the dog that set

the 2nd split time

Split3 Decimal Time recorded for 3rd split.

Split3RugNo Integer Rug number of the dog that set the 3rd split time

`



12.5. Types relating to Persons and Groups



Title Type Mr, Mrs, Miss, Ms, Dr, Prof

State Type ACT, NSW, NT, NZ, QLD, SA, TAS, VIC, WA, INTL



Party Name Type String Maximum 250 characters

Phone Type String A 10 digit number commencing

with a “0” (domestic)

Or

A “+” followed by an arbitrary

number of digits (international)

Each of the following tables defines a single multi-field type:

Type Field Type

Person Name Type Title Title Type

First Name String

Middle Init String

Surname String

Type Field Type

Address Type Street String

Suburb String

State String

Postcode String

Country String

`



Each of the following tables defines a single enumerated type, and provides a description for each possible value:


Person Registration Type 0 Unregistered

1 Trainer

2 Owner


Person Penalty Code 1 Defaulter

2 Suspended

3 Disqualified

4 Subject to Inquiry

5 Not be licensed

6 Warned Off


Group Type S Syndicate

P Partnership

`



12.6. Types relating to Events

The following table defines a single multi-field type:


Event Details Type Owning Authority Authority Type The Owning Authority of the

Entity, after the Event.

Transaction Authority

Authority Type The authority which initiated the Event (e.g. by updating the

Entity.)

Previous Authority Authority Type The Owning Authority of the

Entity, prior to the Event.

Event Type Event Type The type of Event.

Name String The name of the Entity.

Old Name String The previous name of the Entity

(populated in case the Event related to the renaming of the

Entity).

Description String A free text description of the event.

The following table defines a single enumerated type, and provides a description for each possible value:

Type Possible Values Entity Business Operation

(per Section 5.1 )

Event Type

DogNew Dog Create

DogUpdate Dog Update

DogUpdatedBySupport Dog Update (NDR Admin Support Team)

DogUpdateEarbrand Dog Update

DogUpdateTrainer Dog Update (trainer)

DogUpdateOwner Dog Update (owner)

DogUpdatePenalty Dog Update (penalty) – create a new penalty

DogUpdateSire Dog Update (studsire)

DogUpdateMicrochip Dog Update (microchip)

DogUpdateCertificate Dog Update (certificate)

DogUpdateLifestate Dog Update (lifestate)

DogUpdateLitterLink Dog Update (Dog)

DogUpdateAuthorityToBreed Dog Update (authority to breed)

`



Type Possible Values Entity Business Operation

(per Section 5.1 )

DogName Dog Update (name)

DogUpdateRaces Dog Update (Meeting)

DogDna Dog Update (dna)

LitterNew Litter Create

LitterUpdate Litter Update

LitterUpdatedBySupport Litter Update (NDR Admin Support Team)

LitterUpdateWhelping Litter Update (whelping)

LitterUpdateDogLink Litter Update (Litter)

MeetingNew Meeting Create

MeetingUpdate Meeting Update

MeetingUpdatedBySupport Meeting Update (NDR Admin Support Team)

PersonNew Person Create

PersonUpdate Person Update

PersonUpdatedBySupport Person Update (NDR Admin Support Team)

PersonMove Person Update (authority)

PersonUpdatePenalty Person Update (penalty) – create a new penalty

PersonUpdateGroupMembership Person Update

GroupNew Group Create

GroupUpdate Group Update

GroupUpdatedBySupport Group Update (NDR Admin Support Team)