It is too hard for mainstream developers to consume our schema definitions. This is holding back tool development and is easily enough fixed. a JSON view of the hiearrchy would go a long way towards fixing this (but see also meta bug, re CSV and other formats for other audiences, #208 ).
Proposal: a single doc with brief description of all types, JSON-LD in a form that counts as W3C RDFS and also fits default D3.js hieararchy visualizations.
@gkellogg, Sandro Hawke and I discussed this some time back at a SF semweb hackathon, and Gregg has long had a Ruby implementation (@url) that generates such JSON. I've made a cut at similar within the schema.org Python codebase. It's not pretty but does the basic job.
Filing this for gozer since it is pretty much done (with some rough edges), and we need to merge in sdo-scripts anyway.
I'm closing this as the code will ship in this next (gozer) release. There are lots of related things that might be worth doing, e.g. examples, improvements but they can get their own bug. Thanks all!
See also http://bl.ocks.org/danbri/1c121ea8bd2189cf411c
Here's slightly different version that may have a newer class structure:
Using conventional JSON
We didn't use JSON-LD (which is clearly preferred)
We'll do a 'diff' to identify differences.
I've opened #879 for collecting visualization experiments, also blogged at http://blog.schema.org/2015/11/schemaorg-whats-new.html
Very useful - we'd rather be a follower here than a leader.
FYI, here is DBpedia
the color labels are for classes important to our work.
Your JSON-LD file also was useful as a guide to creating class hierarchies.
We have used schema:hasPart and schema:isPartOf to create hierarchies for WebPages, Books and Publications (Journals, Journal Edition, etc.).
Now we see how to design a more conventional class structure.
Here's an observation.
When running your schema.org JSON-LD file thru Google Structured Data Testing Tool (GSDTT), we get the undefined type message for 1-2 of the non-Schema types.
The semantic structure of the JSON-LD seems to be properly processed.
We have tried to use XSD to type data for some schema fields, but the XSD constraints fail and GSDTT reports an unknown type error (for example, some the XSD examples on the schema.org site).
We are watching the Martin Hepp thread about schema:QuantitativeValue.
Changes like that will be helpful.
But is there a way to use XSD to specify the properties of data within a @class structure?
FYI, there are JSON error in some of the schema.org examples. We can point out the ones we've stumbled on - someone at Google may want to run QA on those examples.
Also we can show cases where the microdata produces different result than the companion JSON-LD data in GSDTT.
These are confusing, but we'll post the cases to a different thread.
Quick thought: don't worry too much about Google Structured Data Testing Tool. It is primarily for mainstream Web publishers who are trying to make their content match the expectation of google products (mostly search features). It can complain a little too much about advanced / experimental structures, but the complaints are harmless. You should be able to see if it has successfully extracted the data, even if it doesn't entirely match what it wants.