[AppStream] Adding Age Classification to AppData files

[Matthias Klumpp]

2016-03-08 9:32 GMT+01:00 Richard Hughes <hughsient at gmail.com>:
> Hi all,
>
> I wrote a bit about why I think age ratings are required inside
> software centers:
> https://blogs.gnome.org/hughsie/2016/03/07/age-ratings-in-gnome-software-introducing-oars/
>
> I don't think it makes sense to hide or restrict games based on an
> age, but as a parent it sure would find it useful to know if a game I
> install for my daughter has any unsuitable content. I've put together
> a proposal called OARS, and I've asked the Common Sense Media group to
> work with me on the classifications and the questions we ask
> developers on a web-form. In the meantime, I'd like to talk about what
> I think should go upstream, i.e. into the actual AppData file. I think
> it makes sense to do the mapping from "drugs-narcotics=intense" ->
> "18+" in the client program as it will change depending on country and
> also user preference. It's a little bit of work taking these
> classifications and turning them into a minimum-age rating for an
> application, but I'll of course share all my results and research
> under a GPL license.

Thanks for working on this and going through all the pain (by reading
your G+ posts ^^).


> [ lots of ideas ]
>
> Although I'm not sure if that makes it any clearer. I'm not sure about
> the name of <rating> or of the <classification> and I'm open for ideas
> here. Rating specifically might be too close to the idea of a "star
> rating" and get confused.

Jup, you're taking the word out of my mouth ;-) I would rather prefer
some different name, also "classification" is way too generic.
Maybe "age_classification" and "judgement" would work as pairs,
because the described properties are pretty much a biased judgement of
people, and the actual "age rating" would be done by the Software
Center (resulting in "18+" based on the country), or an organization /
government body judging by the countrie's specific rules.
That's actually a bit what worries me, because making this work in
every country will be *hard*. But it's worth a try!

<classification type="oars-1.0">
>     <rating id="violence-cartoon">moderate</rating>

Doesn't look bad - the group-dash-tag namig scheme makes sense, but I
think to finally decide how that should look like, we will need a list
of the possible rating/judgement/... tags.
Having a separate group attribute could become useful when there are a
lot of those tags, so SCs can group the detailed age information by
type (e.g. user clicks on "Violence" drawer, "moderate cartoon
violence" unfolds as detail).
Let's see :-)

> On the oft-quoted metadata bloat issue, I think this extra data would
> only really be required for games, and I only think a tiny subset of
> games would ship this data initially. We'd obviously focus on the 18+
> games first and then move down the age range.

Yes, this is one of the cases where having additional metadata IMHO
makes a lot of sense because this is important information the user,
or better, the user's parents, want to know before installing the app.
So +1 from me.
For the same reason, I am also not against adding some limited
bibliography the scientific applications, because that's super-useful
for researchers to know before installing the app (still WIP,
currently in "getting feedback" phase).

Cheers,
    Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/