v3 - include context (& maybe specialValue) in series?

[alaendle]

The schema should enforce the semantic of an telegram as good as possible - so I stumble over the context design where the key of a context "...shall be the name of a measurement point (element of series element)". This leaves room for interpretation - first a simple check of the schema could no longer determine if the content of a telegram is valid; second how should a recipient handle invalid context references - just ignore them or discard the whole message, or just store/forward them in/to 3rd party systems. So I wonder why you haven't created a series object that includes an optional context? My guess is that you want to be as much as possible backwards compatible with v2 - but since you introduce breaking changes anyway (e.g. mandatory/renamed time field) maybe it's time to reconsider this design decision. The same is true for special values - and maybe even things like data types could/should be encoded in a way that a schema check really validates a PPMP telegram.

[ameinhardt]

The series is a merely an additional json structure. I don't see a value add of putting the context into the series rather than directly into the (Process-)Measurement. Also, the Special Values are in that scope as well. So the a custom context could apply to them as well. PPMP enforces the syntax but does not aim to validate the semantics of the content. By providing the freetext context namespace, you can provide further links to an elaborate custom semantic model.

[alaendle]

Hmmm --- obviously I didn't got the concept behind it. From the standpoint of a sender or receiver - is any telegram that passes the schema valid? Or is the schema definition really only a syntactical thing without any additional significance? And it is part of the shared assumptions of a sender/receiver pair to define some kind of "grammar" how naming of series/specialValues/etc relates to each other? Or is this rule-set part of the unide specification, but not represented in the schema (e.g. as textual comments)? I tend to believe it could be useful to have something stricter than a pure naming convention - so the idea was to avoid the references by just putting the annotations into the series element (because there seems to be a 0..1-relationship anyway).

Attention! Only guesswork: Can it be the case that this is more a design than a modelling problem? I guess what bothers you is the reference from the series to a context (in an object oriented sense). And I would agree - because the series is interpreted in a context and not "has a" context. But from a document oriented point of view a context without a series doesn't exist (or is at best useless) - so why should the document model allow to define absurd/invalid documents?

[ameinhardt]

Hi @alaendle, PPMP doesn't prevent meaningless content as much as (x)html allows meaningless content and wrong/dead links on a webpage. Yet, html was a basic structure that greatly facilitated information sharing. Do you want to propose any reasonably simple, polyglott way to validate constraints in ppmp messages any better rather than JSON schema?

[alaendle]

Hello @ameinhardt, sorry if you got me wrong, I'm certainly not arguing against JSON schema. The idea was only to evolve the schema in a way that if a message is valid the chances it's also reasonable are high.

With this mindset I wondered if it would be advisable to simplify the schema by avoiding the references from context-elements to a series-element by including the context-object in the series-object. E.g.:

"context: { "<NAME>": { ...variousLimitsUnitsEtc... }, ... }, "series": { "<NAME>": [...values...], ... }

might be changed to a structure like the following to avoid name mismatches/inconsistencies:

"series": { "<NAME>": { "context": { ...variousLimitsUnitsEtc... }, "values": [...values...] }, ... }

Since I now have recognized that specialValues are special to the process telegram and might include different series lets just focus on context for now. I'm aware of the trade-off to introduce an additional series-Object - on the other hand we avoid the redundant naming of the series (but since the context is optional this benefit not always takes effect).

I just wanted to convey the idea. I hope I could clarify my intention now; if the proposal is conflicts with the PPMP design principles please close this issue.

[ameinhardt]

@alaendle, so there would be different context possible for each measurement point? Is that likely in reality? At first, it seems very redundant

[alaendle]

@ameinhardt I didn't get the redundancy argument - the current draft collects all context fields under an object with a series name - so where is redundancy created if this objects moves into the series (it will still be optional). The only redundancy I encounter is the overhead of the series object.

To build up an example:

v3-style:

    {
      "code": "0000 EE01",
      "name": "heating up",
      "phase": "phase 1",
      "result": "OK",
      "ts": "2019-02-11T14:41:28.593Z",
      "context": {
        "pressure": {
          "namespace": "https://mycompany.com/productvariants/5986",
          "unit": "Pa",
          "limits": {
            "upperError": 103000,
            "lowerError": 99000,
            "upperWarn": 102000,
            "lowerWarn": 100000,
            "target": 100950
          }
        },
        "force": {
          "limits": {
            "upperError": [
              29,
              27,
              26
            ],
            "lowerError": [
              23,
              21,
              20
            ],
            "upperWarn": [
              28.5,
              26.5,
              25.5
            ],
            "lowerWarn": [
              23.5,
              21.5,
              20.5
            ],
            "target": [
              26,
              24,
              23
            ]
          }
        }
      },
      "series": {
        "force": [
          26,
          23,
          24
        ],
        "pressure": [
          100952.4,
          100946.32,
          100944.2432
        ],
        "temperature": [
          45.4243,
          46.42342,
          44.2432
        ]
      }
    }

proposal:

    {
      "code": "0000 EE01",
      "name": "heating up",
      "phase": "phase 1",
      "result": "OK",
      "ts": "2019-02-11T14:41:28.593Z",
      "series": {
        "force": {
          "context": {
            "limits": {
              "upperError": [
                29,
                27,
                26
              ],
              "lowerError": [
                23,
                21,
                20
              ],
              "upperWarn": [
                28.5,
                26.5,
                25.5
              ],
              "lowerWarn": [
                23.5,
                21.5,
                20.5
              ],
              "target": [
                26,
                24,
                23
              ]
            }
          },
          "values": [
            26,
            23,
            24
          ]
        },
        "pressure": {
          "context": {
            "namespace": "https://mycompany.com/productvariants/5986",
            "unit": "Pa",
            "limits": {
              "upperError": 103000,
              "lowerError": 99000,
              "upperWarn": 102000,
              "lowerWarn": 100000,
              "target": 100950
            }
          },
          "values: [
            100952.4,
            100946.32,
            100944.2432
          ]
        },
        "temperature": {
          values: [
            45.4243,
            46.42342,
            44.2432
          ]
        }
      }
    }

[ameinhardt]

In my opinion that is too much flexibility to allow different namespaces even in different measurement points. I'd rather move it a level up to telegram level