Add pronouns attribute to Person

[shaedrich]

Fixes #2935 and #2925
Inspired by #1112

[shaedrich]

One thing that isn't covered: Some people have multiple sets of pronouns or use any of them. While you can use the :Text option, it would be nice to have an array for each set of pronouns. Should there be a :PronounsAny type as well?

[danbri]

This would need to work for all languages - is there precedent for doing so in a structured form?

…

On Wed, 1 Mar 2023 at 08:19, Sebastian Hädrich ***@***.***> wrote: One thing that isn't covered: Some people have multiple sets of pronouns or use any of them. While you *can* use the :Text option, it would be nice to have an array for each set of pronouns. Should there be a :PronounsAny type as well? — Reply to this email directly, view it on GitHub <#3272 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABJSGMCCVR445ZMY7JELR3WZ4BCDANCNFSM6AAAAAAVJTR3CU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[RichardWallis]

Is there a recognised authoritative source for such things (sets of pronouns) that could be referenced or linked to.

[shaedrich]

@RichardWallis I linked https://springfield.edu/gender-pronouns and https://pronoun.is/ for further information in the issue but of course, these are no official sources. Would you consider grammar an authorative source and if not, what would qualify as such?

@danbri I don't even think, gender works in each and every language. But I'm not enough of a linguist to provide you with several languages' culture and characteristics. What kind of information would you want as a precedent? And in case of exceptions from the rule, there's always the :Text type.

[zichy]

I would love to see this move forward 🙏

[shaedrich]

@zichy I'm afraid, my last answer was not enough to react to it :/

[WeaverStever]

I checked with the AP Style to see if they have an authoritative source. They are linking to the following.

GLAAD Media Reference Guide - 11th Edition
https://www.glaad.org/reference

[github-actions]

This pull request is being nudged due to inactivity.

[shaedrich]

Well, I answered the questions as good as I could. If that's not enough …

[github-actions]

This pull request is being nudged due to inactivity.

[voxnyx]

I'm really confused why there's no movement on this addition. It's a pretty simple addition, recognized sources have been provided for references, and a large majority of websites currently implement these fields on profiles, would be nice to have schema support on this.

[zichy]

I just realized that GitHub itself does already use itemprop="pronouns".

[shaedrich]

After all, it's just a string, and it can say anything—but nice catch though 👍🏻

I checked, and it doesn't seem like schema.org secretly sneaked in this attribute via another PR or something.

[danbri]

Q: if I were to use schema markup to write “pronouns: they” about myself as a Person, what could a reasonable party conclude about me, based on the proposed new definition? Am I communicating something about my gender identity, or about how I prefer to be written about?

…

On Sat, 6 Jan 2024 at 12:56, Sebastian Hädrich ***@***.***> wrote: After all, it's just a string and it can say anything—but nice catch though 👍🏻 — Reply to this email directly, view it on GitHub <#3272 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABJSGL3QM3O7SYLXWTARVTYNFCZDAVCNFSM6AAAAAAVJTR3CWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZZGY3TINJZHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[shaedrich]

what could a reasonable party conclude about me, based on the
proposed new definition?

If there wasn't any value, why would so many websites (including GitHub) implement this as profile information?

Am I communicating something about my gender
identity, or about how I prefer to be written about?

Pronouns might correlate with gender (being the case in most normative settings), however, they might just as well not, especially for non-binary people.

[danbri]

I am certainly not saying there is no value!

when we add new definitions to schema.org, a vocabulary used on many millions of websites, we have some responsibility to try to make it as clear as possible what the markup means; … what it communicates. That said, we have a long tradition of scruffy pragmatic definitions with various kinds of wiggleroom for alternative readings and evolving interpretations. In this current case it seems prudent to be as clear as possible since we touch on matters that are socially very weighty.

[shaedrich]

So what are we exactly talking about at the current stage?

• Whether we want to have that attribute or not? → I think, this is a no-brainer
• The naming of the attribute and/or the possible values → I'm open for suggestions
• The interpretation of the attribute and its values → if the first point is answered with "yes", this is merely a question for the docs rather than the implementation itself

[danbri]

With respect - that is rather backwards. It is never a no-brainer to add a property whose definition doesn’t clarify its appropriate values. We have made that mistake plenty of times before and the result is that questions later rain down upon this project. Let’s start from what needs to be expressed. We also generally seek implementation commitments from parties who will use (consume, process etc.) the data in software, services, tools etc.

…

On Sat, 6 Jan 2024 at 14:04, Sebastian Hädrich ***@***.***> wrote: So what are we exactly talking about at the current stage? - Whether we want to have that attribute or not? → I think, this is a no-brainer - The naming of the attribute and/or the possible values → I'm open for suggestions - The interpretation of the attribute and its values → if the first point is answered with "yes", this is merely a question for the docs rather than the implementation itself — Reply to this email directly, view it on GitHub <#3272 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABJSGIKAE6JYV3LRL6XSWTYNFKVXAVCNFSM6AAAAAAVJTR3CWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZZGY4TMOJYGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[shaedrich]

I can only emphasize this once more:

what could a reasonable party conclude about me, based on the
proposed new definition?

If there wasn't any value, why would so many websites (including GitHub) implement this as profile information?

I just realized that GitHub itself does already use itemprop="pronouns".

It's already common practice. So this would merely be catching up with real life.

Let’s start from what needs to be expressed. We also generally seek
implementation commitments from parties who will use (consume, process
etc.) the data in software, services, tools etc.

So, how exactly does this process work and what can we do about it?

[danbri]

Let’s dig into the github example, https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#adding-pronouns-to-your-profile is interesting. The meaning there seems to be “pronouns that some account holder on a website prefers be used when mentioning (eg in UI elements) that user to others on that site”. In this situation it isn’t clear what value using a machine readable data sharing system like Schema.org adds, since Github are both the publisher and consumer of the markup. In fact they may not use the markup at all. They also make this point:

Note: Any details you add to your public GitHub profile will be visible

to all GitHub users, including in regions where local laws, regulations, or cultural norms may pose risks to expressing your identity. We respect everyone's decision about whether or not to share information about themselves on their GitHub profile They are very explicit that this is not information they expect to widely broadcast. I have no idea why they put it into an itemprop in their page. Maybe used in their CSs?

Add pronouns to your public user profile to share information about

yourself with other GitHub users. Your pronouns will only be visible to users that are signed in to GitHub. Can you say a bit more about the perceived benefits to users of this change being made to Schema.org. Examples of projects that would *do something* positive with the data. Saying that it is used on Github so should be used on Schema.org is not a good analogy. Schema.org is for communicating data across various barriers, which is why we may seem pedantic when it comes to needing clear definitions up front. Our project is nothing but definitions. If the definition needs to appeal to the notion of a user on a site, for example, that would be useful to agree up front. If it is just a general fact about a person, that is also useful to know and agree. But we don’t want half the world thinking it is one and the other half taking the other interpretation. By asking for information about projects who are likely to use the data, we are just trying to head off such problems up front. Maybe the Solid project would be interested here? On the modeling side it could be easier to represent if we had a type representing an account on some site/service, rather than just for people “in the abstract”.

…

On Sat, 6 Jan 2024 at 15:00, Sebastian Hädrich ***@***.***> wrote: I can only emphasize this once more: what could a reasonable party conclude about me, based on the proposed new definition? If there wasn't any value, why would so many websites (including GitHub) implement this as profile information? I just realized that GitHub itself does already use itemprop="pronouns". [image: Screenshot of the pronouns in GitHub] <https://private-user-images.githubusercontent.com/173749/294678155-d6fcf2dc-c32e-4dde-8120-5ce6ba6731a7.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MDQ1NTMyNTcsIm5iZiI6MTcwNDU1Mjk1NywicGF0aCI6Ii8xNzM3NDkvMjk0Njc4MTU1LWQ2ZmNmMmRjLWMzMmUtNGRkZS04MTIwLTVjZTZiYTY3MzFhNy5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwMTA2JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDEwNlQxNDU1NTdaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT00MDY2MWI2MGZlMDIwMjkwZjg2YzJiYWYzZTJjMzk4ZGI1Yjc0NzNkNDg3YjNjNTRmNzhiMzAxOWQ4OTYyNDhiJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.0eAcLDiPzgN2JJbAPkea-y1unI-b1NMyeknAv1Qkpm4> It's already common practice. So this would merely be catching up with real life. Let’s start from what needs to be expressed. We also generally seek implementation commitments from parties who will use (consume, process etc.) the data in software, services, tools etc. So, how exactly does this process work and what can we do about it? — Reply to this email directly, view it on GitHub <#3272 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABJSGM4XQHLGCVUJBV2ETTYNFRHRAVCNFSM6AAAAAAVJTR3CWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZZG4ZDCNRQHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[voxnyx]

Schema.org Proposal

Add "pronouns" property to "Person"

Background

Schema.org's person schema offers a way to identify the gender of an individual, however, one's gender identity does not automatically identify the appropriate pronouns on an individual. In some cases, especially with the increasing use of AI generated content, to be able to identify the pronouns of a person(s) to properly generate programmatic content, as well as generating metadata in search algorithms, etc. This feature would also be useful for any sort of database generation where someone, or some program may be scraping data to populate a database to be used when writing articles about an individual to reference specific data about them. This data would be valuable for storage in many systems including patient data management systems, employee tracking systems, identity providers.

The more we include pronouns into our meta-data for users as we do many other, less important, pieces of information on a "person" the more we can reduce the mistakes of people when referencing other people. As someone who is, themselves, transgender, I can see a world where in the metadata for sending an email within an organization, pronouns may be displayed in the editor to notify the author of the pronouns any person in the organization may use. In a patient data management system it would be a field displayed (and in some already is) to medical providers to ensure they are following standards of care by referring to patients with the appropriate pronouns, as some systems don't currently support this and results in having to hunt the information down.

I believe the debate over the value, or need of the addition of this relatively simple parameter is a bit reductive. The person type has the following properties, callSign, honorificPrefix, honorificSuffix. Why callSign would serve more use than pronouns in the schema would be a pretty interesting take to hear as I imagine very few of schema.org's users actually implement this field.

Implementation

To align with a use for programmatic content generation, as well as a general data collection perspective I propose the creation of a new intangible type. In this context "pronouns" would be a "thing" a person has to describe it in the same sense a person would have an "occupation".

Thing > Intangible > Pronouns:

nominativePronoun

examples: he, she, they, xe

possessivePronoun

examples: his, hers, theirs, xeirs

objectivePronoun

examples: him, her, them, xir

displayPronoun

examples: "he/him/his", "she/her/hers", "they/them/theirs", "xe/xir/xirs"

I personally would leave it up to every individual site to full define how these are filled, I imagine most sites would just use the "displayPronouns" option by default as in GitHub's implementation it's a free-form field with no per-designated options. This offers a way for websites that do offer pre-baked options, to have a more defined schema in the backend when it comes to generating content from these fields (ex: Facebook who generates notification strings based on pronoun fields).

Otherwise, the currently proposed commit would also work, however to keep with the programtic nature that schema wants to enforce, require a string consisting of 1-3 parts separated by "/". This separation format is widely used when identifying pronouns for an individual for easily parsing.

[voxnyx]

I know you've been responding from email, I'd like to note I made some additional updates to my previous message.

[voxnyx]

I also would like to make some additional points. I've seen in previous comments that have been made on this discussion that maybe it shouldn't be added because people may "miss" the subtext due to translation, etc. You used the example of a dating website that became popular in Iran where users misinterpreted a "looking for" field's subtext to include friendship, or business type relationship building. This would not be an error on the part of schema.org, as in a schema sense, "lookingFor" if it existed in the schema could mean many things depending on the website it's being used on. I guess "seeks" could be used in this context, but it would be solely up to each website to implement their own definition of this property. Pronouns, would have a singular use across the board. While some users may use different pronouns based on what website they're using, and the region their in, local laws, etc, the underlying purpose is the same, provide the pronoun definition for an individual.

We are evolving as a society, and with it comes new ways for people to describe and express themselves. Pronouns are used everyday, whether people want to believe it or not, and there is a very real need for a machine-readable field to be able to process this information and store it or distribute it elsewhere. I'm not sure why the argument so far has been a bunch of what ifs, or where the value is. It's beginning to look like schema.org is resistive to implementing the property, but is trying to avoid any negative public opinion on the push-back at the same time. This field is widely used, serves an obvious purpose, and as other fields, would be up to the developer implementing the field into their schema, to figure out the semantics used in their implementation.

I think the biggest thing that got me to comment and participate in the discussion is the fact that these were originally discussed in July and August 2021, a PR was made Feb of 2023, the last comments from contributors was March 1 despite several updates by those proposing this change. Many of the responses to the discussions have been rather defensive and borderline combative. While I can understand the need to gather information given the sensitive nature of the subject I believe it could have been done better if the goal is truly making sure it's done right. But simply asking for an "authoritative" source and then not re-engaging when people provide these resources is not really a great way to show you're trying to "get it right"

[shaedrich]

Maybe the Solid project would be interested here?

There's only one way to find out. Let's at-mention @solid (not sure, whom to approach here: @VirginiaBalseiro /@csarven /@justinwb /@kjetilk /@KyraAssaad)

The meaning there seems to be “pronouns that some account
holder on a website prefers be used when mentioning (eg in UI elements)
that user to others on that site”.

In this situation it isn’t clear what value using a machine readable data
sharing system like Schema.org adds, since Github are both the publisher
and consumer of the markup. In fact they may not use the markup at all.

Just because something is used in the UI, doesn't mean, it can't also be used in some shape or form of structured data about an entity.

I believe the debate over the value, or need of the addition of this relatively simple parameter is a bit reductive. The person type has the following properties, callSign, honorificPrefix, honorificSuffix. Why callSign would serve more use than pronouns in the schema would be a pretty interesting take to hear as I imagine very few of schema.org's users actually implement this field. […] We are evolving as a society, and with it comes new ways for people to describe and express themselves. Pronouns are used everyday, whether people want to believe it or not, and there is a very real need for a machine-readable field to be able to process this information and store it or distribute it elsewhere. I'm not sure why the argument so far has been a bunch of what ifs, or where the value is. It's beginning to look like schema.org is resistive to implementing the property, but is trying to avoid any negative public opinion on the push-back at the same time. This field is widely used, serves an obvious purpose, and as other fields, would be up to the developer implementing the field into their schema, to figure out the semantics used in their implementation.

My thoughts exactly! Are there any plans to move callSign to a more specific type? Since, contrary to what some conservative people claim very loudly time and again, everyone does have pronouns—something that couldn't be said about a call sign.

@RaineAllDay Thanks for speaking up 👍🏻

nominativePronoun
examples: he, she, they, xe

possessivePronoun
examples: his, hers, theirs, xeirs

objectivePronoun
examples: him, her, them, xir

displayPronoun
examples: "he/him/his", "she/her/hers", "they/them/theirs", "xe/xir/xirs"

Some might even need

reflexivePronoun
examples: himself, herself, themself/themselves

There might be more in other languages.

Interestingly enough, schema.org already has a gender attribute, contributed in #1112, which I referenced as "inspired by"—however, it's more than that. Some people actually stored gender (or actually "sex" according to their definition) as a boolean in their database and didn't offer an option to change this via the UI. Furthermore, some websites started to use services like finnp/node-genderize or markus-perl/gender-api-client to guess the gender by given name. Even though, that might work in a normative world, this is an error-prone approach. The only solution can be self-declaration.

[voxnyx]

If there is opposition to the proposal I prepared from the maintainers, they need to come from a perspective of not matching current standards. As I have not participated in the creation of new schema properties I am not versed in the structure in which the proposal process usually goes. However, the continued discussion and argument over it's value, or need for authoritative sources for values, etc. needs to stop. I am happy to discuss the potential formats, or structure of the data, but it's obviously something that would be useful, unless of course the users of schema.org are only conservative websites that believe that pronouns aren't real, then maybe I can accept the argument that there is no value. Will every schema consumer use the pronoun property? Probably not, but then again, there are many properties not used from any given type, so it's not a valid argument.

This data can serve MANY purposes being shared in a structured way. 99% of the time the data will most likely be used to just display on a profile somewhere. But especially in medical systems which are becoming more and more integrated, ex: insurance data is shared between doctors prescription system and pharmacy, sharing pronoun data is really important, and by having recognized schema orgs include it in their schema, I think it can help continue the progression of implementing these fields into systems that would benefit from consumption.

[shaedrich]

Second that.

Also, there's much value for research, when grouping data together. Something, that can hardly be said about a call sign.

[voxnyx]

@danbri, would you mind responding to my previous question?

[github-actions]

This pull request is being nudged due to inactivity.

[shaedrich]

This pull request is being nudged due to inactivity.

Jesus Christ! Just remove this nonsensical action—it does nothing good here! (╯°□°)╯︵ ┻━┻

[alex-jansen]

@MatthiasWiesmann @shaedrich @danbri

Want to try and get this controversial topic over the finish line.

Here are some observations based on the various discussions:

1. In the context of https://schema.org/Person it appears that we are specifically discussing personal gender pronouns (PGPs), so we should limit the scope to this.
2. Acknowledging that many social media sites (Instagram, Pinterest, LinkedIn, Twitch, Slack, and more) already allow users to set personal gender pronouns in their profiles, so it is a common practice.
3. Also acknowledging that pronouns are very different (or even absent) depending on language.

Therefore proposing to:

1. Add an enumeration PersonalGenderPronounEnumeration with the common English personal gender pronouns "She/Her, He/Him, They/Them".
2. Introduce property personalGenderPronoun for use on Person. This property defines how the subject person wants to be referred to. Absence of the property means no personal gender pronoun has been set by said person.
3. Allow values of 3 different types for personalGenderPronoun: (1) PersonalGenderPronounEnumeration, (2) Text for a custom personal gender pronoun, and (3) DefinedTerm to allow referencing a standard dictionary of personal gender pronoun terms.
4. As usual for new types, introduce the property and enumeration as Pending to monitor adoption and usage. If adoption takes off we will move them to Main.

Note: Given the limitation of enumerations and the differences between languages we could decide to just allow Text and DefinedTerm (or even just DefinedTerm) for the range of personalGenderPronoun, to avoid being too English-centric.

[danbri]

I believe an enumeration managed here will be an impossible maintenance burden. Could use DefinedTerm for those who want to try to maintain lists but here’s my suggestion, based on points I’ve already tried to articulate in the issue.

Counter proposal

1. Add a pronouns property
   domainIncludes Person
   rangeIncludes Text, StructuredValue

“A short string listing or describing pronouns for a person.
“Typically the person concerned is the best authority on this matter. Publishers and consumers of this information are reminded to treat it responsibly eg regarding out of date data, and to be wary of drawing unwarranted inferences about the person being described.

In English formulations such as “he/him” are commonly used online, and can be used here. We do not attempt to enumerate these micro-syntaxes, or enumerate all possible pronouns in all languages.

Parties interested in more structured values for pronoun information, or representation of additional language-related information, are encouraged to share details of their efforts in the schema.org issue tracker.”

[danbri]

@MatthiasWiesmann I didn’t explicitly include DefinedTerm in the draft but it would be a natural fit. Thoughts?

[MatthiasWiesmann]

I'm all in favour of using DefinedTerm, this way everyone can define their DefinedTermSet with whatever they want.

The only question is for the classic english pronouns, if there can be a predefined set. I would have suggested a defined set on schema.org with the english him/her/they, so there that the simple case works out of the box (what Alex suggests doing with an enum). The understanding would be that this is just a basic thing and each community / language should define their own.

My philosophical question is anyway what is the fundamental difference between an enum and a DefinedTermSet, they both define a set of values that have defined meaning.

[danbri]

Yeah, basically same idea. We used to call them “externalEnumerations”. However external schemas share many of the same characteristics especially their types, and DefinedTerm is also designed to fit with W3C SKOS. The crux of all this isn’t really addressed yet, which is whether anyone has said they will create anything at all (software/services/tools/products) which *uses* this data. Without that it is hard to work out appropriate levels of detail for any attempts at structure. By supporting DefinedTerm and StructuredValue we provide a kind of path towards later enrichnent. ps. We should also remember Person covers anything that is in some sense a person, including the dead, undead and fictional. A person (alive, dead, undead, or fictional).

…

On Fri, May 9, 2025 at 14:51 Matthias Wiesmann ***@***.***> wrote: *MatthiasWiesmann* left a comment (schemaorg/schemaorg#3272) <#3272 (comment)> I'm all in favour of using DefinedTerm, this way everyone can define their DefinedTermSet with whatever they want. The only question is for the *classic* english pronouns, if there can be a predefined set. I would have suggested a defined set on schema.org with the english him/her/they, so there that the simple case works out of the box (what Alex suggests doing with an enum). The understanding would be that this is just a basic thing and each community / language should define their own. My philosophical question is anyway what is the fundamental difference between an enum and a DefinedTermSet, they both define a set of values that have defined meaning. — Reply to this email directly, view it on GitHub <#3272 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABJSGPZEY26EP524B6DZNT25SXETAVCNFSM6AAAAAAVJTR3CWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNRWGYZTMMJUGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[philbarker]

I welcome this addition, I wish it had been made earlier, but I prefer the counter proposal from @danbri .

Schema.org has managed for so long without any way to specify pronouns so I doubt there will be any damage done if it doesn't have any built-in restriction or preference—or rather, the perception of such caused by it having its own enumeration. There are several ways in which damage could be done by it having (or being perceived to have) the wrong preferences or restrictions. I suspect that any enumeration of pronouns by Schema.org is more likely to be problematic than useful.

@MatthiasWiesmann I've learned to avoid philosophical questions about fundamental differences around RDF :-) but the functional difference is that terms in a DefinedTermSet were intended for controlled vocabularies defined outside of Schema.org where some of the definition needed to be expressed/comsumed using Schema.org rather than relying on a consuming system to resolve a URI and understand whatever schema had been used to define their meaning.

[shaedrich]

1. In the context of schema.org/Person it appears that we are specifically discussing personal gender pronouns (PGPs), so we should limit the scope to this.

As compared to what?

Add an enumeration PersonalGenderPronounEnumeration with the common English personal gender pronouns "She/Her, He/Him, They/Them".

According to Wikipedia

There exists some disagreement on whether or not to refer to PGPs as "preferred". Some people omit the word "preferred", calling them "gender pronouns" or simply "pronouns" to emphasize that correct use of pronouns is a social obligation rather than an individual preference. There is concern that including "preferred" in the name may cause the perception that using an individual's PGPs is optional. Levin states that "pronouns aren't 'preferred' but simply correct or incorrect for someone's identity.

[danbri]

It is also good to avoid “preferred” since we may be speaking about historical or fictional characters whose preferences are unknown or non existent.

[alex-jansen]

Draft version ready on staging as part of release 29.2. PTAL at the release notes and the new pronouns property.

Please submit your comments here before Thursday 5/15 (the planned release date for 29.2)

(note that I had to create a separate PR #4450 to add a new file (issue-2935.ttl) to Pending, but please continue the discussion here.)

[TallTed]

Suggested change

	rdfs:comment "Pronouns of something, typically a [[Person]], but possibly also fictional characters, animals, etc. While https://schema.org/TheyThem, https://schema.org/HeHim and https://schema.org/SheHer may be used, text strings are also acceptable for people who do not identify as a binary gender. As with the pronouns of individuals, we do not try to enumerate all possibilities."
	rdfs:comment "Pronouns of something, typically a [[Person]], but could also be a fictional character, animal, etc. While https://schema.org/TheyThem, https://schema.org/HeHim, and https://schema.org/SheHer may be used, text strings are also acceptable for people who do not identify as a binary gender. As with the pronouns of individuals, we do not try to enumerate all possibilities."

[alex-jansen]

Note that the staging and candidate live source for adding pronouns is in PR #4450. I had to create a new PR since the new type will be added to Pending, hence it should not be added to schema/data.ttl. I am planning to reject the changes in this PR once this is live. If any feedback/comments, please add them to #4450

[TallTed]

@alex-jansen — Note that #4450 has already been merged, so change suggestions such as mine there don't seem to have a path to being merged.

Also note that the text here and there is substantially different. There is no clear path from one to the other, and it is not clear to me why they differ so much, given that #4450 is apparently meant to be merged after — but is not based on — #3272.

[shaedrich]

Just for the record: #3272 is open for over two whole years now and wouldn't it have been revived by contributors (who all made good points throughout the process) due to neglect by the maintainers without good explanation time and again, yet #4450 chimes in and is merged within a day without much ado, after only four days of prior discussion.

[danbri]

The alternative design I proposed in #3272 (comment) is consistent with what I have been saying all along in issues/PRs here, and based on experience with hundreds of different schema design problems we have faced here. My experience of these discussions has been that they are far and away the most unhappy and unsuccessful iinteractions we have had around here since 2012. I am sorry for my part in any miscommunications and expectation setting. I would have preferred to have wrapped things up earlier but was unavoidably delayed because I was hit by Google’s layoffs programme just after beginning paternity leave last year. I am returning to work (no longer at Google but still engaged here) and responded when I saw the enums-oriented design. I believe enums add verbosity and complexity to the markup and in the case of pronouns are either going to be so tiny as to be not worth doing, or so rich as to be unsustainable in a monolithically curated project like schema.org. It may appear that we are being arbitrary and unfair here but the project had long been extremely resistent to adding *anything* unless some serious data *consumer* brings the design into real people’s everyday lives in a practical way. We already, frankly, have hundreds of properties and types in the vocabulary and being published in site markup, dsspite being basically not used. This is a longstanding embarrassment and shouldn’t be casually exacerbated. We need people consuming our markup not just publishing it! Uses historically has usually been search related, but needn’t be. It could be addressbook software or some AI thing or accessibility tooling. But it really ought to be something. Am I missing an announcement or has nobody stepped forward yet? We have also long been wary of unmaintainable enumerations, and of a bias towards English. The approach I suggest has two language -neutral extensibility hooks that allow for rich structure, and for independently maintained enumerations to be usable without validator.schema.org complaining, and without being blocked by lack of consensus here.

…

On Tue, May 13, 2025 at 20:46 Sebastian Hädrich ***@***.***> wrote: *shaedrich* left a comment (schemaorg/schemaorg#3272) <#3272 (comment)> Just for the record: #3272 <#3272> is open for *over two whole years* now and wouldn't it have been revived by contributors due to neglect by the maintainers *without good explanation* time and again, yet #4450 <#4450> chimes in and is merged *within a day* without much ado, after *only for days* of prior discussion. — Reply to this email directly, view it on GitHub <#3272 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABJSGNPYX4LNO4VHCKT3RD26JDZLAVCNFSM6AAAAAAVJTR3CWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNZXG43DANZWGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[shaedrich]

I am sorry for my part in any miscommunications and expectation setting. I would have preferred to have wrapped things up earlier but was unavoidably delayed because I was hit by Google’s layoffs programme just after beginning paternity leave last year.

Thanks for sharing this—sorry to hear that :/

[danbri]

On Tue, May 13, 2025 at 22:36 Sebastian Hädrich ***@***.***> wrote: *shaedrich* left a comment (schemaorg/schemaorg#3272) <#3272 (comment)> I am sorry for my part in any miscommunications and expectation setting. I would have preferred to have wrapped things up earlier but was unavoidably delayed because I was hit by Google’s layoffs programme just after beginning paternity leave last year. Thanks for sharing this—sorry to hear that :/

Thanks, much appreciated. On balance life’s good and no hard feelings. But it does focus things for me on wanting to make sure schema.org is widely consumed, and that it stays relevant in the face of AI etc. —

…

Reply to this email directly, view it on GitHub <#3272 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABJSGMSLOKQUGVXBNXG3Y326JQVTAVCNFSM6AAAAAAVJTR3CWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNZYGAYTAMBWGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[alex-jansen]

This is now live in release 29.2. Unfortunately I had to create separate PR #4450 (based on Dan's solid proposal) since I did not appear to have the rights to add a new file to this PR.
@TallTed I did indeed merge / close #4450 too quickly while creating the staging build, for which I apologize, please feel free to open a new PR with change suggestions if needed.