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

Greyhounds Australasia

National Data Repository (NDR) Interface Dependency Agreement

Document ID:

Version: 1.6.5

Date: 13 February 2017

Status: Approved – with Updates

`

Commercial-In-Confidence

NDR - Interface Dependency Agreement – v1.5.2 – 10 April 2013 of 113

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 .................................................................................................... 11

2. Introduction .......................................................................................................... 12

2.1. Document Purpose ..................................................................................................... 12

2.2. Intended Audience ..................................................................................................... 12

2.3. Document Scope ........................................................................................................ 12

2.4. Guiding Principles....................................................................................................... 12

2.5. Decision Register ....................................................................................................... 13

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 .................................................................................................................. 59

5.7. Status Codes ............................................................................................................. 60

6. End to End Scenarios .......................................................................................... 62

`



6.1. Success Scenarios ...................................................................................................... 62

6.2. Failure Scenarios ........................................................................................................ 66

7. Backwards Compatibility .................................................................................... 69

7.1. Operation .................................................................................................................. 69

7.2. Existing NDR files ....................................................................................................... 69

7.3. Legacy Unknown Data ................................................................................................ 71

8. Definitions, Acronyms and Abbreviations ........................................................ 72

9. Reference Documents ......................................................................................... 73

10. Appendix: Use of ETags ..................................................................................... 74

11. Appendix: Description of Attributes .................................................................. 76

11.1. Attributes of Dogs ...................................................................................................... 76

11.2. Attributes of Litters .................................................................................................... 78

11.3. Attributes of Meetings ................................................................................................ 79

11.4. Attributes of Persons .................................................................................................. 83

11.5. Attributes of Groups ................................................................................................... 84

12. Appendix: Description of Types ......................................................................... 85

12.1. Basic Types ............................................................................................................... 85

12.2. Types used across Entities .......................................................................................... 85

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

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

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

12.6. Types relating to Events ........................................................................................... 112

`



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.

`




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 0 and the schema types.xsd.

• At the request of Queensland: Added Novice to Dog Grade Type. Affects Section 0 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, 0 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 0, 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, 0, 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 0, 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 0-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.5.2 April 10 2013 Gayle Martin • In order to retain the pedigree of imported dogs, the NDR schema has been updated and the following fields added: o DOG.OWNER.“internationalUnknownParty”

LITTER.BREEDER. “internationalUnknownParty” • These field values can only be set by GA when

recording the importation of an international dog and its related pedigree. If either the DOG.OWNER. “internationalUnknownParty” or LITTER.BREEDER.“internationalUnknownParty” values are set to TRUE, the value “UNKNOWNINTERNATIONALPERSON” will be recorded in the corresponding name field of the Internationally-bred DOG Owner and LITTER Breeder in the NDR.

• Dog Penalty and Dog Trial changes.

1.5.3 August 30 2013 Matt Liu • Added split1, split2, split3 in dogOtherResult on Meeting type.

• Added split1, split2, split3 in dogRaceResult on Meeting type.

• Added entity status to support soft delete for Dog, Litter, Meeting, Person and Group.

• Added international tracks on Meeting type. • Added race grade types for New Zealand meeting. • Added dog grade types for New Zealand meeting. • Added service state in litter FSI details.

1.5.3 October 24 2014 Helal Futloo • Added Grade 6 & 7 race types • Grade 7 for dog

1.5.6 February 6 2015 Helal Futloo • Added new race grades Restricted Win Qualifying Heat and Restricted Win Qualifying Final for Victoria Grade 6 & 7

`




1.5.7 February 26 2015 Helal Futloo • Added new race grades Mixed 6/7 Heat and Mixed 6/7 Final

1.6.1 November 6 2015 Helal Futloo • Added new race grades M123, M123H,M123F, 6NP, XM5NP ,M

1.6.2 June 9 2016 Helal Futloo • XM6NP,XM6NPH,XM6NPF

1.6.3 1st July 2016 Helal Futloo • Mixed 4/5/6, Mixed 4/5/6 Heat, Mixed 4/5/6 Final

1.6.4 8 December 2016 Helal Futloo •

1.6.5 13 February 2017 Derek Baird • Addded new race grade types MAF and MAH

1.4. Stakeholder Signoff

Name Title Sign-Off Received (Version)

Date

Craig Taberner CEO GA

Andrew Gibson Technology and eBusiness Manager - GRV

1.5.2 10/04/2013

Mark Bottcher Manager Greyhound Racing Racing and Wagering Western Australia (on behalf of NSW, WA)

1.0 23/12/2011

Stuart Cashen NZGRA 1.0 7/12/2011

David Rowan GRQ 1.0 8/12/2011

`



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/2103

28 For the sake of dog Pedigree in the NDR, change the NDR schema to allow “UnknownInternationalPerson” to be stored against an Internationally-bred dog as an Owner.

As dog Owner is mandatory, this allows the parents of imported dogs to be recorded in the NDR for the sake of Pedigree – without having to know the owners details.

This means the UnknownInternationalParty will not be displayed as part of previous Owner History of a DOG.

27/03/2013

29 To soft delete incorrect entities created in NDR, change the NDR schema by adding in “entityStatus” to indicate if an entity is deleted.

Only owning authority of the entity can perform this action.

`



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.

10 Only the owning authority can update the entity status.

`



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


Dog does not exist


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

Dna component The URL for the updated Dog

Dog does not exist

`




Permitted Authority



Error Condition

Error Response

Entity. Item not found error

Update (studsire)

GA earbrand POST /dog/<earbrand>/studsire

Studsire component


Dog does not exist


Update (lifestate)

Any earbrand POST /dog/<earbrand>/lifestate

Lifestate component


Dog does not exist


Update (microchip)

Any earbrand POST /dog/<earbrand>/microchip

Microchip component


Dog does not exist


Update (certificate)

Any earbrand POST /dog/<earbrand>/certificate

Certificate component


Dog does not exist


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

Dog does not

`




Permitted Authority



Error Condition

Error Response

(owner) >/owner component Entity. exist


Update (trainer)

Any earbrand POST /dog/<earbrand>/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)


Dog does not exist


Update (penalty) – add a new penalty

Any earbrand POST /dog/<earbrand>/penalty

Penalty component


Dog does not exist


Update (penalty) – modify an

Any earbrand

penalty code

POST /dog/<earbrand>/penalty

Penalty component

The URL for the updated Dog

Dog does not exist

`




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


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)

Any earbrand POST /dog/<earbrand>/authoritytobreed

Breeder component


Dog does not exist

Item not found

`




Permitted Authority



Error Condition

Error Response

error

Update (trial) – add a new trial

Any earbrand POST /dog/<earbrand>/trial

Trial component The URL for the updated Dog Entity.

Dog does not exist


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

Trial component The URL for the updated Dog Entity.

Dog does not exist


Update (entity status)

Owning Authority Earbrand POST /dog/<earbrand>/entitystatus

Entity status component


Dog does not exist


`



5.1.2. Litter API


Permitted Authority



Error Condition

Error Response

Create Any Sire earbrand

Dam earbrand

Service date

POST /litter/<sire_earbrand>/<dam_earbrand>/<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_earbrand>/<service_date>

A Litter Entity The URL for the updated Litter Entity.



Update (whelping)

Any Sire earbrand

Dam earbrand

Service date

POST /litter/<sire_earbrand>/<dam_earbrand>/<service_date>/whelping

Whelping component

The URL for the updated Litter Entity.



Get (entity) Any Sire earbrand

Dam earbrand

Service date

GET /litter/<sire_earbrand>/<dam_earbrand>/<service_date>

- The matching Litter Entity.

Litter does not exist


`




Permitted Authority



Error Condition

Error Response

Get (entity) Any Sire earbrand

Dam earbrand

Service date

GET /litter/<sire_earbrand>/<dam_earbrand>/<service_date>/n

- The matching Litter Entity for version number n.



Get (metadata)

Any Sire earbrand

Dam earbrand

Service date

GET /litter/<sire_earbrand>/<dam_earbrand>/<service_date>/meta

- Metadata for the matching Litter Entity.




Owning Authority Sire earbrand

Dam earbrand

Service date

POST /litter/<sire_earbrand>/<dam_earbrand>/<service_date>/ entitystatus


The URL for the updated Litter Entity.



`



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).


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_code>/<date>/<time_slot>

A Meeting Entity The URL for the new/updated Meeting Entity.

Track doesn’t exist


Get (entity) Any Track code

Meeting date

Meeting time slot

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

- The matching Meeting Entity.

No meeting found


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

`




Permitted Authority



Error Condition

Error Response

error.

Get (metadata)

Track code

Meeting date

Meeting time slot

GET /meeting/<track_code>/<date>/<time_slot>/meta

- Metadata for the matching Meeting Entity.

Meeting does not exist



Owning Authority Track code

Meeting date

Meeting time slot

POST /meeting/<track_code>/<date>/<time_slot>/entitystatus


The URL for the updated Meeting Entity.

No meeting found


`



5.1.4. Person API


Permitted Authority



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.



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)

POST /person/<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)



Update (penalty) – add a new penalty

Any State

State person id

POST /person/<state>/<state_person_id >/penalty

A Person penalty component

The URL for the updated Person Entity.



`




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




Get (entity) Any State

State person id

GET /person/<state>/<state_person_id>

- The matching Person Entity.

No matching person



State person id

GET /person/<state>/<state_person_id>/n

- The matching Person Entity for version number n.

No matching person


Get (entity) – when the Person

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

- The URL for the updated Person

No matching

`




Permitted Authority



Error Condition

Error Response

has moved state State person id

(of the old state)

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

person


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



Owning Authority State

State person id

POST /person/<state >/<person_state_id>/entitystatus



State / Person Id does not exist


`



5.1.5. Group API


Permitted Authority



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.



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



State group id

GET /group/<state>/<state_group_id>/n

- The matching Group Entity for version number n.

No matching group


`




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


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)




Owning Authority State

State person id

POST /group/<state>/<state_group_id >/entitystatus


The URL for the updated Group Entity.

State / Group Id does not exist


`



5.1.6. Events API


Permitted Authority



Error Condition

Error Response

Get (events) Any - GET /events/<date>* - Atom feed of events for the specified date.

No events found

Atom feed is 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.2 –10 April 2013 of 113

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:

`



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>”

where <ETag> corresponds 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>”

where <ETag> corresponds 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>”

where <ETag> corresponds 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

Dog –Entity status Update(dog entity status) dog_update_entity_status.xsd

Litter – Whelping Update (whelping) litter_whelping.xsd

Litter – Entity status Update(litter entity status) litter_update_entity_status.xsd

Person – Owning Authority

Update (Owning Authority) person_owningauthority.xsd

Person – Penalty Update (penalty) person_penalty.xsd

Person – Entity status

Update(person entity status) person_update_entity_status.xsd

Group – Entity status Update(group entity status) group_update_entity_status.xsd

Meeting – Entity Update(meeting entity status) meeting_update_entity_status.xsd

`



Business Operation

(refer Section 5.1)

Component

status

`



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.4. Importation of an International dog GA records the importation of international dogs into Australia and therefore is the owning

authority of the dog.

As the Owner of a dog is a mandatory field in the NDR, an international dog must be recorded in

the NDR with:

1. an Owner who is a registered participant with a racing authority of Australasia. Eg. RWWA, GRV, NZ

or

2. set to Dog Owner Name to UnknownInternationalParty

ie. This will display “UNKNOWNINTERNATIONALPERSON” (for the Owner or Breeder of an International

dog and Litter) in the NDR. This enables the pedigree of international dogs, created by GA, to be

created in the NDR (where the Owner of a dog and the Breeder of a litter is mandatory).

As the whelped date or the pedigree of the Sire and Dam of an imported dog is not always

known, the Sire and Dam’s whelped dates may be optionally entered.

`



This is a GA only 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

DOG.Owner may be set to UnknownInternationalParty (displayed as “Unknown

International Person” in the NDR)

LITTER.Breeder may be set to UnknownInternationalParty (displayed as “Unknown

International Person” in the NDR).

Note: An UnknownInternationalParty will not be displayed as part of previous Owner History for a

DOG.


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.

(OR set DOG.Owner

UnknownInternationalParty to true

“UNKNOWNINTERNATIONALPERSON” will. be displayed for Internationally-bred dog Owners in the NDR. )

5 Person is assigned as dog’s Owner in GA.

Create Dog Dog is created in NDR with Owner assigned OR Owner UnknownInternationalParty is set to true. “UNKNOWNINTERNATIONALPERSON” (for Internationally-bred dog Owners.) is displayed in the NDR.

6 The State Body receives updates from the NDR.

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

`



6.1.5. Deletion of a dog Any owning authority is able to delete dog(or any other entity) via “entityStatuss” operation.

It is a soft delete, meaning that the dog is still physically exist in NDR and it only marked as delete within the “entityStatus” element.

Once the entity is marked as “deleted” the NDR should prevent any other transactions to update the “deleted” entity. However, NDR is not stopping any other entities from referencing the “deleted” entity.

Following table shows the steps to delete a dog from NDR


1 Dog is created by owning authority

Create dog

2 Dog is identified as a invalid via state body

-

3 Owning authority delete the dog in local system

-

4 Owning authority delete the dog in NDR

entityStatus(Dog) Dog updated in ndr with “entityStatus” =“delete”

5 Other state body will be notified

Get(Event) “DogUpdateEntityStatus“ in the atom feed will indicate the change of the entity status

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

• 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)

`




e.g. due to network failure.

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.

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:

3. TrainerState must be supplied 4. StateTrainerID must be supplied where the trainer is from the state uploading the RF file 5. 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 To support backwards compatibility for this file, the following must be observed:

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 To support backwards compatibility for this file, the following must be observed:

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 b. PersonID must be supplied where the state is the same as the state uploading

the PR file c. All other existing rules for the PG record will apply

3. GM Group Member 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 GM record will apply

7.2.5. LD – Litter Detail To support backwards compatibility for this file, the following must be observed:

`



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+Document.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/attachments/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

`



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:


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.


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.



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.



where <ETag> is up-to-date.

An Entity 201 Created

Includes a new ETag, corresponding 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.


An Entity 412 Precondition Failed


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.



where <ETag> is NOT up-to-date.

An Entity 412 Precondition Failed


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 OR “UNKNOWNINTERNATIONALPERSON” if the flag UnknownInternationalParty is set to true

`



Entity

Dog


Unknown InternationalParty

May be set to true. A null value implies false.

From date The date that the owner commenced owning the 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.

`



Entity

Dog


Indicates whether a trial is required to clear the penalty, and specifies which track the trial must be performed it.

Penalty Clearance (Type)

Optional. 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.

Dam Registration state • State in which the registration is made

registrationDate • Date when the registration is made

Exemptions • There may be one or more exemptions

Vaccinations state •

date •

Vaccination Type •

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.

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 OR “UNKNOWNINTERNATIONALPERSON” if the flag Unknown InternationalParty is set to true

Unknown InternationalParty

May be set to true. A null value implies false.

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 /

`



Entity

Meeting


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.

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.

Split1 The first split time recorded of the dog

Split2 The second split time recorded of the dog

Split3 The third split time recorded 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.

`



Entity

Meeting – continued

Sub Sub Attribute Sub Sub Sub Attribute

Description

Split1 The first split time recorded of the dog

Split2 The second split time recorded of the dog

Split3 The third split time recorded 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 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.

Active An active status of a Group is removed when: 1. number of members in the group < 2

OR

2. One or more members have an active penalty applied.

`



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

Entity Status Active, Deleted

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

`




Description Trial Required?

Track-specific trial required?

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

7 Grade 7

M Maiden

G Graduation

J Juvenile

Q Qualify

N Novice

C5 Grade 1 for New Zealand





C0 Maiden for New Zealand

M1 Masters Grade 1 for NSW



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

`



Type

Dog Marking Type


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

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

`



Type Status Sub Status Further Information

Possible Values

(for Further Information)

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)

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.

ServiceState statetype ACT NSW NT NZ

`




QLD SA TAS VIC WA GA INTL

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

SAP Sandown Provincial

VIC

SHP Shepparton VIC MEA The Meadows VIC

MEP The Meadows Provincial

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

`



Type

Track Code type


LAW Lawnton QLD AYR Ayr QLD

MCK Mackay QLD MTI Mt Isa QLD

ROC Rockhampton QLD TOW Townsville QLD

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

`



Type

Track Code type


TOK Tokoroa NZ WAN Wanganui NZ

WAK Waikato NZ WAI Wairarapa NZ

WEL Wellington NZ ADD Addington NZ

INT International Other

BEL Belle Vue (UK) Other

NBR Newbridge (IRE)

Other

BGH Ballyskeagh (IRE) Other

NOT Nottingham (UK)

Other

CAT Catford (UK) Other NVN Navan (IRE) Other

CBY Canterbury (UK) Other OXF Oxford (UK) Other

CLL Clonmel (IRE) Other PBR Perry Barr (UK) Other

COR Cork (IRE) Other

PET Peterborough (UK)

Other

CRF Crayford (UK) Other

PRB Peterborough (UK)

Other

DBL Derby Lane (USA) Other

PSM Portsmouth (UK)

Other

DLK Dundalk (IRE) Other RED Reading (UK) Other

DUN Dungannon (IRE) Other ROM Romford (UK) Other

ECY Enniscorthy (IRE) Other

RTN Raynham Taunton (USA)

Other

HCR Harolds Cross (IRE)

Other SBP

Shelbourne Park(IRE)

Other

`



Type

Track Code type


HEN Henlow (UK) Other SHE Sheffield (UK) Other

HGN Hall Green (UK) Other

SUN Sunderland (UK)

Other

HKY Hackney (UK) Other SWI Swindon (UK) Other

HOL Hollywood (USA) Other THU Thurles (IRE) Other

HOV Hove (UK) Other TLE Tralee (IRE) Other

KIL Kilkenny (IRE) Other WEM Wembley (UK) Other

LGI Long Island (USA) Other

WFD Waterford (IRE)

Other

LIK Limerick (IRE) Other

WHD Wheeling Downs (USA)

Other

MHH Mile High (USA) Other

WLD Wonderland (USA)

Other

MLG Mullingar (IRE) Other

WLN Wimbledon (UK)

Other

MLK Milton Keynes (UK)

Other WST

Walthamstow (UK)

Other

MON Monmore (UK) Other YGL Youghal (IRE) Other

Type

Race Grade Type


1 Grade 1 X12 Mixed 1/2



`



Type

Race Grade Type



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

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

`



Type

Race Grade Type


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

C0 Maiden for New Zealand CNZ23H

NZ Bred - class 2-3 Heat - penalty free

C0H Maiden Heat for New Zealand CNZ23F NZ Bred - class 2-3 Final - penalty free

C0F Maiden Final for New Zealand CNZ45H NZ Bred - class 4-5 Heat - penalty free

C1 Grade 5 for New Zealand CNZ45F

NZ Bred - class 4-5 Final - penalty free

C1H Class 1 heats for New Zealand CNZ05H NZ Bred - class 0-5 Heat - penalty free

C1F Class 1 final for New Zealand CNZ05F NZ Bred - class 0-5 Final - penalty free

C12 Mixed Grade ½ for New Zealand CNZ02DH

NZ Bred - class 0-2 Distance Heat - penalty free

C2 Grade 4 for New Zealand CNZ02DF

NZ Bred - class 0-2 Distance Final - penalty free

C2H Class 2 heats for New Zealand CNZ02H NZ Bred - class 0-2 Heat (deprecated)

C2F Class 2 Final for New Zealand CNZ02F NZ Bred - class 0-2 Final (deprecated)

`



Type

Race Grade Type


C23 Mixed Grade 2/3 for New Zealand CNZ5H

NZ Bred - class 5 Heat (deprecated)

C3 Grade 3 for New Zealand CNZ5F

NZ Bred - class 5 Final (deprecated)

C3H Class 3 heats for New Zealand CRA Restricted Age - penalty free

C3F Class 3 Final for New Zealand CRAH Restricted Age Heat - penalty free

C34 Mixed 3/4 for New Zealand CRAF Restricted Age Final - penalty free

C4 Grade 2 for New Zealand CRAD

Restricted Age Distance - penalty free

C4H Class 4 heats for New Zealand CRADH Restricted Age Distance Heat - penalty free

C4F Class 4 Final for New Zealand CRADF Restricted Age Distance Final - penalty free

C45 Mixed grade 4/5 for New Zealand CINV Class C1 -5 - penalty free

C5 Grade 1 for New Zealand CINVH Class C1 -5 Heat - penalty free

C5H Class 5 heats CSCANP Special Conditions age - penalty free for New Zealand

C5F Class5 final CSC Special conditions for New Zealand

C0D Maiden Distance CSCH Special conditions Heat

C0DH Maiden Distance Heat CSCF Special conditions Final

C0DF Maiden Distance Final CSCD Special conditions Distance

C1D Class 1 Distance CSCA Special Conditions age - penalty free

C1DH Class 1 Distance Heat CSCAH Special Conditions age Heat - penalty free

C1DF Class 1 Distance Final CSCAF Special Conditions age Final - penalty free

C2D Class2 Distance CSCAD Special Conditions age Distance - penalty free

C2DH Class2 Distance Heat CSCADH Special Conditions age Distance Heat - penalty free

C2DF Class2 Distance Final CSCADF Special Conditions age

`



Type

Race Grade Type


Distance Final - penalty free

CNZ01H NZ Bred - Maiden & Class 1 Heat

CNZ01F NZ Bred - Maiden & Class 1 Final

X65 Mixed 6/5 XM56 Mixed M/5/6

OM Open Maiden MQ Maiden Quali

NG Non Graded

M1 Masters Grade 1

M1H Masters Grade 1 Heat

M1F Masters Grade 1 Final

M2 Masters Grade 2

M2H Masters Grade 2 Heat

M2F

Masters Grade 2 Final

M12

Masters Grade 1/2

M12H

Masters Grade 1/2 Heat

M12F

Masters Grade 1/2 Final

M23

Masters Grade 2/3

M23H

Masters Grade 2/3 Heat

M23F

Masters Grade 2/3 Final

M3

Masters Grade 3

M3H

Masters Grade 3 Heat

M3F

Masters Grade 3 Final

7 Grade 7

7H Grade 7 Heat 7SF Grade 7 Semi Final

7F Grade 7 Final 7QH Grade 7 Qualifying Heat

7QF Grade 7 Qualifying Final 6G Grade 6

6SF Grade 6 Semi Final 6H Grade 6 Heat

6QH Grade 6 Qualifying Heat 6F Grade 6 Final

N7 Novice Grade 7 6QF Grade 6 Qualifying Final

`



Type

Race Grade Type


X67 Mixed 6/7

T3-6 Tier 3 Grade 6 T3-7 Tier 3 Grade 7

RWQH Restricted Win Qualifying Heat RWQF Restricted Win Qualifying Final

X67H Mixed 6/7 Heat X67F Mixed 6/7 Final

T3-RW Tier 3 - Restricted Win M123 Masters Grade 1/2/3

M123H Masters Grade 1/2/3 Heat M123F Masters Grade 1/2/3 Final

6NP Grade 6 Non-Penalty XM5NP Grade 5/Maiden Non-Penalty

MA Masters MAO Masters Open

MA5 Masters Grade 5 MA45 Masters Mixed 4/5

QT Qualifying Trial XM6NPH Mixed Maiden and Grade 6 (Non-Penalty) Heat

XM6NPF Mixed Maiden and Grade 6 (Non-Penalty) Final

XM6NP Mixed Maiden and Grade 6 (Non-Penalty)

X456 Mixed 4/5/6 X456H Mixed 4/5/6 Heat

X456F Mixed 4/5/6 Final NPW NOVICE PATHWAY PENALTY

NPWNP NOVICE PATHWAY NON-PENALTY

NPWH NOVICE PATHWAY HEAT PENALTY

NPWNPH NOVICE PATHWAY HEAT NON- PENALTY

NPWF NOVICE PATHWAY FINAL PENALTY

NPWNPF NOVICE PATHWAY FINAL NON PENALTY

MAPW MASTER PATHWAY PENALTY

MAPWNP MASTER PATHWAY NON-PENALTY

MAPWH MASTER PATHWAY HEAT PENALTY

MAPWNPH MASTER PATHWAY HEAT NON- PENALTY

MAPWF MASTER PATHWAY FINAL PENALTY

`



Type

Race Grade Type


MAPWNPF MASTER PATHWAY FINAL NON PENALTY

5PW GRADE 5 PATHWAY PENALTY

5PWNP GRADE 5 PATHWAY NON-PENALTY

5PWH GRADE 5 PATHWAY HEAT PENALTY

5PWNPH GRADE 5 PATHWAY HEAT NON- PENALTY

5PWF GRADE 5 PATHWAY FINAL PENALTY

5PWNPF GRADE 5 PATHWAY FINAL NON PENALTY

MDNPW MAIDEN PATHWAY PENALTY

NMWNP NO METRO WINS NON-PENALTY

MDNPWH MAIDEN PATHWAY HEAT PENALTY

NMWNPH NO METRO WINS HEAT NON- PENALTY

MDNPWF MAIDEN PATHWAY FINAL PENALTY

NMWNPF NO METRO WINS FINAL NON PENALTY

NMW NO METRO WINS PENALTY

R5NP RESTRICTED 5TH GRADE NON-PENALTY

NMWH NO METRO WINS HEAT PENALTY

R5NPH RESTRICTED 5TH GRADE HEAT NON- PENALTY

NMWF NO METRO WINS FINAL PENALTY

R5NPF RESTRICTED 5TH GRADE FINAL NON PENALTY

R5 RESTRICTED 5TH GRADE PENALTY

RMDN RESTRICTED MAIDEN PENALTY

R5H RESTRICTED 5TH GRADE HEAT PENALTY

RMDNH RESTRICTED MAIDEN HEAT PENALTY

R5F RESTRICTED 5TH GRADE FINAL PENALTY

RMDNF

RESTRICTED MAIDEN HEAT PENALTY

`



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


Vaccination Type W06 String 6 Week Vaccination.

W12 String 12 Week Vaccination.

M12 String 12 Month Vaccination.

AB String Annual Booster.

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)

DogUpdateTrial Dog Update (trial)

DogUpdateEntityStatus Dog Update(entity status)

DogUpdateDamRegistration Dog Update(DamRegistration)

DogDeleteDamRegistration Dog Delete(DamRegistration)

DogUpdateVaccination Dog Update(Vaccination)

LitterNew Litter Create

LitterUpdate Litter Update

LitterUpdatedBySupport Litter Update (NDR Admin Support Team)

LitterUpdateWhelping Litter Update (whelping)

LitterUpdateDogLink Litter Update (Litter)

LitterUpdateEntityStatus Litter Update (entioty status)

MeetingNew Meeting Create

MeetingUpdate Meeting Update

MeetingUpdatedBySupport Meeting Update (NDR Admin Support Team)

MeetingUpdateEntityStatus Meeting Update (entioty status)

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

PersonUpdateEntityStatus Person Update (entioty status)

GroupNew Group Create

GroupUpdate Group Update

GroupUpdatedBySupport Group Update (NDR Admin Support Team)

GroupUpdateEntityStatus Group Update (entioty status)