Schemaorg: forum for parties who use Schema.org data (schemas and instance data) to work on interop issues

[mr-c]

In June, or earlier, https://schema.org/docs/schema_org_rdfa.html broke and we were told to use https://schema.org/version/latest/schema.rdf or https://schema.org/version/latest/all-layers.rdf

I opened several dozen PRs all across the CWL ecosystem to fix the link breakage in other people's code.

Now (August) both https://schema.org/version/latest/all-layers.rdf & https://schema.org/version/latest/schema.rdf are broken ; apparently in favor of https://schema.org/version/latest/schemaorg-current-http.rdf

We are not the only people who need to find a machine readable version of the schema.org vocabulary and to do so for a very long time from a stable URL

https://www.w3.org/TR/cooluris/#cooluris reminds us that

The best resource identifiers don't just provide descriptions for people and machines, but are designed with simplicity, stability and manageability in mind, as explained by Tim Berners-Lee in _Cool URIs don't change_ and by the W3C Team in _Common HTTP Implementation Problems_ (sections 1 and 3):

Simplicity.
Short, mnemonic URIs will not break as easily when sent in emails and are in general easier to remember, e.g. when debugging your Semantic Web server.
Stability.
Once you set up a URI to identify a certain resource, it should remain this way as long as possible. Think about the next ten years. Maybe twenty. Keep implementation-specific bits and pieces such as .php and .asp out of your URIs, you may want to change technologies later.
Manageability.
Issue your URIs in a way that you can manage. One good practice is to include the current year in the URI path, so that you can change the URI-schema each year without breaking older URIs. Keeping all 303 URIs on a dedicated subdomain, e.g. http://id.example.com/alice, eases later migration of the URI-handling subsystem.

[RichardWallis]

It is understandable that when changes are made in such areas they can cause knock-on issues.

As the needs and requirements of such files evolve, such as the coverage of the contents and the format (as in http or https), there are two options available. Either, leave the file names the same, and adjust the contents and possibly add some new ones or; change the file names to better reflect updated contents and coverage.

Potentially the first of those options could introduce subtle issues and confusion into the environments that use the downloads that would take some time to come to light. The second option was chosen which, although the impact was more obvious, at least alerted consumers of the files to the changes behind them.

As to future stability. I am not aware of any plans or suggestions to change the current naming again.

[danbri]

"all-layers" has gone away, because the layering system (core + bib + auto + ...) has not proved effective. To leave the old-style naming in place indefinitely comes with its own cost to developer experience. I am looking into setting up a forum for parties who use Schema.org data (schemas and instance data) to work on interop issues; it's possible that improved data / URI documentation could come out of that activity.

[github-actions[bot]]

This issue is being tagged as Stale due to inactivity.