This is a discussion thread for the proposed FEP-fb2a: Actor Metadata. Please use this thread to discuss the proposed FEP and any potential problems or improvements that can be addressed.
Summary
It is useful for actors to publish additional structured information about themselves without necessarily defining an extension property or additional vocabulary. This FEP describes a way for actors to publish generic key-value pairs representing their metadata.
General-purpose actor metadata fields SHOULD be included in the attachment array on the actor. If a more specific property exists and is a better fit for the specific metadata being expressed, then implementations MAY use that instead of or in addition to the more generic actor metadata.
@trwnh If a more specific property doesn’t exist in ActivityStreams vocabulary, what would you recommend? Is it preferable to use an attachment with a more specific type or to define a new property?
It seems to me that grouping similar things under the same property makes more sense.
The intention is to support generic name-value pairs, but without using unnecessary external vocabularies.
By “specific properties”, I meant vocabulary with a better-fitting semantic meaning. If you wanted to define or use an existing property definition for “age” or “pronouns”, you could do that… perhaps your implementation supports something like schema.org and actually makes use of its properties (instead of just PropertyValue and value). But if you didn’t want to do this (or if you otherwise wanted to keep things simple), you could just use generic metadata as defined here.
It is possible there might be some duplication if you want to support some extension or other vocab, and also have that information visible to ActivityPub-only implementations. Say you wanted to share your email to anyone viewing your profile. You might put that information in schema:email, but you might also put that info in a generic profile field as actor metadata (attached Note with name = email, content = your email address), and/or you might put it directly into your bio (using as:summary). Any or all three are valid.
Largely just a more generic way to do “bio fields” / “profile fields” / etc as seen on Mastodon, Pleroma, and Misskey
The problem with those is that they depend on a broken definition for the schema.org context – Mastodon’s context currently/historically defines a term schema which maps to the base IRI http://schema.org#, but it should map to http://schema.org/ or https://schema.org/ instead. When you expand this with JSON-LD, you get http://schema.org#PropertyValue instead of http://schema.org/PropertyValue, which breaks parsing.
Therefore, the goal of the FEP is to propose a simpler alternative: Just use Note/name/content instead of PropertyValue/name/value. Why it wasn’t done like this in the first place years ago is beyond me.