New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
danbri opened this Issue Feb 4, 2015 · 8 comments

Comments

@danbri
Contributor

danbri commented 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 danbri self-assigned this Feb 4, 2015

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

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Feb 4, 2015

Contributor

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

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

danbri commented 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.

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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Apr 17, 2015

Contributor

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

Contributor

danbri commented 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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri May 12, 2015

Contributor

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!

Contributor

danbri commented 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 danbri closed this May 12, 2015

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri
Contributor

danbri commented Nov 5, 2015

@jaygray0919

This comment has been minimized.

Show comment
Hide comment
@jaygray0919

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

jaygray0919 commented 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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Nov 6, 2015

Contributor

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

Contributor

danbri commented 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

This comment has been minimized.

Show comment
Hide comment
@jaygray0919

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

jaygray0919 commented 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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Nov 6, 2015

Contributor

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.

Contributor

danbri commented 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment