{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/vc-data-model/issues/174","repository_url":"https://api.github.com/repos/w3c/vc-data-model","labels_url":"https://api.github.com/repos/w3c/vc-data-model/issues/174/labels{/name}","comments_url":"https://api.github.com/repos/w3c/vc-data-model/issues/174/comments","events_url":"https://api.github.com/repos/w3c/vc-data-model/issues/174/events","html_url":"https://github.com/w3c/vc-data-model/issues/174","id":322087466,"number":174,"title":"Various questions related to the use of the \"type\" property","user":{"login":"vieillevigne","id":39172562,"avatar_url":"https://avatars1.githubusercontent.com/u/39172562?v=4","gravatar_id":"","url":"https://api.github.com/users/vieillevigne","html_url":"https://github.com/vieillevigne","followers_url":"https://api.github.com/users/vieillevigne/followers","following_url":"https://api.github.com/users/vieillevigne/following{/other_user}","gists_url":"https://api.github.com/users/vieillevigne/gists{/gist_id}","starred_url":"https://api.github.com/users/vieillevigne/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/vieillevigne/subscriptions","organizations_url":"https://api.github.com/users/vieillevigne/orgs","repos_url":"https://api.github.com/users/vieillevigne/repos","events_url":"https://api.github.com/users/vieillevigne/events{/privacy}","received_events_url":"https://api.github.com/users/vieillevigne/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":{"login":"msporny","id":108611,"avatar_url":"https://avatars3.githubusercontent.com/u/108611?v=4","gravatar_id":"","url":"https://api.github.com/users/msporny","html_url":"https://github.com/msporny","followers_url":"https://api.github.com/users/msporny/followers","following_url":"https://api.github.com/users/msporny/following{/other_user}","gists_url":"https://api.github.com/users/msporny/gists{/gist_id}","starred_url":"https://api.github.com/users/msporny/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/msporny/subscriptions","organizations_url":"https://api.github.com/users/msporny/orgs","repos_url":"https://api.github.com/users/msporny/repos","events_url":"https://api.github.com/users/msporny/events{/privacy}","received_events_url":"https://api.github.com/users/msporny/received_events","type":"User","site_admin":false},"assignees":[{"login":"msporny","id":108611,"avatar_url":"https://avatars3.githubusercontent.com/u/108611?v=4","gravatar_id":"","url":"https://api.github.com/users/msporny","html_url":"https://github.com/msporny","followers_url":"https://api.github.com/users/msporny/followers","following_url":"https://api.github.com/users/msporny/following{/other_user}","gists_url":"https://api.github.com/users/msporny/gists{/gist_id}","starred_url":"https://api.github.com/users/msporny/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/msporny/subscriptions","organizations_url":"https://api.github.com/users/msporny/orgs","repos_url":"https://api.github.com/users/msporny/repos","events_url":"https://api.github.com/users/msporny/events{/privacy}","received_events_url":"https://api.github.com/users/msporny/received_events","type":"User","site_admin":false}],"milestone":null,"comments":9,"created_at":"2018-05-10T21:14:32Z","updated_at":"2018-05-19T19:51:36Z","closed_at":null,"author_association":"NONE","body":"I am trying to figure out the normative use of the property, “type”. From the draft of May 8 I observe the following:\r\n \r\n- Every object at the top level (except for @context and verifiable profiles) has a “type” property\r\n- Every subobject, except for subobjects which are the values of “claim” properties, have “type”properties.\r\n- Apart from its occurrence in sections 7.2, 8.1 and 8.2 ‘type’ only appears in examples. The sections just mentioned also contain the only apparently normative occurrences of ‘type’.\r\n- The identifier “Credential” appears on the right-hand side of a “type” property only in ‘[..]’.\r\n- With two exceptions “Credential” always appears with another identifier containing ‘Credential’.\r\n- The only occurrences of a multiplicity of types embraced by ‘[..]’ (presumably denoting lists not sets) lead with “Credential”.\r\n- The type to the right of “Credential” always seems to be a specialization (subtype ?) of “Credential”.\r\n- “Credential”, “DocumentVerfification” and “VerfiableProfile” occur in singleton lists.\r\n\r\nMy questions follow:\r\n \r\n1. Except for the fact that the object values associated with “claim” properties do not themselves have “type”  properties, I’d really like to be able to say that “every object and subobject MUST have a “type”  property”. Why don’t, for example, the apparent claim objects have “type” properties?\r\n2. I’d like to be able to say that lists of types denote increasing specialization of type. Why then are there singleton occurrences of types in lists – especially when there are lots of singleton occurrences of types not in lists? What use can I make of a type specifically called out in a specialization hierarchy (if that is what a list intends)? In the case of types not used in lists, how do I know that they are not parts of specialization hierarchies elsewhere? Indeed, how do I know that “Credential” does not appear in a specialization hierarchy? Under what circumstance does one use a list for a singleton?\r\n3. I am particularly puzzled by the assertion at section 5.2 that “A credential MAY be made verifiable by adding the following property …”. This suggests that a credential may be made verifiable in some other way than providing a proof. It also suggests that a credential need not be verifiable at all. Moreover, the example which immediately follows does have a “proof” property and also has a “ProofOfAgeCredential” type. Why is the latter needed in the presence of the former? What are sufficient conditions to be a verifiable credential? What are necessary conditions to be a verifiable credential? Is it intended that there be credentials which are not verifiable?\r\n4. While section 7.2 apparently does say that an object of the “Credential” type MUST have “type” and “claim” properties, it (surprisingly) does not appear to say such a thing for “issuer” and “issued”. The meaning of a type is ordinarily understood to derive from its relationships with other types. On that account, it seems unlikely to me that something intended to be a “Credential” does not always have “issuer” and “issued” values. So what properties MUST an object of type “Credential” have?\r\n5. A verifiable profile object appears to have no requirement at all on its properties. While EXAMPLE 18, EXAMPLE 22 – apparently verifiable profile objects -- have no  “type”  property, EXAMPLE 5 does. (BTW, the ‘Section’ reference in section 8.2.2 is invisible and it actually points to the top level of the document. Ditto the ‘Section’ reference in 8.2.1.) Is the absence of a “type” an error?\r\n6. “type” appears to be a reserved word in JSON schema. I can imagine some of the parties interested in verifiable claims might also be interested in making use of JSON schema to (partially) specify claims. While the magic of namespaces can allow one to deconflict, might not another keyword be better?"},"comment":{"url":"https://api.github.com/repos/w3c/vc-data-model/issues/comments/390428454","html_url":"https://github.com/w3c/vc-data-model/issues/174#issuecomment-390428454","issue_url":"https://api.github.com/repos/w3c/vc-data-model/issues/174","id":390428454,"user":{"login":"msporny","id":108611,"avatar_url":"https://avatars3.githubusercontent.com/u/108611?v=4","gravatar_id":"","url":"https://api.github.com/users/msporny","html_url":"https://github.com/msporny","followers_url":"https://api.github.com/users/msporny/followers","following_url":"https://api.github.com/users/msporny/following{/other_user}","gists_url":"https://api.github.com/users/msporny/gists{/gist_id}","starred_url":"https://api.github.com/users/msporny/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/msporny/subscriptions","organizations_url":"https://api.github.com/users/msporny/orgs","repos_url":"https://api.github.com/users/msporny/repos","events_url":"https://api.github.com/users/msporny/events{/privacy}","received_events_url":"https://api.github.com/users/msporny/received_events","type":"User","site_admin":false},"created_at":"2018-05-19T19:51:36Z","updated_at":"2018-05-19T19:51:36Z","author_association":"MEMBER","body":"> “type” appears to be a reserved word in JSON schema. I can imagine some of the parties interested in verifiable claims might also be interested in making use of JSON schema to (partially) specify claims. While the magic of namespaces can allow one to deconflict, might not another keyword be better?\r\n\r\nWe've been using JSON Schema and Verifiable Credentials together for 7+ years now and have not had an issue. The reason for this is because JSON Schema is often run on JSON-LD objects as they're coming into the system and the two processes operate independently of one another. That is, JSON Schema knows nothing of JSON-LD... and JSON-LD knows how to contort itself such that JSON Schema has no idea that it's looking at JSON-LD. This was by design, and the design seems to be working fairly cleanly 7+ years from when we made those sets of decisions."}}
{"actor":{"display_login":"msporny"}}