Managing CoNE entities - Persons

From MPDLMediaWiki
Revision as of 17:08, 15 December 2008 by Uat (talk | contribs) (update)
Jump to navigation Jump to search

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[edit]

eSciDoc.PubMan will maintain 2 pools of person data:

Un-authorized person data[edit]

  • 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
  • The person information stored with a publication item will not be altered, i.e. the person information stored with a publication item is un-authorized data, but can be related afterwards to a PersonID stored in CONE (see authorized person data)
  • Therefore, the publication item will contain only one possible naming variant, 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[edit]

  • 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[edit]

Submission[edit]

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 and strictly as 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 are not authorized, but have been used by other users.

In case the autosuggest list does not provide any

  • GUI: should consider support for user in identifying from auto-suggest, which of the entries is "authorized"/"un-authorized" (see example WorldCat)

Search[edit]

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[edit]

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
  • edit the personal data related to a PersonID
  • relate one or many un-authorized nameIDs to one PersonID
  • look-up Persons in external authority files (Researcher ID, WorldCat, Kaken, PND)

Open questions[edit]

  • 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[edit]

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

Use cases[edit]

Future development[edit]