Re: Schema.org v4 release draft for review

Ok, version 4 is now published (including a tweak to the /gender changes as
discussed in this thread and github)

https://schema.org/ <https://schema.org/gender>

Thanks everyone!

On Tue, 15 Oct 2019 at 13:17, Dan Brickley <danbri@google.com> wrote:

> 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
>>>
>>