Organization Service Home

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 think about inherited contact information for organizational structures? Does KSS handle this?
Do we really need to name the various hierarchies, or should we just model an entity as having multiple parent organizations, possibly with named relationships, and let the UI present this when the issue arises? When and why would we present this, other than in a CV picker of some sort, in which the parents are context?
Should we follow the KSS model that distinguishes between Auth Groups and Orgs?
- Can an Auth Group be defined from the associations of Persons to an Org?
- Can it be logically defined as such, so that changes to the affiliations are reflected in the Auth group?
- If not, isn't this a pain for authz maintenance?
Must Affiliations support definition/persistence via LDAP (and equivalent) lookup? Sync with LDAP and other systems?
How should we relate the contact info for a person, to the affiliation for that person?
E.g., there might be contact info for someone with a titular function at another museum, as well as contact info for them as a visitor or researcher or consultant.
- Should we somehow associate the contact information with their Affiliation?
- Don't we want to be able to produce a label like:
  Susan B. Cogitus
  Rare Books Collections Manager
  Monitus Maximus Museum
  123 Main Street
  Fooville, BA, 99999-1234

Do we need to support more than just short and long names for an organization?
Do we have any need for org codes?
KSS models the idea of constraints that an Org puts on what type of relationships a Person can have with that org (presumably something like an enumeration of relation types). Do we need this?

Browser not supported