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

Added alsoKnownAs to the context #133

Merged
merged 2 commits into from
Nov 9, 2020
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
5 changes: 5 additions & 0 deletions contexts/did-v1.jsonld
Original file line number Diff line number Diff line change
Expand Up @@ -17,6 +17,11 @@
"SchnorrSecp256k1VerificationKey2019": "sec:SchnorrSecp256k1VerificationKey2019",
"X25519KeyAgreementKey2019": "sec:X25519KeyAgreementKey2019",
"ServiceEndpointProxyService": "didv:ServiceEndpointProxyService",
"alsoKnownAs": {
"@id": "sec:alsoKnownAs",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"@id": "sec:alsoKnownAs",
"@id": "as:alsoKnownAs",

alsoKnownAs is being defined in ActivityStreams, right?

We will also want to either 1) define the as prefix -- which we probably shouldn't do, or 2) use full URLs everywhere -- which will bloat the document, but since it's cached, that shouldn't matter.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why shouldn't we define the as prefix? I had expected to do that, but ivan beat me to the PR.

Copy link
Contributor

@OR13 OR13 Sep 20, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rhiaro I think because defining prefixes is now considered some kind of anti pattern....

w3c-ccg/security-vocab#57

as is using URLs that don't exist to define vocabulary :)

I'd prefer to see the full stable URL added here.

something like https://www.w3.org/TR/activitystreams-core/#alsoKnownAs

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume it would be defined near here https://www.w3.org/TR/activitystreams-vocabulary/#dfn-id ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The URL would be https://www.w3.org/ns/activitystreams#alsoKnownAs

It would be an extension to ActivityStreams, rather than an addition to core (amending the REC is basically impossible without a WG responsible for it at the moment). Getting it added as an extension will need to go through the Social CG, which is something I'm trying to kick off but don't have an ETA yet.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume it would be defined near here https://www.w3.org/TR/activitystreams-vocabulary/#dfn-id ?

No, it's defined in the DID Core spec. That has just been merged into the ED. Then it would be (if all goes to plan) added to the AS2 JSON-LD context and namespace doc which links to the spec definition in DID Core.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@iherman @msporny will did core have a similar document?

https://www.w3.org/TR/activitystreams-core/
https://www.w3.org/ns/activitystreams#alsoKnownAs

https://www.w3.org/TR/did-core/
https://www.w3.org/ns/did/#alsoKnownAs

?

What is the difference between the document we would need for https://www.w3.org/ns/did/ and the did spec registries?.... seems like a lot of code / term duplication... between did core, did registries and some namespace document....

Copy link
Contributor

@OR13 OR13 Sep 20, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sidenote, I was curious about this, so I setup this site:

https://ns.did.ai/did/#publicKeyJwk

^ if you name a file index.json... it gets returned with content-type application/json for the URL of the directory its in.... which means....

https://ns.did.ai/did/v1 works as expected....

These examples use index.md instead of index.html, but normal html is obvious also supported.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As this term is not defined in the Activity Stream vocabulary at present it is not), and, @rhiaro said, it is defined in the DID Core specification with description and all, I do not see why this term would not be added to the did core vocabulary. I have absolutely no idea when and how the AS community will do any change on their own vocabulary, and we cannot be dependent on that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@OR13 wrote:

What is the difference between the document we would need for https://www.w3.org/ns/did/ and the did spec registries?

No difference... https://www.w3.org/ns/did should resolve to the DID Spec Registries document when text/html` is requested. We may want to sprinkle it with RDFa and/or provide an 'application/ld+json' representation of it as well. Again, not mandatory, but given the time, we would do that too.

OR13 marked this conversation as resolved.
Show resolved Hide resolved
"@type": "@id",
"@container": "@set"
},
"assertionMethod": {
"@id": "sec:assertionMethod",
"@type": "@id",
Expand Down