Product Passport Data Model

[ashleythedeveloper]

@onthebreeze has hinted at an update to the Product Passport data model, drawing on insights from CIRPASS.

This ticket is meant to prompt a review and discussion of the suggested changes.

[onthebreeze]

submitted PR #41

[onthebreeze]

But questions remain..

1. Current the claims are associated with the passport. But perhaps it would be better to have claims linked to "facility" or "Product" or "batch" as appropriate - so it's much clearer which thing is the subject of the claims.
2. Which raises a question about SKU vs Itemised DPPs. For a given product there will be many conformity claims that are the SKU level. But some could be at batch/item level and traceability certainly works at the batch/item level. Assume a manufacturer ships 1 million serialised items all from the same SKU. Is that 1 million DPPs with the same or similar SKU data and different item data? Or is it 1 SKU level DPP and a million batch level DPPs, each of which reference the SKU DPP?
3. What happens when SKU level conformity data changes / improves? That should mean a new DPP for that same SKU. It would be pretty simple for a link resolver to always return the latest DPP for a given SKU. But should the older DPPs still be discoverable? If so then maybe DPPs always have a reference to "previousVersion"?
4. The latest DPP spec page includes a "bassBalanceEvidence" property. That was meant to accomodate the problem of linking item level claims to facility level evidence. But I think this is potentially confusing and messy (even though it was me that put it there). id like to remove it and just have claims at the right level as described in the first point in this list.
5. The Claim structure has a "benchmark" property. That's meant to give the consumer something relevant to compare against. For example red meat typically has a carbon intensity of between 3 tons/ton and 30 tons per ton with an industyr average of (I think) about 15 tons per ton. Without that benchmark there's no way to know whether a claim of 5 tons per ton is good or bad. For different products it would be terrible performance but for beef it's very good... Is this a useful idea?
6. Building on the previous point. Should we have overall sustainabilty performance scores (which could be some aggregate comparison of actual to benchmark) and trust performance scores (which could be driven by the existence and integrity (in a trust graph sense) of associated evidence. These properties in a DPP would be self-asserted by the issuer of a DPP so how trust worthy would they be?
7. Finally I've been involved in a few discussions now about the idea of some trusted authority acting as a "verifier" (in a business, not VC sense) of all the claims in a DPP. Or at least a significant subset of them. Some government authorities might do that as an export facilitation service. Also some conformity assessment bodies are considering the idea of "endorsing" a collection of claims even if they aren't the test/inspection authority for some of them. It's a nice idea but what form does this take technically? Does the authority envelope and counter-sign the original DPP - perhaps with some redacted claims that they cant verify)? Or is it an attached guaranteeOfOrigin credential referenced at DPP root level - where the guranteeOfOrigin credential looks just like the DPP but with some claims removed?

Anyhow - lots of interesting business challenges to address here. Fair easy to accomodate technically but we really need some clear thinking on the business needs.

[GerhardHNL]

1. A claim is a statement that is strongly believed to be true, although it may not have been proven. Looking at the data model for product conformity as well, both have the focus on the product. I would leave it as it is like in product conformity model, and use "topic" (assuming this marks the type of assessed object).
2. EU DPP, focusses on model (e.g. being a GTIN), item (example being a SGTIN) and batch (example being GTIN+BatchNo). I do n ot think SKUs are useful, as SKUs are internal identifiers specific to a particular organization, whereas GTINs are globally standardized identifiers used for product identification and tracking across supply chains and retail environments. The GTIN rules, commonly applied to products in a particular sector may have flexibility e.g. by specify which changes may cause the creation of a new product. I worked with CIRPASS on different use case on DPPs where the product was repaired, refurbished or where the manuafacturer did not exist anymore. There will be also references to 'previous/related' DPPs in this context too.
3. See above.
4. Mass balance is something that could be evidenced by traceability data, in which the inputs materials including UoM have been specified for a particlar product and facility OR it could be evidenced by a referenced standard (such as in Textile GOTS, which has this subject into their scope).
5. Benchmark: A metric should have a link to something link Sustainability Score Index, which specifies the benchmark score value and the organization responsible for the benchmark.
6. See above, such is already in the Circular Product Data model. Self-Assessed, how trustworthy. In agriculture business (i am aware off), growers are allowed by the auction to assign a quality level to their products, even sustainability criteria (self-assessments). Random inspections and penalties by the auction make it all quite trust worthy. So it all depends on the context and type of product.
7. Is this all related to the concept of AuthorisedSource, see Product Conformity data model. Can't the authorised source not stand in for serveral claims made, as conformity assessment bodies could follow the instructions on such claims made in standards/regulations? ITC Standardsmap just made clear which criteria could be used and which standards related to these, which makes them trustworthy.

Just some first thoughts. Regards gerhard

[JohnOnGH]

Referring to Steve's numbering...

1. This point (and others in the list) make me feel that we need a more formal description of the model. I'd like to see the logical model be expressed in something like OntoUML (https://ontouml.org/) which would allow us to consider, express and test the logic behind the structure more rigorously.
2. See 1
3. Yes, agree. We must have a way to allow for change and persistence of data and its verifiability and meaning over time.
4. Your view is better informed than mine on this
5. I'd not include benchmark since I think it risks being used for false purposes and ultimately compliance/conformity is the essential quality of claims
6. See 5.
7. Agree with the business benefit of the service. I guess the answer to the technical implementation comes from consideration of what behaviour / capability we want the design to exhibit. If there are no differences between the two choices you present, then we can choose the most technically elegant/efficient.

[onthebreeze]

OK all, based on the discussion in the last meeting and some other bits of feedback, here's the proposed changes for the next PR on DPP.

• I'll remove the "Verifiable Credential" class in the model because it causes some confusion. Better the model represents a logical model of a DPP irrespective of how it is implemented. This does NOT mean we are letting go of VCs as the preferred implementation! But probably better to move this stuff to the Verifiable Credentials section of UNTP where we can describe in more detail how all of the logical models should be implemented as a VC.
• With regard to the SKU vs batch question. First of all the word "SKU" causes some confusion because some regard it as an internal number and some regard it as a global identifier equivalent to a GTIN. So will stop using that word and instead just talk about product identifier. I will refactor the model to put the passport class at the top and change "productInformation" to just "Product" and have pretty much everything about that product including claims, batch, etc stemming from the product class. Better aligned with the CEFACT reference model and some other passport models out there (which we'll need to map to int he next stage of work).
• I'll remove the massBalanceEvidence property. As discussed, it's the job of the related conformity credential to provide evidence to support facility -> product level allocations. There's going to be more interesting discussions ahead about mass balance because facility/product allocations are only one kind. Lets remove this until we have a really solid discussion and consensus about how best to deal with mass balance questions.
• With regard to benchmarks and performance ratings, we ended up with a split between the leave it in and cut it out camps. I had a look at some other passports (notably the GBA DPP) and I do see the idea of ratings in there. What I suggest is that we leave it in and let the value of this stuff be informed by pilot project implementations. If it gets used we keep it if not then deprecate after pilots.
• Looking at several other passports, there is a very common practice of including basic product dimension data like net/gross weight, LxWxH dimensions and so on. I'm tempted to add a class for this which can be extended with industry specific stuff like battery capacity in AmpHours.
• Also many passports have the idea of a bill of materials (BoM) - ie the component parts of a product. A basic feature of UNTP is the traceability event structure that is meant to be a means to trace back from the shipped products to earlier steps in the value chain. So in theory a BoM is implemented in UNTP as an EPCIS event. Digging a little deeper, EPCIS has two different event types for this. One is the transformation event that represents a manufacturing process where inputs are irreversibly consumed (eg the coal and iron ore to make steel). The other is the association event that represents something more like a potentially reversible assembly step (like putting the wheels on a car or major components in a computer). A BoM can also exist at product class level (all cars of model X have four wheels) as well as at batch or item level (this specific Car VIN has these specific serialised wheels). Rather than reinvent all the work that has gone into EPCIS I think best to link the traceability event list to the product and maybe add a short list of UNTP type codes that indicate how EPCIS is used in the UNTP context (for example billOfMaterials might be one of the type codes). I think this is the lowest risk solution which is best validated through pilots rather than too much more discussion?

Will all these changes, I propose that the next PR will close this ticket. The next step will be to actually verify that various industry / jurisdiction passport standards that are under development (eg GBA DPP, EU DPP for textiles, etc) can be mapped fairly easily to UNTP DPP with any industry/country specific stuff being easily supported as class extensions. But I think that work is best done via separate tickets which i'll raise after closing this one.

hope this works for everyone.

[GerhardHNL]

Hi Steve,

About the BoM. In the Product Circularity data model, the BoM is a separate entity, which as a relation to the components it has. In addition, traceability data is part of the model. I would suggest to have the possibility to differentiate meta data on the manufactured finished product and the history data of that product. The BoM is a well know aspect of ERP systems, and therefore easy to produce as data. The BoM serves as a blueprint for manufacturing and procurement processes, ensuring that all necessary components are available and properly assembled to produce the final product. This is especially helpful for repair services, remanufacturing, refurbishing. The aspect of ratings is also in the beforementioned data model. Not yet the benchmarks (e.g. an average rating for the same type of product on the market, for the type of facility in the market etc.). It’s would be a plus when a rating goes along which a benchmark e.g. 12KG of CO2 for a flight between London and Melbourne does tell anyone something, but when compared to industry average it would tell the consumer something about the new or old type of planes he is flying. Net/gross weight are also in the basic information of the product, but also volume for the packaging (think about the air in parcels being transported). The dimensions of the product relate a bit to this but is not in the beforementioned model.

Have a nice eastern weekend.

Best regards Gerhard

[CXsailing]

Hi Steve and all I am in line with your notes and proposal. I trust the BoM has a value in many industries, especially when it comes to volunteer or requested recycling (cf batteries).

[PatStLouis]

@onthebreeze for a conformityInformation entry, is the conformityEvidence.credential URL expected to resolve to a content-type: application/json-ld response containing the signed Conformity Credential?

[onthebreeze]

Hi @GerhardHNL and thanks @CXsailing

with regard to BoM, I agree it's important to include. The question was more about how best to represent it. In the current model, the thinking is that it is just a type of traceability event (transformation or association). But maybe that's a bit too abstract and confusing. However if we add a separate BillOfMaterials structure then there may also be confusion about why there is a BoM as well as a very similar purposed traceability event. One option is to remove the traceability event structure altogether and just have a BoM - on the basis that if you list component parts each with ID then you can resolve each of those component part to it's own DPP, and so on through the value chain. So traceability is achieved with only a BoM in each DPP. But that assumes that we wont find any use cases for other traceability event types. It may look like a nice simplifying strategy that we come to regret. I think this topic deserves a separate ticket so will raise one.

@PatStLouis - yes, except that I think it's important not to assume that every conformity credential is issued as a VC. That's why the evidence.formatCode is there - to allow the URL to point to a PDF for example. Not machine readable but better than nothing.

[PatStLouis]

Thanks for reminding me that other things exist besides VC's, its easy to get tunnel vision sometimes. In the older DPP VC examples, the deforestation evidence was linking to a UI operating a verification with the VC embedded within the page. Returning the VC (or other evidence document type) directly is favorable IMO.

[GerhardHNL]

Hi Steve,

Indeed. While a BOM is a structured list of materials required for manufacturing a product, collecting material information from EPCIS events involves extracting data about the movement and attributes of materials within the supply chain. These two approaches complement each other and can be used together to ensure efficient and transparent management of materials and products throughout their lifecycle. Collecting events remains important in order to capture the journey of the product at every stage in the supply chain. I think the BoM would be the basis for specifying the components of the product or material for a transformation event. This set of components will have an identifier, later reflected in a unique product ID. By associating specific product IDs with the corresponding BoMs, manufacturers can ensure that the correct materials and components are used in the production of each item. Thus, it is relevant for quality control, traceability, and compliance purposes. Maybe for a EPCIS transaction event one could register (create the event) with a reference to the BoM document associated with the product ID that goes along with the transformation event. Similar to the object event showing that a shipment has occurred using as well a transaction event where the product is listed on a trade shipment document.

Best regards,

Gerhard

[crammartos]

With regard to Steve's point 1: Everything in a product passport should be "true" for the product in question, i.e. they are product claims. It is true that claims included in the passport may cover components, batches, facilities, or other product-related inputs or activities. Still, these are only included because the claims in question also apply to the product. In other words, if a facility is certified as paying fair wages, then the product was made by workers who received a fair wage; if the batch was made with safe chemicals, then the product was made with safe chemicals, etc. As a result - all the claims are for the product but, as Gerhard suggests, the "topic" of the claim may differ.

[crammartos]

With regard to Steve's point 7 about "some trusted authority acting as a "verifier" " To my mind the usefulness of this depends on the client/customer for the verification - what do they want, what will they accept/require? This will determine the data required. So, who are the possible clients - who is this verification function being developed for?

• Customs and other border control authorities in the exporting country or in the importing country? - these parties are often constrained in what they can accept by regulations or even laws and while this may be more difficult to cope with in the importing country, it may also be a problem in the exporting country of origin
• Brands and large retailers? - Who might find it useful for demonstrating due diligence
• Final consumers? - Who just want credible reassurances

[crammartos]

With regard to Steve's point 2 SKUs are not useful - it stands for Sales Keeping Unit and is used by wholesalers and retailers for tracking styles, colors and sizes. It is not linked to origin. As a result, products with the same SKU may be manufactured by different companies and even in different countries - so not only might the sustainability of products with the same SKU change over time, they might change by color or size or date of manufacture, etc. SKUs can be useful for determining some aspects related to circularity, for example resale value, season (in the case of clothing), repairability, etc. On the other hand, they are not very useful for sustainability criteria that can vary across countries and manufacturers.

Also, I believe that the sustainability claims valid for a product should be those in effect at the time of manufacture/sale of a product or component. For example, a claim by a facility where a product is manufactured should only apply to the products manufactured while that claim was verified to be valid. In other words, if a product was manufactured before sustainability was improved or after it deteriorated, it is the claim valid at the time of manufacture that should "count". As a result, older sustainability data needs to be kept and needs to be discoverable.

[onthebreeze]

Regarding DPP data model, in addition to all the decisions at https://github.com/uncefact/spec-untp/issues/38 I’ve been thonging about

1. How we manage multiple identifiers for a thing - eg an ABN, a GLN and a DID for the same entity.
2. How we define these identifier relationships (ie this DID is that ABN) so that linked evidence works.
3. Whether we should use resolvable URLs as identifiers for products or whether it’s better to just use the identifier and then resolve using the appropriate link resolution method for that identifier scheme.
4. How to manage product characteristics and packaging information.
5. And, perhaps controversially for UN, whether we should be making much greater use of schema.org semantics - eg https://schema.org/Product. If, as the schema.org publishers claim, this vocabulary is used on over 10 million websites, then it might be more friendly to our implementers to maximise use of that vocabulary.

[nissimsan]

productClass is bad name. It should be (something like) classification.

[nissimsan]

Identification scheme should not be limited by today's constraints.

[nissimsan]

@onthebreeze , pls make a PR so we have something to continue the discussion from

[onthebreeze]

@nissimsan - done via PR #54 - could you review and merge?

[nissimsan]

Reviewed.

But not merging; sticking to our agreed procedures we merge together on the meetings. This way the PR can be introduced, everyone gets a chance to keep track of what is changing.