Resolve apparent conflict between UNTP JSON object modelling requirements and JSON-LD types

I'm spinning this issue off from #540 after chatting with @revstifeev on !556 (closed) . I feel we need to be very clear about where the apparent conflict is and why. If you see issues in this description, please let me know and I'll work to clarify and improve it.

Summary

The issue is that, using the DPP as an example, UNTP wants to have a re-usable and extensible Product as well as being able to generate JSON-Schemas and sample data for the DPP.credentialSubject - which is a Product with related claims and other credential-specific data. The former allows the product to be validated and re-used in other places (such as a transformation event?) without including the credential-specific claims about the product.

For JSON-Schema, this requires two different objects to be defined - the Product type and the type for the DPP credentialSubject which is a Product-with-claims. This is why, within the tool we're using for modeling the data, jargon.sh, we are modeling two objects - a Product and a Product-with-claims (just for clarity - but ProductPassport is the current real name in our model). This allows the tool to generate JSON-Schemas and sample data for the Product-with-claims while still having the Product as a re-usable class.

JSON-LD/RDF on the other hand requires only a single Product type (as long as the related claim term is defined somewhere in the context), since JSON-LD data can be annotated with any defined predicate in an RDF-triple (there is no schema, in that sense).

This lead to issue #540, where it was pointed out that in our 0.6 release, the VC credentialSubject was not a Product (that is, it had a different id to that of the product), which was wrong.

Possible solution or not

I thought we had found a solution to this, which demonstrated that we can model the two types in our tooling (and hence get our correct schemas and sample data) while effectively telling JSON-LD that they are both the same Product type (the @ids of the two types are the same Product URI) with the result that the expanded JSON-LD is identical to the ideal JSON-LD solution (I think - check), though the unexpanded JSON-LD does use the extra type. See the demonstration using the smallest working example.

I understand @revstifeev doesn't like this solution because the DPP credential's JSON data for credentialSubject is then the secondary Product-with-claims type (ProductPassport in the model) rather than just Product, even if the expanded JSON-LD ends up identical (since both those types have the same type IRI pointing at the IRI for Product only). But it's probably better if Roman speaks for himself - there could be other JSON-LD issues with this approach that I've not understood. You can read the whole discussion about this on the merge request.

List of assumptions to re-evaluate solutions

In case we can remove any of the assumptions to find another, better, solution, here they are:

UNTP Assumptions:

A Product is modelled with the properties inherent to the product only - so a Product has a name, a batchNumber, productImage, serialNumber etc. perhaps defined by the manufacturer of that product. It does not inherently include the claims about about the Product (a conformityClaim relationship property). This allows the Product model to be related to claims about a product in a VerifiableCredential's credentialSubject, as well as be reused and extended in other contexts.

So with that assumption, in terms of modelling JSON-Schema and examples, we need both a Product JSON-Schema and a separate Product-with-claims JSON-Schema to validate and provide examples for the VerifiableCredential's credentialSubject. JSON-LD/RDF don't need these two separate models/types as you can simply add relationships (triplets) to any data and so there is just one Product type.

Note that, if we relaxed this assumption in our modelling and only defined a single core UNTP Product including the conformityClaim property (and others), we would have a single type for both JSON-LD and JSON-Schema. We would no longer have the separate re-usable Product (or Facility for DFR's). I'm not sure of the implications. Though it would solve the JSON-Schema and example instances, it would perhaps introduce a similar a new semantic issue from JSON-LD, since the credentialSubject would no longer be the object together with claims about that object, but just the object itself (which includes the claims) - check with Roman and Steve? Maybe it's not an issue and we don't need the separate Product without the claims and so can just define one?

VerifiableCredential Assumptions:

From the Verifiable Credential data model specification, the credentialSubject is an object (can be a set of objects, but in UNTP we're currently using a single object) where that object MUST be the subject of one or more claims [about the object] which [that is, those claims] MUST be serialized inside the credentialSubject property.

So within the VerifiableCredential's credentialSubject, the id (and other properties if desired) are that of the Product (the subject), together with one or more claims about that Product (the conformityClaim property and others, which are not part of the subject Product itself.

Again, for JSON-LD, it's no problem for the Type of the subject to be a Product while including extra relations. But for JSON-Schema, a separate schema is required for this Product-with-extra-relations to be able to validate correctly and generate sample data (unless as above, we only have the Product with the claims as properties always.

Or the original solution in the summary above, where the expanded JSON-LD sees one type only while JSON-Schema sees two.

JSON-Schema assumptions:

A JSON-Schema object used to validate (or create sample data for) the Product-with-claims used in a DigitalProductPassport's credentialSubject is a different JSON-Schema object than that used to validate a Product generally, even if it is only one type in JSON-LD