Managing CoNE entities - Persons

This is a protected page.

Scenarios, use cases and data structure for extending the eSciDoc CONE service with data on persons, especially in the context of eSciDoc.PubMan.

Data pools

eSciDoc.PubMan will maintain 2 pools of person data:

Un-authorized person data

• i.e. names, name variants and respective affiliations as provided during submission or import of data by users
• the data pool will be created by using the current name variants of publication items on pubman and will be continuosly growing by new entries (by submission or import)
• The user who submits data manually, will be supported by an autosuggest list containing all currently available un-authorized data, to reduce duplicate entries (see below Scenarios)
• The person information stored with a publication item will not be altered, i.e. the person information stored with a publication item can be un-authorized data, can be already authorized data. In case of un-authorized data, the unauthorized nameID can be related afterwards to an authorized PersonID in CONE.
• Therefore, the publication item will contain only one possible naming variant, with specific affiliations at a given point in time, which is the one provided during submission/import.
• The entries in the un-authorized pool of data, i.e. including all possible naming variants of the same person, will have internal ID, to be linked to CONE IDs.

Authorized person data

• contains main name entry, controlled alternative name variants, controlled affiliation (see data structure)
• will be controlled by selected users via edition of the CONE service data
• Only selected users can access the CONE service to edit and maintain the controlled person IDs
• Selected users can relate un-auhtorized person name IDs to permanent, controlled, authorized person IDs in CONE.

Scenarios

Submission

During Submission (either easy or full submission), user can enter any name variant. Either s/he follows the "Autopsie Prinzip" and copies the name variant directly from and strictly following the typing on the original copy. Alternatively, to increase data quality, s/he can choose a name variant, including an affiliation, from the auto-suggest list for persons. These values can be un-authorized or authorized person data.

• The User can select a value from the autosuggest list and store the item. In the process of selection from auto-suggest list, he is supported by information, which of the suggested values is an "un-authorized" and what is "auhtorized" person data.(Example worldCat). Afer selection of an value, the publication item contains ID and value of selected ID.

• The user can select an un-authorized name from the autosuggest list, but overwrites the provided value. A new un-authorized nameID is created, without relation to the previosly selected nameID.

• The user can select an Authorized person ID. He is not allowed to overwrite the value, but he can create a "potential candidate" for a new naming variant of the authorized person ID.

• The user can ignore the autosuggest list and enter whatever value for the person. A new un-authorized nameId is created.

Search

Any search triggered via Quick search, Advanced search or Search&Export service will search in both un-authorized nameIDs and authorized CONE-IDs.

The search triggered by "View researcher profile" is searching exclusively on CONE PersonIDs, as the service "view researcher portfolio" is bound to an authorized CONE PersonID.

Edit CONE

Only selected users can define, which of the un-authorized names/naming variants relate to one specific person. They should be able to

• create and release a PersonId in CONE (start content might be ingested?)
• edit the personal data related to a PersonID
• relate one or many un-authorized nameIDs to one PersonID
• add new naming variants to a Person ID (e.g. "potential candidates", cf submission)
• look-up Persons in external authority files (Researcher ID, WorldCat, Kaken, PND)

Open questions

• in case of import of references (bibtex, endnote, fetch md), can we combine it with an alternative to "autosuggest", i.e. to avoid duplicate entries?

Data structure

Based on requirements of first Early Adopters, following data structure on persons should be supported by CONE:

• requs NIMS
• requs ICE

Enhanced Scientific Documentation

Control of Named Entities

Identifier

Personen Normdatei

National Institute for Materials Science Japan

Internet Chat Exchange