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.
  • to be checked if during the linking, the Cone authorized persons will have the un-authorized name variants added as alternative names --Natasa 16:45, 13 January 2009 (UTC)

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.

An example how to distinguish these two lists in the presentation can be found here.

Scenarios

Submission

Status: in specification

Schedule: R4.1

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

Status: in specification

Schedule: R4.1

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

On the PubMan GUI for search results, user should be indicated, that other possible naming variants exist.

Comment Nicole: I think it would be good if the user would get the following information: number of records found with a CONE ID, number of records found with unauthorized person ID, variants. The user should then be able to specify if s/he only wants to see a specific set of records or all. --Nicole 08:30, 18 December 2008 (UTC)

Questions Nicole: How/where shall we search if the user wants to perform an exact search? --Nicole 08:30, 18 December 2008 (UTC)

View researcher portfolio/profile

Status: in specification

Schedule: R4.1

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. Check related use case for details.

Edit CONE

Status: in specification

Schedule: R4.1/R4.2

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?
  • One could think of checking the given name for matches in both pools and then give a message to the user about possible controlled names which he can alter in the edit item mask.--Kleinfercher 08:50, 19 December 2008 (UTC)
• does it make sense to provide additional extension on view item page, to search for "all publications of this author"? Is actually same scenario as search, but in addition to start searching in quick search, user would have option to trigger search right from view item details (i.e. name of person)

Comment Nicole: I think it makes sense to offer a link "all publications of this author", as we also had this in eDoc and I think it was used quite often. The only question would then be, if this will return into an exact search then or not. --Nicole 08:32, 18 December 2008 (UTC)

Possible solution: Linked person names in view item triggers exact search for this person name and provides pubman results. (similar to edoc). Complementary, icons for researcher portfolios are provided for those persons with CONE Id.--Ulla 14:36, 18 December 2008 (UTC)

Data structure

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

• Complete Name, Familiy Name, First Name, Alternative Names --Nicole 12:22, 18 December 2008 (UTC)
• Photo (stored externally, provided by URL)
• eSciDoc CONE ResearcherID (once), including URI
• eSciDoc un-authorized nameID (one or more)
• external ID (multiple), including URI if available. E.g. from KAKEN
• personal URL? (requirement from NIMS) --Melanie.stetter 10:37, 19 December 2008 (UTC)One ore more, to indicate "My websites" (.e.g personal homepages or research websites)--Ulla 14:52, 23 December 2008 (UTC)
• Keywords of research fields and interests (free text)(no controlled categories)
• Subject (DDC) (once)

I would add one or more subjects (optional) --Natasa 11:44, 13 January 2009 (UTC)

Can I then write multiple? --Nicole 07:38, 15 January 2009 (UTC)

• Degree (freetext) (e.g.: PhD in Library Science, 2006) (once? field should have clear separators, so that the different degrees can be searched for) --Nicole 10:06, 18 December 2008 (UTC)

Then we shall have several separate degree fields --Natasa 11:44, 13 January 2009 (UTC)

Can I then write multiple? --Nicole 07:38, 15 January 2009 (UTC)

• Current position (free text) (e.g. Head of Library) (once)
• Awards (free text field) (once? field should have clear separators, so that the different awards can be searched for) --Nicole 10:06, 18 December 2008 (UTC)
• Organizational unit (controlled, fetched by OUtree) (one or more)
• Other affiliations (free text, e.g. Member of IEEE, Fellow student at xy) (once? field should have clear separators, so that the different affiliations can be searched for) --Nicole 10:06, 18 December 2008 (UTC)
• E-Mail address (one or more) optional--Ulla 14:57, 23 December 2008 (UTC)
• Telephone number (one, optional)--Ulla 14:57, 23 December 2008 (UTC)

Additional Fields in ICE DB

• Status (active/inactive) (once)
• OU from until (e.g. MPIPL 2007-2008) (one or more)
• normalization of Name (could be name variant in CONE?) (once)

Data covered by eSciDoc Application Profile for Persons

• Complete Name, Familiy Name, First Name, Alternative Names
• Title (degree)
• Organization (but is in Application Profile for persons only possible once)
• Identifier (only PND is allowed)

Data structure detailed (authorized persons only)

• Complete Name
  • i think the decision was not to use Complete name --Natasa 16:43, 13 January 2009 (UTC)
• Family Name (mandatory, once)
• First Name (optional, once)
• Alternative Names (optional, many)
• Photo (stored externally, provided by URL) (optional, once)
• eSciDoc CONE ResearcherID (once), including URI (mandatory, once)
  • this is the actual Cone identifier, URI syntax to be defined
• external ID, including URI if available. E.g. from KAKEN (optional, many)
• personal URL? (requirement from NIMS) (optional, many)
• Keywords of research fields and interests (free text)(no controlled categories) (optional, once)
• Subject (DDC) (optional, many)
• Degree (freetext) (e.g.: PhD in Library Science, 2006) (optional, many)
• Current position (free text) (e.g. Head of Library) (optional, once)
• Award (free text field) (optional, many)
• Affiliation
  • eSciDoc: Organizational unit (controlled, fetched by OUtree) (mandatory, many (i.e. at least one shall be defined), identifier from eSciDoc Ous + name from eSciDoc Ous, only opened or closed Ous shall be considered)
    • (date-from, date-to)
    • proposal: when keeping it into data simply add same affiliation with different date from, date to in case of multiple
  • eSciDoc (external, with name overwritten): Other affiliations (free text, e.g. Member of IEEE, Fellow student at xy) (optional, many, with identifier for external OUs) *E-Mail address (one or more) optional--Ulla 14:57, 23 December 2008 (UTC)
    • (date-from, date-to)
    • proposal: see above for eSciDoc organizations
• Contact info
  • E-Mail address (many, optional)
  • Telephone number (many, optional)
• person-activity-status (active, inactive), default is active (once, mandatory)

Related links

• Summary and overview on authority files in the context of MPG

• A review of the current landscape in relation to a proposed Name Authority Service for UK repositories of research outputs

good overview on standards in use (international standards, library-derived systems, commercial systems)

Enhanced Scientific Documentation

Control of Named Entities

Identifier

Coordinated Universal Time

Publication Management

Graphical User Interface

Electronic Documentation

Uniform Resource Locator

Uniform Resource Identifier

National Institute for Materials Science Japan

Display Data Channel

philosophiae doctor

Internet Chat Exchange

Organizational Unit

Max-Planck-Institut für Psycholinguistik

Personen Normdatei