Re: Markup Spread on Multiple Pages

On Wed, Oct 31, 2012 at 8:08 PM, Robert Powell <dotcomsuperstar@yahoo.com>wrote:

> If the reviews should not be nested under the product, why does the
> schema.org give the example at http://schema.org/Product with nested
> reviews? Nesting actually seems less ambiguous than relating and allows you
> to provide supplemental data on each page.
>

Either way is schema.org compliant.  I was just saying that if you're
worried about confusion over whether it's a "product" page or a "review"
page, then having the top-level item match the intent seems helpful.


>
> I could see the non nested version working for an actual review page at
> /product-name/reviews/this-blender-rocks considering the root subject of
> the page is that review but when showing multiple reviews, having multiple
> itemtype="http://schema.org/Product" is excessive.
>
> It really seems that simply tagging the root of any itemscope with a url
> itemprop is the most concise way to handle duplicate and widget like data
> on multiple pages. It basically moves the rel="canonical" tag into the
> itemscope, who cares if the the URL is a visible href. Why use itemid for
> url when you have url tag? Seems itemid should be saved for whatever ID I
> want, maybe my unique id. Maybe there should be a special canonical
> microdata tag.
>

itemid or Thing/url are effectively rel="canonical" for items, yes.


> Also, can I get an answer to this? Should I or should I not include the
> overall product rating on every page with microdata and can I have multiple
> pages with the same <div itemscope itemtype="http://schema.org/Product">
> and same value for <span itemprop="name"> or will the pages be seen as
> duplicate?
>

That's kind of a search engine / use case-specific question (iow, I'm not
sure how to answer that form a schema.org perspective)... but
canonicalizing via itemid/url across pages would certainly help parsers
understand what you mean.

-jason


>
>
> Thanks,
> -Robert
>
>
>
>
>   ------------------------------
> *From:* Jason Douglas <jasondouglas@google.com>
> *To:* Robert Powell <dotcomsuperstar@yahoo.com>
> *Cc:* "public-vocabs@w3.org" <public-vocabs@w3.org>
> *Sent:* Wednesday, October 31, 2012 4:08 PM
>
> *Subject:* Re: Markup Spread on Multiple Pages
>
> It would be less ambiguous if you put the review on the outside:
>
> <div itemscope itemtype="http://schema.org/Review>
>   <div itemprop="itemReviewed" itemscope itemtype="
> http://schema.org/Product" itemid="/product-name">
>     <span itemprop="name">product-name</span>
>   </div>
>   ... review properties...
> </div>
>
> or
>
> <div itemscope itemtype="http://schema.org/Review>
>   <div itemprop="itemReviewed" itemscope itemtype="
> http://schema.org/Product">
>     <a itemprop="url" href="/product-name">
>       <span itemprop="name">product-name</span>
>     </a>
>   </div>
>   ... review properties...
> </div>
>
> The latter example is actually why 'url' was proposed as alternative to
> 'itemid'... so that the URL didn't need to be repeated if there already was
> an anchor in the page.
>
> -jason
>
> On Wed, Oct 31, 2012 at 2:09 PM, Robert Powell <dotcomsuperstar@yahoo.com>wrote:
>
> Thanks for the feedback. Sounds like we are all on the same page, tag
> repeated data with some sort of canonical reference. It seems using the
> itemtype="url" content="/product-name" would be the correct way. Here is
> what I am going with:
>
> Every page:
> <div itemscope itemtype="http://schema.org/Product">
>     <span itemtype="url" content="/product-name"/>
>     ...
> </div>
>
> Review Pages & Widget (nested in tags above):
> <div itemprop="review" itemscope itemtype="http://schema.org/Review">
>     <span itemprop="url"content="/product-name/reviews/this-blender-is-great"/>
>     ...
> </div>
>
> Same will go for any other nestable microdata tag that supports a url
> attribute.
>
> I am still a bit worried that tagging every page with the root product
> will make the engines see every sub page as a duplicate. Hope this helps
> placement more than it hurts because it is a lot of work just to make bot
> engineers jobs easier, not to mention illegitimate scrapers! Would hate to
> start seeing penalties (even non intentional algorithmic ones) due to
> microdata implementation.
>
> -Robert
>
>
>   ------------------------------
> *From:* Jason Douglas <jasondouglas@google.com>
> *To:* Robert Powell <dotcomsuperstar@yahoo.com>
> *Cc:* "public-vocabs@w3.org" <public-vocabs@w3.org>
> *Sent:* Wednesday, October 31, 2012 11:18 AM
> *Subject:* Re: Markup Spread on Multiple Pages
>
> You can get the best of both worlds by consistently using itemid
> (microdata) or resource/about (RDFa) to point to the *one* canonical URL
> for the item (in your case /product-name, I presume).
>
> That way you can repeat information across pages for snippeting purposes
> (like say the product name in the reviews page), while still clearly
> indicating that it's the *same* product being described.
>
> -jason
>
>
> On Sun, Oct 28, 2012 at 3:20 PM, Robert Powell <dotcomsuperstar@yahoo.com>wrote:
>
> How should you handle snippets spread across multiple pages? For instance,
> if you have a product website with urls such as:
>
> /product-name
> /product-name/reviews
> /product-name/reviews/this-blender-is-amazing
> /product-name/manufacturers
> /browse
>
> Should I tag all the /product-name/* pages with the root product itemscope
> and simply expand upon nested types such as reviews on that specific page?
> If I have a reviews widget on /product-name should I provide snippets for
> the data within the widget or only markup the reviews page? Is it OK to add
> markup for the overall review score shown on every product page? Should I
> also provide snippets on the browse items lists?
>
> I have a feeling the answer to all my questions are yes, markup every page
> and be sure to provide a "url" property for each schema subject so the
> search engines know the root subject URL. I just want to confirm it and
> ensure that marking up all /product-name/* pages with the same root product
> won't cause the engines to only consider the root URL or something else not
> desirable.
>
> -Thanks for any feedback
>
>
>
>
>
>
>
>
>
>