Skip to end of metadata
Go to start of metadata

Overview of "Create an Org" Use Case

Create an Organization (Org) with defined characteristics

Tip: Key Points
UC Priority= 4 or 5: Critical, is in R2
Only boldface steps are required
<#> before a step —> lower priority
(optional) —> run-time option

Related Jira Issues:   Open   •   All


Refer to the Product Description and Product Description Release 2 pages for metadata definitions.

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.
Lead Team COI
Primary Service Federated Facility Services (Virtual Organization) Part 1
Version 1.2
UC Priority 5
UC Status Mapped + Ready
UX Exposure ONC


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.

Initial State

The Integrated Observatory exists, but the Org to be created does not exist.

Scenario for "Create an Org" Use Case

  1. The Integrated Observatory Manager decides to create a community or domain with certain characteristics.
    1. A typical Release 2 community is an observatory such as RSN or CGSN.
    2. In R3, this can be created by the independent Observatory Manager.
  2. The Integrated Observatory Operator, acting on the Observatory Managers' behalf, specifies such a community, or Org, with the desired characteristics
    1. The characteristics can be declared in any suitable rule language, for example rules that can be interpreted by the JESS rules engine.
    2. Fundamental characteristics are essentially just descriptive metadata; the more advanced rules may not be used in R2.
    3. In R2 some rules can be inherited from the Integrated Observatory (the rules for observatories).
    4. The rules that are created scope the interaction of the Org's members and enforces the Org's policy in administration of the group.
  3. The Integrated Observatory Operator designates an Observatory Manager.
    1. 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.
  4. An Observatory Manager updates the characteristics of the Org.
    1. The updates are constrained by the overarching rules for Orgs in this release.
  5. An agent represents the Org by executing, or interpreting, the rules that specify the Org.
    1. A reasoning engine can implement the rules by performing (forward) chaining on the rules, to enable reactive and proactive action in an agent.
    2. In a more basic approach, the software performs Org business by considering the metadata that defines the Org.

Final State

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.

(click on # to go to R2 use case)
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
61     27B


r2-usecase r2-usecase Delete
usecase usecase Delete
productdescription productdescription Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.