Ordered Device Facets

A sketch of the facets that describe a device

While the ontology itself will not have the hierarchical structure of an outline, it may be useful to view the device facets this way; this is the facet list re-ordered into main categories.  Members, please feel free to update this.

This page last updated: 2010-08-09 (according to comments in 2010-07-27 telecon)

These symbols indicate status of inclusion into the ontology:

  • √√: included and stable
  • : provisionally included
  • +: assigned for inclusion (see issue tracker)

These indicate particular comments during discussions of the group:

§1: During 2010-07-27 telecon.

 

The facet outline is as follows:

  1. Device Construction
    1. √ Original Manufacturer
      1. √ official original name of manufacturer
      2. √ current name/point of contact (i.e., latest company name) for that manufacturer
      3. √ current web site
    2. √ Model
    3. √ Physical
      1. √ Dimensions
      2. √ Weight
      3. √ Buoyancy
      4. √ Materials
    4. √ Absolute physical limitations/restrictions
      1. √ Survival pressure range (depth/pressure limits)
      2. √ Survival temperature range
    5. Component mfgrs, models (JBG: these fold into sub-device's properties)
  2. Functionality: Parameters, measurements, atomic phenomena
    1. √ Measured medium (liquid, water, saline water, fresh water, air, solid) (ref: OGC 'feature type')
    2. Innate attribute measured (temperature, total dissolved salts, water current direction) (ref: OGC 'phenomenon')
    3. Measurement taken (temperature, conductivity, acoustic doppler return) (ref: OGC 'measurement')
    4. + Output provided: (temperature, salinity, water speed and direction) (ref: OGC 'observation result')
    5. + Measurement technique note: reference OntoSensor for more
      1. Gross method: sensing or sampling
      2. √ Engagement: active or passive
      3. √ Sensing method: In-situ by contact, in-situ at distance or remote
      4. Detailed measurement process:
        1. Process: different processes can be used to obtain measurements; for example, temperature can be measured by contact sensing or by remote infrared sensing
        2. Sample scheme: Does the device take a spot sample (i.e. last, first, or center?), or burst sample, or continuous measurements? Does it do an average, boxcar, running mean on these measurements?  Does it control sampling with its own clock (type of clock: a counter, or a "real" clock)?
  3. Operational restrictions, capabilities, processes
    1. Usage
      1. √ Deployed Medium (where device must be to perform: liquid, water, air)
      2. √ Deployed Platform (on what can the device be deployed)
    2. Interfaces (§1 Not so much important)
      1. mounting options (how can I mount it on my platform)
      2. master input/output interface(s) (how can I communicate with it?)
        1. connector attributes
          1. form factor
          2. pin out (wiring)
          3. protocol
          4. communication throughput capacity
        2. Control: commands available
          1. during setup
          2. during operation
          3. during shutdown/offline
      3. slave Input/output/physical interfaces (what else can I attach to it, and how)
        1. mechanical form factor (bolt holes, etc.)
        2. connector attributes
          1. form factor
          2. pin out (wiring)
          3. protocol
          4. communication throughput capacity
    3. + Operational Restrictions
      1. √ Operational pressure range (depth/pressure limits)
      2. √ Operational temperature range
      3. √ Power requirements
      4. √ Data storage capacity
      5. √ Available self-powered operation time
      6. √ Minimum on-time (before sampling)
      7. + Water or wave tolerance, RF tolerance, other interference problems
    4. √ Measurement Capabilities (may vary between sensor components and device)
      1. √ Measurement frequency
      2. √ Accuracy
      3. √ Precision
      4. √ Response time
      5. Measurement range
    5. + Data processing requirements
      1. Processing: highest data level produced (NASA level 0, 1, 2, 3) (note: per parameter? JBG)
      2. Processing software required to access data (none, existing public software, existing public algorithm, proprietary)
      3. Quality control procedures defined/available
  4. + Physical Processing
    1. √ Quality assurance procedures
    2. √ Calibration procedures
    3. √ Required/suggested calibration schedule
    4. + Handling requirements
    5. √ Maintenance procedures
  5. Logistics
    1. Availability status
      1. currently manufactured
      2. currently sold (retail, used)
        1. cost range
    2. √ Is itself consumable
    3. √ Has consumable components
  6. √ Manufacturer Documentation
    1. Manual(s) location
      1. Users, Programmers, Installation, Operation, Software
  7. Instance 
    1. Identification
      1. √ Serial Number
      2. √ Unique Identifier
      3. √ Owner
      4. √ Point of Contact
      5. Date/location of manufacture
      6. Firmware version
      7. Software version
    2. Transaction
      1. Purchase metadata (date, location, reference materials, price, purchaser)
      2. Shipment metadata
    3. Operational availability
      1. Available in-house?
      2. √ Functionality status (unknown, operational, verified, calibrated, broken)
      3. Current deployment status
    4. History
      1. Current Location (§1 For non-deployed devices?)
      2. Deployments (is this a separate, existing ontology?)
        1. √ Start- and end-dates
        2. √ Performance/quality/known issues
        3. √ Dataset links
      3. Calibrations/refurbishments
        1. √ Calibrations (related with CalibrationProcedure class)
        2. Refurbishments
      4. Annotation Logs (users, operators, calibrators, deployers, maintainers)
      5. Device Logs
    5. Planned usage