-
Notifications
You must be signed in to change notification settings - Fork 2
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
Question on Naming Scheme Compatibility with JSONLD #4
Comments
First, a general remark: The JSON Schema (draft) publication follows the UN/CEFACT JSON Schema Naming and design rules (NDR) that can be found here: This NDR assures that the ruleset of the underlying (reference) data model is respected according to the Core Component Technical Specification (CCTS). This is the foundation of all UN/CEFACT semantic data modelling work since decades. Your question points out one significant topic. The data model originates from a process-based data modelling view. All relevant information is clustered according to its process relationship. For instance, all information that is needed for a contractual agreement is grouped under "...Agreement", all that is needed for delivery under "...Delivery" and all that is needed for payment under "...Settlement". So far, so good. Having these basic data classes, issues start to rise when it comes to message design or information exchange design. The JSON Schema NDR takes all of these decisions into account. This is why there is more than one export variant available:
Most of those decisions are (to my understanding) taken into account in the JSON LD vocabulary, but only as a one-in-all respesentation. At the same time, it looks like the JSON-LD, groups some of the classes. As a consequence it looks, like it "only" represents the uncontextualised, highest level. This means that all the business requirement knowledge, that is taken into account in the different contextualisations from real-life-requirements, gets a little bit "hidden" in the JSON LD vocabulary. Coming back to your original question. The "applicableTradeSettlement" in the vocabulary does not contain the contextualisation information the same way, as it is done in the CEFACT semantic library or the JSON schemas. So, the naming (for "Agreement") is the same, if you know what contextualisation to use. But for Settlement there seems to be a difference, indeed: I hope, my long answer helps a bit. It may be valuable to put your issue in the JSON-LD repo as well / instead, as the JSON schemas here represent what is defined in "the UN/CEFACT standard". I would be happy to be pointed to the JSON LD Naming and Design Rules document, where all those rules are defined to be able to automate the needed mapping. BR, |
Thank you very much for your detailed answer Andreas, gave me some great material to go away and familiarise myself with.
So I'll follow up with them to see exactly how this clean up is functioning. Cheers |
For anyone who may see this in the future, The JSON LD Project has updated the names and brought them more in line with the JSON Schema. For example:
However, |
One additional comment on a possible difference between the JSON-LD vocab and JSON Schema: The JSON schema exports reflect the complete library including all semantic (business requirement related) decisions. One example: The document (message) level nearly never uses the highest level data types, as they contain not the right level of contextualisation. The highest level (here BSP) is the result of several decades of international cross-industy and administrative harmonisation. It assures that all the structures are consistent through all their usages and applications in each domain, sector, industry or country.
So those subsets contain only parts of and maybe more specific parts of the BSP (restrictions on properties and codes, clearer definitions for the given context, document related message structures). I am not sure if this level is reflected in the JSON-LD vocab in a comparable way. I would be happy to learn if and how this is reflected. |
Just a question,
In this Cross Industry Invoice, it includes the fields
And in the JSONLD Spec, also under uncefact, I believe the equivalent would be:
https://vocabulary.uncefact.org/applicableTradeSettlement
https://vocabulary.uncefact.org/specifiedPaymentMeans
https://vocabulary.uncefact.org/payerPartyFinancialAccount
https://vocabulary.uncefact.org/debtorFinancialAccountTypeCode
Which follow the same nested pattern.
Is there a reason for the subtle differences between the naming? Are we able to translate easily between names or is any standardisation happening between the JSON Schemas and the JSON LD Project.
Cheers,
The text was updated successfully, but these errors were encountered: