Wrong representation of measurement type in sensor report

[shalikasingh]

Hi @mgh128,

We believe the value of the "type" attribute within the sensor report element in the EPCIS Document SensorDataExample7.jsonld is not compliant/valid as per the CBV document.

Invalid part :

"sensorReport" : [
             { "type": "rail:Abc", "stringValue":"111100001111000011110000", "deviceID":"urn:epc:id:giai:4000001.112"},
             { "type": "rail:Def" , "booleanValue":true, "deviceID":"urn:epc:id:giai:4000001.113"},
             { "type": "example:Ghi", "stringValue":"SomeString", "deviceID":"urn:epc:id:giai:4000001.114"},
             { "type": "example:Jkl" , "hexBinaryValue":"F0F0F0", "deviceID":"urn:epc:id:giai:4000001.115"},
             { "type": "rail:Mno" , "uriValue":"https://example.org/rail/someSectorSpecificValue", "deviceID":"urn:epc:id:giai:4000001.116"}

Below have quoted from 2021_04_13t CBV 2-0 COMMREV, which supports that the following type shouldn't be allowed in sensorReport "rail:Abc", "rail:Def", "example:Ghi", "example:Jkl", "rail:Mno"

Sensor measurement types SHALL be expressed using either URIs or Compact URI Expressions (CURIEs), as follows: 
    • https://gs1.org/voc/MT-X
    • gs1:MT-X
where the X part is a string as specified in § 7.6.3, below. 

Each such URI or CURIE will resolve to an online definition within the GS1 Web vocabulary.

Please let me know if we have interpreted it wrong.

[RalphTro]

Dear @shalikasingh , You are correct that these are not CBV standard vocabulary values. At the same time, I added these examples intentionally to illustrate the extensibility for user/industry group extensions. Does that make sense? Kind regards, @RalphTro

[shalikasingh]

Dear @RalphTro,

It does make sense. But in that case, I have two more doubts listing them below:

1. A/cing to you "added these examples intentionally to illustrate the extensibility for user/industry group extensions", but CBV draft clearly states this "Each such URI or CURIE will resolve to an online definition within the GS1 Web vocabulary." [Note: such URI or CURIE points to the value of measurement type]. Hence either we should remove this statement from the CBV draft or align the example as per the draft.
2. When we use CURIE as "rail:Def", should not we define rail in @context? Currently it's not defined.

Please let me know if I was able to convey my doubts.

[VladimirAlexiev]

I agree with @shalikasingh : the more realistic the examples, the higher the chance people will use the standard appropriately. If we give rail: examples, they should be realistic.

[mgh128]

Clearly those examples conflict with the SHALL statement that currently restricts the values to one of

• https://gs1.org/voc/MT-X
• gs1:MT-X

where the X part is a string as specified in § 7.6.3, below.

If we're supporting user-defined values (expressed as CURIEs or Web URIs), then this needs to be included in the bullet-point options within the SHALL statement, so it could be reformulated to read as follows:

Sensor measurement types SHALL be expressed using either URIs or Compact URI Expressions (CURIEs), preferably using standard values of measurement type defined within the GS1 Web vocabulary as follows:

• https://gs1.org/voc/MT-X
• gs1:MT-X

where the X part is a string as specified in § 7.6.3, below.

For standard values of measurement types (e.g. for physical properties such as temperature, pressure etc.), each such URI or CURIE SHALL resolve to an online definition within the GS1 Web vocabulary. User-defined / vendor-defined values of type are permitted as an alternative where no appropriate value is available within the code list at https://gs1.org/voc/MeasurementType ; in such situations, a user-defined / vendor-defined value SHALL be expressed as a Web URI or as a CURIE, with an accompanying declaration of how the CURIE prefix maps to a Web URI stem or namespace.

[RalphTro]

Good catch. What do you think of just replacing 'rail' with 'example' (which is declared) in the message structure, @shalika-singh?

[shalikasingh]

Yes @RalphTro, if we are in favour of reformulating the statement in the CBV draft to accept user-defined values, then we can simply replace 'rail' with 'example'.

[RalphTro]

Dear All, Just to let you know that I adjusted the message examples on GitHub (i.e. replaced rail --> example ns). I like Mark's suggestion to extend our spec.

[CraigRe]

Adjusted CBV § 7.6.3 to reflect the discussion above, as well as the 31 August telco discussion, in which it was agreed to omit the MT- and SAT- prefixes in the sensor measurement type URIs and CURIEs.

[VladimirAlexiev]

@RalphTro Example-TransactionEvents-2020_07_03y.xml includes realistic rail: examples, so we should preserve that prefix. I've now converted it jsonld.