While the media types describing conforming documents defined in this -specification always express JSON-LD, JSON-LD processing is not required to be -performed, since JSON-LD is JSON. Some scenarios where processing a -verifiable credential or a verifiable presentation as JSON is -desirable include, but are not limited to: +specification always express JSON-LD, RDF processing is not required to be +performed, since JSON-LD is a concrete RDF syntax as described in [RDF11-CONCEPTS]. +Hence, a JSON-LD document is both an RDF document and a JSON document and correspondingly represents an instance of an RDF data model. +
+
+RDF is a technology for modeling graphs of statements. Each statement is a single subject-property-value
+relationship, which is referred to as a claim in this specification. JSON-LD is a technology that
+enables the expression of RDF using idiomatic JSON, enabling developers familiar with JSON to write
+applications to consume RDF as JSON. In general, subjects are expressed as JSON objects with each property and value of the subject as a JSON key and value, respectively. A special affordance is made to express an identifier of a subject, if present, using the @id JSON key, which is aliased in this specification to id.
+See Relationship to RDF for more details.
+
+As JSON can be used to express all different kinds of information, a consumer of a particular JSON
+document can only properly interpret the authors intent if they possess information that contextualizes
+and disambiguates it from other possible expressions. Information to assist with this interpretation can either
+be wholly external to the JSON document or linked from within it. Compact JSON-LD documents include a @context property that internally expresses or links to contextual information and, per the JSON-LD specification, these documents follow object-oriented organizational principles to express claims. These features enable generalized processors to be written to convert JSON-LD documents from one context to another, but this is not needed when consumers receive JSON-LD documents that already use the context and shape that they expect. Authors of JSON-LD documents, such as issuers of verifiable credentials, are required to provide proper JSON-LD contexts and follow these rules in order to facilitate interoperability.
+
+The text below helps consumers understand how to ensure a JSON-LD document is expressed in a context +and shape that their application already understands such that they do not need to transform it in +order to consume its contents. Notably, this does not mean that consumers do not need to understand any context at all, rather, consuming applications only need to understand a chosen set of contexts and document shapes to work with and not others. Issuers can publish contexts and information about their verifiable credentials to aid consumers who do not use generalized processors, just like would be done with any other JSON-formatted data. +
++Processing verifiable credentials or verifiable presentations +by transforming JSON-LD to RDF might be desirable under the following conditions:
--That is, JSON processing is allowed as long as the document being consumed or -produced is a conforming document. If JSON processing is desired, an -implementer is advised to follow the following rule: +Instead of performing general JSON-LD processing, application-specific processing is allowed as long as the document being consumed or +produced is a conforming document. +
+ +
+However, the intention of the issuer is not preserved, unless the rules expressed
+in the @context are followed, and the resulting Verifiable Credential Graphs, and their exact RDF types, and node and edge structure is understood by the verifier. By following the rules laid out in this section, applications can be hard-coded against
+specific contexts, just as they are commonly hard-coded to consume other
+application-specific JSON formats.
+
-The rule above guarantees semantic interoperability between JSON and JSON-LD for -literal JSON keys mapped to URIs by the `@context` mechanism. While JSON-LD -processors will use the specific mechanism provided and can verify that all -terms are correctly specified, JSON-based processors implicitly accept the same -semantics without performing any JSON-LD transformations, but instead by +
+While some RDF processors will use the language features of JSON-LD and can verify that all +terms are correctly specified, JSON-LD processors explicitly accept the same +semantics without performing any RDF transformations, but instead by applying the above rules. In other words, the context in which the data exchange -happens is explicitly stated for both JSON and JSON-LD by using the same -mechanism. With respect to JSON-based processors, this is achieved in a -lightweight manner, without having to use JSON-LD processing libraries. +happens is explicitly stated for both RDF and JSON-LD by using the same +mechanism. With respect to JSON-LD-based processors, this is achieved in a +lightweight manner, without having to use RDF processing libraries. + ++Issuers are advised that while conforming documents are expressed as compact JSON-LD, +not all Holders or Verifiers will understand expressions of intention that are only visible +after RDF processing has occured. +
+
+Some of the best features of JSON-LD are only possible by applying its language features to the
+terms defined in the @context.
+
+Implementers are advised that id and type have been
+aliased to @id and @type, and are marked @protected.
+Depending on the software libraries used, attempts to redefine these terms might raise processing errors.
+Implementers interested in understanding what @id means
+are advised to review Node Identifiers, and
+Specifying the Type.
+
+Implementers are advised that object member, and array element order are not preserved by default in JSON-LD, +therefore, issuers intending to communicate the orders of object +members and/or array elements might need to leverage language and/or other +advanced features of JSON-LD. +See Value Ordering. +
+
+Implementers are advised that while minimal processing of a document might
+make it appear that claims are related,
+the https://www.w3.org/ns/credentials/v2 `@context` leverages
+@container and @graph to separate information
+graphs; in particular, these are used to separate the graphs related to
+verifiable credentials, verifiable presentations, and
+embedded proofs.
+
+Issuers and holders might apply these same techniques to +unambiguously communicate their intention regarding structured claims in +verifiable credentials and verifiable presentations. +Verifiers that do not understand or process JSON-LD will not +be aware of these differences, and confusion between the intentions of the +issuer and the holder could lead to unexpected processing +behavior by verifiers.
-