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

EDI3 #40

Open
VladimirAlexiev opened this issue Dec 21, 2021 · 3 comments
Open

EDI3 #40

VladimirAlexiev opened this issue Dec 21, 2021 · 3 comments

Comments

@VladimirAlexiev
Copy link

Hi folks!
Are you familiar with EDI3?

  • "EDI for the Web: Supply Chain Standards and Tools for Web Developers"
  • Addresses this problem:
    Web APIs are a “publish once, consume many times” model whilst EDI documents are more like a “create once and copy & paste many times” model.
  • https://edi3.org/: home
  • https://edi3.org/semantic-specs/: shows the scope. IMHO there is plenty of overlap with some GS1 specs

It is an informal collaboration that contributes to UN/CEFACT.
IPR Policy for edi3.org:

  • All edi3.org specifications are available under GPL3.0 open source license.
  • edi3.org does not own any IP. Ownership of all contributions remains with the contributor.
  • From time to time, edi3.org specifications may be offered as initial contributions to formal projects run by UN/CEFACT. In such cases, contributors are expected to grant ownership of their IP to the UN.
@philarcher
Copy link
Member

Hi @VladimirAlexiev, yes, we are. Colleagues are involved directly in the UN/CEFACT work from which EDI3 is derived. I see Jaco included you in an email to a lot of people a short while ago so you're up to date. With that in mind, OK if we close the issue here?

@VladimirAlexiev
Copy link
Author

Jaco Voorspuij:
Over the past few years Thierry and I have attended several UN/CEFACT sessions on the topic of EDI3.ORG.
In principle edi3.org “translates” the UN/CEFACT data models into JSON format based API and they (intend to) do that automatically.
So they should in principle be able to quite quickly map any updates to the UN/CEFACT data models into a corresponding JSON format.
This means that again in principle, the edi3.org JSON based API can cover the same business processes that the UN/CEFACT data models cover.
Since GS1 and UN/CEFACT both cover a large number of data models, there is also a large overlap between the models/processes that edi3.org cover.
The issue still remains that the industry does NOT implement the business processes very consistently and therefore the choreography of information exchanges is often incomplete or inconsistent.

This is one of the main reasons that GS1 have started the Visibility4Cargo initiative (lead by the Transport & Logistics sector) that will establish a guideline for consistent implementation of global data standards (including those from GS1 but not limited to GS1) to enable multi-modal track & trace of goods from seller to buyer. EPCIS is one of the primary building blocks for the guideline building on global data standards, but commonly used global identification standards (like the GS1 ID Keys) is the top priority.
The MSWG Visibility4Cargo has its kick-off meeting 12th January.
More info (and option to join) is available here.

Thierry is also involved in a UN/CEFACT group that is engaged in related efforts, so we can align with the UN/CEFACT efforts and standards..
Truth be told, I am not entirely sure about the “official” relationship between UN/CEFACT and edi3.org today.
When I was more closely involved in UN/CEFACT efforts, the official relationship was “complex” and edi3.org was definitely not considered as part of UN/CEFACT.
Unless things have changed a lot, the edi3.org products cannot be considered official standards.

Ultimately, adoption is always more important than solutions being official standards.
Therefore, it is imperative that GS1 develop a good implementation guideline as a result from the Visibility4Cargo MSWG, that industry will want to adopt.
Being the first solution to be (widely) adopted ensures a competitive advantage for further adoption.
The MSWG Visibility4Cargo will welcome further participation to ensure we deliver this good implementation guideline.

@VladimirAlexiev
Copy link
Author

Hi @philarcher sorry, maybe this project is completely inappropriate for EDI3 and maybe instead I should post an issue in EDI3 so they could consider aligning to GS1 standards. But let's keep it open for a while to gather some info.

I'm still trying to orient myself in the GS1 standards universe.

  • I knew about the existence of Visibility4Cargo but not really what it means
  • Jaco wrote "lead by the Transport & Logistics sector": but in my mind GS1 is all about Transport & Logistics? Sure, it has WGs on special topics like tracking of medical devices, but the main topic is Transport & Logistics?
  • I've watched a presentation by the "EDI Semantics" GS1 WG, but if I understand correctly it's not about semantic web at all?

I browsed through EDI3 and

  • many of the specs are just templates with little text inside
  • naming convention between classes (PascalCase) and props (camelCase) is not conformed to
  • this may stem from a mixup between what is class and what is property and what is individual, eg https://github.com/edi3/edi3-json-ld-ndr/blob/main/docs/index.md#linked-data says something atrocious like this (author is not a proper individual, neither it is a proper class for a person!)
    <https://schema.org/author> <https://schema.org/givenName> Nis
  • wrong URLs expressed in Turtle examples, eg
    <rec20:kilogram_per_square_meter> <rdfs:comment> "Unit of surface density, areic mass" .
  • ontology definitions in Turtle are wrong: subClassOf "stringNameOfClass"
  • no proper namespace design, eg new permanent url, e.g https://edi3.org/vocab/2020.09/context.json: "new" and "permanent" make an oxymoron, and ironically that URL does not resolve

I posted a few more specific issues in https://github.com/edi3/edi3-json-ld-ndr/issues

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

2 participants