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

Should terms like ageOver be in the context? #245

Closed
cwebber opened this issue Oct 9, 2018 · 4 comments
Closed

Should terms like ageOver be in the context? #245

cwebber opened this issue Oct 9, 2018 · 4 comments
Assignees

Comments

@cwebber
Copy link
Contributor

cwebber commented Oct 9, 2018

(See also #231.)

We currently have examples using such terms as ageOver which are not currently in the context. We could argue either way whether they they should or should not be:

  • Maybe the credentials context should be minimal enough just include the base functionality. In that case, we should define another context for common terms, or at least include some example.org type imaginary context in such examples in the spec to make clear that these are not defined terms.
  • Alternately maybe we know everyone is going to use these a lot, so it's worth including some of the most common ones in the spec.

(While working on the test suite I converted the suite over to the latest context and discovered these terms were not in there, so currently I have "dumped them" back in, even though this does not reflect the current context, so I'll need to update that once we make a decision.)

@msporny
Copy link
Member

msporny commented Oct 9, 2018

Maybe the credentials context should be minimal enough just include the base functionality.

Yes, let's do this.

In that case, we should define another context for common terms, or at least include some example.org type imaginary context in such examples in the spec to make clear that these are not defined terms.

The WG should publish an "examples" context (https://www.w3.org/2018/vc-examples/v1), so all of the examples actually do work.

@msporny
Copy link
Member

msporny commented Oct 9, 2018

Alternately maybe we know everyone is going to use these a lot, so it's worth including some of the most common ones in the spec.

If we do this, we will get it wrong. The set of use cases is just too broad for us to do a good job with king making "common terms". I suggest we defer to schema.org for "common terms". /cc @danbri

@cwebber cwebber self-assigned this Oct 9, 2018
@David-Chadwick
Copy link
Contributor

Perhaps we should go even further, as @msporny asked me to do when creating examples with addresses in them, and that is to use schema.org terms in all our examples as far as possible, instead of inventing similar terms that dont quite mesh with schema.org ones. So instead of having an example containing the address property, with address in the examples context, instead we use the address, streetAddress, postalCode etc properties from schema.org and add that to the context.
See example 14 in the current DM doc as an example of this approach.

@dlongley dlongley added defer and removed defer labels Oct 22, 2018
@burnburn
Copy link
Contributor

burnburn commented Oct 26, 2018

From TPAC-2018:

  • Create an example JSON-LD context for the spec. Use example.{org,com} for this.
  • Document that the context should not be used for anything other than examples

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