Added `alsoKnownAs` to the context #133

iherman · 2020-09-19T09:37:29Z

Note that, although I used the sec: vocabulary, the property itself is not present in that vocabulary document. This must be done separately.

msporny

Minor nit, otherwise good to go.

msporny · 2020-09-20T15:59:02Z

contexts/did-v1.jsonld

@@ -17,6 +17,11 @@
    "SchnorrSecp256k1VerificationKey2019": "sec:SchnorrSecp256k1VerificationKey2019",
    "X25519KeyAgreementKey2019": "sec:X25519KeyAgreementKey2019",
    "ServiceEndpointProxyService": "didv:ServiceEndpointProxyService",
+    "alsoKnownAs": {
+      "@id": "sec:alsoKnownAs",


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.

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

@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

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

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.

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.

@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....

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.

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.

@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

@msporny your suggestion raises concerns for me, I would prefer to know the exact URL / have some confidence before we merge.

@rhiaro what is the ETA on getting a stable URL for this term?

OR13 · 2020-09-20T16:13:49Z

I had attempted to define it here #132

But I have since removed the JSON-LD side of it, pending a URL that is useable.

iherman · 2020-09-21T09:08:57Z

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

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

This is the issue I raised w3c/did-core#404. My answer is that yes, it must/should.

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....

In my view, the basic difference is that the registries document is to ensure the extension mechanism for the community. It is not a normative document, only the DID-Core is. In other words, although it can mention the terms of DID Core, it cannot replace a normative specification that is part of the DID Core spec.

OR13 · 2020-09-21T14:20:22Z

I've happy to help setup https://www.w3.org/ns/did/... thats the reason I was initially interested in working on the registries.

iherman · 2020-09-21T15:11:05Z

I've happy to help setup https://www.w3.org/ns/did/... thats the reason I was initially interested in working on the registries.

@OR13 thanks. By now the set up of vocabularies on /ns follows a routine pattern, using .var files for redirection. What is really work is to have a final vocabulary we can all agree on and which can serve as a basis for a specification and a vocabulary file. See w3c/did-core#404 (comment) for what I just worked on today (also the relevant vocabulary draft on the wiki).

rhiaro · 2020-09-21T15:29:02Z

My understanding was that https://www.w3.org/ns/did should resolve to the DID Spec Registries HTML doc when text/html is requested (eg. by a browser). Otherwise it should respond with the JSON-LD context when JSON is requested. So no duplication of work for the human-readable vocab listing is required.

OR13 · 2020-09-21T15:31:59Z

My understanding was that https://www.w3.org/ns/did should resolve to the DID Spec Registries HTML doc when text/html is requested (eg. by a browser). Otherwise it should respond with the JSON-LD context when JSON is requested. So no duplication of work for the human-readable vocab listing is required.

does this mean that every term defined in did core must also be defined in the did spec registries? or the ns will have gaps?

rhiaro · 2020-09-21T15:37:10Z

does this mean that every term defined in did core must also be defined in the did spec registries? or the ns will have gaps?

Yes. Everything, no gaps. A lifetime ago I was trying to argue that only extensions need to go in the Registries, and the agreement was reached that everything needs to go in the Registries, including everything defined in DID Core.

Note - nothing is "defined" in the Registries, but listed and their definitions elsewhere (including DID Core) are linked to.

OR13 · 2020-09-21T15:39:59Z

does this mean that every term defined in did core must also be defined in the did spec registries? or the ns will have gaps?

Yes. Everything, no gaps. A lifetime ago I was trying to argue that only extensions need to go in the Registries, and the agreement was reached that everything needs to go in the Registries, including everything defined in DID Core.

Note - nothing is "defined" in the Registries, but listed and their definitions elsewhere (including DID Core) are linked to.

does this include @context ? there is a PR open that removes @context from the registries and is being promoted by @talltree @peacekeeper .

... thinking though this, to make sure we all get on the same page...

https://www.w3.org/ns/did/#alsoKnownAs -> did spec registries with link to -> did core
https://www.w3.org/ns/did/v1 -> did spec registries jsonld

msporny · 2020-09-22T14:26:03Z

@OR13 wrote:

https://www.w3.org/ns/did/#alsoKnownAs -> did spec registries with link to -> did core
https://www.w3.org/ns/did/v1 -> did spec registries jsonld

Nope and nope... corrections:

https://www.w3.org/ns/did#alsoKnownAs -> conneg text/html -> did spec registries with link to -> did core (note: no / before #)
https://www.w3.org/ns/did -> conneg text/html -> DID Spec Registries HTML file (Vocabulary)
https://www.w3.org/ns/did -> conneg application/ld+json OR application/json -> JSON-LD representation of DID Spec Registries as a Vocabulary
https://www.w3.org/ns/did/v1 -> conneg application/ld+json OR application/json -> JSON-LD Context file for DID Core + Spec Registries v1.0

There are other variations we could discuss, the absolute minimum is:

https://www.w3.org/ns/did#alsoKnownAs -> conneg text/html -> did spec registries with link to -> did core (note: no / before #)
https://www.w3.org/ns/did/v1 -> conneg application/ld+json OR application/json -> JSON-LD Context file for DID Core + Spec Registries v1.0

iherman · 2020-09-22T15:28:07Z

https://www.w3.org/ns/did#alsoKnownAs -> conneg text/html -> did spec registries with link to -> did core (note: no / before #)

https://www.w3.org/ns/did -> conneg text/html -> DID Spec Registries HTML file (Vocabulary)

Did Core or DID spec registries? The document should go to the same document, and the fragment ID should point into that document.

Also: we now have .../ns/did/v1 for the context file, using .../ns/did or ../ns/did/for the vocabulary file may be more difficult to set up. I would rather use something like.../ns/did/coreor, if we want to version it,.../ns/did/core/v1`.

https://www.w3.org/ns/did -> conneg application/ld+json OR application/json -> JSON-LD representation of DID Spec Registries as a Vocabulary

https://www.w3.org/ns/did/v1 -> conneg application/ld+json OR application/json -> JSON-LD Context file for DID Core + Spec Registries v1.0

Talking about vocabularies I would also add a turtle version, with conneg text/turtle

We are running ahead of ourselves. We do not have the vocabulary file agreed upon, and that is really the important part. Setting up .../ns/ is, comparatively, trivial.

OR13

I will accept this PR when the URL exists :)

rhiaro · 2020-11-09T11:28:28Z

I will accept this PR when the URL exists :)

The URL exists! https://www.w3.org/ns/activitystreams#alsoKnownAs And the term is in the AS2 JSON-LD context. A successful collaborative effort between the DID WG and the Social Incubator Community Group 👏

rhiaro

My suggested change is to use the full URL for the term in the ActivityStreams 2.0 namespace

contexts/did-v1.jsonld

Co-authored-by: Amy Guy <amy@rhiaro.co.uk>

Added alsoKnownAs to the context

c2a8ef0

iherman requested review from msporny and OR13 as code owners September 19, 2020 09:37

OR13 approved these changes Sep 20, 2020

View reviewed changes

msporny approved these changes Sep 20, 2020

View reviewed changes

OR13 self-requested a review September 20, 2020 16:10

OR13 requested changes Sep 20, 2020

View reviewed changes

OR13 self-requested a review October 1, 2020 21:15

OR13 requested changes Oct 1, 2020

View reviewed changes

rhiaro requested changes Nov 9, 2020

View reviewed changes

contexts/did-v1.jsonld Outdated Show resolved Hide resolved

Update contexts/did-v1.jsonld

3d76738

Co-authored-by: Amy Guy <amy@rhiaro.co.uk>

OR13 self-requested a review November 9, 2020 14:07

OR13 approved these changes Nov 9, 2020

View reviewed changes

OR13 requested a review from rhiaro November 9, 2020 14:08

OR13 merged commit 3db3c42 into master Nov 9, 2020

msporny deleted the adding-alsoknownas branch November 14, 2021 21:31

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Added `alsoKnownAs` to the context #133

Added `alsoKnownAs` to the context #133

iherman commented Sep 19, 2020

msporny left a comment

msporny Sep 20, 2020

rhiaro Sep 20, 2020

OR13 Sep 20, 2020 •

edited

OR13 Sep 20, 2020

rhiaro Sep 20, 2020

rhiaro Sep 20, 2020

OR13 Sep 20, 2020

OR13 Sep 20, 2020 •

edited

iherman Sep 21, 2020

msporny Sep 22, 2020

OR13 left a comment

OR13 commented Sep 20, 2020

iherman commented Sep 21, 2020

OR13 commented Sep 21, 2020

iherman commented Sep 21, 2020

rhiaro commented Sep 21, 2020

OR13 commented Sep 21, 2020

rhiaro commented Sep 21, 2020 •

edited

OR13 commented Sep 21, 2020 •

edited

msporny commented Sep 22, 2020 •

edited

iherman commented Sep 22, 2020

OR13 left a comment

rhiaro commented Nov 9, 2020

rhiaro left a comment

Added alsoKnownAs to the context #133

Added alsoKnownAs to the context #133

Conversation

iherman commented Sep 19, 2020

msporny left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

OR13 Sep 20, 2020 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

OR13 Sep 20, 2020 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

OR13 left a comment

Choose a reason for hiding this comment

OR13 commented Sep 20, 2020

iherman commented Sep 21, 2020

OR13 commented Sep 21, 2020

iherman commented Sep 21, 2020

rhiaro commented Sep 21, 2020

OR13 commented Sep 21, 2020

rhiaro commented Sep 21, 2020 • edited

OR13 commented Sep 21, 2020 • edited

msporny commented Sep 22, 2020 • edited

iherman commented Sep 22, 2020

OR13 left a comment

Choose a reason for hiding this comment

rhiaro commented Nov 9, 2020

rhiaro left a comment

Choose a reason for hiding this comment

Added `alsoKnownAs` to the context #133

Added `alsoKnownAs` to the context #133

OR13 Sep 20, 2020 •

edited

OR13 Sep 20, 2020 •

edited

rhiaro commented Sep 21, 2020 •

edited

OR13 commented Sep 21, 2020 •

edited

msporny commented Sep 22, 2020 •

edited