Re: Schema.org v4 release draft for review

Good afternoon everybody,

I've updated the version of <Schema Generator> 
<https://schema.pythonanywhere.com/> to the latest Schema.org release. 
This is an open source tool anybody can use for free to generate valid 
Schema's to use as a starting point for their web development.

Schema.org contributors can generate valid Schema examples using an 
ontology tool <http://polak.es/en/ontology.html> on my website.

Both the <Schema Generator> and the Ontology tool generate valid 
JSON-LD, Microdata and RDFa formats.

Contributions are welcome.

Yours sincerely,
Hans Polak

On 15/10/19 16:56, Dan Brickley wrote:
>
> 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 
> <mailto:danbri@google.com>> wrote:
>
>     On Thu, 10 Oct 2019 at 00:00, Nicolas Torzec
>     <torzecn@verizonmedia.com <mailto: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 <http://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
>         <mailto:danbri@google.com>> wrote:
>
>             On Wed, 9 Oct 2019 at 12:47, Brendan Quinn
>             <brendan@cluefulmedia.com
>             <mailto: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
>