search

opencreds / website

COMMUNITY: The W3C Credentials Community Group website.
https://opencreds.org/
Creative Commons Zero v1.0 Universal
8 stars 10 forks source link

Feedback on data model doc. #65

Closed gkellogg closed 8 years ago

gkellogg commented 8 years ago
burnburn commented 8 years ago

Regarding type, I had in fact originally written it as a set rather than a sequence, but then I noticed in all the examples (which is all I had to go by) it is rendered as an array (which is ordered), with "Identity" or "Credential" first. I'm happy to make it a generic set, but if we do it should probably be rendered as an object with properties rather than as an array. Would this be a good item for list discussion?

Regarding signature, @msporny told me that there is no one required mechanism for signatures and that I should leave it open, which I did. The examples show the use of LinkedDataSignature, but neither the data model nor the normative wording on converting into syntactic representations requires the use of a LinkedDataSignature.

gkellogg commented 8 years ago

I'd rather just narratively describe type as an unordered collection. In JSON-LD, an array does not necessarily imply ordering. If describing an abstract collection, then serialization-specific conventions such as array ordering should probably not be assumed. I wouldn't like to see it be an object.

Fair enough on choice of signature, but it does, of course, beg the issues of interoperability. We probably want to be more abstract in the use of "signature", so these issues are not presupposed. Ultimately, if a spec chooses a form of LDSigs, or something else, then creating a normalized form for signing will n Ed to be considered. Perhaps a note to point this out is in order.

halindrome commented 8 years ago

+1 on describing as an unordered collection.

+0 on a note.

On Wed, May 11, 2016 at 9:51 AM, Gregg Kellogg notifications@github.com wrote:

I'd rather just narratively describe type as an unordered collection. In JSON-LD, an array does not necessarily imply ordering. If describing an abstract collection, then serialization-specific conventions such as array ordering should probably not be assumed. I wouldn't like to see it be an object.

Fair enough on choice of signature, but it does, of course, beg the issues of interoperability. We probably want to be more abstract in the use of "signature", so these issues are not presupposed. Ultimately, if a spec chooses a form of LDSigs, or something else, then creating a normalized form for signing will n Ed to be considered. Perhaps a note to point this out is in order.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/opencreds/website/issues/65#issuecomment-218483594

Shane McCarron halindrome@gmail.com

msporny commented 8 years ago

Consider "set of" instead of "sequence of".

It should be "set of"

If a signature is based on an LinkdedDataSignature algorithm, doesn't this mean that every representation must be reducible to RDF?

No, it needn't been reducible to RDF (heresy, I know!). The Linked Data Signatures spec allows the normalization, message digest, and signing algorithms to be varied. That basically means that you can sign JSON data using Linked Data Signatures if you have a mechanism to normalize that JSON data. One approach is to use JSON-LD to go to RDF and then normalize (this is what the LinkedDataSignature2015 signature suite does). Another approach is to create some JSON normalization algorithm (without going to RDF) and sign the digest of that algorithm. To be clear, you /could/ sign JSON-LD data like this as well. We have this feature in there for the people that hate RDF and Linked Data. There is still a mechanism for them to use Linked Data Signatures without them committing to RDF. All that's missing is a JSON normalization algorithm. :)

burnburn commented 8 years ago

On Wed, May 11, 2016 at 8:53 PM, Manu Sporny notifications@github.com wrote:

Consider "set of" instead of "sequence of".

It should be "set of"

I'm happy to change the data model to be 'set of'. As a consequence I will be changing the syntax representations away from arrays as well since we are defining expected syntactic mappings in addition to defining the syntax-independent data model.

If a signature is based on an LinkdedDataSignature algorithm, doesn't this mean that every representation must be reducible to RDF?

No, it needn't been reducible to RDF (heresy, I know!). The Linked Data Signatures spec allows the normalization, message digest, and signing algorithms to be varied. That basically means that you can sign JSON data using Linked Data Signatures if you have a mechanism to normalize that JSON data. One approach is to use JSON-LD to go to RDF and then normalize (this is what the LinkedDataSignature2015 signature suite does). Another approach is to create some JSON normalization algorithm (without going to RDF) and sign the digest of that algorithm. To be clear, you /could/ sign JSON-LD data like this as well. We have this feature in there for the people that hate RDF and Linked Data. There is still a mechanism for them to use Linked Data Signatures without them committing to RDF. All that's missing is a JSON normalization algorithm. :)

— You are receiving this because you were assigned. Reply to this email directly or view it on GitHub https://github.com/opencreds/website/issues/65#issuecomment-218631825

burnburn commented 8 years ago

@gkellogg there is no problem adjusting the data model text to refer to a set. The issue comes when we provide guidance on how to represent the data model in different syntactic structures. For JSON at least the obvious conversion from a generic set is an object literal. I don't think we can have it both ways. Either we say it is unordered and recommend that for JSON (and JSON-LD, likely) it is represented as an object or we say it is ordered and recommend that it be represented in JSON(-LD) as an array.

burnburn commented 8 years ago

Hmm, unless we just state in the mapping rules that a (unordered) set may be represented as either an object or an array. Maybe I'll just do that for now and let someone else complain that it is vague :)

msporny commented 8 years ago

@burnburn wrote:

state in the mapping rules that a (unordered) set may be represented as either an object or an array.

JSON-LD treats all JSON arrays as unordered sets (unless specified otherwise in the JSON-LD context).

-1 to representing it as either an object or an array. We could just say - unordered set, which in JSON is represented as an array.

burnburn commented 8 years ago

On Mon, May 16, 2016 at 1:03 PM, Manu Sporny notifications@github.com wrote:

@burnburn https://github.com/burnburn wrote:

state in the mapping rules that a (unordered) set may be represented as either an object or an array.

JSON-LD treats all JSON arrays as unordered sets (unless specified otherwise in the JSON-LD context).

-1 to representing it as either an object or an array. We could just say - unordered set, which in JSON is represented as an array.

That doesn't work generically, since the claim property has, as its value, an unordered set which is rendered in JSON as an object.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/opencreds/website/issues/65#issuecomment-219482107

burnburn commented 8 years ago

On Mon, May 16, 2016 at 1:45 PM, Daniel Burnett danielcburnett@gmail.com wrote:

On Mon, May 16, 2016 at 1:03 PM, Manu Sporny notifications@github.com wrote:

@burnburn https://github.com/burnburn wrote:

state in the mapping rules that a (unordered) set may be represented as either an object or an array.

JSON-LD treats all JSON arrays as unordered sets (unless specified otherwise in the JSON-LD context).

-1 to representing it as either an object or an array. We could just say

  • unordered set, which in JSON is represented as an array.

That doesn't work generically, since the claim property has, as its value, an unordered set which is rendered in JSON as an object.

Actually, I take that back. This can work if I distinguish between "an unordered set of values" and "an unordered set of name-value pairs". The former becomes an array, while the latter becomes an object.

—

You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/opencreds/website/issues/65#issuecomment-219482107

msporny commented 8 years ago

This can work if I distinguish between "an unordered set of values" and "an unordered set of name-value pairs".

Exactly, that's what I was trying to get at. The type field (where this discussion started) is an unordered set of URIs (values), not an unordered set of name-value pairs.

burnburn commented 8 years ago

Updated in commit e285e15edca97332dbbe2f9c38f4cffbd3588979. @gkellogg can you verify you're okay with the changes? If so, I'll close this issue.

gkellogg commented 8 years ago

Other than word-smithing, I'm :+1: on this. Not all forms will support compact, or potentially absolute URIs, but it should be clear that "Identity" represents the URI associates with that concept.

burnburn commented 8 years ago

Yeah, I probably would have said "string", but Manu very specifically called the values in the type field URIs. Feel free to suggest improved wording there.

-- dan

On Tue, May 17, 2016 at 11:51 AM, Gregg Kellogg notifications@github.com wrote:

Other than word-smithing, I'm [image: :+1:] on this. Not all forms will support compact, or potentially absolute URIs, but it should be clear that "Identity" represents the URI associates with that concept.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/opencreds/website/issues/65#issuecomment-219762511

burnburn commented 8 years ago

Sorry, I see you made some concrete suggestions on the commit itself (I was reading from email and not github). Thanks!

On Tue, May 17, 2016 at 12:07 PM, Daniel Burnett danielcburnett@gmail.com wrote:

Yeah, I probably would have said "string", but Manu very specifically called the values in the type field URIs. Feel free to suggest improved wording there.

-- dan

On Tue, May 17, 2016 at 11:51 AM, Gregg Kellogg notifications@github.com wrote:

Other than word-smithing, I'm [image: :+1:] on this. Not all forms will support compact, or potentially absolute URIs, but it should be clear that "Identity" represents the URI associates with that concept.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/opencreds/website/issues/65#issuecomment-219762511