Discuss schema.org, activitypub, VC and DID JSON-LD overlap

[OR13]

At some point, we should have a special topic call, that connects what is going on in these industry ontologies with the work we are doing designing DID Core.

Particularly as it related to things like owl:sameAs or ap:alsoKnownAs...

• https://docs.microsoft.com/en-us/azure/digital-twins/concepts-models
• https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/dtdlv2.md
• https://www.w3.org/TR/activitypub/

Feels like given how much JSON-LD is in the VC Data Model and DID Core Spec, its worth exploring how DIDs and VCs might make their ways into existing JSON-LD ecosystems, like azure iot, schema.org, or other industry vocabularies...

Consider this a request for a special topic call, potentially with some invited guests from the relevant ecosystems.

cc @msporny @selfissued @talltree @peacekeeper @brentzundel @burnburn

[OR13]

proposal to discuss this on upcoming special topic call.

[rhiaro]

My take on this is that any external vocabulary terms that a DID method wants to use in the DID docs produced can be registered here (in the Registries) and then just used by including the external JSON-LD context as you would for any 'extension'. I think this applies to owl:sameAs as well. We don't need to worry about re-defining or re-stating any of these in the DID Core spec unless we need to define some constraints around a term that apply universally to all DID methods and aren't covered by the original definition.

The important thing is that they go into the Registries - even if they have existed in the LD ecosystem for a long time for example - so that they are not 'unknown' terms (to be ignored) and different DID methods don't start using them differently or something. We can also use this opportunity to note any security warnings etc about such terms.

(For the record, ap:alsoKnownAs isn't a thing.)

[kdenhartog]

I believe with the report back from @rhiaro that the Social Web CG has adopted the alsoKnownAs property in the ActivityStreams 2.0 namespace that we can now close this issue rather than moving to did-core. Is there anything else you'd like to address with this issue @OR13 ? If so, we can transfer it to did-core and keep it going there.

[OR13]

I suggest we close this issue.