Just some questions from my - still limited, so pls bear with me - understanding of the subject matter. From the SocialCG meeting minutes:
RESOLUTION: we accept the
alsoKnownAs definition in the DID Core spec ("This relationship is a statement that the subject of this identifier is also identified by one or more other identifiers. ") as a starting point that can be iterated on with the participation of both the DID and SocialCG communities.
This with the following understanding:
- AS definition is the most generic, and DID a specialization (e.g. added restriction to be a set)
@rhiaro: “Yes, exactly – identifier and subject are meant to be general…
… The subject could be an Activity Pub profile URl – supposed to be general/generic language… relationship is alsoKnownAs – ANY identifiers, HTTP URLs, DIDs, etc.”
@nightpool, @kaniini: The Domain and Range of
alsoKnownAs is Actor, i.e. an URI to an actor profile ID.
Aren’t the two sub-bullets in conflict with each other? Wouldn’t it imply a
did:alsoKnownAs to refer to an actor, if there’s compatibility?
Currently in AS Vocab the DID specialization is referred to. So with the above Resolution this is temporary - so as not to block @msporny with DID spec progress - and the intention is to iterate on a generalization of this? That would mean that eventually we’d have an
as:alsoKnownAs, am I right? Probably defined in a FEP.
Will this interpretation give problems in having a universal understanding of the semantics of
as:alsoKnownAs? Btw, in the context of a Move it is not necessarily the same Person that controls both (e.g. the move is from a personal account to one representing an organization actor).
Wouldn’t it be great to have some consensus on how all this works? This concept of Moving applies to ALL activitypub application types, and - if not well-defined - the situation on Fediverse will become messier and messier. Here @macgirvin with nomadic identity and
copiedTo may have great input.
Shouldn’t we consider this? Maybe the Domain and Range of
as:alsoKnownAs should be Object? Consider e.g. an Event that has a Mobilizon url, a Gathio url, and an Organization website page (with SEO in it).
I see that in the Lemmy code the JSON-LD context is defined as:
I need to read up on the JSON-LD spec, so can’t say if this is correct. But I wonder about the mechanism in general. Matrix is just one of the many, many web locations that can represent an
alsoKnownAs relationship. (For instance Keyoxide is an app to represent a code-generated verified profile with an ever-growing list of such relationships).
Shouldn’t there be a machine-readable way to figure out the type of link, without having to define unique property names for each of them? I don’t know what’s the best way, or if it is even desired. In schema.org (see data model notes) you have
identifier where the latter can be a PropertyValue with a
"name": "Library linked data in the cloud : OCLC's experiments with new models of resource description",
"author": "Carol Jean Godby",
PS. Note that AFAIK there’s no
as:stickied (In Mastodon there’s featured,
toot:featuredTag). Nor are there