ConformityCredential Product vs DPP Product

[Fak3]

On the ConformityCredential diagram There is a Product class, which has properties testedBatchId and verifiedByCAB which do not belong to the generic Product, but to the particular ConformityAsessment If there are multiple ConformityAsessment of the same product, the resulting graph will appear confusing, as json object nesting is lost at the graph level:

- type: ConformityAsessment
  subjectProducts:
  - id: product1
    testedBatchId: goodBatch1
- type: ConformityAsessment
  subjectProducts:
  - id: product1
    testedBatchId: badBatch1

will result in RDF graph triples:

product1 testedBatchId goodBatch1;
product1 testedBatchId badBatch1;

The association of product batch to the measured results is lost.

One potential way to correctly model the graph is to introduce ProductAsessment class:

classDiagram
    ConformityAsessment <|-- ProductAsessment
    ProductAsessment <|-- Product
    class ConformityAsessment{
      ProductAsessment subjectProducts
    }
    class ProductAsessment{
      URI testedBatchId
      Product product
    }
    class Product{
      Identifier indentifier
      Text modelName
    }

Another way could be to rename Product to the ProductAsessment, so that the assessment has unique id, distinct form the Product id

[PatStLouis]

since the assessment already occurred I would be more include to assessedProducts or attestedProducts ? Have a product assessment within an assessment seems redundant but maybe I'm not seeing this from the right angle

[Fak3]

since the assessment already occurred I would be more include to assessedProducts or attestedProducts ? Have a product assessment within an assessment seems redundant but maybe I'm not seeing this from the right angle

Or make ProductAsessment a subclass of ConformityAsessment. With extra fields, referencing product and batch id.

[onthebreeze]

Good comments. One attestation has many assessments and the subject of an assessment can be either product(s) or facility(s). So perhaps the solution is to call them assessedProduct?

[Fak3]

Good comments. One attestation has many assessments and the subject of an assessment can be either product(s) or facility(s). So perhaps the solution is to call them assessedProduct?

Can a single attestation have both product and facility assessments?

[PatStLouis]

@onthebreeze does it have to be a facility or could we call it a location leaving room for defining if its a facility or an area of land?

In our use case, when emitting a TenureTitle its an assessment made on an area of land which may or may not have a facility (well) on it depending on the title. Some title give permission for 'exploration' of the land.

so something like:

"assessedLocations":[
  {
      "type": ["Facility", "PetroleumWell"]   \\ Facility would be defined by the UNTP, while PetroleumWell would be defined by the assessor
  },
  {
      "type": ["RegulatedLand", "Tract"]
  }
],
"assessedProducts":[
  {
      "type": ["RawMaterial", "Petroleum"] \\ we are referring to a type of product more than a specific instance
  }
]

assessedProducts or attestedProducts both sound great to me

@Fak3 to answer your question yes, at least in some use cases. All of this really depends on the assessment/use case.

The reason why I'm not seeing value in defining a specific product is simply based on the use case we are looking at in BC. Let's say a DPP is about a shipment of copper. It would link to some ConformityAttestation, one of them containing a MinesActPermit. The DPP product will be about a specific instance/shipment of copper, which was extracted at a specific time (probably linking to a traceability event) and of a specific volume.

The ConformityAssessment won't be about this specific instance of copper in our case, it will simply say that the issuer of the DPP (which I would believe to be the producer here) is legally allowed to operate on this specific piece of land/mine facility to extract copper (and any other commodity included in the permit).

So its not bound to a specific product instance but more a product type. Linking it to a specific product instance would mean we would have to re-issue a new conformity credential for each DPP which is not the model we are going after. If a permit is valid for 5 years, we will issue it once (unless there are amendments made to the permit and/or the legal act).

Now this being said, I'm interested in hearing a use case you might be looking into where a specific instance of a product would need to be included in the ConformityAssessment so we can make a sound decision here.

[onthebreeze]

This facility complies with std ABC for the production of products X, y, z

Or this company complies with std ABC for the production of x, y, z at facilities q, r, s

Or this product complies with std ABC if made in facilities q, r, s

Or this specific batch was tested for conformance with criteria abc at facility x