#42 Use of ‘summary’ for object descriptions

Closed
opened 8 months ago by fr33domlover · 2 comments

The summary property can be used for providing summaries of objects, both activities and other things, as HTML text. I'm wondering how much to use/reuse/abuse this property. For example, if users of my software write one-line plain-text descriptions for some objects, I can publish those using summary, putting the text inside a <p> tag or something. But is that a good idea?

Pros:

  • Use an existing ActivityPub property

Cons:

  • It's HTML, so all the guarantees and assumptions about the content are lost (e.g. if I want to embed it in a web page, I can't assume it's a one-line text etc., it's basically an arbitrary chunk of HTML from another server
  • "summary" and "description" aren't the same thing, so the name can be a bit misleading. You can describe a banana but you probably wouldn't "summarize" a banana.

I'm leaning towards not using summary for anything but the general case where some arbitrary-HTML summary of something is provided. For everything else, including all cases where the description of something is known to be plain text, or needs to be a single-line text, or any requirement that is more specific than just-arbitrary-HTML-fallback-because-idk-how-to-display-this-object, use other properties.

How does this sound? I want to pick properties for stuff in ForgeFed, and replace all my uses of summary (e.g. for descriptions of repositories) with other properties (whether standard AP or external/extension). If that doesn't sound right to someone, please explain :)

SocialHub forum thread

The `summary` property can be used for providing summaries of objects, both activities and other things, as HTML text. I'm wondering how much to use/reuse/abuse this property. For example, if users of my software write one-line plain-text descriptions for some objects, I can publish those using `summary`, putting the text inside a `<p>` tag or something. But is that a good idea? Pros: - Use an existing ActivityPub property Cons: - It's HTML, so all the guarantees and assumptions about the content are lost (e.g. if I want to embed it in a web page, I can't assume it's a one-line text etc., it's basically an arbitrary chunk of HTML from another server - "summary" and "description" aren't the same thing, so the name can be a bit misleading. You can describe a banana but you probably wouldn't "summarize" a banana. I'm leaning towards not using `summary` for anything but the general case where some arbitrary-HTML summary of something is provided. For everything else, including all cases where the description of something is known to be plain text, or needs to be a single-line text, or any requirement that is more specific than just-arbitrary-HTML-fallback-because-idk-how-to-display-this-object, use other properties. How does this sound? I want to pick properties for stuff in ForgeFed, and replace all my uses of `summary` (e.g. for descriptions of repositories) with other properties (whether standard AP or external/extension). If that doesn't sound right to someone, please explain :) [SocialHub forum thread](https://socialhub.activitypub.rocks/t/use-of-summary-for-object-descriptions/285)
zPlus commented 8 months ago
Owner

Activitystream vocabulary defines the property as "A natural language summarization of the object encoded as HTML". This was discussed on #peers, and I personally agree with the conclusion that is better not to use it. An activity should be self-describing by looking at its properties (actor, object, type, ...). I've already removed it completely from my code.

Activitystream vocabulary [defines the property](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-summary) as "A natural language summarization of the object encoded as HTML". This was discussed on #peers, and I personally agree with the conclusion that is better **not** to use it. An activity should be self-describing by looking at its properties (actor, object, type, ...). I've already removed it completely from my code.
fr33domlover commented 5 months ago
Collaborator

DECISION: Prefer not to use summary. Always discuss and reach consensus before using it for anything in the spec.

DECISION: Prefer not to use `summary`. Always discuss and reach consensus before using it for anything in the spec.
Sign in to join this conversation.
Loading...
Cancel
Save
There is no content yet.