Difference between revisions of "Managing CoNE entities - Persons"
(update) |
|||
Line 1: | Line 1: | ||
<accesscontrol>MPDL</accesscontrol> | <accesscontrol>MPDL</accesscontrol> | ||
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]]. | |||
==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 | *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 | *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. | ||
===Authorized person data=== | ===Authorized person data=== | ||
*contains main name entry, controlled alternative name variants, controlled affiliation (see data structure) | |||
*contains main name entry, controlled alternative name variants, controlled affiliation (see | *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: