wrong uncl1153 namespace

[VladimirAlexiev]

Several schemas (eg https://github.com/w3c-ccg/traceability-vocab/blob/main/docs/openapi/components/schemas/common/BillOfLading.yml)
use wrong URLs for uncl1153 props, eg
https://service.unece.org/trade/uncefact/vocabulary/uncl1153/#Consignment_identifier_carrier_assigned.

The rights URL use # not /#, eg
https://service.unece.org/trade/uncefact/vocabulary/uncl1153#Consignment_identifier_carrier_assigned.

As you can see here: https://service.unece.org/trade/uncefact/vocabulary/uncl1153.jsonld.

BTW, it's much better to define prefix uncl1153: in the JSONLD context,
and then use CURIEs (eg uncl1153:Consignment_identifier_carrier_assigned)
in $linkedData.@id. But is that allowed in the JSON Schema that you use?

[OR13]

https://www.w3.org/TR/cooluris/

Let's make a concrete proposal, or close this issue.

[brownoxford]

Discussed, and the working group has decided not to use CURIEs, closing.

[VladimirAlexiev]

@brownoxford Maybe you meant to close #285? But please provide some justification or point to some minutes!

This issue is about some of the schemas using wrong URLs. So reopen it.

[brownoxford]

@VladimirAlexiev please see new issue #536

[VladimirAlexiev]

@brownoxford This issue is still not fixed, please reopen it.

[TallTed]

@VladimirAlexiev —

• Rather than battling to get this issue (wrong uncl1153 namespace #268) reopened, I submit that your concern will be much more quickly resolved via a fresh issue that discusses only your specific concern about changing all instances of the incorrect —
  https://service.unece.org/trade/uncefact/vocabulary/uncl1153/#
  — to the correct —
  https://service.unece.org/trade/uncefact/vocabulary/uncl1153#
  — throughout this repo.

• The already-existent newer issue Align to the production UN Vocab #536 mentioned by @brownoxford may be sufficient, albeit opaquely titled, if you digest this (vaguely detailed, but I think clearly intended to address the concern you raised here) bullet in @nissimsan's opening comment, there —

  • Switch away from /# (see wrong uncl1153 namespace #268 and namespace problems #531).

• I suggest that you leave all discussion of CURIEs, if any further is needed, to use CURIEs in $linkedData #285.

---

@OR13 —

Your #268 (comment) added unnecessary tangent-driving noise to this issue, via the CoolURIs link, which is irrelevant to discussion of CURIEs. CURIEs are not URIs; CURIEs are expanded to URIs.

If you were trying to suggest that the incorrect /# URIs used within this repo should not be changed to the correct # URIs, you aren't properly applying the CoolURIs article, which is meant for URI minters, not referrers. The incorrectness is simply that the /# URIs do not identify the resource described by the page found by dereferencing the # URIs. That is our error.

Also, your request for a "concrete proposal" ignored the one made in @VladimirAlexiev's initial comment, which I summarized in the initial paragraph of this comment. You might consider hiding (or deleting) it.

[brownoxford]

@VladimirAlexiev, are you saying that #536 does not accurately reflect what needs to happen here, or that you disagree with waiting for the vocab v1 bump later this year? @nissimsan is point on this issue currently, and his suggestion is: "I advise that we don't start this work until the UN vocab is published"

[nissimsan]

... And to qualify that, @brownoxford and @TallTed , my aim is to stick with a single URL for defining terms.

https://service.unece.org/trade/uncefact/vocabulary/uncl1153/#
and
https://service.unece.org/trade/uncefact/vocabulary/uncl1153#
are not the same. They produce different RDF nodes, and changing them breaks proofs.

Despite the uncoolness factor, I consistently stick with the URL which I get redirected to as a general practice or convention. I don't consider this a problem for us (trace-vocab) to be solving - it should be solved by the vocab we're referencing (in this case UN cefact). And it is.

[TallTed]

I consistently stick with the URL which I get redirected to as a general practice or convention

That will break Linked Data, consistently and absolutely, and I will block it by any means necessary.

[nissimsan]

@TallTed, your argument on uncefact/spec-jsonld#25 (comment) has changed my mind on this. Thank you!

[VladimirAlexiev]

@brownoxford I don't know what are the future plans, but this bug should stay open until it is fixes.
I just checked, the bug is still present.