Re: Schema.org version 16 is live

Hi Richard,

thank you for enlightening us on schema.org's storing & release 
procedure and providing the missing vocabulary files.

Sinc. Omar


On 24.05.23 13:27, Richard Wallis wrote:
> Hi Omar,
>
> A little bit of clarification on how/where release files are published 
> and stored, and reference to a minor recent issue in this area.
>
> When each release is built, a set of definition files are created in a 
> directory named as per the version number (eg. version/20.0)  and 
> included in the build of the static schema.org 
> <http://schema.org> website to be deployed to the hosting platform.  
> For convenience a redirecting link is configured from 
> https://schema.org/version/latest/* to that directory.
>
> For host sizing, upload timing, and potential usage reasons, only the 
> current version release files are uploaded to the Schema.org 
> <http://Schema.org> site.
>
> At the same time a copy of the release files directory is archived 
> into the schemaorg GitHub repository in the data/releases code folder: 
> https://github.com/schemaorg/schemaorg/tree/main/data/releases
>
> Developers wishing to access any of thes files have two options.  For 
> the currently published release they can access them directly via 
> https://schema.org/version/latest/* URLs - as per the links on the 
> Developers page. For that and any previous release versions they are 
> available for inspection and download in the public GitHub repository 
> from the 
> https://github.com/schemaorg/schemaorg/tree/main/data/releases folder.
>
> Due to a recent minor technical issue the archive release files for 
> versions 16.0 - 20.0 were not added to the GitHub repository.  These 
> missing versions have now been added.
>
> ~Richard.
>
>
> On 23 May 2023 at 15:00:19, Omar Holzknecht 
> <omar.holzknecht@onlim.com> wrote:
>>
>> Hello Dan,
>>
>> this sounds like a good plan to quickly publish improvements and 
>> react to typos and bugs. I wonder if increasing the release counter 
>> by one for every small change is a good idea though, especially since 
>> now there seems to be a new schema.org version every working day 
>> <https://schema.org/docs/releases.html>. I guess every new release 
>> should also include vocabulary definition files in different formats 
>> <https://github.com/schemaorg/schemaorg/tree/main/data/releases/> for 
>> us developers, as it has been until version 15.0. After all, we need 
>> to fetch and parse the versions listed in the release log 
>> <https://github.com/schemaorg/schemaorg/blob/main/versions.json>, to 
>> be schema-version-aware and so (semi-)automatically adapt our tools 
>> and data to the changes of schema.org <http://schema.org>.
>>
>> Since I couldn't find new vocabulary definition files at 
>> github/data/releases 
>> <https://github.com/schemaorg/schemaorg/tree/main/data/releases/> I 
>> checked the page for developers 
>> <https://schema.org/docs/developers.html#defs>, where only the latest 
>> version is listed, e.g. 
>> https://schema.org/version/latest/schemaorg-all-https.jsonld
>>
>> I changed "latest" to "20.0" (the latest version at time of writing 
>> this email) in the URL and i got the same vocabulary, as expected: 
>> https://schema.org/version/20.0/schemaorg-all-https.jsonld
>>
>> Changing the version string to earlier releases did not work though: 
>> https://schema.org/version/18.0/schemaorg-all-https.jsonld
>>
>> I guess those vocabulary definition files must be stored somewhere, 
>> else the latest versions could not have been served as it is 
>> currently with "20.0". I hope some clarification can be provided 
>> about these vocabulary definition files in the context of these 
>> faster release cycles.
>>
>> Thank you very much for your work, Dan.
>>
>> Sinc. Omar Holzknecht
>>
>>
>>
>> On 17.05.23 05:21, Dan Brickley wrote:
>>>
>>> See https://schema.org/ and https://schema.org/docs/releases.html 
>>> for details.
>>>
>>> From this release, the Schema.org workflow is simplified. Roughly - 
>>> we discuss things here and in Github, and the main schema.org 
>>> <http://schema.org> site is periodically updated. There is no reason 
>>> for updates to sit around for weeks or months while a larger release 
>>> is put together - if something is a fix or improvement, let's push 
>>> it live asap. In the (reasonably rare) cases when a bad change is 
>>> made, we can follow up with good changes immediately afterwards. Our 
>>> history since 2011 is pretty clear: there are always bugs, releases 
>>> have always improved things, and conflicts are rare.
>>>
>>> I and others have found that the combination of (a) having an 
>>> editorial drafting/staging site at webschemas.org 
>>> <http://webschemas.org> (b) the remnants of our old subdomain-based 
>>> extensions system ("____.schema.org <http://schema.org>" URLs e.g. 
>>> pending.schema.org <http://pending.schema.org>) and (c) the "Pending 
>>> area" concept itself, taken together, tend to cause needless 
>>> confusion, and add friction to the development and maintenance 
>>> process. They also create technical debt and conceptual complexities 
>>> that make it harder to share the workload with community members who 
>>> have not spent 10+ years on the project.
>>>
>>> I shall try to put this into practice and make some additional 
>>> changes (for consistency with the above, as well as addressing open 
>>> issues) over the coming days. For each release, we should just 
>>> increment the release counter by one. A release for this kind of a 
>>> project should not be a big occasion but a natural and frequent side 
>>> effect of maintenance and improvement.
>>>
>>> cheers,
>>>
>>> Dan
>>>
>
>
> -- 
> Richard Wallis
> Founder, Data Liberate
> http://dataliberate.com
> Linkedin: http://www.linkedin.com/in/richardwallis 
> <http://www.linkedin.com/in/richardwallis>
> Twitter: @dataliberate @rjw
>