W3C CCG Call: Have you considered the UBL 2.2 specification for the 80+ most common business document schema?

[mwherman2000]

Have you looked at the UBL 2.2. specification for the 80+ most common business documents:
http://docs.oasis-open.org/ubl/os-UBL-2.2/UBL-2.2.html#S-UBL-2.2-DOCUMENT-SCHEMAS

[OR13]

Thanks these look awesome!

[mprorock]

Definitely have worked with UBL in the past (and some of the spin off versions of it. Great definitions for common properties at a minimum. When I was last working with UBL it was in an offshoot from an EDI scenario and I recall SAP and some of the other enterprise things that always seem to be present requiring some "fun (tm)" from an ETL and integration point. That obviously has improved quite a bit as branches of UBL I know are seeing broader adoption on a country by country basis. One nice thing that I think the approach we are taking here affords us is the ability to map the ontologies over to one another fairly rapidly, and I think there will be room to incorporate at some point compatibility layers to other "languages" as we need to.

[mwherman2000]

Not really related: this popped up in my Inbox this morning:
A SHARED LANGUAGE FOR SUPPLY CHAIN SECURITY

[mwherman2000]

Back to UBL and it's relationship to business documents being represented as VCs and given unique DIDs...
A particular UBL business document (schema) is composed of many standard sup-parts (sub or base schema).

Although the UBL specification doesn't support it, from a VC (and ledger storage) perspective, it would be interesting to create a model where a particular UBL document is not stored in its entirety but as "wrapper" or "envelope" VC that in turn contained pointers (URIs) to the sub parts also persisted as small VCs.

For example, a company object, company address object, person object, contact object, purchasable item object, invoice line item object, etc. ...that can be "aggregated" into top-level business documents like Purchase Orders, Invoices, Waybills, Delivery Confirmations, etc.

...part of my #ELT vision (Tokenize Every Little Thing): https://hyperonomy.com/2018/01/24/tokenization-of-every-little-thing-elt/
...which, in turn, rolls up into my Trusted Digital Web project: https://www.youtube.com/playlist?list=PLU-rWqHm5p45dzXF2LJZjuNVJrOUR6DaD ...the first video is 5 minutes long.
...Trusted Digital Web whitepaper: https://hyperonomy.com/2019/11/06/trusted-digital-web-whitepaper/

[OR13]

@mwherman2000 yes, thats the approach we have taken here.... essentially:

1. We use JSON Schema to define a JSON-LD type
2. We autogenerate JSON-LD context and vocab from a folder of linked JSON Schemas
3. We use the JSON Schema and JSON-LD context to produce verifiable credentials

For any document / type in UBL we could do the following:

1. convert it to JSON Schema
2. ensure there is a generator for producing valid synthetic JSON-LD

One of the main challenges is picking the correct vocabulary IRIs for embedding in the JSON Schema... I have not looked enough at UBL to see how this is solved, but here are some examples regarding chemicals / molecules:

https://w3c-ccg.github.io/traceability-vocab/#inchikey

in this case, we rely on a well established academic onoltogy for the term definitions:

http://purl.obolibrary.org/obo/chebi/inchikey

for example: https://www.ebi.ac.uk/chebi/searchId.do?chebiId=CHEBI:17790

[OR13]

@mwherman2000 can you propose some small json example here that might move this issue forward?

[OR13]

Discussed on the call, waiting for proposal on next steps to move this forward.

[nissimsan]

I reviewed the UBL Bill of Lading a few months ago. What is has is good, but there are important shortcomings: missing cargo description and codification, and also container details.

[mprorock]

@mwherman2000 just wanted to check in if we have any examples of this in json?

if not, I propose we close the issue unless we can get some concrete examples and motivation to add into the spec

[TallTed]

@mprorock -- s/close/label as deferred/. Closed issues have no easy path to discovery or tracking, so issues that haven't been resolved should be kept open, with suitable labels and such.

[mprorock]

@mprorock -- s/close/label as deferred/. Closed issues have no easy path to discovery or tracking, so issues that haven't been resolved should be kept open, with suitable labels and such.

Definitely open to this - @TallTed have a label suggestion for "abandoned" or low activity issues? other option is to add an "unresolved" label, and then a search for closed + unresolved shows any of those issues if they are closed and not re-opened

[TallTed]

"Deferred" with or without a target version seems to be the most common label used. I still prefer and recommend keeping these open. (It's easy enough to build search terms that exclude "deferred" when reviewing issues actively being worked.) (And these would differ from "closed wontfix" which could otherwise look the same.)

[mwherman2000]

Checkout https://docs.oasis-open.org/ubl/UBL-2.1-JSON/v1.0/cnd02/json/
More specifically, https://docs.oasis-open.org/ubl/UBL-2.1-JSON/v1.0/cnd02/json/UBL-Invoice-2.1-Example.json

[nissimsan]

I looked pretty extensively at UBL's Bill Of Lading when reviewing the BOL schema recently (just merged today). So first of all I withdraw my earlier comment - it's quite extensive. And the publishing format is also very intuitive and useful. Knowing UN/CEFACT quite well I found lots of similarities - the models are clearly connected and fundamentally the same.

The invoice schema also seems to be aligned with CEFACT's Cross Industry Invoice (CII) (ref. https://unece.org/trade/uncefact/mainstandards).

One thing which seems to be a UBL addition is sample data (ref. your link, @mwherman2000). That's a valuable addition.

I for one will continue to seek inspiration from the UBL library in ongoing work. Formally, we should semantically link to CEFACT, given that they are essentially the same. UN is the ultimate authority and CEFACT has json-ld vocabulary exposed (https://service.unece.org/trade/uncefact/vocabulary/uncefact/). But again: I actually like UBLs publishing better than CEFACT's and will continue to use.

It isn't clear what precisely it will take to close this issue. The main purpose is awareness, I believe? I'd say we're there.

[OR13]

We have reviewed, and answered this question.

[BenjaminMoe]

Closing to lack of activity. Can re-open if needed.