Add a structure for "pros" and "conts" to be associated with a review (most typically of a reviewed product)

[danbri]

For a Review where the itemReviewed is most typically a Product, it is common for sites to use organized lists of "pros" and "cons" to show summaries the positive and negative aspects.

This is a proposal from Google to add a structure that makes this kind of data explicit. If adopted by schema.org and publishers we consider it likely that we could improve search experience by making use of such markup.

Proposal

• add a pair of properties, /positiveNotes and /negativeNotes, applicable on /Review, with /ListItem and /Text values.
• typical usage would be an order-preserving list of short sentences. Let's start with an ItemList of strings.
• Potentially could be more structured (add a WebContent node, so variants of each pro/con could be represented with different properties.
• Complex comparisons of characteristics of products could be modeled with a /PropertyValue structure, but that would be more challenging.
• Let's acknowledge that ItemList is not a work of beauty, but it is our current main structure for representing order within the graph.

Example usage (simplified, showing "PROs" only):

This example skips any description of Product, and any example of /negativeNotes.

{
  "@context": "https://schema.org",
  "@type": "Review",
  "name": "Megaphone 11 review",
  "description": "blah blah",
  "positiveNotes": 
  {
    "@type": "ItemList",
    "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "item": "Tougher and water resistant design."
    },
    {
      "@type": "ListItem",
      "position": 2,
      "item": "Cheery bright colours and solid feel."
    },
    {
      "@type": "ListItem",
      "position": 3,
      "item": "Excellent amplification."    
    }
  ]
 }
}

[danbri]

I should add, that /item doesn't currently expect /Text or other /DataType values. I was exploring ways to keep the markup minimal.

Another approach I would eventually like us to get to is using JSON-LD's native container syntax, e.g.

  "@context": [ "https://schema.org/",
    {"positiveNotes":{"@id":"schema:positiveNotes","@container": "@list"}},  
    {"negativeNotes":{"@id":"schema:negativeNotes","@container": "@list"}} ],
  
 "@type": "Review",
  "name": "Megaphone 2000 review",
  "description": "blah blah",
  
  "positiveNotes": [
      "Tougher and water resistant design.",
      "Cheery bright colours and solid feel.",
      "Excellent amplification." 
  ],
  "negativeNotes": [
      "Sticky trigger.",
      "Battery indicator hard to see in bright sunlight.",
      "Too good to be true?" 
  ]
}

[jvandriel]

I'm liking it but I am worried this potentially overlaps with product reviews that have more structured parts (aspects of which the order in most cases isn't important, and which are often created on review platforms by the people who bought the product) - In my personal experience parts/aspects (also quite common nowadays) are often summarized in the 'pros' and 'cons' lists of expert/aggregated reviews, e.g.

{
  "@context": "https://schema.org",
  "@type":"Review",
  "name":"Megaphone 2000 review",
  "reviewBody":"blah blah",
  "hasPart":
  [{
    "@type":"Review",
    "reviewAspect":"Appearance",
    "reviewBody":"Cheery bright colours and solid feel.",
    "reviewRating":
    {
      "@type":"Rating",
      "ratingValue":"4.7",
      "bestRating":"5",
      "worstRating":"1"
    }
  },{
    "@type":"Review",
    "reviewAspect":"Sound quality",
    "reviewBody":"Excellent amplification.",
    "reviewRating":
    {
      "@type":"Rating",
      "ratingValue":"4.5",
      "bestRating":"5",
      "worstRating":"1"
    }
  },{
    "@type":"Review",
    "reviewAspect":"Ease of use",
    "reviewBody":"Sticky trigger."
    "reviewRating":
    {
      "@type":"Rating",
      "ratingValue":"3.5",
      "bestRating":"5",
      "worstRating":"1"
    }
  }]
}

[DamonHD]

In principle very much in favour.

[sumutcan]

I should add, that /item doesn't currently expect /Text or other /DataType values. I was exploring ways to keep the markup minimal.

Another approach I would eventually like us to get to is using JSON-LD's native container syntax, e.g.

in principle I like the idea. Why do we care about the order of the Pros/cons though? can't we just define a positiveNote property and assert it in the annotation multiple times? are some notes more important than the others?

btw, I like @jvandriel's example. This way by just extending the Review type, we can allow definition of pros and cons for each aspect of the review. (if one of the goals is also to keep the schema simple)

[DamonHD]

1. Whatever happens, please don't break using HTML5 microdata.

2. I would assume that much of the time some items are more important or higher priority than others...

[github-actions]

This issue is being tagged as Stale due to inactivity.