(adult-oriented product offers and ...) Proposal to expand support for audience restrictions #2989
Comments
|
Thanks, Alex! I am supportive of this direction in that it leaves some scope for nuance and multiple perspectives while giving a practical path for some common cases.
@philarcher - any thoughts on this? Given your ICRA background, experience with POWDER and product description interests, it would be good to get your perspective |
|
Just mentioning that archives have collections which have audience
restrictions. Also Dublin Core has an audience element. Adding restrictions
could be an interesting exercise. More recently LRMI has an audience
element. Some learning resources have restrictions, like test keys. So
these are two schema types which would also benefit from this proposal.
- Hugh
On Sun, Nov 14, 2021 at 4:16 PM Dan Brickley ***@***.***> wrote:
Thanks, Alex! I am supportive of this direction in that it leaves some
scope for nuance and multiple perspectives while giving a practical path
for some common cases.
- A detail but you might want to consider whether to say Tobacco or
"Tabacco and Nicotine"; my understanding is that e-cigarettes are devices
that can deliver nicotine without burning or containing tobacco.
- "AdultContent - The product contains adult content such as nudity,
sexually suggestive or explicit material, or is intended to enhance sexual
activity. Examples: Erotic videos, sex toys."
- I am a little uncomfortable that this conflates "adult" with
"sex", even if calling it adult "content" softens that a little. The other
topical concerns discussed here are also rather adult. Euphemisms work
better in society than in schemas, maybe?
- It pushes everything into the "content" lens, which
prototypically would be pornographic digital or physical documents, images,
movies etc. Schema.org's "Product" type in practice somewhat embraces
Services, although we have the underused https://schema.org/Service
type too (in goodrelations it was ProductOrService). But presumably there
are adult *services* online too - should they also be covered? I
guess anything illegal should have an Audience of "nobody" anyway, but
different things are legal in different countries.
@philarcher <https://github.com/philarcher> - any thoughts on this? Given
your ICRA background, experience with POWDER and product description
interests, it would be good to get your perspective
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2989 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAJ2JVDUOCWQR52MZJ44J3UMARJTANCNFSM5IADX6KA>
.
--
All the best,
-Hugh
…Sent from my iPhone
|
|
Oh what a minefield. This makes sense and is definitely worth looking at, but there are many cans of worms here. I note that "The actual interpretation (e.g., deciding whether or not to block the content) of the tag is left to the consuming system." but that begs the question what sort of consuming application do you have in mind? @alex-jansen kindly referenced my old ICRA fail doc from years ago (boy I'm embarrassed that's a PDF, I really need to update it into a proper doc with a redirect from the original URL). Presuming the idea is to remain neutral, fine, but are you as happy with people actively looking for restricted content as avoiding it? While content can indeed be harmful, it's only one kind of online harm. Disinformation, hate speech, grooming etc. It's a long list. Is there a good answer to "yeah, great, but what about... ?" Declaring the intended audience, within a set of regulations or cultural norms, makes sense, sure. And the proposal acknowledges that. Good. What about 'professional classification' from film classifiers, and book publishers (Young Adult etc.) And what about content that is not of itself problematic but is a commentary on such content? We ended up with a classifier that said something like "we don't think there's anything contentious here but please note that it is written for an adult audience". That's getting towards the concept of 'Adult Themes' that - a favourite anecdote of mine - research at the British Board of Film Classification showed that teenagers thought the term meant something like paying the mortgage, i.e. "being an adult." It's 13 years since I was involved in online safety so I am obviously out of date. There are other people, of course, you might want to ping on this one. https://twitter.com/johnc1912 is and has been a grand fromage of the space for many a year and is a champion of the UK's online harms bill, for example. |
|
Notes from chat with @alex-jansen:
|
|
Nearby (via @philarcher 's doc), https://www.rtalabel.org/index.php?content=howto - "restricted to adults"; apparently adopted (for content), despite not having much of a definition. |
|
Talking this over with Alex, and looking at older failed initiatives, I think we should try to keep this as simple as can be. But that's a cliche / truism in all standards work. The two opposing forces here are:
While I like the idea of using Audience, I am less sure that it works well here. Partly because the driving motivation for this proposal is to address the "how to mark a product as adult-oriented" usecase from e-commerce. If we do something now with Audience it would look equally applicable to every other area where schema.org describes content, and a lot more research would be needed. I suggest we do something that is Product / Offer oriented. New proposal: adultOrientedConsideration + enumerationsNew proposal:
For EvidenceOfAdultAudienceEnumeration we could have enumerated values including:
For EvidenceOfNonAdultAudienceEnumeration we could have e.g.:
Notes:
The assumption would be that an item (or a place-scoped offer of an item) could be described using adultOrientedConsideration, quite possibly repeated. We should also make isFamilyFriendly available on Product and Offer, for the case where a single boolean is needed. Some wording tweaks should link these two descriptive approaches. |
|
This makes more sense than adjusting audience. I would suggest adultOrientedConsideration is applicable to Service as well as Product |
|
Attaching regional descriptors seems like a fundamental use case. We need to be clear about balancing the difference between the web, available globally modulo local censorship, and the rules of particular societies defined under the right to self-determination. Applying policies from any one jurisdiction to the web is problematic. Some places have very strong laws that prohibit advertising of sex work, or nicotine products. But they are often different places. Likewise rules about what is "protected free expression" or criminalised "promotion of terrorism" or "hate speech" vary widely. But when the question is how to describe them in a schema, it's the same practical issue. There is also the question Phil asked - are we talking about restricting an audience, or directing an audience to something they are looking for? Am I going to search for nicotine products? Where does army recruiting fit in? |
|
Does *adultOrientedConsideration *apply to USA size 12 shoes? Does it
apply to gambling? Does it apply to content offered from secret societies
oriented toward adult members?
How does the use of this kind of element in the schema not require the
browser to reveal the age of a user, and isn’t that a privacy exposure?
(Presuming that the element is being used to direct traffic to content.)
Instead of 6 or 8 new properties, why not one property with an expected
value from a defined taxonomy?
- Hugh
On Tue, Nov 16, 2021 at 7:02 AM chaals ***@***.***> wrote:
Attaching regional descriptors seems like a fundamental use case.
We need to be clear about balancing the difference between the web,
available globally modulo local censorship, and the rules of particular
societies defined under the right to self-determination.
Applying policies from any one jurisdiction to the web is problematic.
Some places have very strong laws that prohibit advertising of sex work, or
nicotine products. But they are often different places. Likewise rules
about what is "protected free expression" or criminalised "promotion of
terrorism" or "hate speech" vary widely.
But when the question is how to describe them in a schema, it's the same
practical issue.
There is also the question Phil asked - are we talking about restricting
an audience, or directing an audience to something they are looking for? Am
I going to search for nicotine products? Where does army recruiting fit in?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2989 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAJ2JVU5VWV5MDVRYJVJ4TUMJB5DANCNFSM5IADX6KA>
.
--
All the best,
-Hugh
…Sent from my iPhone
|
danbri
changed the title
|
Thanks all for comments. Responding to Hugh here:
It could potentially be applied to all of these, but it is likely that nobody will rush to build something to use the data in all those scenarios.
Nobody mentioned web browsers. Schema markup is most often consumed server-side, i.e. more "world wide web" rather than "web platform". In general schema markup doesn't require or assume any particular processing model or application, it just provides factual data / claims that can be used in various ways.
The motivating usecase here was for product offer structured data being published by e-commerce sites.
I am sorry if this wasn't obvious but that was the proposed design I sketched above. The enumeration defines values that can be used with that one property. We could add more codes to the enumeration(s) to capture additional considerations. The main difference between this and @alex-jansen original proposal is that it lets people just straightforwardly say more about the item, without forcing them to do so via making sweeping statements about its suitability for particular audiences. |
|
It is a minefield indeed @philarcher :) @HughP Adding "one property with an expected value from a defined taxonomy" is actually the intent, except with the idea that a focus on a minimal taxonomy for goods/services that are traditionally restricted would be most useful and avoids the complexities of defining or adopting an existing "complete" public taxonomy tree with potentially thousands of categories. Note this could be accomplished also by building on the existing /category property, which @danbri and I considered, see "Considerations" under the original proposal. |
|
Wrt Hugh's mention of Dublin Core and LRMI, cc:ing @philbarker although note that the direction I propose most recently above is less tied to Audience. @philarcher wrote:
Absolutely (edit: meant w.r.t “only one kind of” rather than whether there is a good general answer). This is not a general solution to all kinds of online harm. It is in fact oriented towards buyable products, which might be adult oriented (eg sex toys) without being "content" in the images-and-text sense. Specifically at Schema.org I would point to our ClaimReview, MediaReview structures for use in factchecking and misinformation settings. @chaals writes
I have always maintained (since the days of PICS) that richer description standards are a double-edged sword. In fact the underlying technology behind Schema.org (i.e. RDF) developed from PICS, as PICS-NG was adapted to take its technical design from MCF and requirements from Dublin Core. https://www.w3.org/TR/NOTE-PICS-Statement in 1996 said
Schema.org in many ways fulfills this vision. There is a loose coupling between vocabulary terms and the various uses they can serve. I once used PICS-like labels + SVG to annotate "rude" parts of an image in RDF to illustrate that you could equally use it to blur the naked areas in an online photo, or to make a collection of nude images. That same dynamic is hard to escape in a decentralised web. |
I saw both @HughP's mention and the move away from Audience. This is a minefield I don't fancy walking through, but I will note that one of the properties originally from LRMI, |
|
WRT
https://schema.org/typicalAgeRange
This is an interesting use. I find as I work more with industry that many
engineers assume that schema.org is a flat metadata structure with all
properties being equal and mixable. Most don’t have concepts like types and
embedded types.
WRT server-side primary consumption: In my sectors most uses of schema.org
are presented for SEO consumption while this is server to server
communication a separate transaction happens where the user queries the
search engine. So there is a strong sense that there is a client oriented
impact.
On Tue, Nov 16, 2021 at 10:33 AM Phil Barker ***@***.***> wrote:
Wrt Hugh's mention of Dublin Core and LRMI, cc:ing @philbarker
<https://github.com/philbarker> although note that the direction I
propose most recently above is less tied to Audience.
I saw both @HughP <https://github.com/HughP>'s mention and the move away
from Audience. This is a minefield I don't fancy walking through, but I
will note that one of the properties originally from LRMI, typicalAgeRange
<https://schema.org/typicalAgeRange>, which we naively thought would be
used to indicate the age for which a learning resource was useful, seems to
be widely used with the value "18+" on porn sites[1].
1. https://dl.acm.org/doi/10.1145/3041021.3054160
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2989 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAJ2JS6ITS2RSYR4K6VEELUMJ2V5ANCNFSM5IADX6KA>
.
--
All the best,
-Hugh
…Sent from my iPhone
|
I would suggest you stop there. Say 'Adult oriented consideration' and leave at at that. The more you have to say, the more you have to justify and the more chance there is that you'll touch a nerve somewhere that you don't want to touch. I'd forgotten about the RTA label but now that you remind me, that's what it was about, i.e. just saying "Restricted to Adults". It made no judgement about why is was restricted to adults, just that it was, so that the adults could make their own mind up. Of course it's true that some things are legal in one place and illegal elsewhere. So a jurisdictional statement might be appropriate but even there, is there something that is 'perfectly OK for all ages' in one place and 'always illegal' somewhere else? Well, OK alcohol sales might fit that, and there was a case many years ago where a UK teacher ran off to France with his then 15 year old pupil/girlfriend. There was some trouble getting him extradited back to UK as, under French law, he'd done nothing illegal. But in both of those cases, a flag that says "you might want to think about this" is equally applicable, both sides of the border.
Hmm... maybe. The UK film classification 'U' does this. It says "this is for Universal audiences and is particularly suitable for children" (or something like that). But I'd be tempted to start with just the adult flag and see how it goes. Whatever is decided, it will clearly be important to monitor usage and see whether it is used as intended. |
|
@philarcher Very much in favor of this limited extension before going further and boiling the ocean. The. RTA label seems to be excellent prior art for something simple that works. |
|
how would *adultOrientedConsideration alone be sufficient to be actionable?
Some of the considerations will suggest less likelihood of it being
adult-oriented.*
*If we set up an enumeration hierarchy we can throw anything in there
-nipples, kitemarks or whatever. Whenever we do something we no structured
value it is generally hard to use the data, particularly when crossing
natural language divide.*
…On Tue, 16 Nov 2021 at 18:21, Alex Jansen ***@***.***> wrote:
@philarcher <https://github.com/philarcher> Very much in favor of this
limited extension before going further and boiling the ocean. The. RTA
label seems to be excellent prior to art for something simple that works.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2989 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABJSGKJHZRPKO7JUUQILTLUMKOLDANCNFSM5IADX6KA>
.
|
|
Revisesd proposal:
ping @philarcher |
|
I think those points cover it, yes. We know that whatever the documentation and definitions say, it's not possible to predict with accuracy how a given term will be used so this will need extra-careful monitoring to see how it's actually used. If it's used as intended - great! If not, we'll need to think again of course. It all sounds very simple but of course it's a very tricky topic. There's no intention in this thread to link this markup directly to anything like a safety filter but the temptation might be there, which would bring us right back to ICRAfail. In potentially related news... https://twitter.com/johnc1912/status/1466712986014339076 |
Context
This is a proposal from Google based on our experience consuming schema.org Product markup and working with similar data from online merchants. If it were accepted, it would allow site owners to add structured data that specifies potential audience restrictions for eCommerce products, for example based on law or commonly accepted norms in specific countries or cultures.
Proposal
Schema.org currently allows specifying a suggested gender or suggested (or required) age-range on the /PeopleAudience class. However, depending on the country or region, a specific product might or might not be legally allowed or might have different age restrictions (for example: marijuana is legal in some US states and not in others). We therefore propose to add a new /applicableRegion property with range /DefinedRegion to the /PeopleAudience class to specify the region(s) for which the specific PeopleAudience instance applies.
User (audience) restrictions might not always be age-related (for example, some products require special training before use), so we also propose to add a new property /audienceRestriction to the /PeopleAudience class that allows site owners to specify why a product could be audience-restricted, e.g., because it is dangerous and requires certain training, because it is considered harmful for children, because it is designed to inflict bodily harm, etc.
The range of the proposed /audienceRestriction property would be a new enumeration /AudienceRestrictionEnumeration with the following suggested enumeration values based on common reasons why a product could be audience-restricted:
Additionally we could add /Text to the range of /audienceRestriction to allow a free-form explanation of why a product is audience-restricted.
Possible extensions
To further classify narcotics we could consider introducing a new property /narcoticSchedule (with range Number and values 1-4 per the schedules defined by the UN).
To further classify dangerous goods we could introduce a new enumeration type /DangerousGoodTypeEnumeration and property /dangerousGoodType with possible values:
We could consider adding existing rating schemes for certain types of content, e.g, the EU and US rating schemes for movies.
Considerations
The text was updated successfully, but these errors were encountered: