|This page provides an overview of the Integrated Observatory Network's Resource Model. The term "Resource" represent an entity in the system that captures information about a physical, computational or informational asset managed by the ION system. All resources are described by an object in ION's common object model, stored in the Resource Registry. Resources are managed by services specific to the type of resource.|
- The Glossary for the definition of terms Resource, Information Resource and Taskable Resource.
- The Resource Model appendix for the specification of specific resource types and base classes
- The Resource Registry for the services that operate on resources of any type and their definition
- The Services overview page for a list of specific services managing specific types of resources
Resources are assets within the OOI Integrated Observatory that can be owned, described and controlled. We speak of resources under OOI governance. OOI resources are grouped into the following high level categories:
- Information Resources: represent artifacts existing in electronic form that do not exhibit active behavior
- Taskable Resources: represent assets that have behavior and internal state; may be physical or computational, within the system or external to the system
- System Resources: represents elements used internally in the system that do not fall into one of the two above categories
Figure 1 shows a class diagram decomposing the high level categories of Resources in the system. It also shows Associations, explained below.
Figure 1. ION Resources and Associations (OV-7)
See the Resource Model appendix for a detailed specification of OOI Integrated Observatory Network Resource Types and common base types, including the high level categories listed above.
The following pages contain detailed descriptions of resources and their associations by subsystem:
- COI Resources and Associations
- CEI Resources and Associations
- DM Resources and Associations
- SA Resources and Associations
- AS Resources and Associations
Note: Resource types themselves are represented in the ION Resource Model as resources, in order to keep the architecture self-similar and extensible. New resource types can be added at run-time.
Associations are first class information objects in the system that reference 2 resources (see Figure 1). Associations belong to neither of the two resources they associate and can be managed (i.e. defined, created, owned, manipulated and deleted) independently.
Associations provide the following information:
- A subject resource. The resource from which the association logically originates from
- An object resource. The resource to which the association logically points at
- A predicate. A verb determining the interpretation of the association, e.g. "hasModel" or "ownedBy"
- Additional association metadata, including creation timestamp, keywords and ordinal
The COI Resource Management Service provides a higher level management interface that enables to add new resource types and new resource type lifecycle workflows. It also enables the generic management of resources of any kind through generic interface abstractions.
Resources are described by objects representing the resource's metadata attributes. Resource objects follow definitions in the common OOI object model. In particular, the schema of the object for every different resource type is constrained by an object interface definition.
Resources can be queried via the Resource Registry or via the DM Discovery Service. Associations are the primary mechanism to find resources linked to other resources, representing a graph database.
All resources follow lifecycle models determined by the resource type. See below for the Resource Lifecycle, and more details here.
A Resource Lifecycle defines the set of possible states for a type of Resource. A Resource instance changes its lifecycle state based on actions performed by actors, such as Provider (Owner), Operator, Consumer and the System (Infrastructure). All actions and their resulting resource lifecycle state changes apply under system governance and may have dependencies; for instance, a resource must be integrated before being ready for deployment. Depending on the authorization level of the Actor, as established by the Owner, Operator/Maintainer or other authorized Actor, the set of actions available for that Actor is a subset of the overall set of actions. Consequently, the available set of state transitions that may be triggered by the Actor is a subset of the available states of the Resource Lifecycle.
Figures 2 and 3 below show the common resource lifecyle states for all types of resources under OOI governance. Lifecycle state decomposes into the 2 following components:
- Maturity indicates how far a resource is along the process of being fully integrated and accessible by other users
- Availability indicates the degree of exposure to resource consumers
Maturity state follows the lifecycle workflow depicted below. Some states may be optional or unused for certain resource types to simplify dealing with the resource. The initial state for resources may vary if a simplified resource workflow is applied for certain resource types:
Figure 2. Resource Maturity Lifecycle (OV-6)
Availability state follows the lifecycle workflow depicted below. Some states may be unused for certain resource types to simplify dealing with the resource. The initial state for resources may vary if a simplified resource workflow is applied for certain resource types:
Figure 3. Resource Availability Lifecycle (OV-6)
See here for detailed description of the resource lifecycle:
OOI's Common Object Model is the basis for specifying objects of different types, and for transporting, persisting and manipulating them. Objects are used as the bases for ION Resources, as described above, as ION events, and as special and shared structures for transporting data in uniform ways through the system.
The Common Object Model guarantees that objects of the same type are represented throughout the system in a uniform way, for instance when encoded in a Python based capability container for transport via messaging to a Java based consuming container.
Science Data, in particular, is described using the Common Object Model, see the Science Data Model. The actual values of science data are not represented by objects, but as coverages and granules in their own specialized representations.