Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wrong uncl1153 namespace #268

Closed
VladimirAlexiev opened this issue Jan 25, 2022 · 11 comments
Closed

wrong uncl1153 namespace #268

VladimirAlexiev opened this issue Jan 25, 2022 · 11 comments

Comments

@VladimirAlexiev
Copy link
Contributor

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
Copy link
Collaborator

OR13 commented May 10, 2022

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

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

@brownoxford
Copy link
Collaborator

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

@VladimirAlexiev
Copy link
Contributor Author

@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
Copy link
Collaborator

@VladimirAlexiev please see new issue #536

@VladimirAlexiev
Copy link
Contributor Author

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

@TallTed
Copy link
Contributor

TallTed commented Aug 23, 2022

@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 —

  • 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
Copy link
Collaborator

@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
Copy link
Collaborator

... 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
Copy link
Contributor

TallTed commented Aug 25, 2022

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
Copy link
Collaborator

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

@VladimirAlexiev
Copy link
Contributor Author

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants