PID setup for personal data #14
Labels
No labels
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
inm7/inm7-concepts#14
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
We should not be using the same PIDs for person(al) data for internal and public records. Doing so would make it easier to deduce information from internal records, even if the actual person records are inaccessible (because a public record with the same PID would reveal other public information, such as the author name from a publication record).
We are considering to use a truncated hash of a person's name and their starting date as the (internal) PID. Those could be prefix like
inm7:person/<hash>. For any to-be-exported record, we could generate a public identifier from this information by adding a "salt" and rehashing it.This could also be just a fallback, and we could, by default, use an ORCID, if that is on record for a person.
https://concepts.inm7.de/about/ now shows that filter and transformation operations are possible for metadata being exported to other scopes/models. This would be the place where arbitrary ID mappings could take place. The sibling operation for metadata intake is also included in the design, and would allows for the inverse mapping to take place.