W3C home > Mailing lists > Public > public-schemaorg@w3.org > February 2017

RE: Google Structured Data Testing Tool - improved support for multiple independent types

From: Greg Hullender <greg_hullender@hotmail.com>
Date: Fri, 3 Feb 2017 23:58:24 +0000
To: Dan Brickley <danbri@google.com>, schema.org Mailing List <public-schemaorg@w3.org>
Message-ID: <CY4PR2001MB1783E228082F674C21ADA54FE24F0@CY4PR2001MB1783.namprd20.prod.outlook.com>
Now if only there were some way to make it believe that a book with editors but no authors is an anthology, not an error.

--Greg

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: Dan Brickley<mailto:danbri@google.com>
Sent: Friday, February 3, 2017 10:33 AM
To: schema.org Mailing List<mailto:public-schemaorg@w3.org>
Subject: Google Structured Data Testing Tool - improved support for multiple independent types



A quick note to let folk here know of recent improvements to Google's Structured Data Testing Too<https://search.google.com/structured-data/testing-tool>l. Some of you have been asking for this ... for a while.  The tool now allows multiple independent types to be applied to a single entity without errors/warnings.

For example, Book and Product are defined as independent branches of the schema.org<http://schema.org> type hierarchy. And yet it is sometimes appealing to combine "book-ish" and "product-ish" properties on a single item / entity, i.e. sometimes a thing can be both at once.

e.g. like this,

{
  "@context": "http://schema.org/",
  "@type": ["Product", "Book"],
  "name": "books can be products!",
  "gtin13": "1234",
  "isbn": "5678"
}

Previously this kind of structure made the Google testing tool complain needlessly. The final part of the fix for this recently went live, so you should now see a more sensible response<https://search.google.com/structured-data/testing-tool?url=https://gist.githubusercontent.com/danbri/10bcf62cba95a0a20a30ee8a78246774/raw/45e0dde4b681963e442be44cfd1d725e7726f6c9/gistfile1.txt#url=https%3A%2F%2Fgist.githubusercontent.com%2Fdanbri%2F10bcf62cba95a0a20a30ee8a78246774%2Fraw%2F45e0dde4b681963e442be44cfd1d725e7726f6c9%2Fgistfile1.txt> to this sort of markup, which now includes a simple "/"-separated list of the types that were found. And less complaining.

Here's a Microdata example,

<div itemscope itemtype="https://schema.org/Book https://schema.org/Product">
   <span itemprop="name">books can be products!</span>
   <span itemprop="gtin13">1234</span>
   <span itemprop="isbn">5678</span>
  </div>

And RDFa 1.1,

<div vocab="https://schema.org" typeof="Product Book">
   <span property="name">books can be products!</span>
   <span property="gtin13">1234</span>
   <span property="isbn">5678</span>
</div>

As schema.org<http://schema.org>'s vocabulary has grown, the possibility to mix together pieces of complementary vocabulary like this is increasingly useful. I hope the conformance section of the schema.org<http://schema.org> site - see http://schema.org/docs/datamodel.html - makes clear that this flavour of schema.org<http://schema.org> description is very much in the spirit of the project...

cheers,

Dan

ps. only loosely related, but I was recently asked about combining RDFa and Microdata within the same section of markup. It can be done, although probably always a bad idea: https://twitter.com/danbri/status/827492508426964994

pps. this notion of multiple-types shouldn't be confused with a related situation, which is where schema.org<http://schema.org> itself says that *all* members of some type are always members of multiple supertypes. We don't do this often, but for example we say that anything which is a LocalBusiness is going to also be both an Organization and a Place. The approach I'm talking about today is about allowing anyone to mix together types when it seems sensible / appropriate, without the combination being explicitly anticipated by the schema.org<http://schema.org> project.
Received on Friday, 3 February 2017 23:59:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:12:33 UTC