• Embed Doc
  • Readcast
  • Collections
  • CommentGo Back
 
NicNames application
Draft 0.1.1, 30 Jan 2009 – Thomas Rutter – Please comment
Contents
 NicNames application..........................................................................................................................1Contents...........................................................................................................................................1Aims.................................................................................................................................................1Data model.......................................................................................................................................2 NicNames unique identifier........................................................................................................2Properties associated with an identity.........................................................................................3Database format..........................................................................................................................7User interface...................................................................................................................................8Search query................................................................................................................................8Displaying a record.....................................................................................................................9Access to the user interface.........................................................................................................9Merge feature..............................................................................................................................9Split feature...............................................................................................................................10Query service.................................................................................................................................10Data format................................................................................................................................11Bulk import or 'harvesting'.............................................................................................................11Persistence of user corrected information.................................................................................12Idempotence..............................................................................................................................12
 Aims
Provide a unique identifier which can be used to refer to a particular person in institutionalrepositories and other external applications which do not otherwise maintain identityrecords.
Provide a tool to help distinguish the identity and retrieve the correct unique identifier of a person given their name and a small amount of knowledge about them, even if that person'sname is ambiguous or multiple people share the name. Such a tool should be easilyintegrated into external applications where data entry is done.Without NicNames, repositories and other external applications which do not otherwise maintainidentity records suffer from the following problems:
lack of a way to reliably retrieve or group records by a certain author, if the author's name isdifferent across different publications.
lack of a way to distinguish between two authors with the same name.Solving these problems in institutional repository software unable to maintain identity recordsrequires deciding upon one unique, authoritative form of each author's name, and using that sameform throughout the repository. It has been decided that this approach is not satisfactory for an1
 
institutional repository, because:
There are legitimate reasons why an author may be known by different names in differentcontexts within the same repository, including situations where this would be more correctand useful than denoting one name to be the 'authoritative' form.
In the unlikely event that two authors share the same name, it would be more correct anduseful to allow both to be referred to by this name in the repository, than to modify one or the other of their names to ensure uniqueness (by adding middle initials or other informationto the end of the name that they wouldn't otherwise use).
Data model 
NicNames unique identifier 
The NicNames database shall give each identity record its own unique identifier. This will allowexternal applications, such as repositories, to associate their own records with an identifier from NicNames.The identifier shall be a positive number, incrementing in sequence – thereby containing noconfidential, private information or information which will go out of date. The numeric identifier shall be unique only to that particular installation of NicNames. This ensures that anybody is free toset up their own installation of NicNames, should they choose to, without needing to cooperate withany other organisation or central authority when adding new records.Identities shall also have a mechanism to be associated with the same identity in other NicNamesdatabases, just as they might be associated with the same identity in external databases such asScopus, Researcher ID or People Australia.Where-ever an application might refer to an identifier from an external NicNames database, a prefixshould be used with the identifier, which indicates the NicNames database that the identifier camefrom. Where NicNames exposes its data to other applications via a web service, this shall include itssuggested prefix.It would be advantageous for prefixes used to describe a given NicNames database to be consistentamong other databases. Therefore, some global and exclusive way of choosing a prefix could beused. A central governing body which maintains a list of the prefixes for NicNames installationscould be used, however, this would require ongoing maintenance, and it would also impact upon thefreedom for anybody to set up a NicNames installation of their own, if they choose to, withoutneeding approval or cooperation from others. Therefore, a prefix based on the domain name of theinstitution, such as “swinburne.edu.au” may be an appropriate convention, as it is globally uniqueand would need no governing body beyond obtaining a domain name, which an organisation islikely to already have. Institutions could run more than one installation and give prefixes containingadditional information, like department.swinburne.edu.au. Note that a NicNames unique identifier is not intended as a URL or resolver service which can locate a NicNames installation; just anidentifier that can associate a record in one system with a record in a known NicNames installation.Any organisation who chooses to install NicNames can, at their option, choose to share their identifiers with anybody else or publicly advertise the availability of open web services for 2
 
accessing their NicNames data including their identifiers. It is expected that institutions will sharetheir data with partner institutions.
Properties associated with an identity
Identities in NicNames can have any number of properties associated with them. This includes oneor more names or forms of names, resources, other people, identifiers in external applications andmore. The additional properties can aid in distinguishing the identity and retrieving the correctunique identifier for a person even if the name is ambiguous or the same name is used by multipleidentities.All properties associated with a name are optional and non-exclusive other than the NicNamesunique identifier. That is, a record may have zero or any number of each type of property. Thesmallest record which could possibly be useful would have, at a minimum, only one name or other  property in addition to the NicNames unique identifier.Each identity may have:
 Names
Related resources
Related events
Related organisations
Related people
Related identifiers
An optional comment
Names
Each person may have any number of names. Sometimes, we can distinguish between types of names, and variants of the same name.Examples:
Person has 'publishedasname' of surname 'Smith', givennames 'Michael J.'
Person has 'employeename' of no surname, givennames 'Madonna' on dates 1984-
Person has 'publishedasname' of surname 'Kim' and givennames 'Il-sung' and surnamecomes first, and this is a 'romanised' version of name B (which is a 'publishedname' of surname '
' and givennames '
일성
').A name associated with a person may include:
surname
givennames
title
surnamefirst (yes or no)
type (see below)
 pointer (ie self-referential foreign key) to name it was derived from
derivetype (see below)
comment3
of 00

Leave a Comment

You must be to leave a comment.
Submit
Characters: ...
You must be to leave a comment.
Submit
Characters: ...