Re: Schema.org v4 release draft for review

On Thu, 10 Oct 2019 at 00:00, Nicolas Torzec <torzecn@verizonmedia.com>
wrote:

> *RE #2242 - Added property gender to SportsTeam type:*
>
>    - The range of *gender <https://webschemas.org/gender>* is *genderType
>    <https://webschemas.org/GenderType>*, which is an enumerated type with
>    two possible values: *Male*, *Female*.
>    - Some disciplines and teams are actually mixed. How do we represent
>    them?
>    - E.g., Triathlon Mixed Relay
>    <https://en.wikipedia.org/wiki/ITU_Triathlon_Mixed_Relay_World_Championships> is
>    an ITU discipline since 2009 and a 2020 Olympic events.
>
> Thanks for raising this. Enumerated values around gender have many
problems. This is why http://schema.org/gender already also anticipates
text values, to give more freeform expressivity.

Currently the property is defined as "Gender of the person. While
http://schema.org/Male and http://schema.org/Female may be used, text
strings are also acceptable for people who do not identify as a binary
gender.". Minimally we should amend the text to anticipate non-person
things being described with it. I would like to ship schema.org v4 with
such a fix, and we can come back to the possibility of more explicit
strtucture here in v5 or later. Vicki - can you take a look?
>
>
>
> *RE #2232 - Simplified example for Audiobook*
>
>    - Users will wonder how to connect audio books to their printed
>    counterparts
>    - Should we highlight how to do this in the definition?
>    - E.g. via about <https://schema.org/about>, workExample
>    <https://schema.org/workExample>?
>
> workExample sounds about right to me. Anyone else care to take a look at
this for v5?

cheers,

Dan



> Cheers.
> -N.
>
>
>
>
> On Wed, Oct 9, 2019 at 7:52 AM Dan Brickley <danbri@google.com> wrote:
>
>> On Wed, 9 Oct 2019 at 12:47, Brendan Quinn <brendan@cluefulmedia.com>
>> wrote:
>>
>>> Hi Dan, hope you are well!
>>>
>>> What's the thinking behind the change in version numbering strategy? Is
>>> it just to make things simpler and use one increasing number, or are there
>>> breaking changes of some kind in the "4.0" release?
>>>
>>
>> Hi Brendan,
>>
>> Thanks for asking. It is fairly simple. We are now on monthly releases
>> (more or less), and I wanted to decouple the release identifiers from any
>> sense of whether a given release is or is not "huge progress" against the
>> prior release. If you look at the early releases,
>> https://schema.org/docs/releases.html we went as follows:
>>
>> 0.91, 0.95, 0.96, 0.97, 0.98, 0.99, 1.0a, 1.0b, 1.0c, 1.0d, 1.0e, 1.0f,
>> 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.91, 1.92, 1.93, 2.0, 2.1,
>> 2.2, 3.0, 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 3.7, 3.8, 3.9, ...
>>
>> ... as which point we find ourselves in a similar situation to the
>> buildup to "1.0" and "2.0", where we avoided using up a
>> major-release-sounding version number on a release that was not
>> substantively a huge change. The first time we avoided "1.0" by qualifying
>> with "a", "b" (alpha and beta of 1.0) but then got stuck with 1.0c etc. The
>> second time we used finer-grained increments instead. This time, by simply
>> incrementing integer-based version numbers each time, we avoid this sense
>> of "impending major release" imposed by the numbering system. Naturally we
>> should still strive to make - and publicise - more than incremental
>> improvements, but these needn't be dictated by calendars and counting
>> schemes.
>>
>> Hope this helps,
>>
>> Dan
>>
>