Skip to content
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.

Sign up for GitHub

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

Jump to bottom

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

Open
danbri opened this issue Feb 9, 2021 · 6 comments
Open

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

danbri opened this issue Feb 9, 2021 · 6 comments
Assignees
@danbri
Labels
no-issue-activity Discuss has gone quiet. Auto-tagging to encourage people to re-engage with the issue (or close it!).

Comments

@danbri
Copy link
Contributor

danbri commented Feb 9, 2021

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 danbri self-assigned this Feb 9, 2021
@danbri
Copy link
Contributor Author

danbri commented Feb 9, 2021 •
edited

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
Copy link

jvandriel commented Feb 9, 2021 •
edited

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
Copy link

DamonHD commented Feb 9, 2021

In principle very much in favour.

@sumutcan
Copy link

sumutcan commented Feb 9, 2021

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
Copy link

DamonHD commented Feb 9, 2021 •
edited

  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
Copy link

This issue is being tagged as Stale due to inactivity.

@github-actions github-actions bot added the no-issue-activity Discuss has gone quiet. Auto-tagging to encourage people to re-engage with the issue (or close it!). label Apr 11, 2021
danbri added a commit that referenced this issue Jun 25, 2021
@danbri
Added draft for pending, addressing #2832 pro/con proposal.
4ff5a4e
@danbri danbri mentioned this issue Aug 17, 2021
Open
@alex-jansen alex-jansen mentioned this issue Aug 1, 2022
Closed
danbri added a commit that referenced this issue Aug 9, 2022
@danbri
Updated to make broadly symmetrical changes to /negativeNotes.
d5a550f 
Also we note that negativeNotes on a Product self-description are unlikely to be common.

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

@danbri danbri

Labels
no-issue-activity Discuss has gone quiet. Auto-tagging to encourage people to re-engage with the issue (or close it!).
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@danbri @sumutcan @DamonHD @jvandriel