Difference between revisions of "Managing CoNE entities - Persons"

From MPDLMediaWiki
Jump to navigation Jump to search
(update)
Line 1: Line 1:
<accesscontrol>MPDL</accesscontrol>  
<accesscontrol>MPDL</accesscontrol>  


prelim scenarios and use cases for specification of Service for control of named entities, for dealing with persons in the context of PubMan solution.
Scenarios, use cases and data structure for extending the eSciDoc CONE service with data on persons, especially in the context of [[Portal:PubMan |eSciDoc.PubMan]].  
Both scenarios and service will be extended in future.


==Data pools==
==Data pools==
Line 9: Line 8:
*i.e. names, name variants and respective affiliations as provided during submission or import of data by users
*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 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 submitting data manually will be supported by an autosuggest list containing all currently available un-auhtorized data, to reduce duplicate entries
*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)
*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 be linked to only one naming variant, which is the one provided during submission/import.
*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 will have internal ID, to be linked to CONE IDs.
*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.
*GUI: should consider support for user in identifying from auto-suggest, which of the entries is "authorized"/"un-authorized" (see example WorldCat)


===Authorized person data===
===Authorized person data===
*will be controlled by the CONE service
*contains main name entry, controlled alternative name variants, controlled affiliation (see data structure)
*contains main name entry, controlled alternative name variants, controlled affiliation (see final data structure, based on NIMS and ICE requirements)
*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
*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.
*Selected users can relate un-auhtorized person name IDs to permanent, controlled, authorized person IDs in CONE.
Line 26: Line 24:


In case the autosuggest list does not provide any
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===
===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
*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===
===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?
*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:
==Use cases==
==Use cases==
==Future development==
==Future development==

Revision as of 17:08, 15 December 2008

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]