|Questions and answers about OOIN Release 2 are included below, grouped by category.|
The OOIN User Documentation will be in Confluence through Release 2 (R2). Further development beyond R2 will be determined by the scope of features for future releases. Tentatively, an interactive online help system is scheduled to be provided in Release 3. Added Feb 28, 2013
In Release 2, the following browser list will be supported:
- IE 10 on Windows 7
- Firefox 13 & 14 on Windows 7, Mac OS 10.6 & 10.7, and Linux (Ubuntu)
- Chrome 19 & 20 on Windows 7, Mac OS 10.6 & 10.7, and Linux (Ubuntu)
- Safari 5.x on Mac OS 10.6 & 10.7
More recent versions may also be supported as they are released, if they do not require significant software modifications. CI intends to support all the common operating system/browser/browser version combinations, consistent with available resources. For further details see, Product Description - Release 2 Browser Support. Edited Aug 07, 2013
The system was designed for 1440x900; note that below the minimum supported screen resolution of 1024x768, formatting of pages may not display appropriately. Added Aug 20, 2013
The term historic was used as a placeholder in early development to distinguish between older and incoming real-time data. That terminology is no longer utilized as there is now only one data graph with older data that is updated with new data as it is received. The update should occur automatically but a refresh of the current screen will also enable the user to activate the update, see the User Documentation for further details on Interacting with Data . Added Apr 04, 2013
It's an easy way to view and choose variables, raw data is parsed into a canonical format. This allows for no loss of precision and is akin to L0 data in that it is unprocessed. For a given instrument, multiple parsed components may be available that represent the various data streams coming off the device. Edited Apr 04, 2013
What are the various data products and how does the process of getting from one type to another work?
The data available through OOI can be as raw, parsed, L0, L1, or L2. For further definitions and to understand the process of getting from one type to another see the User Documentation Data Products page. Added Apr 04, 2013
(For example, 2 sensors on one platform, or 2 nearby sensors)
This is anticipated to be available in a later version. The intent is to have the ability to overlay data from different data products, for instance, data from two different sensors on a single platform or from two different instruments. Edited Apr 02, 2013
Yes, from the Data tab section of any Data Product, the user can print directly or export the graphic image via two icons. In the far upper right of the data block, the graphic image can be printed directly or exported as png, jpeg, pdf or svg. For further details, see the User Documentation Interacting with the Data View.
Additionally, more options of image downloading are available after downloading the data and utilizing the ERDDAP page options. For further details, see User Documentation on Downloading an Image. Added Aug 06, 2013
Will there be one unified list of commands that is found for all instruments or will they be instrument specific?
Answer is actually both, there is a set of common commands and there can be additional commands specific to an instrument. For a list and description of the common commands see the User Documentation Command a Resource page. See the individual Instrument Operational Specification (IOS) page for details on instrument specific commands. The IOS pages can be accessed from the full instrument list at https://confluence.oceanobservatories.org/display/instruments/OOI+Instruments. Added Apr 04, 2013
Currently produced events and their descriptions are included in the User Documentation Events page. Any Facility Members can subscribe to specific events for a given resource, see Subscribe or Unsubscribe to a Resource page for more details. Added Aug 15, 2013
Is there a way for users to add notes and comments for data products and instruments, to annotate them?
Yes, Facility Operators and above can create manual events for a resource, that will show up in the Recent Events tab, see the User Documentation Manual Entry to Event Log page for details on functionality. Edited Aug 15, 2013
Is there the ability in the system to expand events to include detection and notifications for science events.
Yes, the system is setup to allow new types of events to be added in the future, such as program specific science events. Though, this functionality is not fully implemented yet. Added Aug 15, 2013
Currently status for a marine resource is shown in the upper right of its title bar. For more details see the User Documentation Status Flag Details page. Added Aug 12, 2013
Actual plans for future scope are being determined but below are initial design plan depictions.
- A graphical depiction of the status page for a platform:
- A sketch view of a later development of the information content of the page:
In the later view, the evolution of "status" into the "Power history," "Communications flow," "Data flow," and "Location history" indicators can be seen that came out of discussions with users.
These mockups and others are posted at https://userexperience.oceanobservatories.org/. Edited Aug 12, 2013
If you browse through the Status pages in "Low-Fidelity" views (listed after the Pixel-Perfect views in the left-hand navigation pane), you will note that the pages all have the same basic structure: Quick status at the top of the page (in fact, this is on all pages), followed by Summary status, Overview status of hosted components, and then any further detail we have available. On the Observatory page, the hosted components are the sites that the observatory comprises, for Sites they are the Platforms (and stand-alone Instruments, if any), for Platforms they are hosted Platforms and Instruments, for Instruments they are Sensors.
With this design, we hope that the user will be able to develop and update a well-structured current operating picture by drilling down or navigating up through the hierarchy of marine resource relationships, and that they can then use this mental structure to use lateral short-cuts (e.g., jumping from an instrument on one platform to a similar instrument on nearby platform) to get to their locus of interest quickly and efficiently. Of course, they will also be able to bookmark pages and, eventually, configure their starting page, so that they can go directly to the views they use frequently.
The Dashboard or landing page for OOIN consists of a Map view or Resources view and is the jumping off point for exploring or navigating resources, and is accessible for the beta version at http://ion-beta.oceanobservatories.org/. For more details about the Dashboard views, take the User Documentation initial Tour of the OOIN Interface.
The OOI homepage is the starting point for OOI programmatic information and details, and is accessible at http://www.oceanobservatories.org/. Added Aug 06, 2013
The lifecycle states show the current state of the resource in a broad way, similar to stages that the resource would go through. Some of the current lifecycle states are developed, integrated, and deployed. See the User Documentation for the available lifecycle states and their current definitions.
The status shows a more immediate and up to date condition of the resource, for more details, see the User Documentation Status Flag Details page.
Note that not all resources within OOIN will display a status nor are all the lifecycle state options pertinent, for example Data Products have a lesser number of Lifecycle States available and do not display a status. Added Aug 06, 2013
The deployment block on a resources Facepage conveys the timeframe/temporal bounds for the deployment and that particular association. Note that the OOIN system allows for the tracking of a specific instrument being deployed or associated with varying platforms or stations over the course of its lifetime. The deployment functionality is a key part of that temporal tracking of resources and their associations over time. See the User Documentation for more details about Deployments and Associations.
Additionally, the advanced search function allows the user to search over specific temporal bounds for data products and other resources within OOIN. The User Documentation outlines the advanced searching functionality available. Added Aug 14, 2013
How does the information represented in the OOIN application connect to information in the SAF application?
The Integrated Observatory Network (OOIN) application will be preconfigured with information from several sources:
- The SAF database
- A spreadsheet augmenting the mapping between SAF and OOIN (created by Ed Chapman, Sheri White, Mike Mulvihill, and Matthew Arrott)
- A spreadsheet of all DPSs (for Data Product attributes and variables)
- A spreadsheet of all IOSs (for Instrument attributes)
As we refine the preload process and information is gathered, more sources may be added. Edited Apr 02, 2013
The platform tab within a platform Facepage, allows for the case where there is a sub-platform on a platform. There is currently not a good example of this functionality but the need for this type of association is anticipated. The platform tab within a platform Facepage will list the associated sub-platform, description, and link to its Facepage. The User Documentation page Introduction to OOIN and its definition of terms is an available reference. Added Aug 13, 2013
Yes, there is a grid showing the Allowable Activities by User Role in the User Documentation.
The roles give general capabilities, currently there is no way to restrict which attributes of a resource can be modified by which role. If the user has editing for a resource, they can change each and every attribute associated with that resource. There is the ability to enhance the granularity of access control in future scope based on MIO feedback. Added Aug 15, 2013
That is for example, can the observatory manager also perform the functions of the operator and data operator with higher level roles inclusive of the lower level roles- nested?
What process for approval will be followed when an individual is to be added or deleted as a marine user?
I expected a list of user names to be presented (e.g., RSN administrator, RSN Operator, RSN engineer).
I expected a list of permissions (policies) to be more detailed for each user name.
Here is a list of the OOIN concepts defined:
- A User Account represents an individual human user and stores their preferences and settings. One of these settings is their Name, which is they can edit themselves and is primarily used for human to human communications, e.g., if one operator needs to call another. OOIN users do not need a special OOIN User ID (login name) or password, since the login process is handled through the institution of their choice.
- A Policy is a set of rules defining what actions someone is allowed to perform on a particular Resource.
- A Role is a name for a set of Policies. This is a convenience that takes advantage of common patterns of use to make Policy assignments and management easier. Roles are merely definitions of sets of access permissions, and can be assigned to any number of users.
- Access permissions are either requested by a user or offered/denied for a particular role by an Administrator.
In Release 2, the system will provide a set of built-in Roles and internal Policies to support them. These are
- Observatory Administrator
- Can make changes to the Observatory information itself (e.g., its name)
- Has authority to confer Roles to users
- Can post events related to the Observatory as a whole
- Observatory Manager
- Can make changes to the Observatory configuration, including creating and modifying Sites and change lifecycle states of Observatory resources
- Can post events related to individual Sites
- Observatory Operator
- Can operate all Instruments and Platforms in the Observatory
- Can post events related to individual Instruments and Platforms
- Observatory Data Operator
- Can operate (manipulate) all Data Products in the Observatory
- Can post events related to individual Data Products
- Observatory Member
- Can subscribe to events related to observatory resources
- Has personalized preference settings
- Can browse and view Observatory resources
Note that these Role definitions and their supporting Policies are common to all Observatories (RSN, CG, EA), and the permissions are granted to entire classes of resources across the Observatory. In other words, if a user is granted the role of Observatory Operator in the RSN Observatory, they will have permission to operate all Instruments and Platforms in the RSN Observatory. (If a user needs to operate equipment in two different Observatories, they would be granted the Observatory Operator role in each.)
Roles are merely definitions of sets of access permissions, and can be assigned to any number of users. So you can have as many Admins or Managers as you like. And one user can assume as many Roles as needed (both within and across Observatories). The system is fully capable of allowing us to define additional roles that play on permutations (e.g., admin+operator, admin-operator) if that is needed with higher level roles inclusive or exclusive of lower level permissions.
We (CI) will implement more tailored Roles and Policies, for instance, defining a Glider Operator role that can be applied to a specific set of gliders in the Observatory, as needed, and will be working with the Marine IOs during the R2.0 Beta R2.0 releases to determine their specific needs. The R2.1 release includes the ability for an Observatory Administrator to add new Roles themselves by importing a Role definition that is defined outside the OOIN system (this may be in a simple programming-language-like format) and which draws on the Policies implemented in the system.
There are two ways in which a user can be granted a Role: they can request to be granted a Role, or the Observatory Administrator can offer them a Role. In either case, one party initiates the request/offer, the other party is notified that the request/offer has been extended, and can then Accept or Decline. You may already be familiar with this hand-shaking model from Google Drive and many mailing list systems. The key is that anyone can make a request and no one can be forced into a role.
For the convenience of the Marine IOs, CI will pre-configure OOI staff accounts, including granting Roles, as requested. We will be working with you during the Release 2 Beta to determine your specific needs.
A Facility Administrator (there can be more than one) grants permission to roles and access to devices, can offer roles, and has the ability to review who has what roles within a Facility. A Facility member can request or be offered the Facility Operator role. With the Facility Operator role, some general functions are available but access to and the ability to command specific instruments and platforms must be requested and granted separately for each device. General information about the User Roles is available in the User Documentation, it also outlines for a user how to Establish User Role & Access Permissions and gives details on how to Manage Roles & Access for the administrator. Added Aug 14, 2013