SENSOR User Best Practices and Infos

• What SENSOR is
  • a software to manage sensor metadata

• What SENSOR is not
  • a warehouse management for sensors
  • a laboratory management system
  • storage system for sensor or sample data (we have other systems for that)

• What is an item?
  • item is the general term for platforms or devices
  • be sure to distinguish between item type and instance of an item
  • several platforms of a specific platform type may exist
    • g. Polarstern and Heincke are platforms of platform type ‘vessel’
  • several devices of a specific device type may exist
    • g. TM_Ice_Corer_2 and UAF_TM_Ice_Corer_3 are both devices of device type ‘corer’’
  • Generally, a platform carries 1-n devices, which in turn can also have their own (sub)devices

• Short names
  • catchy abbreviations of your device or platform names
  • cannot be modified once they are created!
  • they are very important, because they are used by linked systems
  • you cannot have two devices with the same short name under one parent device
  • to avoid naming conflicts, one could use the serial number as a short name suffix (Example: adcp_23984059)
    
    
• URNs
  • URN means Uniform Resource Locator and points to exactly one device
    (Example: vessel:ms_hel:fb_740602 points to the ferrybox on MS Helgoland)
  • They consist of "platform type + short name(s)"
  • The path to your data is also based on the device / platform URN

• Contacts:
  • Contacts can have different roles e.g. Editor, Owner, Principal Investigator, etc.
  • Make sure to have the following contacts assigned to your device
    • At least one Editor: an editor is allowed to modify the device/platform and its sub devices and acts as contact person. The editor may be inherited from the parent device/platform
    • At least one Owner:
      • “Institute” owning the device. Select your institute contact from the list of contacts or send a request to o2a-support (at) awi.de to do so, if it is not available
    • Add Contact person with role 'Principal Investigator' for the device who can either edit the device in SensorWeb or knows who to contact this for.
    • Add contact “polarstern dship” with role “dship connector” to have devices available in DSHIP
  • Note: Contacts with role 'Editor' or 'Data Provider' will have write access on the MOSAiC Central Storage in the respective Device Directory

• Collections: Add collection(s) to specify the project in which the sensor is being used. This facilitates the search for sensors used in a certain project and grouping sensors in AWIs data portal (data.awi.de)

• Item States:

  • Construction:

    • Seen only by “editor” of this device under “My Devices”
      • not Ready for publication

    Public:

    • Seen by everybody (no Login)
      • Ready for publication
      • Public devices should not be deleted. (Measured data would loose metadata)

    Store:

    • Device they are not in use
    • Device at the store

• Versioning
  • Every time you add an action of type deployment, mount, calibration or commissioned, a version of your current sensor configuration is permanently stored
  • All versions get a citation with a persistent identifier (like DOI) and therefore can be referenced in publications
    • Because of that deletion of versions is always critical, because we never know, if they are already referenced in other publications
    • They can only be deleted by a system administrator
    • Just think about a version like a data publication
  • Enter changes in the order they were done on the device / platform
    • This is a best practice, because once created versions cannot be modified afterwards
  • Every device should be versioned before first device operation with action type ‚comissioned‘ and label ‚PS122-Leg-No', e.g. "PS122-1" for Leg 1.

• Cloning (Copying)
  • A device / platform can be duplicated with all of it's attributes
  • Be sure to enter everything you want to be cloned before cloning

• Reassignment (Move device)
  • Every reassignment triggers the creation of unmount and mount events in the source and target devices / platforms by default
    • Event creation can be switched off, if you don't want this reassignment to be documented for the future

• Actions (Events)
  • Example actions are: Deployment, Recovery, ...
  • Action labels can be auto-completed for Polarstern and Heincke journeys
  • Please type at least three characters to start auto-completion (Example: "PS1...", "HE4...")
  • Actions can be inherited to all sub-devices
    
    
• Device / platform statuses
  • A device / platform can be in different statuses such as
    • Construction
      • Not publicly visible
      • This status is normally used for initial configuration
    • Public
      • Publicly visible
    • Store
      • Device / Platform is not in use and may be used by other scientists
    • Create other users
      • If you want others to also manage your device / platform, just enter them as editors under the contact tab
• Resources: 
  • Upload or link to documents containing SOPs, Data Formats, Manuals, Technical documentation 

  • We strongly encourage you to use the second choice for documentation that should be published along with your scientific data. Please upload the document to a place with a persistent identifier. AWI people can use the ePIC system and use the corresponding handle.  Others may have the possibility to use your institutional repository ,if available.  If not available something like zenodo.org might work.  At the end a DOI would be desirable like doi:https://doi.org/10.1093/gigascience/giz067

• Examples for device structures and relations between devices 
  • CTD and Nutrient Analyser
    • CTD: vessel:polarstern:ctd_watersampler, with subdevices:
      • Altimeter: vessel:polarstern:ctd_watersampler:altimeter
      • Watersampler sbe32: vessel:polarstern:ctd_watersampler:sbe32
      • Conductivity Sensor sbe4: vessel:polarstern:ctd_watersampler:sbe4
      • …
    • Nutrient Analyser: laboratory:awi-e-2080:iarc_aa3_iarc_rember
    • relate run of nutrient analyser to CTD-cast from which water sample was obtained:
      • create action for nutrient analyser and
      • add new “Event Relations” of type “Deployed with” and choose CTD for “Related Root Item Urn”
  • Remotely operated vehicle ‘Beast’: vehicle:beast
  • Icecorer:
    • Used on pack-ice platform called ice_station
    • pack_ice:ice_ps:tm_ice_corer_2
  • Snowpits in which density cutter and snow micro pen is used for sampling/measuring
    • pack_ice:parent_snowpit with subdevices
    • Snow Micro Pen: pack_ice:parent_snowpit:slf_smp02
    • Snow density cutter: pack_ice:parent_snowpit:density_cutter01
  • Handheld CTD
    • Can be used from multiple platform types, e.g. vessel, pack-ice, small_boat, etc.
    • Use platform “Unassigned Platform” of platform type ‘unassigned’
    • unassigned:unassigned_plattform:handheld_ctd

Ingest of Data for Dashboard

see INGEST