Skip to end of metadata
Go to start of metadata

Overview of "Define Marine Observatory Resources and Policy" Use Case

Define the assets of a marine observatory and their related policies.

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 Marine Observatory Manager (Observatory Manager)
References R2-R3 Architectural Composition-Principals to Services
UC.R2.10 Manage Marine Platform
UC.R2.35 Share Affiliated Orgs' Resources-Deprecated
UC.R2.36 Create an Org
UC.R2.37 Control Service Interactions
UC.R2.40 Monitor ION Resources
Uses UC.R2.42 Define Resource Policy
Is Used By  
Is Extended By  
In Acceptance Scenarios AS.R2.01A Operate Marine Observatory, AS.R2.01B Define Marine Observatory Policies, AS.R2.02C Instrument Life Cycle Support
Technical Notes This activity is implemented in R2 to satisfy initial OOI marine deployments; it will be extended in R3.
Lead Team SA
Primary Service Marine Observatory Facility Services
Version 2.4
UC Priority 4
UC Status Mapped + Ready
UX Exposure MNC


Define resources of a marine observatory, such as instruments, platforms and deployments. Define policy for these resources and for the observatory.


  • A person with the appropriate role is responsible for defining policies for the observatory's resources.
  • The Integrated Observatory Manager has set up the available actions, conditions, and roles that can be applied; a Marine Observatory Manager may extend the list of roles.
  • Those that define policy may select from the pre-configured options. (A user interface may be provided to simplify this process.)

Initial State

The relevant marine observatory is registered in the system.

Scenario for "Define Marine Observatory Resources and Policy" Use Case

  1. Marine Observatory Manager defines resources to be deployed in a marine observatory offline for scripted ingest.
    1. The definitions are entered into a commonly shared document like a Google spreadsheet.
    2. This is the option likely to be used for most resources, especially when the system is brought up, to submit large collections of resources at one time via a command script.
    3. Definitions include metadata and can be changed before the resource is read in, or using the user interface of the Integrated Observatory after the resource is in the system.
  2. At a mutually agreed time, Integrated Observatory Operator executes the necessary commands to read in the offline definitions.
    1. While this capability will likely exist in some form after the observatories are operated, support for it is not guaranteed.
    2. In some cases it may be possible to delete and re-read the resources, but this is not guaranteed.
  3. Marine Observatory Manager uses a user interface to define resources to be deployed in a marine observatory.
    1. (via a user interface).
    2. Definitions include metadata and can be changed any time.
    3. User interface provides means to add or edit metadata for a resource.
    4. Operational resource interactions, e.g. commanding them and changing their life-cycle states, are different proceses, with separate use cases.
  4. <3> Marine Observatory Manager defines policy for the observatory
    1. Policy rules are defined in OOI policy specification language; user interfaces may help select appropriate (basic) policies
    2. The rules that are created scope the interaction of the observatory's members and enforces the observatory's policy in administration of the group.
    3. Ideally any newly created conflicts (existing operations or plans that are no longer supported) would be highlighted when a policy is created.
  5. <3> Marine Observatory Manager defines policies for individual resources, such as instruments, platforms, or sites.
    1. Policy rules are defined in OOI policy specification language, with respect to user roles.
  6. <3> Policies that apply to specific resources may be viewed in the page for that resource.
    1. In operation, a role may be scoped to a particular resource, and possibly within a period of time.
    2. Policies that apply by composition or inference to a resource (i.e., because the resource is related to another primary resource which has the policy applied) may not be visible in the page for the non-primary resource, though this would be desirable.

Final State

Observatory resources are defined, along with their attributes and metadata.


These comments provide additional context (usually quite technical) for editors of the use case.

The availability of policy allows observatory managers to operate and govern a marine observatory facility independently from the Integrated Observatory, applying marine IOs' resource use policies. It enables each observatory to define its own resource use policies, and to assign resource attribute values (e.g., life cycle state) that engage the appropriate policies given the roles of the principals.

Policy is strongly considered by the COI federated facility, SA marine facility and the Org affiliation and resource sharing use cases. Policies can control resource access or use, based initially on resource state.

The types of marine assets for which policies can be constructed include whole observatories (possibly composed of observatories), platforms (possibly composed of platforms), and instruments (possibly composed of instruments). Resources like data products can also have policies applied. Policies applied to an aggregating resource like a platform or observatory are expected to flow down to contained resources, unless otherwise specified.

In this Release policy options are relatively few, and their setup is changed relatively rarely. The Release 3 observatory will support more flexible policy capabilities to control observatory operations.

(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.
  1. Dec 26, 2011

    Kohei Honda says:

    This is one of good descriptions of interesting protocols/use cases, which invol...

    This is one of good descriptions of interesting protocols/use cases, which involve substantive interactions and "policies". In fact policies involved may not be all of this, and that shows how complex policy descriptions can become: it cannot be application programmers' responsibility to take care of all that.

    Well, it is of course dangerous if any application can alter policies.

    And well, an application will be written this year and one may add new policies five years later. So there is no way an application can be very well aware of it. 

    Well, all this is standard, starting from the age of Multics.

    What is not standard here is that we are aspiring to be end-to-end in OOI CI terminology, that is we want our dear oceanographers can write and change and delete and in effect understand the status of these policies associated with importan actions. 

    For example, one of the directors of ION or an external security auditor or whoever with good reason and enough privilege, may wish to see what is the current status of information security in OOI in the year 2032.  Well quite a few policies will be written and updated and deleted by then. How can she or he can get what is happening, how can she correct the wrongs if any, how can users feel all are being operated fairly? The more successful we are, the more needs will be there for such descriptive transparency (by this term I mean: it is easy to understand what is happening, whatever that means for a given level of personnel).

    If we solve this then it will be easy to use (we can make it easy to use) hence there will be more and more accumulation of policies and their updates and therefore, well, we may need a new articulation, new services, etc. But first we want such a situation --- that everybody very easily and reliably use such facility.

    * * * 

    The infrastructure to be able to solve this problem is not just *cyber" infrastructure: and it is part of this programme, I believe, that we are going to accumulate substantive UX experiments to build non-cyber infrastructures. But the cyber part should give a basis for all these human-level exercises which will ensue. Such description (and all those in and out of R2 LCA) are interesting because of this dynamics.