Develop JSON Schema for Event Profile 'Fishing Event'

[RalphTro]

Dear @Aravinda93 , dear @albert-verdeny ,

This is an event profile for fish traceability, loosely aligned with existing solutions and guidelines, but deliberately not a 1:1 copy to not overcomplicate things. It contains a couple of elements that, from my POV, our tool should be able to cover, incl. support for 'legacy' EPC URIs, quantities, specific unit codes, ILMD data (even though the latter is likely to be discouraged/deprecated in the upcoming future), hierarchical data structures in extensions, code values, etc. So, I think that developing the corresponding JSON schema for this is a valuable and important exercise.

Event Profile 'Fishing Event'

Set of rules

1. The EPCIS Event is an ObjectEvent.
2. The actionfield is populated with the value "ADD".
3. The bizStepfield is populated with the value "commissioning".
4. The readPointis populated with an SGLN EPC URI (e.g. "urn:epc:id:sgln:4012345.00001.0")
5. The quantityListincludes exactly one ID.
6. The ID in the quantityListis an LGTIN, expressed as an EPC Class URI (e.g. "urn:epc:class:lgtin:4012345.099914.LOT1").
7. The quantityfield as part of the QuantityElement must be populated with a positive decimal value.
8. The uomfield as part of the QuantityElement must be populated with a UN/CEFACT Rec 20 value for mass (FYC, see https://github.com/gs1/UnitConverterUNECERec20/blob/master/src/UnitConverterUNECERec20.js - type "mass"), e.g. "KGM"
9. The event contains an ilmdfield.
10. All ILMD field names are prefixed with "cbvmda".
11. The event contains a proper declaration for "cbvmda" ("urn:epcglobal:cbv:mda").
12. Within the ILMD element, there is a cbvmda:bestBeforeDate field.
13. The cbvmda:bestBeforeDate field is filled with a proper date value.
14. Within the ILMD element, there is a cbvmda:storageStateCode field.
15. The cbvmda:storageStateCode field is filled with a corresponding code value according to https://navigator.gs1.org/gdsn/class-details?name=StorageStateCode&version=12 (e.g. "PREVIOUSLY_FROZEN")
16. Within the ILMD element, there is a cbvmda:vesselCatchInformationList field.
17. Within the cbvmda:vesselCatchInformationList field, there are two sub-fields: cbvmda:vesselID and cbvmda:vesselFlagState.
18. The cbvmda:vesselID field is filled with a string value.
19. The cbvmda:vesselFlagState field is filled with a ISO 3166-1 alpha-2 code value (e.g. "DE").

Are all of the above rules understandable/make sense for you?

Very much looking forward to seeing the corresponding JSON schema come alive - many thanks in advance for your support in this!

Kind regards; Ralph

@dakbhavesh: FYI.

[Aravinda93]

Dear @RalphTro

Just wanted to update you that @albert-verdeny and I are in contact and started to develop the JSON Schema based on your detailed description. We will keep you posted on the same and request for your feedback as we have the draft version of the same.

Best regards, Aravinda

[RalphTro]

Dear @Aravinda93 and @albert-verdeny - MANY THANKS!

[Aravinda93]

Dear @RalphTro

I have one small confusion associated with point 16 of your description. It has been mentioned as the field cbvmda:vesselCatchInformationList so should this be of "type": "array" or "type": "object"?

Because the field key contains list I thought it should be array but the later points 17, 18 and 19 of the description do not seem to support list but rather as object so thought of clarifying the same.

Can you please confirm if cbvmda:vesselCatchInformationList is array or object? As per the description in CBV Standard doc it should be a List

Example 1 with "type": "array":

"cbvmda:vesselCatchInformationList": [
  {
    "cbvmda:vesselFlagState": "DE",
    "cbvmda:vesselID": "1234"
  }
]

Example 2 with "type": "object":

"cbvmda:vesselCatchInformationList": {
  "cbvmda:vesselFlagState": "DE",
  "cbvmda:vesselID": "1234"
}

[RalphTro]

Dear @Aravinda93 , Good question. I just double-checked CBV section 9.2.3, and given that the CBV states "The value of vesselCatchInformationList consists of one or more elements named vesselCatchInformation, which contains the following subelements (...)". Even though implementations I am aware of did not repeat fields such as e.g. vesselID etc., I think the CBV specification (at this time, we only had an XML mapping) was intended to cater for situations to indicate several ones. So, if we apply/map this to the JSON/JSON-LD world, I think it should be an array of objects; i.e. option 1. WDYT? Kind regards; Ralph

[Aravinda93]

@RalphTro

Thanks a lot for the quick clarification. Yes even I thought it should be an option-1 with "type": "array" but just wanted to double-check. I will proceed with option1 in JSON Schema.

[albert-verdeny]

Dear @RalphTro, many thanks for the great profile! And thanks so much @Aravinda93 for driving the technical implementation!

Just a minor clarification about the requirement 11: what do you mean exactly with "declaration"? "cbvmda": "urn:epcglobal:cbv:mda:" is already part of the epcis context – are you thinking of something beyond that?

[RalphTro]

Dear @albert-verdeny , You are right! I think this happened becase I was looking at an old XML event when drafting this. ;-) So, please disregard this requirement. Just crossed it out. :-)

[RalphTro]

Dear @albert-verdeny and @Aravinda93, Brief question: are you able to share a first draft of the JSON profile until Friday this week? That would be perfect, as I reserved some time for testing/providing feedback on Friday, which would then give you the opportunity to refine it before our call on Dec 3rd, if necessary.

[Aravinda93]

Dear @RalphTro

Surely we can provide you with the first draft of the JSON profile before Friday. It has gone through initial testing from @albert-verdeny and my side. There are some minor changes and final validation needs to be done from our end as soon as it's done we will provide you with the same.

[RalphTro]

Super. Thanks for the heads-up and looking forward to testing it!

[albert-verdeny]

Dear @RalphTro,

Another point I would like to clarify: in your requirement

Within the cbvmda:vesselCatchInformationList field, there are two sub-fields: cbvmda:vesselID and cbvmda:vesselFlagState.

I understand the two fields are required, correct?

Now, in the comments above we see that cbvmda:vesselCatchInformationList needs to be an array.

Do we want to ensure that there is at least one element on this array or any similar condition?

If not, this means cbvmda:vesselCatchInformationList can then technically be empty, so the event wouldn't necessarily have cbvmda:vesselID and cbvmda:vesselFlagState.