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

1.1Check  Contributor ID

1.1.1No record found

1.1.2More than one record found

1.1.3One record found

1.2Sanity Check

1.2.1People Records

1.2.2Organisation records

1.3Part A: Example A: Contributors  ids

1.4Part A: Example B: Surname sanity check

1.5Part A: Example C: No surname sanity check

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

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

2.1Using a Persistent Identifier found in the record

2.1.1Check it is not a “disambiguation identity”

2.1.2Perform a Sanity check

2.2Using an identifier found in the record other than recordID

2.2.1Check it is not a “disambiguation identity”

2.2.2Perform a Sanity check

2.3Without using a Persistent Identifier

2.3.1For records which have an entityType of “person”

2.3.2For records which have an entityType of “corporateBody”

2.4Part B: Example A. Surname check.

2.5Part B: Example B. Forename check.

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

2.7Part B: Example D. Corporate name check.

2.8Part B: Example E. Existence date matching

2.9Part B: Flowchart diagrams

2.9.1Part B: Flowchart - No matches on surname

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

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

2.9.4Part B: Flowchart - Record with no localType


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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 1st name entry part (with or without local type) encountered in both records

 

Check that the value of the 1st nameEntry 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">   brown </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">Browne</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                    Part B – Rules to match an incoming record to an identity

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 1st 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        Part 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