The VSS Taxonomy defines what data "entities" (Signals and Attributes) we can deal with.  In addition to VSS itself, we see a need for defining the data-exchange formats (e.g. actual message content whether in JSON or other) for measured values of those Signals.

Certain protocols include part of this, but others, such as GraphQL are generic and need definition of types, schemas, etc. to be used.

Signal:

• An data entity defined by its identifier
• In practice we here mean the absolute path of the node in a VSS taxonomy

Request:

• A request to deliver a measurement or measurements, as according to the chosen communication protocol.
• For example an instance of GET in VISS/W3C Gen2, or a Query in GraphQL, or ...
• This could request a set of data that has already been measured, or an instantaneous value.

Job:  

• A request to make measurements (typically some time in the future)
• TODO: Check SENSORIS work on this.
• Clarify difference Job/Request

Record:  (or Measurement, or Observation)

• A single measured data value
• Record Types indicate which Signal has been measured,
• Record Types are used to represent data with associated metadata, as needed for different cases
• Example of types:
  • Just the value.
  • The value plus a timestamp
  • The value plus a timestamp plus a timestamp accuracy information
  • The value plus additional qualitative information

PlainRecord, TimeStampedRecord   (not specifying the signal, only the value)

+ Record types which specify the signal inside.

TODO: For Snapshot you need a Record Type that also includes the signal name.

"Container" – naming of this? 

   A delivery of data sent at a particular time.

... metadata ...

  * Job ID
  * Sequence number (if partial delivery of a Job)
  * Values container (of type Snapshot, Bundle, or single Record)
 

NOTES: General metadata needed for measurements:

• Vehicle identity – should this be special or is a measured instance of VIN number (defined already in VSS) enough?
• <Benjamin to add>

Snapshot:

• Several measured values, of different signals, each having a
  relationship to each other because they were measured "at the same time"
  (which means within a defined time period, of any chosen length)
• A snapshot is built up of several Records, and additional information
• Clarify if snapshot should have only one measurement per signal.
• Explain timestamp inaccuracy...

Bundle:

• Several measured values _of the same signal_, taken over a period of time.
• A bundle contains time stamp for each value
• A bundle is a collection of Records

Stream

• Continuous delivery of data points according to... (complete this)
• Not only a different container type.  It deals more with the delivery method (constant stream compared to atomic message)
• Does not have a fixed start/end time
• Delivers a stream of Records
• Could delivery side-band information also (e.g. Job information)

Examples, in JSON

PlainRecord: (one Record Type)

{
   "value" : " 100.54"
}

TimestampedRecord:

{
   "ts" : "20200319123245Z123456" # Zulu time ISO std + microsecond - to be clarified
   "value" : "42 "
}

Bundle:

{ 
    "signal"  :  "vehicle.body.cabin.temperature"
    "count"   : "132"
    "values" : {
        { 
            "ts" : "20200319123245Z123456"
            "value" : "42 "
        },
        { 
            "ts" : "20200320120101Z100000"
            "value" : "43"
        },
        ...
    }
}

Snapshot:

{ 
    "timeperiod" { 
        "start" : "xxx",
        "end" : "xxx"
    },
    "measurements" {
     {    
        "signal" : "vehicle.body.cabin.temperature",
        "value" : "22",
        "ts" : "20200320120101Z100000"
     },
     {
        "signal" : "vehicle.drivetrain.engine.rpm.average",
        "value" : "3200",
        "ts" : "20200320120101Z100000"
     }
}