Difference between revisions of "Managing CoNE entities - Persons"
(update) |
(update) |
||
Line 8: | 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 who submits data manually, will be supported by an autosuggest list containing all currently available un-authorized 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 (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 | *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, which is the one provided during submission/import. | *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. | *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. | ||
Line 21: | Line 21: | ||
==Scenarios== | ==Scenarios== | ||
===Submission=== | ===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 and strictly | 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. | ||
In | *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=== | ===Search=== | ||
Line 35: | Line 40: | ||
===Edit CONE=== | ===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 | 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 | *create and release a PersonId in CONE (start content might be ingested?) | ||
*edit the personal data related to a PersonID | *edit the personal data related to a PersonID | ||
*relate one or many un-authorized nameIDs to one 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) | *look-up Persons in external authority files (Researcher ID, WorldCat, Kaken, PND) | ||
===Open questions=== | ===Open questions=== | ||
Line 44: | Line 50: | ||
==Data structure== | ==Data structure== | ||
Based on requirements of first Early Adopters, following data structure on persons should be supported by CONE: | Based on requirements of first Early Adopters, following data structure on persons should be supported by CONE: | ||
*requs NIMS | |||
*requs ICE | |||
==Use cases== | ==Use cases== | ||
==Future development== | ==Future development== |
Revision as of 17:24, 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 (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[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 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[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 (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[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:
- requs NIMS
- requs ICE