Create an Organization (Org) with defined characteristics
|Actors||Integrated Observatory Manager, Integrated Observatory Operator, Observatory Operator, Observatory Manager|
|References||Federated Facility Services
CIAD COI OV Governance Concepts
JESS Rules Engine
UC.R1.36 Create an Org
|Uses||UC.R2.33 Enroll in an Org
UC.R2.34 Share an Org Resource
|Is Used By|
|Is Extended By|
|In Acceptance Scenarios||AS.R2.01B Define Marine Observatory Policies, AS.R2.03A Modelers Integrate External Model with OOI|
|Technical Notes||In the OOI space, agents represent autonomous entities such as individuals and Organizations (Orgs) or communities.
This process should also work for creating an individual with defined characteristics, as the Agent can represent either any individual entity.
|Primary Service||Federated Facility Services (Virtual Organization) Part 1|
|UC Status||Mapped + Ready|
This information summarizes the Use Case functionality.
In OOI, an Org is a formalization of an organization: each Org "realizes an Org Specification that states the Contract Templates applying to its various Org Roles." (ref) To create the Org, we must create a computational description of the characteristics that describe the Org (the Org Specification), and creating an agent that can act on behalf of the Org by executing the applicable rules (in the Org Specification).
- Relatively few Orgs are created in Release 2, and they are all inheriting resources from the Integrated Observatory.
The Integrated Observatory exists, but the Org to be created does not exist.
- The Integrated Observatory Manager decides to create a community or domain with certain characteristics.
- A typical Release 2 community is an observatory such as RSN or CGSN.
- In R3, this can be created by the independent Observatory Manager.
- The Integrated Observatory Operator, acting on the Observatory Managers' behalf, specifies such a community, or Org, with the desired characteristics
- The characteristics can be declared in any suitable rule language, for example rules that can be interpreted by the JESS rules engine.
- Fundamental characteristics are essentially just descriptive metadata; the more advanced rules may not be used in R2.
- In R2 some rules can be inherited from the Integrated Observatory (the rules for observatories).
- The rules that are created scope the interaction of the Org's members and enforces the Org's policy in administration of the group.
- The Integrated Observatory Operator designates an Observatory Manager.
- In the absence of such a designation, the Default Observatory Manager (specified as the Org owner when the Org is created) has the ability to act as the Observatory Manager.
- An Observatory Manager updates the characteristics of the Org.
- The updates are constrained by the overarching rules for Orgs in this release.
- An agent represents the Org by executing, or interpreting, the rules that specify the Org.
- A reasoning engine can implement the rules by performing (forward) chaining on the rules, to enable reactive and proactive action in an agent.
- In a more basic approach, the software performs Org business by considering the metadata that defines the Org.
The Org has been created with appropriate metadata and rules.
These comments provide additional context (usually quite technical) for editors of the use case.
Note: An 'org' is an extremely abstract term which is constrained only by what is supports, namely the ability to meet specifications that are role-specific. (So the org must be able to take on roles, and must be able to be specified as to its behaviors with respect to those roles.)
In most systems, the concept of org is not brought forward as a first class object, but is encoded directly in the applications. To get additional flexibility and limit the hard-coding of specifications, orgs can be specified using a language independent of the execution of the system.