Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add a JSON(-LD) view of the entire type hierarchy #318
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.
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.
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.