| Div | ||
|---|---|---|
| ||
Questions
Note that it is better to place discussion points inline, as sub-bullets, than to put them in comments where the context and flow is harder to reconstruct.
- Do we need to explicitly model the distinction between system users and "referenced Persons"?
We know we will have roles associated to system users for various AuthZ issues. However, is it enough to just note Persons with user AuthZ role associations, or do we have a fundamental modeling difference between these system users and other Persons described or referenced? We might have policies around minimal info for users, but not for referenced Persons. Both will need associations, possible contact info, etc.
Some of the uses for referenced Persons include authors of documents, staff at other institutions (responsible for loans, exhibitions, etc., but not users of the local system), faculty, etc. Note also that not all "users" in the system are necessarily users of the primary CollectionSpace services. E.g., there may be public users of a derivative website that presents a collections browser, an online exhibition or a tagging tool. These public users may register to preserve state like tags, favorites, etc., but may never be granted access to CMS tools. At the core, we will likely have a generic Person entity service, and could then specialize this to define/enforce policies on information requirements. The key here is to specify when a role is not enough, so we do not conflate specialized person entities with roles. If we can, we should probably stick with Person and not define subclassed entities. OTOH, how does this align to KSS and their Student entity model? Is Student a Person subclass, or a Person-Role association? Note also that KSS handles this with a mechanism of Type values for a variety of entities, including Resource, Person, Organization, etc.
...