National Library of Australia

Trove Party Infrastructure

 

 

Rules for matching party records

for Trove

 

 

 

 

 

 

 

Version 2.0

 

Last updated: 20 January 2012

 

 

 

 


 

 

 

 

 

 

 

 

 

Document History

Title

Version

Last update

Comments

People Australia Requirements Specification for People Australia Harvester Module

1.16

20 May 2010

Original version of the matching rules

Rules for matching party records in Trove for the Trove Party Infrastructure

2.0

20 Jan 2012

Revised as part of the ARDC Party Infrastructure  Project

 


Trove Party Infrastructure

 

Rules for matching party records

 

 

Introduction and background

 

The rules for matching people and organisation records for the Trove Party Infrastructure   are designed to determine if a party record  harvested from a contributor to Trove can be automatically matched with an existing record in Trove or added as a new identity.

 

In Part A, the rules are applied to determine whether the harvested record is the same as an existing record in Trove.

 

Records that fail matching as specified in Part A are passed through the matching rules of Part B.

 

In Part B, the rules are applied to determine whether the incoming  record should be part of an  identity record.

 

In summary:

 

Part A:

Purpose: to decide if two records are actually the same record

An incoming  record is checked to determine if it has the same contributor ISIL and record ID as a record in Trove. If it does, a sanity check is applied. If the incoming  record passes the sanity check, it is automatically matched and  overlays (replaces) the matching record in Trove. If the incoming  record fails the matching rules in Part A then matching rules in Part B are applied.

 

Part B:

Purpose: to decide if a record should be part of an existing identity.

The rules specified in Part B are applied to an incoming record that has failed the matching rules specified in Part A.

 

An incoming record is checked to determine if it has an NLA persistent identifier. If it does, a sanity check is applied and must be passed for a match to occur

Incoming  records that fail the matching rules specified in Part A and B are passed by the identity service to the unmatched record queue for human review for matching or new record creation in  the Trove Identities Manager (TIM) previously called the Party Administration Tool.

 

Extension of matching rules

The ARDC Party Infrastructure Project (January 2010 to July 2011) was tasked with extending the existing People Australia Infrastructure  matching rules to cater for the contribution of party records from the research sector.  A Names Roundtable organised by the ARDC Party Infrastructure Project was held on 18 June 2010 and reflected the following:

 

“The percentage of records without public, persistent identifiers is expected to be initially high as the research sector will be presenting new party records that will not already exist in Trove. Effort associated with creating new records and matching records would require resourcing from contributors. As the quantity of party data from the research sector submitted to Trove increases, automatic matching will improve and the amount of hand matching will subsequently decrease.”

 

Significant concerns were raised by the Roundtable participants about who would do the matching at their institution and how this activity would be funded. In this context, the matching rules were revised in order to reduce the quantity of hand matching required from contributors.

 

As part of the ARDC Party Infrastructure Project, the data format of party records was migrated from EAC 2004 to EAC-CPF. This was completed in May 2011.

 

Summary of changes

These Rules have been and will continue to be revised to achieve the objective of automatically creating and accurately matching identity records for Trove.

 

Changes included:

       Searches restricted to the same entity type, i.e. a “person” or “corporate body”

       Matching on record identifier and the Agency Code (ISIL)

       For records with entity type “person”

       New auto creation rules

       If there are no identities with the exact surname as the incoming record then create a new identity

       For potential matches based on surname, compare first letter of each forename name part and if none match then the identity is not a potential match and therefore a  new identity will be automatically created.


Contents

 

1.               Part A – Rules for matching and updating an existing record in an identity               7

1.1               Check  Contributor ID               7

1.1.1               No record found               7

1.1.2               More than one record found               7

1.1.3               One record found               7

1.2               Sanity Check               7

1.2.1               People Records               7

1.2.2               Organisation records               9

1.3               Part A: Example A: Contributors  ids               10

1.4               Part A: Example B: Surname sanity check               11

1.5               Part A: Example C: No surname sanity check               13

1.6               Part A: Example D: Sanity check – organisation name               15

2               Part B – Rules to match an incoming record to an identity               17

2.1               Using a Persistent Identifier found in the record               17

2.1.1               Check it is not a “disambiguation identity”               17

2.1.2               Perform a Sanity check               17

2.2               Using an identifier found in the record other than recordID               18

2.2.1               Check it is not a “disambiguation identity”               18

2.2.2               Perform a Sanity check               18

2.3               Without using a Persistent Identifier               18

2.3.1               For records which have an entityType of “person”               18

2.3.2               For records which have an entityType of “corporateBody”               21

2.4               Part B: Example A. Surname check.               23

2.5               Part B: Example B. Forename check.               25

2.6               Part B: Example C. First letter of forename check.               26

2.7               Part B: Example D. Corporate name check.               28

2.8               Part B: Example E. Existence date matching               30

2.9               Part B: Flowchart diagrams               31

2.9.1               Part B: Flowchart - No matches on surname               31

2.9.2               Part B: Flowchart - Match on surname, no match on forename or forename initial               32

2.9.3               Part B: Flowchart - Match on surname, match on forename               33

2.9.4               Part B: Flowchart - Record with no localType               34


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


1.                Part A – Rules for matching and updating an existing record in an identity

 

1.1          Check  Contributor ID

Check if the  contributor recordId (eac- cpf/control/recordId ) in the incoming record exactly matches the contributor recordId in an existing record.

 

Check if the contributor agencyCode in (eac- cpf/control/maintenanceAgency/

agencyCode) in the incoming record exactly matches the contributor agencyCode in the existing record 

 

See Part A: Example A: Contributor Record Ids

 

Notes:

       Both recordID (the identifier) and agencyCode ( the ISIL of the contributor of the record) must match.

       The contributors  agencyName is not used in this check.

       Ignore capitalisation (case insensitive).

       Punctuation is significant.

       The OAI id can be used as a  contributor id

 

1.1.1     No record found

If no existing record is found the  incoming record passes to the Part B rules .

1.1.2     More than one record found

If more than one existing record is found, a match / update cannot be applied with certainty and the incoming record passes to the Unmatched records in the Trove Identity manager.

1.1.3     One record found

If one existing record is found, the incoming record passes to the Sanity check, to mitigate the risk of contributors record  ids that overlap.

 

1.2     Sanity Check

1.2.1     People Records

For a record where the value is “person” in the record entity type  (cpfDescription/identity/ entityType) check:

1.2.1.1    Surname

If both records have a name entry part with local type “surname” in the name entry part ( nameEntry/part localType=”surname” )

Check that the value of a name in the incoming  record matches the value of a name in the existing record.

If the incoming record passes this sanity check the incoming record updates the existing record.

 

Notes:

          The recommended values  for the Trove Party Infrastructure for the nameEntry/part locaType for “persons”  are “surname” and  “forename”.

          localType “forename’ is not used in this sanity check.

Other localType values (e.g. title” or “extension”) are not significant

 

 

See Part A: Example B: Surname sanity check

 

1.2.1.2    No surname

If there is no name Entry part with local type “surname” in the incoming record use the 1 st name entry part (with or without local type) encountered in both records

 

Chec k that the value of the 1st nameEntr y part in the incoming  record matches a nameEntry part in the existing record.

 

If the incoming record passes this sanity check the incoming record updates the existing record. 

 

If the sanity check fails , the incoming record passes to the Unmatched  record queue in the Trove Identities Manager. 

 

 

Notes:

         Exist dates are not used in this sanity check.

         Ignore whitespace at the start or end of the name value.

         Ignore capitalisation (case insensitive).

         Punctuation is significant.

         Diacritics are significant (although diacritics encoded in different ways   should be considered the same

 

 

See Part A: Example C: No surname sanity check

 

 

 

 

 

 

 

 

 

 

1.2.2   Organisation records

 

For any record for an organisation name where the value is “ corporateBody ” in the record entity  type (eac- cpfDescription/identity/entityType element with the value corporateBody)

 

Check that the value of all name parts in an organisation name entry in the incoming record matches the values in all name parts in the name entry in an existing  record.

 

If the incoming record has a name entry part localType  check if the 

existing record has a name entry localType

 

Check values if name entry part has localtypes in both records.

 

Notes:

       Order of name parts is not significant.

       Ignore whitespace at the start or end of the name value.

       Ignore capitalisation (case insensitive)

       Articles (e.g. the) are included in the value of  the words in the name parts

       Punctuation is significant

       The check ignores terms in the following list: (punctuation in these terms can be ignored)

       Pty

       Ltd

       Proprietary

       Limited

       existDates are not used in this sanity check.

       name entry part localType is significant. If present must match in both records

       If there are existDates, they must be present and match in both records

          Dates to be ISO-8601 (the universal standard for numerical data) 

          existDates to be in dateRange not  date

          All dates normalised to yyyy-mm-dd (ISO-8601)

          Check the normalised version of the date. Do not attempt to parse the non-normalised

          Use only the first set of existence dates. Only year needs to match, not  month or day

 

 

See Part A: Example D: Sanity check – organisation name .

 

 


1.3     Part A: Example A: Contributors ids

 

Example Record

<control>

<recordId>abcd-1324</recordId>

<maintenanceAgency>

<agencyCode>AU-NUN:DAAO</agencyCode>

</maintenanceAgency>

</control>

 

Matches:

<recordId>abcd-1324</recordId>

<agencyCode>AU-NUN:DAAO</agencyCode>

<agencyName>Dictionary of Australian Artists Online</agencyName>

              Note: Agency name is not included in comparison

 

<recordId>abcd-1324</recordId>

<agencyCode>au-nun:daao</agencyCode>

              Note: Agency code case is not significant

 

<recordId>abcd-1324</recordId>

<agencyCode>AU-NUN:DAAO</agencyCode>

<otherRecordId> daao-1324 </otherRecordId>

              Note: Other record ID is not included in comparison

 

Does Not Match:

<recordId>abcd-1324</recordId>

<agencyCode>AU-NLA:MA</agencyCode>

              Reason: Agency code (ISIL) does not match

 

<recordId>abcd-1324567</recordId>

<agencyCode>AU-NUN:DAAO</agencyCode>

              Reason: Record ID does not match

 

<recordId>abcd-1324</recordId>

<agencyCode>NUN:DAAO</agencyCode>

              Reason: Agency code does not match (uses a different encoding standard)

 

<recordId>abcd-1324</recordId>

<agencyCode>AU-NU:NDAAO</agencyCode>

              Reason: Punctuation in agency code does not match

 

<recordId>daao-1324</recordId>

<agencyCode>AU-NUN:DAAO</agencyCode>

<otherRecordId> abcd-1324</otherRecordId>

              Reason: Other record ID is not included in comparison

 


1.4     Part A: Example B: Surname sanity check

 

Example record

<cpfDescription><identity>

<entityType>person</entityType>

<nameEntry>

<part localType="surname">Brown</part>

<part localType="forename">Jane S.</part>

</nameEntry>

</identity>

 

 

Matches:

<nameEntry>

<part localType="surname">   b rown </part>

<part localType="forename">Jane S.</part>

</nameEntry>

Note: Leading and trailing whitespace is not significant.

Note: Forename is not included.

Note: Case of surname is not significant.

 

 

Does Not Match:

<nameEntry>

<part localType="forename">Jane S.</part>

</nameEntry>

Reason: No surname

 

<nameEntry>

<part localType="surname">Jane S.</part>

<part localType="forename">Brown</part>

</nameEntry>

Reason: Surname is different

 

<nameEntry>

<part localType="surname">Brown e </part>

<part localType="forename">Jane S.</part>

</nameEntry>

Reason: Surname is different

 

<nameEntry>

<part localType="surname">Bro-wn</part>

<part localType="forename">Jane S.</part>

</nameEntry>

Reason: Punctuation in surname is significant

 

 

 

<nameEntry>

<part localType="lastname">Brown</part>

<part localType="forename">Jane S.</part>

</nameEntry>

 

Reason: LocalType is significant.

Note: Lastname is not equivalent to surname.

 


1.5     Part A: Example C: No surname sanity check

 

Example record 1

<cpfDescription><identity>

<entityType>person</entityType>

<nameEntry>

<part localType="forename">Jane S. Brown</part>

</nameEntry>

</identity>

 

Matches:

<nameEntry>

<part localType="forename">Jane S. Brown    </part>

</nameEntry

Note: Ignore trailing, leading whitespace.

 

<nameEntry>

<part localType="surname">Jane S. Brown</part>

</nameEntry

Note: Part type does not have to be the same

 

Does Not Match:

<nameEntry>

<part localType="forename">Jane Brown</part>

</nameEntry>

Reason:  Name part value does not match

 

<nameEntry>

<part localType="forename">Jane S.</part>

<part localType="surname">Brown</part>

</nameEntry>

Reason: First name part does not match

Note: Order of names parts in the record is significant

 

<nameEntry>

<part localType="forename">Jane S. Collins</part>

</nameEntry

Reason: Different forename value

 

 

<nameEntry>

<part localType="forename">J. S. Brown </part>

<part localType="extension">Jane S. Brown</part>

</nameEntry

Reason: local type extension is not included in check  

 

 


Example  record 2

<nameEntry>

<part localType="forename">Kylie</part>

</nameEntry>

 

Matches:

<nameEntry>

<part localType="surname">Kylie</part>

</nameEntry>

Note: Part type does not have to match

 

Does Not Match:

<nameEntry>

<part localType="forename">Kylie Minogue</part>

</nameEntry>

Reason: Different name part value

 

 

 

 

 


1.6     Part A: Example D: Sanity check – organisation name

 

Example record 1

<identity>

<entityType>corporateBody</entityType>

<nameEntry>

<part>The Australian Computer Society</part>

</nameEntry>

</identity>                  

 

 

Matches:

<nameEntry>

<part>The australian computer society</part>

</nameEntry>

Note: Case is not significant .

 

<nameEntry>

<part>The Australian Computer Society Pty. Ltd.</part>

</nameEntry>

Note: Strip out terms such as Pty Ltd before performing comparison

Note: Articles (e.g. the) are included in the value in  the part

 

Does Not Match:

<nameEntry>

<part>ACS</part>

</nameEntry>

Reason: Part value does not match

 

<nameEntry>

<part>The International Computer Society</part>

<part localType="subordinate">The Australian Computer Society</part>

</nameEntry>

Reason: Parts for ‘subordinate’ or’ parent’ are not included in check

Note: The first <nameEntry>< part> is selected for matching

Note: Part type is not significant

 

<nameEntry>

<part>The Australian Computer Society</part>

<part localType="jurisdiction">Australia</part>

</nameEntry>

Reason: All parts must match (in this case includes value for jurisdiction)

 

<nameEntry>

<part>The Australian-Computer Society</part>

</nameEntry>

Reason: Punctuation is significant

 


Example record 2

<nameEntry>

<part localType="acronym">ACS</part>

</nameEntry>

 

Matches:

<nameEntry>

<part localType="abbreviated”>ACS</part>

</nameEntry>

 

<nameEntry>

<part localType="acronym”>ACS</part>

</nameEntry>

Note: Type is not significant

Note: Use of localtype nonPreferred, abbreviated, acronym etc is not               recommended. Can use “authorizedForm”

 

Does Not Match:

<nameEntry>

<part > The Australian Computer Society</part>

</nameEntry>

Reason: Part value does not match

 

<nameEntry>

<part localType="jurisdiction”>Australia</part>

<part>ACS</part

</nameEntry>

Reason: All parts must match, including jurisdiction

 

<nameEntry>

<part>A.C.S.</part

</nameEntry

Reason: Punctuation is significant

 

 

 

 

 

 

 


2                   Pa rt B – Rules to match an incoming record to an identit y

If an incoming record fails the rules in Part A, then the matching rules in Part B are applied.

 

The rules to decide if a record should be part of an existing identity are:

2.1          Using a Persistent Identifier found in the record

Check if the incoming record has a NLA party identifier (PI)  and Agency code for the National Library of Australia Party Infrastructure  (ISIL = AU-ANL:PEAU) in control/sources/source/objectXMLWrap and if so, whether an identity with that PI (or superceded PI) can be found.

 

If one identity is found:

2.1.1     Check it is not a “disambiguation identity”

If it is, check the identities it refers to as you would for a record with no PI. If they don’t match, the process has failed.

2.1.2 Perform a Sanity check

Use the rules described for a Sanity check in Part A – Rules for matching records for people and organisations.

 

For organisation names all the name entry parts and values in the incoming record must be the same as the name entry parts and values in an identity for a match on a Persistent Identifier.

 

If the sanity check does not pass, the matching process has failed

 

If no identity or more than one identity was found for the PI, the matching process has failed and the record passes  through check 2.2 as detailed below.

 

Notes:

       Record NLA Party id’s in sources ( eac-cpf/control/sources/

source/objectXMLWrap.

       Matching on NLA party ids provides a match point for automatic matching of research sector records that would otherwise fail at other match points.

 

 

 

 

 

 

2.2          Using an identifier found in the record other than recordID

Check if the incoming record has another record identifier and Agency code  in the sources element ( control/sources/source/objectXMLWrap) e.g. record id and Agency code (ISIL) OCLC-VIAF) for Virtual International Authority File

 

If one identity is found:

2.2.1     Check it is not a “disambiguation identity”

If it is, check the identities it refers to as you would for a record with no PI. If they don’t match, the process has failed.

2.2.2     Perform a Sanity check

Use the rules described for a Sanity check in Part A – Rules for matching records for people and organisations.

 

For organisation names all the name entry parts and values in the incoming record must be the same as the name entry parts and values in an identity for a match on a Persistent Identifier.

 

If the sanity check does not pass, the matching process has failed.

 

If no identity or more than one identity was found for the ID, the matching process has failed and the record passes through check 2.3 as detailed below.

 

2.3          Without using a Persistent Identifier

If the incoming record does not have an identifier other than recordID:

 

2.3.1     For records which have an entityType of “person”

Check the name entry part with local type ‘surname’ for  in an incoming record for a match with an  existing record that contains  a name entry part with local  type of “surname”.

 

Check all parts of the incoming record against all parts of the identity record that have a localType of “surname”.

 

Notes:

       Name entry part type is significant. The recommended values for the Trove Party Infrastructure for the nameEntry /part localType are “surname” and ‘forename”.

       Order of parts is not significant.

       Punctuation and diacritics are significant.

       Ignore whitespace at the start or end of the name value.

       Ignore capitalisation (case insensitive)

       Ignore localtype authorizedForm

       Ignore existence dates (existDates)

 

2.3.1.1    No match

If there is no existing record that contains a match with the value in the name entry part localType of “surname” a new identity record is automatically created from the incoming record.

2.3.1.2    One or more matches

If there is one or more existing record(s) that contains a match with a name entry part with localType of “surname” check if the matching record(s) also contain a match with a name entry part with localType of “forename”.

 

Check all name entry parts of the incoming record against all name entry parts of the matching identity record that have a localType of “forename”.

 

Notes:

          The local  type must be “forename”. There must already be a match with a name entry part local type of “surname”.

          Name entry part type is significant. The recommended values for the Trove Party Infrastructure for the nameEntry /part localType are “surname” and ‘forename”

          Order of parts is not significant.

          Punctuation and diacritics are significant.

          Ignore whitespace at the start or end of the name value.

          Ignore capitalisation (case insensitive)

          Ignore localType  authorizedForm

          Ignore existence dates ( existDates )

2.3.1.3 Match found:

If a match is found check the existence dates (existDates) in the incoming record for a match with the existDates in the matching identity record

 

Both start and end dates should match. If a start or end date is not present,  check that the other date matches

 

Notes:

       existDates to be in dateRange not date

       Dates to be ISO-8601 (the universal standard for numerical data) 

       All dates normalised to yyyy-mm-dd (ISO-8601)

       Check the normalised version of the date. Will not  parse the non-normalised

       Only year needs to match, not month or day

 

If there is a match on name entry part with localType  “surname” but no match on name entry part with localType  “forename” check for an existing record that contains a match between the first letter of the value in “forename” of the incoming  record with the first letter of the value in “forename” of an existing identity record.

 

 

Check all name entry parts of the incoming  record with a localType of “forename” against all name entry parts of an existing identity record with a localType of “forename”. Ignore length of value in “forename” (include “forename” values that have a single letter).

 

Notes:

          Name entry part type is significant. The recommended values for the Trove Party Infrastructure for the nameEntry /part localType are “surname” and ‘forename”

          Part type is significant. The local attribute type must be “forename”.

          Order of parts is not significant.

          Punctuation and diacritics are significant.

          Ignore whitespace at the start or end of the name value.

          Ignore capitalisation (case insensitive)

          Ignore localType  authorizedForm

          Ignore existence dates ( existDates )

 

2.3.1.4 If no match found

If no match is found a new identity record is automatically created from the incoming record

2.3.1.5 If a match is found:

Check the existence dates (existDates) in the incoming record for a match with the existDates in the matching identity record

 

Both start and end dates should match. If a start or end date is not present check that the other date matches

 

Notes:

       existDates to be in <dateRange> not <date>

       Dates to be ISO-8601 (the universal standard for numerical data) 

       All dates normalised to yyyy-mm-dd (ISO-8601)

       Check the normalised version of the date. Will not  parse the non-normalised

       Only year needs to match, not month or day

 

 

 

See Part B: Example A. Surname check.

                            See Part B: Example B. Forename check .

See Part B: Example C. First letter of forename check.

See Part B: Example E. Existence date matching

 

 


2.3.2     For records which have an entityType of “corporateBody”

For any organisation name ( cpfDescription/identity/entityType element with the value “corporateBody”) in the record:

 

In the incoming record check all name parts match all the name parts in an existing identity. Check includes name entry localType  and value if included in the  incoming or identity record. If all name entry parts and values (and localType if included) match, check existDates.

 

If the incoming record has existDates check the identity record for existDates.

 

2.3.2.1 No existDates

If no existDates in the Identity record the incoming record is not a match and passes to the unmatched records

 

2.3.2.2 If one existDates

In the incoming record check if the 1 st set of existDates/dateRange and values match the existDates/dateRange and value in the identity

 

2.3.2.3 If two existDates

If the incoming record and identity record both contain two existDates dateRanges and values check if all existdates dateRanges and values match.  

 

If match is found, the record is added to the matching identity record.

 

If no match is found, the record DOES NOT automatically create a new identity. The record passes to the unmatched queue for manual review.

 

Notes:

       Order of name parts is not significant

       The number of name entry parts is significant

       localType is significant.

       Ignore whitespace at the start or end of the name value.

       Ignore capitalisation (case insensitive).

       Punctuation is significant.

       Articles  are included in the value of the words in name entry parts

       The check ignores terms in the following list: (punctuation in these terms can be ignored)

       Pty

       Ltd

       Proprietary

       Limited

       existDates to be in <dateRange> not <date>

       Dates to be ISO-8601 (the universal standard for numerical data) 

       All dates normalised to yyyy-mm-dd (ISO-8601)

       Check the normalised version of the date. Will not parse the non-normalised

       Only year needs to match, not month or day

       Both start and end dates should match.

       If start or end date is missing, check that the other date matches.

       If both records have no dates, they are not a match.

 

 

 

 

See Part B: Example D. Corporate Name Check

See Part B: Example E. Existence date matching .

 


2.4     P art B: Example A. Surname check.

 

 

Example record

< nameEntry >

< part   localType="surname" >Moffat</part>

< part   localType="forename" >Steven</part>

< part   localType="forename">James</part>

< part   localType="extension">Sir</part>

</nameEntry>

 

Matches:

< part   localType="surname" >Moffat</part>

< part   localType="forename" >Evelyn</part>

< part   localType="forename" >Jacqueline</part>

Reason: forename is not included in check

 

< part   localType="surname" >Moffat</part>

< part   localType="forename" >Boris</part>

< part   localType="forename" >Karlofski</part>

< part   localType =" extension " >Prince</ part >

Reason: extension is not included in check

 

< part   localType="surname" >moffat</part>

< part   localType="forename" >steven</part>

Reason: Case is not significant

 

<nameEntry>

< part   localType="surname" >Moffat Smith</part>

< part   localType="forename" >Steven</part>

< part   localType="forename" >James</part>

</nameEntry>

<nameEntry>

< part   localType="surname" >Moffat</part>

< part   localType="surname" > Smith</part>

< part   localType="forename" >Steven</part>

< part   localType="forename" >James</part>

</nameEntry>

Reason: All name elements are checked

 

< part   localType="forename" >Steven</part>

< part   localType="forename" >James</part>

< part   localType="surname" >Moffat</part>

Reason: order of part types is not significant

 

 

 

< part   localType="surname" >Moffat</part>

< part   localType="forename" >Steven</part>

< part   localType="forename" >James</part>

< authorizedForm >AACR2</authorizedForm>

Reason: authorised form is not significant

 

< part   localType="surname" >Moffat</part>

< part   localType="surname" >Smith</part>

< part   localType="forename" >Steven</part>

Reason: localType is repeatable; all localTypes are checked for matches

 

< part   localType="surname" >Moffat</part>

< part   localType="forename" >Steven</part>

< part   localType="forename" >James</part>

No exist dates included

Reason: existDates are ignored.

 

 

Does not match:

< part >Mofatt</part>

< part >Tracey</part>

Reason: nameEntry has part but no localType

 

< part   localType="surname" >Mofffat</part>

< part   localType="forename" >Steven</part>

< part   localType="forename" >James</part>

Reason: surname does not match

 

< part   localType="forename" >Moffat</part>

< part   localType="surname" >Steven</part>

< part   localType="forename" >James</part>

Reason: surname does not match, part type is significant

 

< part   localType="surname" >Moffat Smith</part>

< part   localType="forename" >Steven</part>

< part   localType="forename" >James</part>

Reason: surname does not match

 

< part   localType="surname" >Mof-fat</part>

< part   localType="forename" >Steven</part>

< part   localType="forename" >James</part>

Reason: punctuation is significant

 

 


2.5     Part B: Example B. Forename check.

 

Example record

< nameEntry >

< part   localType="surname" >Gardener</part>

< part   localType="forename" >Ellen</part>

</nameEntry>

 

Matches:

< part   localType="surname" >Gardener</part>

< part   localType="forename" >Ellen</part>

< authorizedForm >AACR2</authorizedForm>

Reason: forename matches. Authorized Form is not significant.

 

< part   localType="surname" >Gardener</part>

< part   localType="forename" >Ellen</part>

< part   localType="forename" >Louise</part>

Reason: only one instance of forename is required to make a match

 

< nameEntry >

< part   localType="surname" >Gardener</part>

< part   localType="forename" >E</part>

</nameEntry>

< nameEntry >

< part   localType="surname" >Gardener</part>

< part   localType="forename" >Ellen</part>

</nameEntry>

Reason: only one instance of forename is required to make a match

 

Does not match:

< part   localType="surname" >Gardener</part>

< part   localType="forename" >E</part>

Reason: single letter in forename

 

< part   localType="surname" >Gardener</part>

< part   localType="forename" >Eileen</part>

Reason: forename does not match

 

< part   localType="surname" >Gardener</part>

< part   localType="forename" >Ellen M.</part>

Reason: forename does not match

 


2.6     Part B: Example C. First letter of forename check.

 

Example record

< nameEntry >

< part   localType="surname" >Smith</part>

< part   localType="forename" >Matt</part>

</nameEntry>

 

Matches:

< nameEntry >

< part   localType="surname" >Smith</part>

< part   localType="forename" >M</part>

</nameEntry>

Reason: first letter of forename matches. Length of value in forename is not significant (i.e. includes check where the value is a single letter).

 

< nameEntry >

< part   localType="surname" >Smith</part>

< part   localType="forename" >M.</part>

</nameEntry>

Reason: punctuation is not significant

 

< nameEntry >

< part   localType="surname" >Smith</part>

< part   localType="forename" >m</part>

</nameEntry>

Reason: capitalization is not significant

 

< nameEntry >

< part   localType="surname" >Smith</part>

< part   localType="forename" >Margaret</part>

</nameEntry>

Reason: first letter of forename matches

 

< nameEntry >

< part   localType="surname" >Smith</part>

< part   localType="forename" >M</part>

< part   localType="forename" >J</part>

</nameEntry>

Reason: first letter of one forename instance matches

 

< nameEntry >

< part   localType="surname" >Smith</part>

< part   localType="forename" >Matt</part>

< part   localType="forename" >Jorge</part>

</nameEntry>

Reason: first letter of one forename instance matches

 

 

< nameEntry >

< part   localType="surname" >Smith</part>

< part   localType="forename" >Sebastian</part>

</nameEntry>

< nameEntry >

< part   localType="surname" >Smith</part>

< part   localType="forename" >Michael</part>

</nameEntry>

Reason: all forename parts are checked. First letter of one forename instance matches one of the forename parts .

 

< nameEntry >

< part   localType="surname" >Smith</part>

< part   localType="forename" >Michael Jones</part>

</nameEntry>

Reason: first letter of forename matches

 

Does not match:

< nameEntry >

< part   localType="surname" >Smith</part>

< part   localType="forename" >Ethel Mary</part>

</nameEntry>

Reason: first letter of forename does not match

 

< nameEntry >

< part   localType="surname" >Smith</part>

< part   localType="forename" >Emily</part>

</nameEntry>

Reason: first letter of forename does not match

 

< nameEntry >

< part   localType="surname" >Smith</part>

< part   localType="forename" >Jones Matt</part>

</nameEntry>

Reason: first letter of forename does not match

 

< nameEntry >

< part   localType="surname" >Smith</part>

< part   localType="extension" >Matt</part>

</nameEntry>

Reason: extension is not included in check

 


2.7     Part B: Example D. Corporate name check.

 

Example record

< entityType>corporateBody</entityType>

<nameEntry>

<part>Sydney Dance Company</part>

<authorizedForm>AACR2</authorizedForm>

</nameEntry>

 

Matches:

<entityType>corporateBody</entityType>

<nameEntry>

<part>Sydney Dance Company</part>

</nameEntry>

Reason: exact name string. Authorized Form is not significant .

 

<entityType>corporateBody</entityType>

<nameEntry>

<part localType=”superior”>Sydney Dance Company</part>

</nameEntry>

Reason: localType is not significant where there is only one part.

 

<entityType>corporateBody</entityType>

<nameEntry>

<part>Sydney dance company</part>

</nameEntry>

Reason: Ignore capitalization (case insensitive).

 

 

Does not match:

<entityType>corporateBody</entityType>

<nameEntry>

<part>Sydney Dance Co.</part>

</nameEntry>

Reason: Does not match exact name string.

 

<entityType>Person</entityType>

<nameEntry>

<part>Sydney Dance Company</part>

</nameEntry>

Reason: entityType is significant .

 

<entityType>corporateBody</entityType>

<nameEntry>

<part>Company Dance Sydney</part>

</nameEntry>

Reason: name string is not exact.

 

<entityType>corporateBody</entityType>

<nameEntry>

<part>Sydney Dance, Company</part>

</nameEntry>

Reason: punctuation is significant.

 

<entityType>corporateBody</entityType>

<nameEntry>

<part>The Sydney Dance Company</part>

</nameEntry>

Reason: stop words are significant.

 

<entityType>corporateBody</entityType>

<nameEntry>

<part>Sydney</part>

<part>Dance</part>

<part>Company</part>

</nameEntry>

Reason: multiple parts is significant.

 

<entityType>corporateBody</entityType>

<nameEntry>

<part>Sydney Dance Company</part>

<part localType="subordinate">Indigenous Performance Group</part>

</nameEntry>

Reason: multiple parts is significant.

 

<entityType>corporateBody</entityType>

<nameEntry>

<part>Sydney Dance Company</part>

<part localType="title">The</part>

</nameEntry>

Reason: multiple parts is significant.


2.8     Part B: Example E. Existence date matching

Note: Standard used for <existDates> is ISO-8601

For consistency in records use <dateRange> for all <existDates> not <date>

 

Example record

<description>

<existDates>

<dateRange>

<fromDate standardDate="1893"/>

<toDate standardDate="1973"/>

</dateRange>

</existDates>

 

Matches:

<existDates>

<dateRange>

<fromDate standardDate="1893-12-25"/>

<toDate standardDate="1973"/>

</dateRange>

</existDates>

Note: Only year has to match .

 

<existDates>

<dateRange>

<fromDate standardDate="1893"/>

</dateRange>

</existDates>

Note: Start date matches. No end date is present.

 

<existDates>

<dateRange>

<toDate standardDate="1973"/>

</dateRange>

</existDates>

Note: End date matches. No start date is present.

 

Does Not Match:

<existDates>

<date>1973</date>

</existDates>

Reason: Needs to be in dateRange and as a start (fromDate) or end (toDate) date

             

<existDates>

<dateRange>

<fromDate standardDate="1893"/>

<toDate standardDate="1974"/>

</dateRange>

</existDates>

Reason: End date does not match.


2.9     Part B: Flowchart diagrams

 

2.9.1   Part B: Flowchart - No matches on surname

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


2.9.2   Part B: Flowchart - Match on surname, no match on forename or forename initial

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


2.9.3   Part B: Flowchart - Match on surname, match on forename

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2.9.4   Part B: Flowchart - Record with no localType