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

danbri · Feb 4, 2015

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 · Feb 4, 2015

@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):

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 · Apr 17, 2015

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

danbri · May 12, 2015

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 · Nov 5, 2015

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

jaygray0919 · Nov 5, 2015

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 · Nov 6, 2015

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

jaygray0919 · Nov 6, 2015

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 · Nov 6, 2015

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.

danbri self-assigned this Feb 4, 2015

danbri added this to the 2015 Q1 milestone Feb 4, 2015

danbri added guidelines docs examples standards + organizations site tools + python code status:implementing status:needs review type:enhancement labels Feb 4, 2015

danbri modified the milestone: The distant, hazy future (or possibly never), 2015 Q1, sdo-gozer release Apr 17, 2015

danbri closed this May 12, 2015

schemaorg/schemaorg

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

Projects

Labels

Milestone

Assignees

2 participants