RalphTro / epcis-event-hash-generator

ALGORITHM and SOFTWARE PROTOTYPE to uniquely identify/validate the integrity of any EPCIS event through a common, syntax-agnostic approach based on hashing. Takes an EPCIS Document (formatted in either XML or JSON-LD) and returns the corresponding hash value(s).
MIT License
8 stars 4 forks source link

Sensor Report in pre-hash string #56

Closed clementh59 closed 3 years ago

clementh59 commented 3 years ago

Hi,

In the second example, the pre-hash string generated by the package is:

sensorElement -- sensorMetadata -- -- deviceID=https://id.gs1.org/8004/4000001111 -- -- deviceMetadata=https://id.gs1.org/8004/4000001111 -- sensorReport -- -- type=gs1:MT-Humidity -- -- value=12.1 -- -- uom=A93 -- sensorReport -- -- type=gs1:MT-Molar_concentration -- -- chemicalSubstance=urn:epcglobal:cbv:inchikey:CZMRCDWAGMRECN-UGDNZRGBSA-N -- -- value=0.18 -- -- uom=C35 -- sensorReport -- -- type=gs1:MT-Molar_concentration -- -- microorganism=https://www.ncbi.nlm.nih.gov/taxonomy/1126011 -- -- value=0.05 -- -- uom=C35

Shouldn't it be something like this:

sensorElement -- sensorMetadata -- -- deviceID=https://id.gs1.org/8004/4000001111 -- -- deviceMetadata=https://id.gs1.org/8004/4000001111 -- sensorReport -- -- sensorReport -- -- -- type=gs1:MT-Humidity -- -- -- value=12.1 -- -- -- uom=A93 -- -- sensorReport -- -- -- type=gs1:MT-Molar_concentration -- -- -- chemicalSubstance=urn:epcglobal:cbv:inchikey:CZMRCDWAGMRECN-UGDNZRGBSA-N -- -- -- value=0.18 -- -- -- uom=C35 -- -- -- type=gs1:MT-Molar_concentration -- -- -- microorganism=https://www.ncbi.nlm.nih.gov/taxonomy/1126011 -- -- -- value=0.05 -- -- -- uom=C35

(I followed the same pattern as a QuantityList for the sensorReport list except the element isn't called a SensorReportElement here but it is called SensorReport again (https://github.com/gs1/EPCIS/blob/master/JSON/EPCIS-JSON-Schema.json#L172))

Thanks a lot.

RalphTro commented 3 years ago

Dear @clementh59 ,

Thanks for your question, happy to answer as follows:

To be sure/double-check, I just created an EPCIS event accommodating two quantityElements and two sensorElements (complying to the current EPCIS 2.0 draft XSD), and passed it the algorithm.

I think the algorithm returns the correct structure (quantityList -> quantityElement and sensorElementList -> sensorElement -> sensorMetadata | sensorReport):

(...) quantityList --quantityElement ----epcClass=https://id.gs1.org/01/04023333111119/10/987 ----quantity=10.5 ----uom=KGM --quantityElement ----epcClass=https://id.gs1.org/01/04023333111119/10/988 ----quantity=10.6 ----uom=KGM (...) sensorElementList --sensorElement ----sensorMetadata ------time=2019-04-02T14:05:00.000+01:00 ----sensorReport ------type=gs1:MT-Humidity ------value=12.1 ------uom=A93 ----sensorReport ------type=gs1:MT-Temperature ------value=26 ------uom=CEL (...)

As a matter of fact, -- sensorReport -- -- sensorReport would not be valid, as the parent of sensorReport is sensorElement.

Do you agree with this/does this make sense?

BTW, your feedback revealed another issue we have to address (pertaining the time value, for which I think you already opened another issue) - so, thanks for this, very much appreciated!

Have a pleasant weekend and kind regards, @RalphTro

clementh59 commented 3 years ago

Dear @RalphTro ,

Thanks for your answer.

Regarding the example you gave, I understand that -- sensorReport -- -- sensorReport would not be valid, as the parent of sensorReport is sensorElement.

But in a quantityList, we have this in the json:

'quantityList': [
      { // a quantityElement
        'epcClass': 'urn:epc:class:lgtin:4054739.099914.20160711',
        'quantity': 600,
        'uom': 'KGM',
      },
      { // a quantityElement
        'epcClass': 'urn:epc:class:lgtin:4012345.099988.2014-02-10',
        'quantity': 2030,
        'uom': 'KGM',
      },
],

QuantityElements are direct children of quantityList, so the pre-hash string should be: quantityList --quantityElement --quantityElement

which is what we get with the algorithm.

But for a sensorElement, as it is defined in the standard, we have two children: https://github.com/gs1/EPCIS/blob/db2c1d0e09c1dd7f43e470b6ded9fe92d94838fe/JSON/EPCIS-JSON-Schema.json#L154 a sensorMetadata and a sensorReport.

And, to me, if you you have a pre-hash string like this: sensorElementList --sensorElement ----sensorMetadata ----sensorReport ----sensorReport

it means that you can have multiple sensorReport in a sensorElement, which isn't really the case since you have only one sensorReport which contains a list.

Here is an example of JSON for a sensorElement:

{
  sensorMetadata: {
    time: '2019-07-19T14:00:00.000+01:00',
    deviceID: 'urn:epc:id:giai:4000001.111',
    deviceMetadata: 'https://id.gs1.org/giai/4000001111',
    rawData: 'https://example.org/giai/401234599999',
    dataProcessingMethod: 'https://example.com/gdti/4012345000054987',
    bizRules: 'https://example.org/gdti/4012345000054987',
  },
  sensorReport: [
    { type: 'gs1:MT-Humidity', value: 12.1, uom: 'A93' },
    {
      type: 'gs1:MT-Molar_concentration',
      chemicalSubstance: 'https://identifiers.org/inchikey:CZMRCDWAGMRECN-UGDNZRGBSA-N',
      value: 0.18,
      uom: 'C35',
    },
    {
      type: 'gs1:MT-Molar_concentration',
      microorganism: 'https://www.ncbi.nlm.nih.gov/taxonomy/1126011',
      value: 0.05,
      uom: 'C35',
    },
  ],
}

And, to me the pre-hash string that you gave would match something like this:

{
  sensorMetadata: {
    time: '2019-07-19T14:00:00.000+01:00',
    deviceID: 'urn:epc:id:giai:4000001.111',
    deviceMetadata: 'https://id.gs1.org/giai/4000001111',
    rawData: 'https://example.org/giai/401234599999',
    dataProcessingMethod: 'https://example.com/gdti/4012345000054987',
    bizRules: 'https://example.org/gdti/4012345000054987',
  },
  sensorReport: {...},
  sensorReport: {...},
  sensorReport: {...},
}

Which wouldn't have any sense in a JSON of course.

The pre-hash string generated by the algorithm works for me, and if you think it is the right solution, I would understand, but I just want to be sure that this particular 'rule' is identified so that it can be added to the readme.

Thanks a lot, and have a pleasant weekend too,

Clément

RalphTro commented 3 years ago

Dear @clementh59 , As to your comment "it means that you can have multiple sensorReportin a sensorElement, which isn't really the case since you have only one sensorReport which contains a list." - the standard explicitly allows to have multiple sensorReport elements, which e.g. is reflected in the folowing example we provided: https://github.com/gs1/EPCIS/blob/master/JSON/WithSensorData/SensorDataExample1.jsonld

A sensorElement can have a sensorMetadata field and must have at least one sensorReport field. Do you still see an issue or does this explanation make sense now?

Kind regards and have a good start into the new week; Ralph

clementh59 commented 3 years ago

Dear @RalphTro ,

I see your point now! Thanks a lot!

Best regards and have a good start into your week too,

Clément

RalphTro commented 3 years ago

You are welcome, Clément!

Thus, can we close this issue then?