Should we use 'also known as' instead of 'otherIdentifiers'

[zachzeus]

Also known as come from the DID scheme.

[Fak3]

We can't use alsoKnownAs because it instructs to merge the graph nodes into one.

Current sample taken from DigitalProductPassport.md:

"issuer": {
   "type": "CredentialIssuer",
   "id": "did:web:identifiers.acme.com:12345",
   "name": "ACME industries",
   "otherIdentifiers": [{
      "type": "Entity",
      "id": "https://abr.business.gov.au/ABN/View?abn=90664869327",
      "name": "ACME Pty Ltd",
      "idValue": "90664869327",
      "idScheme": "abr.business.gov.au",
      "idSchemeName": "Australian Business Number"}
    ]},

if we were to use alsoKnownAs instead of otherIdentifiers, then all the idValue, idScheme, etc.. would merge on the node with id did:web:identifiers.acme.com:12345, losing their original plain json association:

{
"id": "did:web:identifiers.acme.com:12345",
"idScheme": ["abr.business.gov.au", "gln", "business.eu", "etc"]
}

[VladimirAlexiev]

• @Fak3 Completely agree: companies and their identifiers are totally different entities. Eg an identifier typically has issuance and expiration date that have nothing to do with company founding and dissolution date (think LEIs: LEI issuers like to make money on a subscription basis)
• So alsoKnownAs has the semantics of owl:sameAs?
• I guess alsoKnownAs is a URL: so another reason why we cannot do this is because not all identifier systems have an established URL representation.

[Fak3]

I was wrong - alsoKnownAs has different semantics from owl:sameAs. See note in the spec: https://www.w3.org/TR/did-core/#also-known-as. It does not necessarily tell to merge the nodes in the graph.

But the issue with describing identifiers separately from entities still exists, as described in the issue #137