- Author: Ken Ebert [email protected], Brent Zundel [email protected], Alexander Shcherbakov [email protected]
- Start Date: 2019-06-07T13:51:17-06:00
- Status: PROPOSED
- Status Date: 2019-06-18
- Status Note: part of Rich Schema work
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.
@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.
@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.
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"
}
]
@context
will be written to the ledger in a generic way defined in
Rich Schema Objects Common.
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
.
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:- a URI (it should dereference to a Context object)
- a Context object (a dict)
- 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 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
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.
- 0119: Rich Schema Objects
- 0120: Rich Schema Objects Common
- Common write request structure
- Common read request structure
- Common transaction structure
- Common reply structure for write requests
- Common reply structure for read requests
Requiring a @context
for each rich schema object introduces more
complexity.
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.
- 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.