Add a JSON(-LD) view of the entire type hierarchy

[danbri]

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.

[danbri]

@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.

• JSON-LD doc: http://sdo-scripts.appspot.com/docs/tree.jsonld
• Example implementations (tmp urls):
  • http://sdo-scripts.appspot.com/docs/tree.html
  • http://sdo-scripts.appspot.com/docs/tree2.html
  • http://sdo-scripts.appspot.com/docs/tree3.html
  • http://sdo-scripts.appspot.com/docs/tree4.html
  • http://sdo-scripts.appspot.com/docs/tree5.html

Notes:

• We have a couple of cases where a schema.org type is defined as having multiple supertypes. Any LocalBusiness will be both an Organization and also Place. Any MedicalEnumeration will be an Enumeration and also a MedicalEntity. This JSON representation over-simplifies this by just reporting a single type and locating each type within one branch of a simple tree. It should at least mention the 2nd supertype.
• There are no type/property associations in the data.
• After discussion with @lanthaler and @gkellogg I'm convinced that there is relatively little merit to converge this representation with the JSON-LD contex file. They serve different purposes and audiences.

[danbri]

Filing this for gozer since it is pretty much done (with some rough edges), and we need to merge in sdo-scripts anyway.

[danbri]

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!

[danbri]

See also http://bl.ocks.org/danbri/1c121ea8bd2189cf411c

[jaygray0919]

Here's slightly different version that may have a newer class structure:

   http://ontomatica.com/public/test/schema_sunburst/index.html

Using conventional JSON

   http://ontomatica.com/public/test/schema_sunburst/index.json

We didn't use JSON-LD (which is clearly preferred)

   http://schema.org/docs/tree.jsonld

We'll do a 'diff' to identify differences.

/jay

[danbri]

I've opened #879 for collecting visualization experiments, also blogged at http://blog.schema.org/2015/11/schemaorg-whats-new.html

[jaygray0919]

Very useful - we'd rather be a follower here than a leader.

FYI, here is DBpedia

   http://ontomatica.com/public/test/dbpedia_sunburst/index.html

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.

/jay

[danbri]

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.