untp.Party should be a subclass of Identifier

[absoludity]

Describe the bug
One of the issues on #184 which @PatStLouis mentions is:

Type validation too strict

• For some of the nested objects, there is too strict validation on the types set. As an example, I can't set an "issuingParty" to a type of "Party", it must be set to "Identifier".

which, given that the property is called issuingParty yet the type is explicitly Identifier, sounds like either

• Party should be a sub-class of Identifier so that the type would be ["Party", "Identifier"] ( and the JSON Schema should check that the type contains Identifier rather than equality with ["Identifier"], but that's being handled separately as part of the main extensibility of Conformance feedback from BCGov - DCC Extension - BCMinesActPermitCredential #184), or
• the type of issuingParty should actually be Party

or both. I suspect it is the former but need input from someone who was involved in this. See below for reasoning.

Case for Party IS An Identifier

Looking at the untp-core 0.5.0 definitions in the jargon.sh editor (as Identifier is #hidden so doesn't appear on the image/map), the Identifier entity has only 4 properties: id, name, registeredId and idScheme, which are the same first four fields found on the core Party entity, as well as the core Product and Facility entities. This would be the case explicitly if Party was a subclass of Identifier, currently they just both happen to have the same first four fields.

The description for the Identifier entity says:

The ID and Name of an identified entity such as a product, facility, party, standard, etc.

which also implies that Product, Facility, Party and Standard have either an "IS A" or "HAS A" relationship with Identifier. The entity descriptions imply the first three are sub-classes ("IS A"), while Standard HAS An Identifier (the issuingParty property), which leaves me wondering if that description could be improved [1]

Back to the DCC 0.5.0 definitions , the issuingParty property in question is part of the ConformityAssessmentScheme which is a subclass of untp.Standard:

ConformityAssessmentScheme:untp.Standard
  trustmark:untp.BinaryFile

so the issuingParty property is actually on the base Standard entity from which ConformityAssessmentScheme is subclassed - a ConformityAssessmentScheme HAS An Identifier as Standard (the parent class) explicitly defines the property as an Identifier:

Standard
  ^id:URI
  name:Text
  issuingParty:Identifier
  issueDate:Date

So I suspect (but am keen for someone with more experience to confirm) that Party, Product and Facility are intended as sub-classes of Identifier. This would mean that the type of a Party would be ["Party", "Identifier"] for example, and so with the extensible JSON Schema changes, would allow a Party to be used as the issuingParty.

Note that it would also allow a Product, Facility or any other sub-class of Identifier to be used as the issuingParty. If that is not intended (?) then I expect that Standard.issuingParty's type should be Party (while still having all 3 sub-classing Identifier, this restricts issuingParty to just Party identifiers.

[1] Perhaps:

The ID and Name of an identified entity such as a product, facility or party etc.

[absoludity]

Based on the above, I've created a related jargon suggestion that:

• Updates Party, Product and Facility to be sub-classes of Identifier
• Updates standard.issuingParty to use the type Party (which is now an Identifier) rather than Identifier (which would allow any Identifier sub-class to be used (I don't have the background to know if that's intended, but from the naming, it sounds not).

https://jargon.sh/user/unece/untp-core/suggestion/1/?view=changes

[absoludity]

After chatting with @onthebreeze about this and other related issues, I understand a bit more about the intention of the Identifier entity (something like an $id but that provides a bit more context without having to necessarily look up the $id, which may even be private - this is why certain core entities are redefined with certain properties removed on DCC/DPP etc). So I'll close the above jargon suggestion and investigate options.