Translation CURIEs (XML) to bare string notation (JSON/JSON/LD) for standard values

[RalphTro]

Dear @sboeckelmann , Im using your (great) web application, I just noticed that if an XML document makes use of CURIEs in e.g. the bizStep field, the same value is taken over in the JSON/JSON LD document as well. At the same time, a JSON/JSON-LD doc, IMHO, should only contain the corresponding bare string notation for all CBV standard values. Interestingly, it works for typein the sensorReport field: in this case, the tool correctly translates the value from 'gs1:Dimensionless' to 'Dimensionless'. But e.g. for 'cbv:Disp-in_progress', it leaves the value as is.

AFAIK, we never provided message examples for this case, so I am happy to provide the following exemplary EPCIS XML Doc:

<?xml version="1.0" encoding="UTF-8"?>
<epcis:EPCISDocument xmlns:epcis="urn:epcglobal:epcis:xsd:2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:gs1="https://gs1.org/voc/" xmlns:cbv="https://ref.gs1.org/cbv/" xmlns:ext1="https://ns.ext.de/epcis/" schemaVersion="2.0" creationDate="2023-01-11T12:00:00.000+01:00" xsi:schemaLocation="urn:epcglobal:epcis:xsd:2 EPCglobal-epcis-2_0.xsd">
    <EPCISBody>
        <EventList>
            <ObjectEvent>
                <eventTime>2023-01-11T12:00:00+01:00</eventTime>
                <eventTimeZoneOffset>+01:00</eventTimeZoneOffset>
                <certificationInfo>https://accreditation-council.example.org/certificate/ABC12345</certificationInfo>
                <epcList>
                    <epc>https://id.gs1.de/01/04012345999990/21/XYZ-1234</epc>
                </epcList>
                <action>OBSERVE</action>
                <bizStep>cbv:BizStep-receiving</bizStep>
                <disposition>cbv:Disp-in_progress</disposition>
                <readPoint>
                    <id>https://id.gs1.de/414/4012345000115</id>
                </readPoint>
                <sensorElementList>
                    <sensorElement>
                        <sensorMetadata ext1:someFurtherMetadata="metadataText" time="2023-01-11T11:05:00Z" bizRules="https://id.example.com/253/4012345000054987"/>
                        <sensorReport exception="gs1:ALARM_CONDITION" coordinateReferenceSystem="http://www.opengis.net/def/crs/EPSG/0/27700" ext1:someFurtherReportData="reportText" type="gs1:Dimensionless"/>
                    </sensorElement>
                </sensorElementList>
            </ObjectEvent>
        </EventList>
    </EPCISBody>
</epcis:EPCISDocument>

Would you agree that it make ssense to adjust this behaviour?

Kind regards, @RalphTro

[sboeckelmann]

Dear @RalphTro, thank you so much for testing, this really helps us a lot to improve our code-base! @Aravinda93 will pick it up immediately 😃

[Aravinda93]

@RalphTro

Thanks for reporting the issue, I just analysed the code and found that its happening because we have only taken care for the CBV formatted urn that starts with urn:epcglobal:cbv:*** hence we were not supporting the cbv:***- but we are currently in process of adding them as well.

During the analysing of your XML I noticed that when converting to JSON the sensorReport -> exception in converted JSON appears as gs1:ALARM_CONDITION should it also be converted to barestring something like ALARM_CONDITION similar to how we are handling the sensorReport->type field?

Thought of confirming with you so if this requires any modification I can take together.

[RalphTro]

Dear @Aravinda93 , Many thanks for taking a look into this matter. Turning to your question: That is at least my understanding given that they are embedded in the EPCIS JSON schema in a simlar fashion (see https://ref.gs1.org/standards/epcis/epcis-json-schema.json). Do you share my POV? Kind regards, Ralph

[sboeckelmann]

@Aravinda93 I remember that you changed voc to cbv with one of your latest changes on the digitallink converter and I want to make sure that we get the vocab stuff right.

https://ref.gs1.org/standards/epcis/epcis-context.jsonld:

"cbv": "https://ref.gs1.org/cbv/"
"gs1": "https://gs1.org/voc/"

CBV - Core Business Vocabulary

https://ref.gs1.org/cbv/ see https://ref.gs1.org/standards/cbv/ 3.3.1 (page 27/28) https://ref.gs1.org/cbv/X-Y -> urn:epcglobal:cbv:X:Y with JSON-LD using the shortened Y-only expression see bizStep defined in https://ref.gs1.org/standards/epcis/epcis-context.jsonld

GS1 Web Vocabulary

https://www.gs1.org/voc/ see https://ref.gs1.org/standards/cbv/ 7.6.1 (page 55) https://www.gs1.org/voc/X -> gs1:X

@Aravinda93 can you please double check if we got all of this right, also in the digitallink converter?

Also important to note: in the example, @RalphTro added gs1 and cbv as XML namespaces ;-)

[Aravinda93]

Dear @RalphTro

The reported issue has been resolved and the fix has been successfully deployed to the web application. The updated functionality is now available for use. However, it appears that we may have missed informing of this update. We apologize for the same.

After implementing the fix, when the XML provided by you above is input into the system, we are now able to generate the following JSON output:

{
  "@context": [
    "https://ref.gs1.org/standards/epcis/2.0.0/epcis-context.jsonld",
    {
      "ext1": "https://ns.ext.de/epcis/"
    }
  ],
  "type": "EPCISDocument",
  "schemaVersion": "2.0",
  "creationDate": "2023-01-11T12:00:00.000+01:00",
  "epcisBody": {
    "eventList": [
      {
        "type": "ObjectEvent",
        "eventTime": "2023-01-11T12:00:00+01:00",
        "eventTimeZoneOffset": "+01:00",
        "certificationInfo": "https://accreditation-council.example.org/certificate/ABC12345",
        "epcList": [
          "https://id.gs1.de/01/04012345999990/21/XYZ-1234"
        ],
        "action": "OBSERVE",
        "bizStep": "receiving",
        "disposition": "in_progress",
        "readPoint": {
          "id": "https://id.gs1.de/414/4012345000115"
        },
        "sensorElementList": [
          {
            "sensorMetadata": {
              "time": "2023-01-11T11:05:00Z",
              "bizRules": "https://id.example.com/253/4012345000054987",
              "ext1:someFurtherMetadata": "metadataText"
            },
            "sensorReport": [
              {
                "type": "Dimensionless",
                "exception": "gs1:ALARM_CONDITION",
                "coordinateReferenceSystem": "http://www.opengis.net/def/crs/EPSG/0/27700",
                "ext1:someFurtherReportData": "reportText"
              }
            ]
          }
        ]
      }
    ]
  }
}

If the issue has been resolved, could you please confirm the same so that we may proceed with closing this ticket as resolved? Thank you.

Kind regards, Aravinda

[RalphTro]

Dear @Aravinda93 and @sboeckelmann , Many thanks for adjusting this! Happy to close this issue. Kind regards, Ralph