Expanding UNTP Credentials based on the Proposed JSON-LD Context File Structure

Created by: ashleythedeveloper

Based on my understanding, it has been proposed that we have a more "compact" JSON-LD structure than what we are currently producing via Jargon.

For example:

Compact JSON-LD context file

{
  "@context": {
    "@protected": true,

    "untp": "https://test.uncefact.org/vocabulary/untp/",

    "ConformityCredential": {
      "@id": "untp:ConformityCredential",
      "@context": {
        "@protected": true,

        "id": "@id",
        "type": "@type"
      }
    },

    "ConformityAttestation": {
      "@id": "untp:ConformityCredential#conformityattestation",
      "@context": {
        "@protected": true,

        "id": "@id",
        "type": "@type",

        "untp": "https://uncefact.github.io/spec-untp/docs/specification/",

        "assessments": "untp:ConformityCredential#conformityassessment"
      }
    },

    "ConformityAssessment": {
      "@id": "untp:ConformityCredential#conformityassessment",
      "@context": {
        "@protected": true,

        "id": "@id",
        "type": "@type",

        "untp": "https://uncefact.github.io/spec-untp/docs/specification/",

        "topic": "untp:ConformityCredential#sustainabilitytopic",
        "level": "untp:ConformityCredential#assessmentAssuranceCode",
        "regulation": "untp:ConformityCredential#regulation",
        "products": "untp:ConformityCredential#product", 
        "entities": "untp:ConformityCredential#party",
        "facilities": "untp:ConformityCredential#facility"
      }
    },
    ...
  }
}

"Inline" JSON-LD context file

{
  "@context": {
    "@version": 1.1,
    "description": "xsd:string",
    "validFrom": "xsd:string",
    "validTo": "xsd:string",
    "scope": {
      "@id": "xsd:string",
      "@context": {
        "id": "xsd:string",
        "name": "xsd:string",
        "dateOfIssue": "xsd:string",
        "issuingBody": {
          "@id": "xsd:string",
          "@context": {
            "id": "xsd:string",
            "name": "xsd:string",
            "type": "xsd:string"
          }
        },
        "criteria": {
          "@id": "xsd:string",
          "@container": "@list",
          "@context": {
            "id": "xsd:string",
            "description": "xsd:string",
            "type": "xsd:string",
            "validationService": "xsd:string"
          }
        }
      }
    },
    "issuedBy": {
      "@id": "xsd:string",
      "@context": {
        "id": "xsd:string",
        "name": "xsd:string",
        "type": "xsd:string"
      }
    },
   ....
}

One of the issues I have had previously using the compact context file structure (logically grouped terms in classes), as opposed to an "inline" context file structure (defines all of the terms at the root level of the context file), is that when a Verifiable Credential is produced with such a context file (logically grouped terms in classes) in the context array, the resulting VC fails to expand.

That is, if we either have not defined the "@vocab": "https://www.w3.org/ns/credentials/issuer-dependent#" term, which will resolve any undefined terms, or we pollute the VC with "type" properties mapping to the corresponding term defined in the context file.

For example:

With vocab

{
  "@context": {
    "@protected": true,

    "@vocab": "https://www.w3.org/ns/credentials/issuer-dependent#",

    "untp": "https://test.uncefact.org/vocabulary/untp/",

    "ConformityCredential": {
      "@id": "untp:ConformityCredential",
      "@context": {
        "@protected": true,

        "id": "@id",
        "type": "@type"
      }
    },

    "ConformityAttestation": {
      "@id": "untp:ConformityCredential#conformityattestation",
      "@context": {
        "@protected": true,

        "id": "@id",
        "type": "@type",

        "untp": "https://uncefact.github.io/spec-untp/docs/specification/",

        "assessments": "untp:ConformityCredential#conformityassessment"
      }
    },

    "ConformityAssessment": {
      "@id": "untp:ConformityCredential#conformityassessment",
      "@context": {
        "@protected": true,

        "id": "@id",
        "type": "@type",

        "untp": "https://uncefact.github.io/spec-untp/docs/specification/",

        "topic": "untp:ConformityCredential#sustainabilitytopic",
        "level": "untp:ConformityCredential#assessmentAssuranceCode",
        "regulation": "untp:ConformityCredential#regulation",
        "products": "untp:ConformityCredential#product", 
        "entities": "untp:ConformityCredential#party",
        "facilities": "untp:ConformityCredential#facility"
      }
    },
    ...
  }
}

With type

{
  "id": "http://university.example/credentials/3732",
  "type": ["VerifiableCredential", "ConformityCredential"],
  "issuer": "did:web:api.vckit.showthething.com",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "http://example.com/D1013",
    "type": "ConformityAttestation",
    "assessorLevel": "3rdParty",
    "assessmentLevel": "Accredited",
    "description": "The provided certificate is issued to Alrite Steel and Services NZ, Ltd by the Australasian Certification Authority for Reinforcing and Structural Steels Ltd (ACRS). It certifies that the company complies with the ACRS Traceability Scheme and relevant ACRS Quality and Operations Evaluation Procedures. The certification covers the purchase, supply, and utilization of sub-contracted services for steel reinforcing materials, hot-rolled plates, floorplates, slabs, flat products, bars, and sections as per various AS/NZS standards.",
    "scope": {
    "type": "ConformityAssessmentScheme",
      "id": "https://www.steelcertification.com/traceability-certification",
      "name": "Traceability Certification Scheme",
      "issuingBody": {
        "type": "Party",
        "name": "AUSTRALASIAN CERTIFICATION AUTHORITY FOR REINFORCING AND STRUCTURAL STEELS LTD",
        "identifiers": [
          {
           "type": "Identifier",
            "scheme": "https://abr.business.gov.au",
            "identifierValue": "40096692545",
            "identifierURI": "https://abr.business.gov.au/ABN/View?abn=40096692545"
          }
        ]
      },
      "dateOfIssue": "2000-01-01T10:00:00.000Z"
    },
    ....
}

My question is, if we proceed with the proposed shape of the context file (logically grouped terms in classes), is it sufficient to pollute the credential with "type" properties for the Credential to expand, or is there another way to map the properties defined in the credential with the terms within the context file?

If the solution to allow the credential to expand is to pollute the credential with "type" properties pointing to the correct term in the context file, I believe we have a conflict within the Conformity Credential data model as it contains a property "type", and there will be a conflict with the "type" property pointing to the correct term within the Conformity Credential Context file.