Common properties for schema:Person would be nice of they were added

[summercms]

Hi,

There are many common fields not included with this taxology and I just thought I'd suggest some common property fields to be added to the class Person

• Age

• Weight

• Blood Type

• Star Sign

• Measurements

• Cup Size

etc.

For example:

<script type="application/ld+json">
    {
      "@context": "http://schema.org/",
      "@type": "Person",
      "image": "http://example.com/images/profile.jpg",
      "name": "Claire Smith",
      "jobTitle": "Developer example for schema dot org",
      "age": 21,
      "height": "160cm",
      "weight": "46Kg",
      "bloodType": "O",
      "starSign": "Cancer",
      "measurements": "36–29–38",
      "cupSize": "C",
      "address": {
        "@type": "PostalAddress",
        "addressLocality": "Briar Park",
        "addressRegion": "Manitoba"
      },
      "email": "mailto:example@nothing.com"
    }
</script>

I thought FOAF was brought over to schema and I'm surprised age is not included: http://xmlns.com/foaf/spec/#term_age

[akuckartz]

"age in years" never made sense.

[summercms]

The reason I suggested age in years was because of privacy issues.

For example having this displayed in public on a frontend website, might not be a good idea:

    "birthDate": {
        "@type": "Date",
        "name": "1999-01-01"
    },

And having an extra option like this, is a bit safer to display in the wild:

    "age": "21"

Of course can combine both:

    "birthDate": {
        "@type": "Date",
        "name": "1999-01-01"
    },
    "age": "21"

That was my reason for the age in years suggestion.

[edit] Unless schema is happy to write this:

    "birthDate": {
        "@type": "Date",
        "name": "1999"
    },

The web page: https://schema.org/birthDate doesn't mention the correct format?

[danbri]

Thanks for the suggestions. For birthDate, the documentation on the associated type does mention using ISO-8601 but I agree that we could be clearer.

We have just crossed 1000 open issues at schema.org, which is frankly too many (see schemaorg/schemaorg#2573). At the same time it is good to have free discussion on these sorts of improvement ideas. I mention this because I want us to move towards a model used by other projects, where there is a separate more open-ended issue tracker for brainstorming. We will then gradually move towards the original issue tracker being for areas where schema.org has made a commitment to work, and for proposals driven by a consuming application.

(All this as context to explain why this issue may get a new URL in a few seconds...).

[danbri]

ok, instead of being the 2581-th issue in the old issue tracker, we are now the 3rd issue in the new https://github.com/schemaorg/suggestions-questions-brainstorming/issues tracker.

This should not limit discussions in any way, but it will also hopefully help separate discussions of general improved expressivity, from discussions motivated by a consuming application. Schema.org has always prioritized the latter, but we never made a good structure for the open-ended proposals like this. There are so many different things you could say about a person, e.g. medical information, genealogy, their interests etc., that we need some scoping mechanism to decide which go into schema.org. That scoping mechanism has historically been the simple question of "is anyone going to build something explicitly using this data?". So - what apps do we have in mind here?

[summercms]

Added a suggestion to help you, with your 1000 open issue problem.