add example Web URLs with CBV URLs and Digital Link URLs

[VladimirAlexiev]

Fix some examples to use cbv: namespace instead of urn:epcglobal:cbv.
For example, we should do these replacements:

• <urn:epcglobal:cbv:btt:po> -> cbv:BTT-po
• <urn:epcglobal:cbv:disp:in_transit> -> cbv:Disp-in_transit

---

How about EPC identifiers? Do we dare do this:

• <urn:epc:id:sgtin:0614141.107346.2018> -> <https://id.gs1.org/01/06141411073462018X>
• <urn:epc:id:sgln:0614141.07346.1234> -> <https://id.gs1.org/414/061414107346X/254/1234>

I'm much less keen on this:

• We'd need to compute the check-digit (displayed as X above)
• The AI numeric codes (01, 414, 254) are harder to grasp than the alphabetical identifier types
• The GS1 resolver needs to be operational

[mgh128]

We're not deprecating or dropping the URNs. The Web URI alternatives for CBV code list values and the use of GS1 Digital Link URIs as permitted alternatives for EPC URNs and EPC class URNs is additional rather than a complete replacement.

We therefore should not make this change in all examples. For those who defend the continued use of URNs, it is important that some examples should still show them.

In terms of CURIEs and QNames, the problem with cbv:BTT-po and cbv:Disp-in_transit is that we can never declare that cbv = urn:epcglobal:cbv: in the way that we can declare that cbv = https://ns.gs1.org/cbv/
If we wanted that flexibility, we'd need one CURIE prefix per CBV code list,
e.g. cbvbtt = urn:epcglobal:cbv:btt: or cbvbtt = https://ns.gs1.org/cbv/BTT- , though it's not possibly to declare that a single CURIE prefix expands to both of these simultaneously.

Regarding the EPC identifiers, we need to preserve a mixture across the examples of some EPC URNs and some GS1 Digital Link URIs. However, where equivalent examples are prepared using both formats, then the conversion must be done correctly.

For example, <urn:epc:id:sgtin:0614141.107346.2018> -> <https://id.gs1.org/01/10614141073464/21/2018> , not <urn:epc:id:sgtin:0614141.107346.2018> -> <https://id.gs1.org/01/06141411073462018X>

The GS1 resolver is operational but probably does not resolve most example values based on GS1 Company Prefix 0614141 or GS1 Prefix 952, nor does it provide much of a welcome page at https://id.gs1.org .

Yes, we did have alphabetic identifier types in GS1 Digital Link URIs to make them more developer-friendly but they're dropped in v1.2 because some members of the work group were concerned about needing to support all of those mappings e.g. 01 <-> gtin, because they only applied to the URI path information, not the URI query string, and because alphabetic characters result in a slightly higher count of modules in a 2D symbol such as QR code because alphabetic characters require 7 bits per character, whereas digits require 3.32 - 4 bits per digit.

[VladimirAlexiev]

should not make this change in all examples

I'm glad of it :-).

Let's keep existing examples as they are, but add a few examples to showcase all options

• ADD at least one that uses the CBV URLs (Example_n.n.n-Web_URLs)

we can never declare that cbv = urn:epcglobal:cbv: ... If we wanted that flexibility, we'd need one CURIE prefix per CBV code list, cbvbtt = urn:epcglobal:cbv:btt:

You can declare a prefix on a URN just as well as you can do it on a URL. And prefixed names can include colon. So this works:

@prefix cbv: <urn:epcglobal:cbv:>.
@prefix epcis: <https://ns.gs1.org/epcis/>.
@prefix ex:    <http://example.org/>.

ex:bizTransaction epcis:type cbv:btt:po.

If you save it to a file, you can convert it to other formats to confirm it's correct:

riot -out ntriples urn-prefix.ttl
<http://example.org/bizTransaction> <https://ns.gs1.org/epcis/type> <urn:epcglobal:cbv:btt:po> .

riot -out jsonld urn-prefix.ttl
{
  "@id" : "ex:bizTransaction",
  "type" : "cbv:btt:po",
  "@context" : {
    "type" : {
      "@id" : "https://ns.gs1.org/epcis/type",
      "@type" : "@id"
    },
    "epcis" : "https://ns.gs1.org/epcis/",
    "ex" : "http://example.org/",
    "cbv" : "urn:epcglobal:cbv:"
  }
}

it's not possibly to declare that a single CURIE prefix expands to both of these simultaneously

Yes. We could use uppercase CBV: for the old way (URNs) and lowercase cbv: for the new way (URLs)?

we need to preserve a mixture across the examples of some EPC URNs and some GS1 Digital Link URIs.

Yes! We can use that same Example_n.n.n-Web_URLs.

And thanks for providing correct Digital Links!
(Though the more I look at them, the less I like them :-)

[VladimirAlexiev]

EPCIS/JSON/WithDigitalLinkID/ has 4 examples that use URLs for EPClist, EPCclass, etc.
Should we use the cbv: URL prefix in all of them as well?

[mgh128]

@VladimirAlexiev suggested that we could write a CURIE such as cbv:btt:po - but from a quick test using JSON-LD playground it appears that only the part before the first colon is expanded.
Our CBV code lists use colon as delimiter, e.g. urn:epcglobal:cbv:bizstep:shipping , whereas the GS1 Web vocabulary does not use colon in its Web URIs for code lists and code list values. Instead it uses a hyphen separator.

If the intention of cbv:btt:po is to support either a mapping to a CBV v1.2 URN or to a CBV v2.0 Web URI then I can't find a way to get this to work. If @VladimirAlexiev has a working example for a CURIE that uses more than one colon and which can expand cbv:btt:po to something like https://ns.gs1.org/cbv/BTT-po then please provide a working example.

[VladimirAlexiev]

CURIE such as cbv:btt:po - but from a quick test using JSON-LD playground it appears that only the part before the first colon is expanded.

Yes, that's what I showed. I didn't claim more.

My point is that if we define two prefixes:

"CBV": "urn:epcglobal:cbv:"
"cbv": "https://ns.gs1.org/cbv/"

Then the user can write

"type": "CBV:btt:po" # old-style BTT URI
"type": "cbv:BTT-po" # new-style BTT URL

and doesn't have to write urn:epcglobal:cbv:bizstep:shipping.

Guess I misunderstood your comment

we can never declare that cbv = urn:epcglobal:cbv: ...

But all this is beside the point: I'm not advocating that CBV:btt:po is better than urn:epcglobal:cbv:bizstep:shipping.

I'm advocating that the new style URL cbv:BTT-po is the modern way, and we should give examples (eg rework the 4 EPCIS/JSON/WithDigitalLinkID/ examples) that use only URLs and not URNs.

[mgh128]

OK, I now understand better what you meant. Yes, that all looks fine.

…

On Wed, Apr 28, 2021 at 3:18 PM Vladimir Alexiev ***@***.***> wrote: CURIE such as cbv:btt:po - but from a quick test using JSON-LD playground it appears that only the part before the first colon is expanded. Yes, that's what I showed. I didn't claim more. My point is that if we define two prefixes: "CBV": "urn:epcglobal:cbv:""cbv": "https://ns.gs1.org/cbv/" Then the user can write "type": "CBV:btt:po" # old-style BTT URI"type": "cbv:BTT-po" # new-style BTT URL and doesn't have to write urn:epcglobal:cbv:bizstep:shipping. Guess I misunderstood your comment we can never declare that cbv = urn:epcglobal:cbv: ... But all this is beside the point: I'm not advocating that CBV:btt:po is better than urn:epcglobal:cbv:bizstep:shipping. I'm advocating that the new style URL cbv:BTT-po is the modern way, and we should give examples (eg rework the 4 EPCIS/JSON/WithDigitalLinkID/ examples) that use only URLs and not URNs. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#237 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSXRL424RWJEH67BBCNLVTTLAKLPANCNFSM42CMWOIQ> .

[mkotoff]

Can we set urn:epc:id:sgln: as default namespace of readPoint and bizLocation, as will be done for type, bizStep, disposition etc? But we can't do that for source and destination because they could be sgln or pgln
"readPoint": {"id": "urn:epc:id:sgln:0614141.00777.0"},
"bizLocation": {"id": "urn:epc:id:sgln:0614141.00888.0"},
{ "type": "urn:epcglobal:cbv:sdt:possessing_party", "source": "urn:epc:id:sgln:4012345.00001.0" },
{ "type": "urn:epcglobal:cbv:sdt:location", "source": "urn:epc:id:sgln:4012345.00225.0" }
{ "type": "urn:epcglobal:cbv:sdt:owning_party", "destination": "urn:epc:id:sgln:0614141.00001.0" },
{ "type": "urn:epcglobal:cbv:sdt:location", "destination": "urn:epc:id:sgln:0614141.00777.0" }

Also can we apply epcClass: as default namespace for urn:epc:class:lgtin: ?

[RalphTro]

Dear @mkotoff ,
I am wondering if this makes sense in light of our decision that (as of CBV 2.0) we can express an SGLN not just as an EPC URI, but also as an GS1 Digital Link URI, i.e. https://id.gs1.org/414/... or https://id.example.com/414/... What is your take on that?
And which advantages/consequences does it have to set a default namespace in the first place? Thanks in advance for helping me to understand your suggestion better. :-)
Kind regards,
@RalphTro

[mgh128]

For properties such as bizStep, disposition etc., it's convenient to set a default namespace in the way that José has suggested in his pull request #275

For readPoint and bizLocation the URI values are not as constrained; they're typically SGLN values rather than code values such as 'shipping' / 'in_transit' from an enumerated CBV code list. Furthermore, as @RalphTro notes, we now support the expression of SGLN via the GS1 Digital Link URI syntax as an alternative to the existing EPC URN syntax. These URIs are structurally different and aren't simply a code value such as 'shipping' preceded by two alternative URI stems.

For example, the same SGLN might now be expressed in v2.0 as

urn:epc:id:sgln:0614141.12345.400
OR
https://example.com/414/0614141123452/254/400
OR
https://id.gs1.org/414/0614141123452/254/400

so it should be clear that choosing a default namespace of urn:epc:id:sgln: would put the GS1 Digital Link URI format at a disadvantage, while choosing a default namespace of https://id.gs1.org/ or https://id.gs1.org/414/ puts the EPC URN format at a disadvantage and that there is a risk of an invalid URI being constructed if the terminal value format for the SGLN does not agree with the proposed default URI stem / namespace.

I therefore think that it is safest to only define default namespaces for properties that expect URIs from enumerated code lists in CBV, in which the same standardised simple string terminal value such as shipping or in_transit can be prepended with a default namespace / URI stem, using José's approach - and not to use that approach for properties that expect an SGLN or PGLN.

Even then, since EPCIS/CBV 2.0 is all about modernisation and making the standard more usable, intuitive and accessible, I'd always recommend choosing the Web URI format for the stem, e.g. choosing 'https://ns.gs1.org/cbv/BizStep-` over urn:epcglobal:cbv:bizstep: , because URNs are still URIs that Resolve Nowhere.

[VladimirAlexiev]

Agree with everything in Mark's comment.
And in this spirit of modernization, shouldn't we add such a paragraph in CBV and not just an example?

I'd also quote the saying URIs that Resolve Nowhere, but I guess such talk is not standardsy-enough :-)