0138: Contexts for Rich Schema Objects

Status

Summary

Every rich schema object may have an associated @context. Contexts are JSON or JSON-LD objects. They are the standard mechanism for defining shared semantic meaning among rich schema objects.

Context objects are processed in a generic way defined in Rich Schema Objects Common.

Motivation

@context is JSON-LD’s namespacing mechanism. Contexts allow schemas, mappings, presentations, etc. to use a common vocabulary when referring to common attributes, i.e. they provide an explicit shared semantic meaning.

Tutorial

Intro to @context

@context is a JSON-LD construct that allows for namespacing and the establishment of a common vocabulary.

Context object is immutable, so it’s not possible to update existing Context, If the Context needs to be evolved, a new Context with a new version or name needs to be created.

Context object may be stored in either JSON or JSON-LD format.

Example Context

An example of the content field of a Context object:

"@context": [
    "did:sov:UVj5w8DRzcmPVDpUMr4AZhJ,
    "did:sov:AZKWUJ3zArXPG36kyTJZZm",
    "did:sov:9TDvb9PPgKQUWNQcWAFMo4",
    {
          "dct": "http://purl.org/dc/terms/",
          "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
          "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
          "Driver": "did:sov:35qJWkTM7znKnicY7dq5Yk:8:driver:2.4",
          "DriverLicense": "did:sov:Q6kuSqnxE57waPFs2xAs7q:8:driver-license:3.5",
          "CategoryOfVehicles": "DriverLicense:CategoryOfVehicles"
    }
]

Stored on Ledger

@context will be written to the ledger in a generic way defined in Rich Schema Objects Common.

Indy Node Context API

Indy Node processes ledger transaction requests via request handlers.

There is a write request handler for JSON_LD_CONTEXT transaction. The numerical code for a JSON_LD_CONTEXT transaction is 200.

A Context can be obtained from the Ledger by the generic GET_RICH_SCHEMA_OBJECT_BY_ID and GET_RICH_SCHEMA_OBJECT_BY_METADATA requests (see Rich Schema Objects Common). The numerical code for a GET_RICH_SCHEMA_OBJECT_BY_ID transaction is 300. The numerical code for a GET_RICH_SCHEMA_OBJECT_BY_METADATA transaction is 301.

JSON_LD_CONTEXT Transaction

Adds a JSON LD Context as part of Rich Schema feature.

It’s not possible to update an existing Context. If the Context needs to be evolved, a new Context with a new id and name-version needs to be created.

  • id (string):

    A unique ID (for example a DID with an id-string being base58 representation of the SHA2-256 hash of the content field)

  • content (json-serialized string):

    Context object as JSON serialized in canonical form. It must have @context as a top level key. The @context value must be either:

    1. a URI (it should dereference to a Context object)

    2. a Context object (a dict)

    3. an array of Context objects and/or Context URIs

  • rsType (string enum):

    Context’s type. Currently expected to be ctx.

  • rsName (string):

    Context’s name

  • rsVersion (string):

    Context’s version

The combination of rsType, rsName, and rsVersion must be unique among all rich schema objects on the ledger.

The generic patterns for JSON_LD_CONTEXT transaction, request, and reply can be found in Rich Schema Objects Common.

Indy VDR API

Indy VDR methods for adding and retrieving @context from the ledger comply with the generic approach described in Rich Schema Objects Common.

This means the following methods can be used:

  • indy_vdr_build_rich_schema_object_request

  • indy_vdr_build_get_schema_object_by_id_request

  • indy_vdr_build_get_schema_object_by_metadata_request

Reference

More information on the Verifiable Credential data model use of @context may be found here.

More information on @context from the JSON-LD specification may be found here and here.

Drawbacks

Requiring a @context for each rich schema object introduces more complexity.

Rationale and alternatives

Though requiring a @context for each rich schema object increases the complexity of the system, it also provides a means for better managing the complexity already present.

Unresolved questions and future work

  • We are not defining Rich Schema objects as DID DOCs for now. We may re-consider this in future once DID DOC format is finalized.

  • It may make sense to extend DID specification to include using DID for referencing Rich Schema objects.

  • The proposed canonicalization form of a content to be used for DID’s id-string generation is in a Draft version, so we may find a better way to do it.

  • We don’t check if the specified @context is valid by resolving all external links.