W3C home > Mailing lists > Public > public-vocabs@w3.org > December 2012

Audience and suggestedMaxAge property

From: Dan Brickley <danbri@google.com>
Date: Thu, 13 Dec 2012 19:06:13 +0000
Message-ID: <CAK-qy=7pUWYaa=EVvgsd_oDYXbXW+sHsE1LjW3UpEGmry=nmXw@mail.gmail.com>
To: Phil Archer <phila@w3.org>
Cc: "public-vocabs@w3.org" <public-vocabs@w3.org>, Egor Antonov <elderos@yandex-team.ru>
(top posting, but leaving some context below)


We've discussed this (and your points below) amongst the schema.org
partners. Here is a sketch of a compromise approach.

1. First, we acknowledge that schemas are useful when they reflect the
complexity of real life rather than codifying over-stereotypical or
cartoon views of the world, even though schemas by definition are
always to some extent simplified descriptions. For example, schemas
that describe people and model gender as a static binary property are
over-simplifying the lives of many people, and can casually cause
entirely avoidable offense. Although lots of Web sites do simplify in
this way, it is probably not a good idea to have binary 'gender'
properties in Web schemas, since sites that offer a more realistic
nuanced view of the world shouldn't be forced to adopt the simplified

2. Generally sites have an incentive not to arbitrarily exclude
potential audiences from their materials and offers; suggestedMaxAge
is therefore probably of modest interest to most publishers.

3. There are some reasonable use cases for targeting content and
offers by gender (e.g. health), and age (e.g. mortgage policies). Any
reasonably expressive descriptive schema can be used to say
ill-advised things. While there are unreasonable or foolish or
tasteless or thoughtless potential uses of such vocabulary; it is not
clear that restricting schema.org's vocabulary will help discourage
sites from saying those things in natural language. It is hard to make
general schema design policies in this area, and perhaps better to
consider terms case by case. In this particular case, sites that
needlessly exclude audiences may well be nudged more by common sense
(why exclude potential customers?) than by the decisions of schema

4. Schema.org provides a dictionary of terms; it leaves open the
possibility of very different uses being made of those terms. You
could use it to make a search system that excluded sites it deemed
sexist or ageist or otherwise socially regressive. Or you could use it
quite opposite ways. Neither usage scenario would be dictated by the
definition of 'suggestedMaxAge'; the property would just make the
statements from publishers easier to compute with.

My sense is that there is enough reason to add such a property, but
that it is worth documenting the fact that it is generally less useful
than the suggested*Minimum*Age property. Speaking personally, although
I do feel the Guardian-reading liberal urge to try to reform the world
through schema design, I think that impulse should generally be
restricted to avoiding patterns (eg. the gender example given earlier)
whose every use is somehow problematic.

Thanks for any further thoughts on this,



On 10 December 2012 18:10, Egor Antonov <elderos@yandex-team.ru> wrote:
> Hi Phil,
> thanks for the review.
> Let me emphasize, that these properties are not restrictive (at the last
> schema.org talk we decided to rename them to suggestedMinAge etc to make it
> more clear).
> It's just a hint for personalization issues, pointing at the nucleous of
> people, who maybe want to view/buy/use some content.
> If somebody searches for films, he/she probably wants to see that films
> which are intended for his/her age (and gender, too).
> Also, there can be non-matching correlation between user and intended
> audience.
> We can understand, that somebody likes non-typical (for his age/gender)
> things and suggest those things he/she likes.
> There are many websites with products, services and  creative works, which
> explicitly mark their audience:
> Games (5-12 years old):
> http://www.mosigra.ru/Face/Show/detskie_detektivi_5_12/
> Sport classes (mostly constrained by age in Russia): http://ttcentr.ru/
> Music courses (also russian): http://www.muz-school.ru/courses/deti
> http://www.ssww.com/item/candy-land-GA4700/cmc=BRWSGAMBRDYTH/grp=GAM/sbgrp=BRD/ln=YTH/fp=GA4700/sort=sales/p=1/
> http://www.games14.co/
> http://www.gymboree.com/index.jsp?ASSORTMENT%3C%3East_id=1408474395917465&FOLDER%3C%3Efolder_id=2534374303003787&bmUID=1354815600298
> (see categories)
> (I skip huge amount of woman clothes)

>  2. The Audience proposal; based on the RDFa schema in
>  https://bitbucket.org/elderos/schemaorg/src I've built a test version
>  of the schema.org site that includes the Audience proposal (see
>  http://www.w3.org/wiki/WebSchemas/Audience ). The draft site is at
>  http://sdo99a.appspot.com e.g. see http://sdo99a.appspot.com/Audience
> [..]
>  From a technical point of view, this is fine of course. From an ethical
> one, there are aspects I find seriously worrying if not potentially
> offensive.
> Why does anyone need to define the maximum age of an audience? An adult
> friend of mine is not a strong reader. He reads books targeted at 11
> year olds - and enjoys them. Why put it in his face that he's reading
> children's books?
> Minimum age - fine. We understand that. But you won't ever see a maximum
> age on a film or game.
> Daft. Drop it.
> Gender? For a target audience? What? OK, so I'm a wishy washy dripping
> wet liberal but if a girl wants to play with "boys' toys" or a boy wants
> to read "chick lit" - why not? I think the content should speak for
> itself and the potential consumer decide whether he/she wants it. The
> Twilight saga is basically aimed at teenage girls, yes? I know at least
> one teenage boy that read the whole series and many post-teenage girls
> who enjoyed it too.
> Of course content *is* targeted at gender, but I don't think it should
> be part of the data.
> Drop it.
> The parental ones - i.e. this is for parents of children aged x - y does
> make sense. That's potentially useful for parents.
Received on Thursday, 13 December 2012 19:06:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:48:50 UTC