Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sorting out @contexts #429

Closed
David-Chadwick opened this issue Feb 22, 2019 · 4 comments
Closed

Sorting out @contexts #429

David-Chadwick opened this issue Feb 22, 2019 · 4 comments
Assignees

Comments

@David-Chadwick
Copy link
Contributor

First I am not able to retrieve any of the context definitions. The URLs fail.
Secondly we should ensure that all the contexts, when published, match the examples in the specification. Here is one that appears not to.

In the Extensibility section, Example 13 says this new type of VC is "CustomExt12" but what or how is this type linked to the @context specification, since the @context definition does not contain this type. In other words, how does a verifier know, when reading this new type of credential, that it will contain referenceNumber and favouriteFood properties? Surely the @context should could the definition of "CustomExt12"

@BigBlueHat
Copy link
Member

The https://www.w3.org/2018/credentials/v1 URL will (at publication time at the very latest) resolve to the JSON-LD context defined by the final data model spec. You can read more here:
https://www.w3.org/TR/verifiable-claims-data-model/#contexts

The example.com URLs (which represent example extension) won't ever resolve to anything--by design. 😃 They are examples, and not meant to be used in anything but examples.

Consequently, Example 13 includes a reference to https://example.com/contexts/mycontext.jsonld as the example extension. Per the text just prior to that example, that extension context URL would resolve to Example 12 as it's context.

If someone were to replicate that example specifically, they would need to store the example 12 context file at a URL, and put the URL they stored that file at into the example 13 credential data document.

The end result would be an extended credential document containing the extensions referenced in the example 12 context file.

how does a verifier know, when reading this new type of credential, that it will contain referenceNumber and favouriteFood properties?

The verifier knows (or rather learns) the extension terms by dereferencing the extension URL. Once dereferenced, the verifier can read that referenceNumber and favouriteFood terms are defined in that example 12 context file.

Hope that clarifies it a bit!

@brentzundel
Copy link
Member

brentzundel commented Mar 5, 2019

Decision from F2F in Barcelona:
We should not use schema.org
we should not have an embedded context. This will make the examples too complicated.

  • @msporny will submit a PR that fixes the definition of '@context' in the data model to support objects.
  • @chaals will allocate and publish the JSON-LD context used for examples.

@jonnycrunch
Copy link
Contributor

This could be related to the MIME type discussion. see: #421 (comment)

@msporny
Copy link
Member

msporny commented Mar 15, 2019

The data model now supports objects when associated with the @context property (via 4dab134). Thanks to @jonnycrunch for catching that bug in the spec.

The examples JSON-LD Context will be published at:

https://www.w3.org/2018/credentials/examples/v1

and will contain the following content (which may change during CR based on implementer feedback):

https://github.com/w3c/vc-data-model/blob/gh-pages/contexts/credentials/examples/v1

This means that all examples in the spec will actually work when copy-paste dumped into a JSON-LD processor, such as the JSON-LD Playground.

This also means that @chaals now owes me a beer for finishing his action item. :P

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants