Define a property for Content Warnings

[ThisIsMissEm]

Taken originally from: w3c/activitystreams#583

Currently mastodon (and inspired/compatible fediverse software) use the summary and summaryMap properties for content warnings, which isn't ideal since these are also used for actual summaries of Articles, Documents and other object types.

We need to define a new property or set of properties specifically for the purposes of doing content warnings, these are typically applied by the author of a post when they compose it.

Content Warnings can largely be just a duplication of what we have for summary/summaryMap (i.e., contentWarning/contentWarningMap).

This could be seen just as an effort to formalise an existing practice by defining an appropriate property for content warnings on objects.

There is already an ongoing effort to formalise the as:sensitive property.
The has been formalisation of the as:sensitive property in the SWICG Miscellany report

[snarfed]

Starting with a bang, real practical utility here. I like it!

[bumblefudge]

Here's the only chatter I could find about formalizing as:sensitive:

w3c/activitystreams#571 (comment)

https://socialhub.activitypub.rocks/t/property-under-tag/3488/20

where else should I be looking?

[bumblefudge]

I am exactly the opposite of an ontology queen, but my intuition is that sensitive should be a property that nests multiple possible subproperties, since few communities would have a category of the sensitive fully congruous/coextensive with any other's, and would probably want to focus filtering efforts on only some sensitives and not others. whatever shape the ontological thinking goes, i'm hugely supportive of migrating from summary to any form of sensitive that can be spec'd out and making summary summary again 💪

[ThisIsMissEm]

@bumblefudge https://swicg.github.io/miscellany/#sensitive

[AnSavvides]

I am exactly the opposite of an ontology queen, but my intuition is that sensitive should be a property that nests multiple possible subproperties

To @bumblefudge's point, it'd be great for us to discuss / explore if we could go a step further beyond mirroring summary/summaryMap, and instead introduce a canonical set of sub-properties, along with the ability to add custom ones for more flexibility. Maybe something along these lines?

contentWarning: { violence: boolean, nudity: boolean, ..., other: string }

That would mean that a piece of content could have multiple warnings, and a custom property for anything that doesn't fit whatever list of subproperties this is seeded with (which is probably a whole separate exercise in and of itself).

Though to @evanp's point in w3c/activitystreams#583 (comment):

One complication is how we shift from using summary for content warnings to using contentWarning or whatever property you think up is deprecating the use of summary for CWs. The problem is that if clients don't use it, there's some potential for bad experience for the user -- seeing something they don't want to see. We'll need to design that transition carefully; I don't have a clear picture of it right now.

I expect mirroring summary/summaryMap would mean an easier transition from one to the other, so probably a path to adoption and effort we'd require folks to support this should probably be a consideration.

[ThisIsMissEm]

@AnSavvides I think there's two or three things here:

• content labelling (i.e., violence, nudity, gore, politics, etc)
• content summary (user wants to collapse their post behind some text, often used for jokes or shitposting)
• content warning (a textual description that accompanies content labelling and sensitive marker explaining why)

Looks like I didn't create the issue to track content labelling yet

[jfinkhaeuser]

@AnSavvides I would shy away from a canonical set of labels, but rather look towards something like the vocabulary in #15.

The immediate issue with a canonical list is that there is huge cultural variance between what is considered sensitive or not.

It's IMHO best to allow for distinct and/or overlapping vocabularies in order to avoid being prescriptive.

Illustrative example from the world of movies: what's considered too nude in the US often gets a pass in Germany, but it's vice versa with regards to violence. If this kind of variance isn't allowed for, I worry that the system may be abused and/or simply not be adopted.

[AnSavvides]

The immediate issue with a canonical list is that there is huge cultural variance between what is considered sensitive or not.
It's IMHO best to allow for distinct and/or overlapping vocabularies in order to avoid being prescriptive.

Great points, and very much see what you are saying around cultural variance and not being prescriptive. I'll have a read through #15 and follow up there!

[tesaguri]

As for the problem of canonical labels, I think labels can be @ids rather than a fixed set of strings, so that spec-defined labels, community-provided shared labels and even ad-hoc content warnings can coexist, like so:

{
  "type": "Note",
  "ex:moderationLabel": [
    "ex:violentContent",
    "https://example.com/label/42",
    {
      "type": "Note",
      "name": "Spoiler of the latest episode"
    }
  ]
}

An unobvious point of this approach is that, while multiple "labels" for a single post make sense, you might not usually want multiple "content warnings", so maybe content warnings should be separated from labels to make it easy to restrict their cardinality. But there may be cases where you want an author-provided warning and a moderator-provided warning at the same time, so… I'm not sure if it's a good idea to restrict cardinality of content warnings either.

[jfinkhaeuser]

@tesaguri That's the essence of #15, though that issue distinguishes between defining and referencing a vocabulary. You could of course always include individual terms immediately as you describe. Maybe that's a good additional thought for that other issue, too.

[ThisIsMissEm]

This is a rather interesting article on Content Warnings and labeling of content: https://shelraphen.com/on-content-warnings/

[evanp]

as:sensitive is defined in the Miscellany report:

https://swicg.github.io/miscellany/#sensitive

[ThisIsMissEm]

@evanp thanks for the update, have added that in the issue description; that report was still being written when i wrote this issue, hence saying the work was in progress.